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

Posted in: agile

Leave a Reply