Public Impediments – Toronto March 2014

Here are the issues this group thought were important.  Many are ‘issues’ in a waterfall model.  Not necessarily in priority order. Not necessarily impediments in an Agile model.  Some are vague here (stated in few words), but I think they knew what they really meant.

1. Management apathy
2. Unclear goals
3. Too much process
4. Changing requirements
5. Insufficient people
6. Work overloaded
7. Large team
8. Redundant skillset
9. Internal compertition
10. Single out individuals
11. Late request
12. Project cancelled
13. Newly formed team
14. Distributed
15. More layers (different teams)
16. Too many scope creeps
17. Not enough executive engagement
18. Not good leadership
19. Delays from vendor
20. Not enough knowledge in team to solve issues
21. Tasks not properly assigned to team members
22. Didn’t allocate enough time for unknowns
23. Team was told what / when
24. Management and Execs painting a different picture
25. Blame / “steamrolling”
26. Forced to “report” waterfall way
27. No clear product owner

Public Impediments - Charlotte March 2014

The group came up with these impediments.

1. People issues
2. Distractions (multitasking)
3. Lack of resources
4. Arbitrary long time estimates
5. Lack of feedback
6. Black box projects
7. Dishonesty
8. Management constraints
9. Team too big or too small
10. No clear roles
11. No funding
12. Unrealistic expectations, time or $
13. Team improperly formed
14. Too many impediments (main cause of failure)
15. Inexperience (wrong skills)
16. EGO
17. Poor listening
18. Unchesiveness
19. (lack of) localization support
20. No direction
21. Stubborn people not aligned with Team
22. Budgeting not clear
23. Shareholders having diverse interests
24. Lack leadership
25. Teams not talking to associated teams
26. Lack of resources dedicated to Team
27. People turnover
28. Performance not measured - no data
29. Real product owner is not identified
30. No clear process / product owner
31. Cross-purposed stakeholders
32. Lack of stakeholder buy-in / support
33. Upstream / downstream dependencies

We hope this list helps your team get more creative about the impediments.
We are a strong advocate of a public impediment list.

Definition of Ready

Gabriel asked:

Hi Joe,

Can you recommend few good sources for "Definition of Ready" ?

***

I like Jeff Sutherland's stuff.

Did you see this?
http://scrum.jeffsutherland.com/2009/07/ready-dynamic-model-of-scrum.html

It includes an article.  Read that.

As he taught me, the DOR is flexible team by team.  Each team must decide on the details of a DOR, based on the needs of the team members, the PO, the type of product, etc.

And from their experience (what works, what doesn't).

One key thing: eliminate anything the Team  (Doers) do not use.  Do not over-document.

See also Jeff's blog on the Enabling Specification. (I also have some blog posts on this topic.)
And see my earlier post on getting to Ready.

Regards, Joe

Public Impediment List - Charleston Mar 2014

I am a big advocate of each team having a public impediment list.  Elsewhere I describe that in more detail, and some issues with it.  The key thing: the main purpose of the list is to enable us to fix the 'best' impediment faster.  We don't just have a list to assure we do NOTHING.

In the recent course in Charleston they identified these impediments.  You may or may not agree.  There may be duplicates (maybe a rough indicator of greater impact).  Maybe some are not clear to the reader, but only to the writer or that Team.  The order is random.

We hope this list makes your Team more creative in identifying its 'best' impediments.

1. Small group supporting sustaining work
2. Lack of experience (skill set)
3. Knowledge transfer
4. Automated build-test / quality
5. Requirements traceability
6. Loading radios [To test the functionality of the software in the radios]
7. Schedule tight
8. Undefined goals
9. Inexperienced people
10. Shifting priorities
11. Hiring people
12. Establishing a team
13. Unresponsive vendors (external)
14. Issue with external system not in our control
15. Moving timeline, target date
16. Lack of ownership from product owner
17. Changing scope
18. Team concept
19. Work distribution
20. Lack of knowledge
21. Inaccurate information
22. No mitigation strategy [for risks, I think]
23. Lack of buy-in
24. No planning
25. Inexperienced people
26. Insufficient client management
27. Not understanding client's true needs
28. Inadequate skills
29. Inefficiency
30. Changing personnel
31. Over-committed [given too much work, I think]
32. Don't understand process
33. Team not on same page
34. Lack of pre-plan
35. Lack of ownership [by team, I think]
36. Adequate training (lack of)
37. Weak company management
38. Failure to commit
39. Weak PM [in Scrum terms, I might say weak SM -- depends what he/she meant by PM]
40. Changing goals, moving target
41. Lack of resources, HW, SW
42. Weak IT
43. Risk mis-management
44. Failure to communicate
45. Do not understand goals
46. Lack of teamwork
47. No support
48. Time Zones
49. Change of vision
50. Org not ready for change
51. Budget
52. Scope creep
53. Unrealistic deadlines
54. Mean team members
55. Moving timetable
56. Disorganized
57. Lack of experience
58. Under budget
59. Poor stakeholder management
60. Over budget
61. Lack of leadership
62. Unavailable team members
63. Inconsistency
64. No requirements
65. Changing requirements
66. Ins budget [Insufficient budget, I think]
67. Bad estimates
68. Lack ofparticipation
69. Missed deliverables
70. Poor attitudes
71. Not enough tech knowledge
72. Poor communication
73. Product failure [one might need to identify the root causes here]
74. Non compliant
75. No gate reviews [In Scrum, each Sprint is a kind of 'gate review' -- but not sure this would be enough for the person who raised this concern]
76. Unrealistic scope
77. Lack of commit
78. Employee no shows
79. Insufficient time allotment
80. No leadership [person started with 'A lack...' and crossed that out]
81. Creeping scope
82. Change of scope
83. Team incompetent [for this work??]
84. No enough people
85. Inadequate schedule
86. Lack of planning

***
To get this list, I asked two questions, one early and one later:
1. What are the root causes of failure in most projects?
2. We need to double velocity in 6 months, and we have to change radically.  What do we have to change to get the velocity (productivity) to double?
This may explain some of the duplicates.