While he was updating his paper for Scrum "Shock Therapy," Scott Downey of Rapid Scrum found one of the original emails he wrote about how he boosted dozens of teams into hyper productivity. He comments below and the full paper was published as:
J. Sutherland, S. Downey, and B. Granvik, "Shock Therapy: A Bootstrap for a Hyper-Productive Scrum" in Agile 2009, Chicago, 2009.
Jeff will be at Agile 2012 in Dallas and talking about hyperproductivity at 9:30 on Thursday, 16 August.
- A minimum of 240% increase in Velocity
- They have completed three consecutively successful Sprints
- They have identified a good business reason to begin changing rules
My initial rules are roughly these:
Everyone on the team will attend a Scrum Training session.
I conduct an extremely condensed Introduction to Scrum course and the entire team comes together for a single session. Until everyone has been trained, we won't begin our first Sprint.
Sprints will be one week long.
I justify this by pointing out that there is a reason geneticists study mutations in Fruit Flies instead of Elephants – they want to see the mutations quickly and adapt their studies accordingly. So do I. Teams generally hate this part as much or more than anything else I require of them but I have been able to coax every team into giving me at least four, one-week Sprints as a trial. Here's a favorite exchange of mine that almost always comes up:
Engineer: "But I can't do anything in one week!"
Scott: "Then simple math suggests that you can only do four nothings in a month."
Interestingly, by the time the teams have met the three criteria for changing this rule, only one so far has ever elected to change it.
They will start out by using my definition of "Done".
This is often one of the thorniest issues to iron out with a team, so I take it off the table until they have some shared success as a foundation. My initial definition of "Done" is this:
- Feature Complete
- Code Complete
- No known defects
- Approved by the Product Owner
- Production Ready
All estimates will be exclusively in Story Points.
Regardless of the Scrum model you will eventually follow, Story Points are a key part. Some authors recommend using Story Points only for the Product Backlog estimation but require that you shift to hours-based estimates when building the Sprint Backlog. Personally, having learned that hours-based estimates are wrong by a factor of 50% or more, I never want such an inaccurate and easily abused unit in my metrics.
But my reasoning goes further.
Since you must learn to use Story Points eventually – if only for the Product Backlog – it stands to reason that the more practice you get, the faster you learn. So by constraining all votes and estimates to the Story Point scale, teams quickly learn to use this new mechanism for quickly categorizing work.
Again, this one is sometimes met with a ceremonial rolling of the eyes but – so far, anyway – they have all eventually come around to this. It's usually at about week three when I can intentionally spark a debate over whether a card is a 3 or a 5, then have the pleasure of pointing out to them the passion with which they are debating these recently-meaningless values.
I also make a point of shouting "BA!" whenever they all vote the same value for a given card. My intent is to show them how often they actually agree in their vote. As the mood on the team lightens up, some teams begin scanning the other votes and cheering themselves when that happens. Only one has returned my "Ba!" with a "Humbug!" In any event, they all start having fun with it and that's important.
We will use a physical Information Radiator.
Not only do I insist on a physical Information Radiator but I also stop all use of any project management software and backlog management tools. I want my teams to get a physical, tactile experience out of the boot-up process so that – even if the cards happen to become electronic later – they can still feel and picture the flow of what is happening.
I have a basic template that I use initially for all teams. It includes four columns that are drawn to be the exact width of the User Story cards we use (to prevent creating rows of cards in a single swim lane). The columns are “Product Backlog”, “Sprint Backlog”, “In Progress” and “Done.” This is usually met with complaints that the board doesn’t allow the Team to represent enough “states” (Design, Coding, Code Complete, Testing, Test Complete, Bug Fix, etc.).
This is the perfect chance to educate the Team about the true purpose of the Board as an Information Radiator to non-Team members. It is there to reflect what the Team knows about a card. It is not a communication tool between Team members, so any states that are meaningless to external observers are not appropriate on the board.
I choose the location of the Scrum Board unilaterally and use it as the focus of the Daily Stand-Up Meeting. When the team is first formed, I let them focus on the interaction with their teammates (the three Achievement questions, plus my Fourth Question described in Scrum Metrics for Hyper Productive Teams paper from Agile 2010) and I move their cards across the Radiator's surface myself.
Within a couple of weeks, they start moving cards themselves without having been asked. This is usually my first indication that I can begin slowly stepping back and relaxing my demands.
Sprint Planning Meetings will be four hours, once per week.
The first complaint of most Engineers is that they perceive Scrum imposing a highly disruptive schedule on them, with more meetings than they somehow think they have ever had before. To minimize this common concern, I consolidate everything but the Daily Stand-Up meetings into a single, four-hour meeting.
Within a few weeks, most Teams only need a couple of hours to achieve it all. And by the end of about eight Sprints together, the meetings are becoming ninety minutes or less in duration for a one week Sprint.
My initial agenda is as follows:
Demonstrations, where the Team shows the Product Owner the work they achieved and receives Story Point awards based on their accuracy.
The Retrospective comes next, aided by a host of metrics that I track. I only track whole-team metrics, never individual metrics. Initially, though I publish many metrics, I only focus on Velocity, Burndown, Work Capacity and Commitment Accuracy.
Product Backlog Presentation follows, during which the Product Owner discusses the content of the Backlog at that point in time. The Team is free to question motives, suggest alternatives and add requirements at this point. I reject any improperly formed User Stories on behalf of the team but always strive to meet with the Product Owner ahead of this meeting, review their work and give them a chance to correct the mistakes before the meeting is called to order.
Estimation and Negotiation signals that the meeting is nearly complete. They happen in a single motion with my new teams, though more mature teams eventually choose to split these activities into unique meetings. The Product Owner participates in an advisory role only during this phase of the meeting but never votes or tries to influence the estimates.
I spend most of my time in this phase trying to keep the teams from unnecessarily breaking Story Cards down into task sequences, which some tend to do. The INVEST mnemonic is really handy here. As soon as a card passes all six INVEST checks, we stop breaking it down, estimate it and get to work.
Sprint Backlog Commitment is the final act of this Ubermeeting. In the first few Sprints, I literally read aloud what "Commit" does and does not mean so that there is no doubt in anyone's mind. Once the team commits to the work, the meeting adjourns.
During the Sprint, Multi-Tasking is Forbidden. Work must be in addressed and completed in Priority Order.
Some Engineers understand this right away. Others feel most productive or fulfilled when they have multiple projects in progress. They don't appreciate my pointing out that there is no value in incomplete work – but point it out, I do. Often.
I insist and enforce that they work on cards without multi-tasking and in priority order. Sometimes this leads to petulant protests with people sitting idle but they’re doing less damage in that mode than with their hands in nine projects, none of which will be done.
I also have standard layouts that I use for their initial Sprint Planning Boards, User Stories, Story Cards, Burndown Charts and Velocity tracking.
As I said in the beginning, I do try to get all of this done with a friendly smile and a "please" but generally have to insist -- sometimes quite forcefully -- to get all of them moving. Although the beginning is rocky, we usually start laughing and having fun in the meetings within a week. And as they become more focused on and competent with Scrum, I quickly relax my grip on some of the rules and let them redesign their environment to their own liking – so long as they continue to respect the principles of Scrum. It is always my goal to step out of the spotlight, turn control back over to the Team and become an advisor whose participation is not required for the Team to succeed.
Three key reasons that I believe I am successful with this approach are:
- I find the biggest, nastiest problem that the team has and solve in within a day or two of the first Planning meeting if at all possible. Some teams quickly volunteer this problem to me in their first Retrospective while others require observation, careful listening and behind-the-scenes reconnaissance to tease it out. Especially for those teams who haven't worked directly with me yet, having that very large problem go away underscores that they are important to me, that I take them seriously and that I am working hard to make their world a better place.
- Since I am the head of Agile Practice for the entire company, I am never a new Team’s permanent Scrum Master. This gives me the freedom to create a bit (but only a very small amount) of "Us vs. Him" atmosphere at first. It causes the team to bond in what is often an entirely new way than they have before, and also sets up their permanent Scrum Master to be the "good cop" down the road. It allows me to be more firm about standing during Stand-Up, keeping your estimates private until the vote is called during estimation, etc. Keeping in mind that I generally have to bow out and move on to another team after just a few weeks, by which point they are functioning very well and are (on average) around the 500% mark, most teams tolerate this very well and learn good habits more quickly – even if it does leave me feeling a bit a schoolmarm.
- I think Socrates was on to something. When I see something going wrong – say, someone sitting during the Daily Stand-Up – I don't always address the transgressor directly. Instead, sometimes I stop the meeting and ask the team, "Team, do any of you see something going wrong with our meeting right now?" Ironically, it is almost always the most skeptical or resistant person who is the first to correct the insolently perched teammate. Soon, they start calling one another on leaning or sitting long before I stop the meeting and ask what's going wrong. It helps them begin to police themselves so that I don't always have to be around to elicit good behavior.
This is roughly how I have driven teams into hyper-productivity in as few as four weeks, and why one of my co-workers calls me "The Scrum Whisperer." I have one team that has achieved 1,650% higher targeted value contribution per week after just four months (16 Sprints) together. We are pretty proud of those numbers.
I've also noticed that teams using this immersive training approach tend to hit their Velocity elbow much sooner, giving Product Owners a greater and more stable view of the roadmap than teams who use longer Sprints or spend their inaugural period hashing out where they want their Scrum Board to be located.
It's a fairly large culture shock for most teams and doesn't yield a lot of friendly lunch invitations at first. But, per feedback from my VP of Engineering, they only “…hate [me] for about 2-3weeks. Then they're indifferent to [me] for another few weeks. Then they scream bloody murder if [he tries] to take [me] away from them."
I do stay in touch with teams that I've kick-started like this and, with one notable exception, they have all continued their trend of improvements in my absence, which was always my goal.
I hope you'll find some of this helpful as you try to slingshot your teams into optimum Scrum performance.
Scott Downey
Owner, RapidScrum.com
Scott@RapidScrum.com
English 
French 
Spanish