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 » »