Impediments – Charlotte in-house course

These impediments were identified (some I think are redundant).  Note that some are expressed in quite a different way (eg, some negative, some positive). Dups may indicate that an issue is very important.

1. Legacy Code impacts
2. Allocate the correct people to the team
3. Address Env Issues
4. Define scope / business ask (better)
5. Multiple decision makers
6. Need more clarity on current state requirements
7. Lessen the amount of requirements for MVP
8. Empower them to make project choice decisions
9. What is MVP?
10. External influences
11. Failing to ask customer what they want
12. Defects
13. Communication
14. Ensure understanding
15. Team building
16. Clean up technical debt
17. Implement automated unit testing
18. Setup collocated team
19. Reduce env. setup time
20. Reduce approval wait time
21. Environment Management improvement
22. Documentation of hack fixes or work-arounds (technical debt)
23. Clear architectural picture of systems & apps & what impacts what
24. Bad requirements
25. Moved too fast
26. Under-estimating story
27. Waterfall mind
28. Poor planning
29. Lack of people
30. Need an account with every possible type of purchase history scenario
31. Need dedicated team
32. Waterfall mindset
33. Tech Debt
34. Missed requirements
35. No coffee
36. Team interruptions
37. No collaboration
38. Poor processes
39. Working as a Team.of.One
40. Document priority list
41. Get team working together on same project
42. Fix technical debt
43. Role clarification
44. No scope definition
45. Infrastructure
46. Less confidence
47. Team members boxed into projects
48. Wrong skill-set in Team
49. Too big
50. Remove resource sharing
51. Move resource to area
52. Unknown technology
53. Lack of resources
54. Not working together
55. No business direction
56. Fix environment
57. Changing direction
58. Silos
59. Scope creep
60. Changing teams
61. Lack of communication
62. Environments
63. Poor testing
64. Wrong stakeholders
65. Date of deployment changed
66. People allocation
67. Too many organizational changes
68. Lack of product knowledge
69. Poor upfront planning
70. Extended testing duration
71. Poor performing team
72. More defined scope
73. Dedicated team members
74. Organize a team (define key roles within the team)
75. Do Scrum right (daily scrum, retrospective, length of sprint)
76. Dependencies on other releases
77. Have a scrum master assigned
78. Have a dedicated team!
79. Have a daily standup
80. Have a sprintly retrospective
81. Communication from offshore team
82. Competing priorities
83. Lack of process knowledge
84. Unclear requirements
85. Lack of funding
86. Lack of understanding of team goal
87. Get all stakeholders on the same team
88. Remove dependencies from other teams
89. Internal politics
90. No sponsorship
91. Improve communication with team in Chicago
92. Team members not focused only on our team / project
93. Ability to release (lack of)
94. Code integration practices
95. Reduce environments (number of)

How many impediments should a team have on the list?  Well, it is important to identify the biggest thing to work on, and in that way, a list can help.  But after the top 20, does a longer list help?  Probably not.

If you have a group of teams, how many impediments should we have?  Well, in reality, we have 900+ impediments because nothing we do is perfect.  So, all 900 things might be improved.  But, again, realistically, with 4 scrum teams, a manager of that group might find a list of 15 helpful, but probably not more than that.

 

 

« « Joe’s real agile contract || Open Agile Adoption » »