Jeff's new book Scrum: The Art of Doing Twice the Work in Half the Time is coming out on September 30, 2014. I thought I'd share an excerpt from it on how the Daily Scrum came to be. Pre-order the book from Amazon, BN, iTunes, or Indiebound.
With the first Scrum team at Easel Corporation in 1993, I regularly showed them a video of the All Blacks rugby team getting ready for a game. The All Blacks, a legendary team from the small country of New Zealand, are a transcendent team. Before every game they perform the Maori warrior ceremony of the haka. The haka is a warrior dance that charges up people about to go into battle. While watching it, you can almost see the energy come out of each player and coalesce into a greater whole. With synchronized stomping and clapping and chanting—ritualized movements of cutting an enemy’s throat—you can see ordinary men transform themselves into something bigger, something greater. They’re invoking a warrior spirit that does not accept defeat or dismay.
It took a few viewings of the video, but my team of slightly-out-of-shape computer programmers eventually started to talk about how they could be that way.
So they went into the literature to find out how the best teams did it. One of the great things about software development is that the situation early on was so bad, and so much money was being wasted—billions and billions each year—that people spent a lot of time studying why, and there was data on everything.
One paper we found was an examination of a Borland Software Corporation project called Quattro Pro for Windows. For the project one million lines of software code had been created. They took thirty-one months to produce and were the output of eight people. That means each team member produced one thousand lines of code each week. That’s the fastest of any team on record. (see Jim Coplien's paper on it for details)
One of the elements of Borland team’s “secret sauce” was that they would have everyone on the team meet every single day to discuss how they were performing. Getting everyone together in a room was key, because it gave the team the opportunity to self-organize around challenges. If someone was stuck with a problem—if the accelerometer wasn’t talking to the altimeter—everyone saw that the impediment could block the whole Sprint, and they swarmed on it, making sure it got fixed pronto.
At Borland the daily meeting was an hour at least. That struck me as too long, so I looked at the core things that need to be communicated in that huddle and came up with the three questions.
And that’s how the daily meeting came to operate. We had certain rules. The meeting was held at the same time every day, and everyone had to be there. If the entire team wasn’t present, communication simply didn’t happen. And it didn’t matter what time of day the meeting took place, as long as it was at the same time every day. The point was to give the team a regular heartbeat.
The second rule was that the meeting couldn’t last more than fifteen minutes. We wanted it to be crisp, direct, and to the point. If something required further discussion, we noted it and met further after the daily meeting. The idea was to get the most actionable and valuable information in the least amount of time.
The third rule was that everyone had to actively participate. To help this happen, I said that everyone had to stand up. That way there’d be active talking and listening going on. It also would keep the meetings short.
This is the reason such a meeting is often called the Daily Standup or Daily Scrum. It doesn’t really matter what you call it. It has to be at the same time every day, with the same three questions, and last no more than fifteen minutes.
The problem that I frequently see crop up is that people have a tendency to treat the Daily Scrum as simply individual reporting. “I did this . . . I’ll do that”—then on to the next person. The more optimum approach is closer to a football huddle. A wide receiver might say, “I’m having a problem with that defensive lineman,” to which an offensive blocker might respond, “I’ll take care of that. I’ll open that line.” Or the quarterback might say, “Our running game is hitting a wall; let’s surprise them with a pass to the left.” The idea is for the team to quickly confer on how to move toward victory—i.e., complete the Sprint. Passivity is not only lazy, it actively hurts the rest of the team’s performance. Once spotted, it needs to be eliminated immediately.
I want aggressive teams—ones that come out of the daily meeting knowing the most important thing they need to accomplish that day. One person will hear another say that a task will take them a day, but another team member might know how to do it in an hour if they work together. I want teams emerging from that meeting saying things like, “Let’s nail this. Let’s do this.” The team needs to want to be great.
My standard speech to teams large and small is: “Do you really want to suck forever? Is that what your motivation is in life? Because it’s a choice, you know—you don’t have to be that way.” A team has to demand greatness from itself.
At Easel, with the first Scrum team, we implemented the Daily Scrum during the third Sprint. We’d planned out four weeks of work for that Sprint—pretty much the same workload as the previous month. We finished it all in a week. A 400-percent improvement. That first Friday the whole team just looked around at one another and said, “Wow.” That’s when I knew I might be on to something.
Pre-order Scrum:The Art of Doing Twice the Work in Half the Time from Amazon, BN, iTunes, or Indiebound.
English 
French 
Spanish