Impediments: from the Charleston CSM class in September

As you may know, I think in Scrum it is key to aggressively attack impediments.

I think each Team should have a (mostly) public impediment list. The SM should be attacking the top impediment each day.  This ‘kaizen’ should lead to improvements in velocity. Every Team can get better. Always.

An impediment is anything (anything!) that is slowing the Team down (or stopping the Team).

So, I asked the Charleston class to list their top impediments. It was a diverse crowd, representing many teams and several companies.  Here are the stickies that they showed each other:

  • Deflection
  • Skill set (lack of…)
  • Identifying risks upfront (lack of…)
  • Market (changes?)
  • Interest (by the Team??)
  • Eliminating scope creep (ok, I think now they would say ‘reducing’)
  • Notification of deadlines
  • Communication
  • Hardware defective
  • Environments not ready
  • Task slippage (too much)
  • Too many items open at once
  • Not co-located
  • No project rooms
  • DBA backlog
  • Too much talking – too little action
  • Operational responsibilities
  • No staffing in critical areas
  • Lack of documentation
  • Status updates
  • No prioritization
  • Wrong product selection
  • Night job; people working day jobs fit it in when they can
  • Wrong Tech skills
  • Too aggressive a schedule
  • Not enough people
  • Customer won’t accept product
  • Unclear scope
  • Not knowing what the customer wants
  • Unclear product owner
  • Risks were not mitigated
  • Changing end goal mid project (and it didn’t make enough sense)
  • Management issues
  • Poor process
  • Poor planning
  • No project methodology
  • Market value (effort had a ‘low’….)
  • Not enough $ (for effort, per what makes business sense)
  • Lack of control – outsourcing too much
  • Morale
  • Customer participation
  • Structure
  • Poor system availability and speed
  • People constraints (eg, tech)
  • Prioritization (lack of)
  • Communication
  • Synch of environments (lack of)
  • Control of patches (lack of)
  • Improve upper mgmt focus
  • Unwilling to ask for help
  • Unknown requirement
  • Lack of Auto testing
  • Undefined goals
  • Improving the ‘owner’ (maybe the PO)
  • No accountability
  • Managing whirlwind
  • Knowledgeable subject expert not available
  • Lack of procedure
  • Lack of Scrum [I liked this one – smile]
  • Broken code
  • No installation guide
  • Incorrect estimates
  •  Indecisive “decision” makers
  • Data crash
  • Time spent on non-value added tasks

A wide variety of different things.  I recommended to them that a Team track the top 20 impediments…that was probably enough.

I hope this list suggests to you or your team that maybe there are…. one or two more ‘opportunities for increased excellence’.

Facebooktwitterredditlinkedinmail

« « Scrum is Hard! (Scrum is fun!) || What’s wrong with that impediment list? » »

Leave a Reply