Key Impediments – Toronto

I am a big advocate of a public impediment list.  (Yes, for some of you, I am saying this again.  I think in general it bears repeating and repeating in a company.)

There is some discussion to explain skeptics WHY I recommend this. I will not attempt that discussion here (but maybe I should soon in another post … I have in the past, just search).

By the way, I recommend only ONE list of all impediments.  Some people are tempted to have several lists. One for org impediments, one for agile adoption issues, one for Blockers (things that block a story from getting done, is the usual definition), one for impediments (however they define that term).  To me, ALL these things (and more) are just different types of impediments. We we need only ONE list.  And work from the top.

In the Toronto class this week, the group identified these impediments.  They are not in any specific order.

• Poor skill Team (skill sets are weak)
• Non Formed Teams
• Source Availability Planning
• Under estimate scope by Prod Owner
• Lack of investment (don’t remember what kind of investment the person wanted)
• Lack of requirements
• No product road-map (vision)
• Scope creep
• Lack of Comms
• Final product quality was poor
• Project team over-worked
• Senior leadership commitment & mission
• No clear product owner
• Unrealistic Time/Scope commitment
• Low accountability
• Project over budget
• Lack of ownership individuals
• Business down – layoff of developers / teams
• Ownership to one person
• Technology hurdles (ie, infrastructure)
• Too Bossy, No Teamwork
• Not able to remove impediments
• Low communication
• Not doing demo (sprint fail)
• No connection between Dev & Business

Pretty good list.