Impediments – Charlotte December 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).

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 things that can be improved.  Anything can be slowing the Team down.  Usually it is something slowing us down now, but something Big is likely to slow us down tomorrow.  Often the Team does not mention things they think will never change ( 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. Finger pointing
  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 fail over 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?’  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.



« « Agile Contracts || A song for the season » »


Leave a Reply