Friday, March 28, 2014

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

Friday, March 14, 2014

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.

Wednesday, March 12, 2014

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?

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

Wednesday, March 5, 2014

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.