Thursday, December 19, 2013

Impediments – Charlotte Dec course

I am an advocate of a public impediment list.  The ScrumMaster must always be working on the top impediment. Until the Team is perfect (and it is never perfect).

And the value of that can be seen when the Team has doubled (or increased) their productivity or velocity.

The Team must be creative and aggressive in identifying all the things that can be improved.  Anything anything can be slowing the Team down.  Usually it is something slowing us down now, but it can be something Big that is likely to slow us down tomorrow.  And, again, often the Team does not mention things that they think will never change (and yet could actually change now).

In Charlotte this week, this is what the class identified:

  1. Lack of (the right) people
  2. Failure to include business (end users)
  3. No stand-up
  4. (Lack of) funding
  5. People dependencies
  6. Process dependencies
  7. Poor time management
  8. Vague / ambiguous requirements
  9. Missed milestones
  10. Lack of buy-in
  11. No leadership
  12. No management support
  13. No team commitment
  14. Poor attitude
  15. Lack of collaboration
  16. Under direction
  17. Lack of decisions
  18. Lack of understanding
  19. Squeaky wheels (getting too much attention)
  20. No compromise
  21. Defensiveness
  22. Keep moving the line in the sand
  23. Fingerpointing
  24. Unrealistic expectations
  25. People who cannot say ‘no’
  26. No ownership
  27. Unstated assumptions
  28. Poor education of process
  29. No Buy-in (dup?)
  30. Personality conflict
  31. Management or leadership changes
  32. Late delivery of artifacts by client
  33. Lack of test planning
  34. No clear vision
  35. No failover plan
  36. Direction change
  37. No ‘circular’ communication
  38. No fun
  39. Unclear on Sprint Goal
  40. Release doesn’t meet ‘minimum needs’
  41. PO and SM are same person
  42. Insufficient quality
  43. Scope creep
  44. Technical incompetency
  45. Improper user acceptance criteria
  46. Lack of correct skill sets (dup?)
  47. Turnover (team)
  48. Lack of management support (dup?)
  49. Lack of business partner support
  50. Poor or unorganized testing
  51. Market conditions
  52. Inability to make decisions
  53. Old requirements (no longer current)
  54. Multitasking (team members doing too many different things)
  55. Crap code (technical debt)
  56. Lack of career progression
  57. High defects / errors
  58. LONG Hours
  59. Impediments not removed
  60. Poor PM
  61. Collaboration (lack of)
  62. Poor or no backlog
  63. (Lack of) LOB / PO involvement
  64. No fundamental structure
  65. Not enough time
  66. Lack of people (dup?)
The question was broad, with no time constraint and not necessarily about Agile: ‘what are the root causes of project failure?’  So, some of the answers are from a waterfall viewpoint.  But I think most people can translate them to an agile context (where necessary).

Hopefully these help your team learn.

No comments: