Thursday, January 06, 2011

Optimized Scrum: Getting to Done Done Done Done


At my last company we delivered production software to multiple large enterprises at the end of every sprint. Within two years we dominated all competitors. Our CEO said he didn't understand why we couldn't get Done (feature testing), Done (integration testing), Done (performance testing), and Done (user acceptance testing) by the end of every sprint . Only then could he collect revenue from customers.

The Scrum teams told him it was impossible and then self-organized to achieve it with the CEO aggressively removing all impediments (including management when necessary). By the time they achieved this they were benchmarked at 10 times the velocity of our outsourced Indian waterfall teams. The revenue for the company quadrupled in one year.

Why can't Scrum teams get shippable code at the end of a sprint?

The biggest problem worldwide for Scrum teams is getting shippable code at the end of every sprint. That was the goal of the first Scrum team in 1993 and they delivered it for every sprint, including the first sprint. Yet over 50% of Scrum teams cannot do this worldwide and this slows them down by somewhere between 2 and 24 times depending on the complexity of their application.

I have found a solution to this. Scrum Inc and our partner qaSignature have teamed up to offer a way to ensure that full regression testing is completed every day of the sprint so getting to done at the end of the sprint is guaranteed. We are working with a local software product company that has increased their ability to release product by a factor of 6 just using the regression testing capability. The CEO of this company will be coming to our Scrum class in Cambridge to plan for deployment of Scrum to double this initial gain to a factor of 12.

Call us about an “Optimized Scrum” course focused on implementing QA during sprints beyond unit and functionality tests, unclogging software development’s biggest bottleneck. We will discuss complete daily automated regression testing independent of application size or number of products in a portfolio.

5 comments:

@Armond_M said...

Jeff, as you point out, it requires executive management's active involvement in order to get shipable product at the end of every sprint. In my experience, very few executives have the Scrum training or the interest in removing the impediments necessary to make this happen. Until agility and lean-ness is embraced throughout the entire organization the teams' effectiveness plateaus very quickly. Executive education is the next big hurdle for Scrum.

Dion said...

What happened to the fifth Done (released to production for all users)? As you said in your talk to Google: 'Let's see if the phone rings in the next hour. That's our
demo. And if the phone didn't ring, it was a great demo.'

abdellatif said...

Interesting! (and that’s with respect to the resulting achievements)

But I have a question here. Fundamentally, the concept of discovering (going iteratively) approach should still be applied.

So, where are those (discovering) activities being done if our focus, or target, is to always produce ‘shippable working software’ at the end of every sprints? Are there some sort of iterations within each one of your sprints?

Thanks,

abdellatif said...

Interesting! (and that’s with respect to the resulting achievements).

But I have a question here. Fundamentally, the concept of discovering (going iteratively) approach should still be applied.

So, where are those (discovering) activities being done if our focus, or target, is to always produce ‘shippable working software’ at the end of every sprints? Are there some sort of iterations within each one of your sprints?

Thanks,

Jeff Sutherland said...

Innovation is a hot topic in Tokyo this week. I got the same question on a panel with Nonaka who inspired Scrum with his 1986 HBR paper.

Innovating teams take "spikes" into their sprints as timeboxed research tasks. I see silicon valley teams with 1/3 of their backlog as spikes in each sprint. This is R&D to answer questions, not produce shippable code.

For research organization like Los Alamos Laboratories or John's Hopkins Applied Physics Laboratories, 100% of their sprint backlog is often spikes.

In addition, most companies using Scrum provide special time for teams to innovate on their own. Google's 20% time for personal projects is just one example.