Impediment List – Inhouse Course May 15

I am a strong supporter of identifying small things that we can take action on, one at a time, to get better.  In Scrum, we call this an impediment list.  This week, the class identified these impediments. I think I have ‘translated’ them correctly ….

  1. Lack of governance
  2. 0% transparency
  3. Actively disengaged team members
  4. Competing goals
  5. Adversarial sponsors
  6. Poorly understood technology
  7. Losing people mid-project
  8. Too many cooks
  9. No change management
  10. No requirements
  11. Individual contributions [not team contributions]
  12. Finger-pointing
  13. Lack of support
  14. Ill-defined teams / structure
  15. Lack of team collaboration (including vendor-client)
  16. Unrealistic estimates
  17. Exit criteria [lack of?]
  18. Too high expectations
  19. Insufficient funding
  20. Silos
  21. Changing scope without adjusting (R or T or B).
  22. Poor communication
  23. Lack of Buy-in
  24. Absences from meetings
  25. People availability
  26. Poor estimates of time
  27. Poorly defined tasks
  28. No direction
  29. No / lack of leadership
  30. No understanding of benefits
  31. Personal agendas
  32. Command and conquer
  33. Constant distractions
  34. Unrealistic expectations
  35. Business ownership / partnership
  36. Lack of communication
  37. Lack of buy-in / ownership
  38. Disengaged team
  39. Unrealistic value
  40. Skill sets [lack of]
  41. Lack of coordination
  42. Hidden assumptions
  43. Complete assumptions
  44. Just get ‘it’ done – don’t know what
  45. Unhealthy communication
  46. Confusion
  47. Lack of involvement from customer
  48. Unclear purpose
  49. Poor definition
  50. Poor team dynamics
  51. Single points of failure

There is some duplication, I think, for many reasons.  But perhaps useful in suggesting relative priorities.

A couple of key points:

  • We have a list to prioritize.  Then we can act on the most useful stuff first
  • Prioritize mainly by ‘how much it is slowing down the team’
  • Use cost-benefit analysis to some degree (maybe only intuitive)
  • Drive one to completion at a time
  • Make them small.  No bigger than one sprint.
  • Get the managers to help you (and the Team as well)
  • Show results

 

 

Facebooktwitterredditlinkedinmail

« « Velocity: What if a story is partially completed in one sprint? || “It’s not too far, it just seems like it is.” (Yogi Berra) » »

Leave a Reply

Your email address will not be published. Required fields are marked *