Shock Therapy: Bootstrapping Hyperproductive Scrum

1. Everyone on the team will attend a Scrum Training session.
   I conduct an extremely condensed Scrum at MySpace course in about four hours, and the entire team comes together to a session. Until everyone has been trained, we won't begin our first Sprint.
2. 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 – feel free to use it:
   Engineer: "But I can't do anything in a 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.

3. 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:

1. Production Ready
1. All estimates will be exclusively in Story Points.
   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 "baa"ing like sheep 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.
2. We will use a physical Information Radiator.
   Not only do I insist on a physical Information Radiator, but I have a basic template that I use initially for all teams. 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 ) 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.
3. 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, the teams usually only needs a couple of hours. 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:
   1. Demonstrations where the Team shows the Product Owner the work they achieved and receives Story Point awards based on their accuracy.
   2. 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.
   3. 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.
   4. 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. 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.
   5. Sprint Backlog Commitment is the final act of the Planning Meeting. 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.
4. Multi-Tasking is Forbidden. Work must be in Priority Order.
   Some Engineers understand this right away. Others feel most productive or fulfilled when they have multiple projects in progress and they don't appreciate my pointing out that there is no value in incomplete work – but point it out, I do. And often. I insist and enforce that they work on cards without multi-tasking and in priority order.

1. I find the biggest, nastiest problem that the team has and solve in within a day or two of the first Planning meeting. 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.
2. Since I am the Master Scrum Master/Scrum Evangelist for the entire company, I am almost never their permanent Scrum Master for any given team. 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 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 also 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 6-12 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.
3. 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 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 "quick format" 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.