Scrum as a Teenager: A Retrospective from Jeff Sutherland

Getting to Done

This post is a summary of Jeff Sutherland's presentation to the DC Scrum Users Group, 21 May 2015.
The slide deck is available at Jeff's company's website.
The entire presentation can be seen on the DC Scrum Users Group Meetup site which may require you to join the group, as well you should if you are in the DC area and interested in Scrum.

Reminder: the goal of Scrum is to produce working software at the end of each sprint.

The Agile Manifesto did not spring from the blue.  The group drew its conclusions from over 20 years' of data compiled by Bell Laboratories. Those records showed conclusively that:

• Communications drive production effectiveness
• Specialization cripples production

Quite aside from the speed aspect, the data also showed  (and current data continues to show) that a bug (or failed test) that escapes from a sprint costs 24x the original development effort and time to find it and fix it.  Keep track of these events is important: in his experience, as soon as management get hard data on it, the problem of whether software needs to work at the end of a sprint is dealt with immediately.

Jeff provided references to a second data source (the Chaos Manifesto) which found that the long-standing problem with delivery of IT projects documented by the  Standish Group over the years has not changed much for Scrum-managed projects.

He also noted that for small projects, waterfall is just about as effective as Agile, probably because the timing and scope don't offer much risk anyway.

What are the blockers to success with Agile?  Success being defined as ready and done.

• Teams trying to drive features out at maximum velocity are buried in technical debt.  You can't dig your way out of that hole with continuous improvement efforts later on.
• There is organizational debt.  This is what Kik Piney calls "anti-maturity"; you can learn more about it in this post. 
• Organizations are stuck in "old way" thinking: press the developers harder, and compile more reports.

How bad is it?  At Microsoft, as much as 85% of the effort is classified as "non-tool" (a euphemism for "rework").  But at least they have recognized it and are doing something about it.  Something quite scary-sounding, in fact: they are abolishing all testing outside the main sprints. [Audience gasps]. At Nokia, the company's Agile process got so bureaucratic they were completely unable to react to the invention of the smartphone.  Ironically, Microsoft returns to the story - it bought Nokia and killed off the company.

Some bad news for those consultants who have gone in on the credential mania: Silicon Valley is now divesting itself of Agile Coaches, replacing them with internal assets because they already understand how the company actually works and they can be held accountable to deliver working software.

One of the big new topics is Agile at  Scale.  The consensus seems to be that it does not work.  That isn't really true.  Consider the Internet itself, the world's largest and longest Agile effort! Scaling Agile and Scrum, like the one-project versions, depends heavily on competence for success. It is best done by scaling out, not up, though coordination rather than developing policies.  Consider the 24-hour car-building project.

So why are we not getting to done?

• Done is not well-defined.  Done must include "working".  Product owners are sometimes pressured to accept work that is not truly done in order to maintain an appearance of "no problems".  That's not the point of Agile. Accepting incomplete work also provides a distorted view of velocity (well, that is rather the point, isn't it) that just makes subsequent estimates even worse.
• Stories are not ready.  Estimates are bad; stories are not broken down to minimal bites.  Failing to understand true velocity causes the team to take on too much work, and then they just start shaving the work even more. 
• Dysfunctional leadership.  Often, they can't stick with their priorities long enough to get through a sprint.  Worse, when things run into issues, they are willing to paper over it to provide the illusion of velocity for reporting purposes.
• Technical debt (already discussed)
• Organizational debt (already mentioned)
• Last but not least, bad Agile Coaching.

What can we do about it?

• Use a defined Scrum model. That would include the definition of done.  If effectively defined, it may not be necessary to test every feature on every build or sprint.
• Have stories ready.  They need to be defined effectively, and trying to get it all done in a few Spring Planning meeting hours is simply not possible.  So you have to front-load that effort.
• Major shifts in the corporate supporting processes.
• Establish goals and work to them
• Establish a viable business plans before starting development
• Remove barriers and wastes
• Hold the Product Owner accountable for the value delivered per story point
• Hold the Scrum Master accountable for ... well, that is the key question.
• Eliminate Technical Debt.
• Identify and fix blocks
• Use cross-functional feature teams
• Train and hire "T-shaped people" - people with the ability to contribute in several areas (wide) and solid skills in one or more particular areas (deep).
• Build out an object-oriented architecture to permit re-use
• Monitor the value streams
• Queues
• Wait status
• Other metrics

This summary didn't capture all of the nuances - many of the pearls are in the one-liners!  See the live presentation, you will enjoy it.