Why not?

July 5, 2018

Rijon Erickson (sounds like “Ryan”) has an excellent post in LinkedIn.

See here:  https://www.linkedin.com/in/rijonerickson/detail/recent-activity/

His (currently) latest posts asks for a DOR (definition of ready) and then a DOD (definition of done) (visually, he uses post-its).  The next post-it says “Simple (but) Not Easy”.

To me, he is saying: We should be able to use the DOR and DOD to get more working software delivered by the end of the Sprint.  And yet, even though these concepts and this possibility if out there, it is not happening.

My next question: Why the hell not?

Well, first, from what I can see, this is not a universal problem, but it is a very common problem.

But, again, why not?  Why is this not happening almost universally?

The reason I say it that way is that these ideas are so basic to Scrum.  Anyone should be able to do these basics.  (I understand that if my children (not almost adults) say “Dad, that’s basic” it is a type of insult.  I am not trying to insult anyone.)

Scrum overall is hard, apparently, based on what we see.  But why should this (what you have in his picture) be hard?

Here are some root causes that I proposed based on my experiences and the many questions and comments in my classes.

  1. Do not understand Scrum well enough.  This seems to be common.
  2. Do not have enough of the skill sets to get to working product in 2 weeks (one sprint).  (If software, see XP.)
  3. Stories not small enough (yet).
  4. Do not have enough resources (eg, infrastructure in some sense) to get to working product in 2 weeks.  Or the resources do not work well enough.
  5. Over-committing. (And therefore getting nothing done.)
  6. Business side or customers will not define the features well enough.  PO cannot get them to change (enough).
  7. PO and Team have not defined DOR well enough.
  8. Insufficient understanding of the “single-piece continuous flow” concept.
  9. Too many dependencies on people outside the Team. And these impediments not worked well enough.
  10. Insufficient transparency that not delivering enough working product each sprint is a problem.  Eg, Team does not track their velocity. See also #1 above.

There are others.  That’s a good start.

Do you feel other root causes should be in the Top 10?  Please tell us.  (I am expecting you will identify some others. I am fairly confident this list could be improved.)

 

« « Waterfall is done. Where is the debate now? || Velocity: Some preliminaries » »

Posted in: Better Agile, Key problems
Tagged:

Leave a Reply