Friday, July 23, 2010

Eight Strategies for Achieving the Scrum Sprint Commitment

I just finished leading an in-house Scrum Product Owner course with a group of 6 actual or future product owners. One of their most pressing issues was what to do when the team does not meet its commitment. "My Team regularly commits to 20 points, then only delivers 10. What can I do?"

We briefly discussed the alternatives of shooting, firing or otherwise punishing team members for not meeting their commitment, but quickly came to the realization that such measures are likely to be counterproductive. If the team fears the consequences of not meeting a commitment, it will be very cautious about making those commitments.

Here are eight strategies for achieving the sprint goal:

1. Yesterday's Weather

If the team finished three backlog items ("stories") for a total of 10 points in the last sprint, then that is a good place to start for the next sprint. As a product owner, only accept a commitment to 10 points. As a team, only offer to take on 10 points. If the team runs out of work, it can always go back to the product owner and ask for more.

2. Smaller Stories

The larger the backlog item, the higher the complexity and the higher the risk. By breaking the story down into smaller stories, you decrease the risk of each individual story. If 3 of 6 stories go South, the Team has a problem, if the team does not succeed on 3 of 20, it's not such a big deal.

Current recommendations suggest that a team should commit to 10 to 20 stories per sprint. For two week sprint with 6 people on the team, that means each story (backlog entry) will need, on the average, about 3 to 6 Person-days to complete.

Reminder: each story must meet the INVEST criteria and have an acceptance test associated with it.

3. Prioritize large stories higher

Even if you are aggressively breaking down stories, some will be bigger than others. It's dangerous to have big, low priority items. When the team starts the story, the sprint should be nearing its end, so the story may not fit. Get the big ones out of the way first, then do the smaller ones.

4. Defend against Scope Creep

A common problem in the sprint is discovering "new" requirements during the course of the sprint. (Product owner says, "check our requirements document, chapter 4.1.3 for the details." Chapter 4.1.3 is where the skeletons are hiding. No-one has really studied the implications of 4.1.3 and it will surely have surprises which cause the effort to rise.

I have found the following strategy to be useful: The story has precedence over the requirements doc. It represents the instructions for this sprint, which is should create a small piece of the entire product. If I stumble on a requirement which is not clearly part of the story, I report that to the product owner, who then decides what to do with the "new" requirement (in backlog or not, prioritized high or low), and I continue to implement the story as previously agreed.

How do you identify what is in the story and what not? Two components define the story: 1) its title 2) how do demonstrate it to the Product Owner at the end of the sprint. If the functionality in question is needed to make the title happen and is visible in the 'how to demo' workflow, then it is part of the story, otherwise not.

Even if title is not a correctly formatted user story, the story should be a complete sentence. For example:
  • Good: As a job hunter, I want to send my resume with my job application so that....
  • OK: Send resume with job application.
  • Much room for improvement: Attach resume.
The second component is "how to demo." This is a simple work-flow which the team will use to demonstrate the story and that they have met the requirements on the story, for instance: 1) chose a want-ad, 2) select "Apply," 3) select "Attach resume," 4), pick file from dialog 5) upload, 6) Send. At there very latest, Team and product Owner should agree on this work-flow during the Sprint Planning.

So the team is working on this story, reads chapter 4.1.3, and discovers 'E-Mails should be signed with PGP to assure authenticity." Sounds like a great, trust building requirement. Is it part of this story? No! There is nothing about digital signing, neither in the title nor in the 'how to demo'. Report this to the PO who can create and prioritize a new story, if appropriate.

5. Strict Prioritization

The backlog items are prioritized in the Product Backlog. This prioritization is carried over into the sprint backlog. A simple approach is to consider the top story 'Must have' and everything else 'Nice to have' until the top story is finished. The team members should always focus on getting the top story finished before looking at issues further down the priority list.

6. Early Acceptance

There is no rule which says the Product Owner must wait until the Sprint Review before definitively accepting a story. If the story is done after three days, then ask the product owner to accept it right away. This smooths out his workload and reduces the uncertainty on how many stories have been accepted.

7. Swarming / Pairing

Consider a team with 4 people, 4 stories each estimated at 10 days each, a 2 week sprint (10 working days), and in which each team member takes on 1 story and works on it large by himself. On the 9th day, each story is 90% done.

How many stories will be done at the end of the sprint? Hard to say. Getting stories done usually means coordinating with other people: a code review, an independent test, acceptance by the Product Owner. This can become a tremendous bottleneck and it is possible that no stories get finished, even if the work on each really was 90% done. The situation gets worse if the stories were underestimated. They don't need 10 days to finish, but 13. At the end of the sprint, nothing is finished and the burn-down chart remains unchanged.

Let us assume that this team applied Strict Prioritization and the entire team worked on one story at a time and that this did not affect the working time needed to complete the story. The first story would finish after 3 days, the second after 6, the third after 9 days. At the end of the sprint, the team has taken 30 points off the backlog. Not the 40 they had hoped, but better than the zero achieved with everybody working on their own story.

Can a team -- and in particular your team -- really apply swarming? Only one way to find out: Try it on a story or two and see how it works. More widely practiced is pairing, in which two team members work on a story together. This is almost always useful, because it stimulates knowledge sharing and prevents becoming too dependent on a single team member.

8. Throttling

The Product Owner cannot and should not tell the team to pair or swarm. But the P-O can still influence this process. Let us assume the team has 6 members. If the product owner only asks for 3 stories (sized according to the guidelines above), then the team is forced to ask themselves, 'How can we work together to solve this problem?'

I recommend this approach to teams that are just getting started, in combination with a few weeks of one week sprints. This helps them learn to do Scrum quickly and to work as a team effectively.

These strategies have worked for me. What other strategies do you use to help your team achieve its commitment at the end of each sprint?

Thursday, July 8, 2010

In Praise of the Waterfall

I have been following an interesting discussion on scrumdevelopment looking for case studies on Productivity improvements and ROI from Scrum. Roy Morien wrote:
"What I am always puzzled about is that in the history of software development, during which the Waterfall type approaches have been taken as THE way to develop systems, I have seen little, if any, real evidence of the effectiveness and efficiency of using them. I have also seen little demand for such evidence. The industry has adopted these approaches, and that's that! What I have seen is a vast amount of evidence that these approaches do NOT ensure successful outcomes."
Why was the waterfall adopted without appropriate rigor? Very simple, you don't need a statistic or a study to understand something that you already know!

This may be a surprise to some people, but waterfall was a substantial improvement compared to its predecessor - which I'll call 'unstructured chaos' for lack of a better term. Waterfall imposes constraints on the development process, so it can proceed effectively. Waterfall says:
  1. Figure out the business requirements first
  2. Don't change your requirements while you are implementing
  3. Test your code to ensure that it works
I have met a number of large companies for whom imposing this basic discipline was a tremendous improvement over unstructured chaos. So when a CTO is hesitant to give up his waterfall, it's because s/he remembers (and probably paid for) the bad old days.

Waterfall fails because these constraints are impossible to uphold over the length of an entire project. 

Scrum and XP impose these constraints at the sprint level, and introduce an additional constraint: the time-box. Seen from this perspective, Agile is surprisingly similar to waterfall!

By processing small batches and producing "finished" functionality, the performance, reliability and predictability of the system improves dramatically (the Poppendiecks taught us that).

Iteration also introduces the opportunity for frequent reflection, which turbo-charges the improvement process. Agile groups can get much better very quickly and fruits of their labor are more closely aligned with customer needs. Regular reflection also has the side effect of making work much more fun.

So let us not condemn the waterfall. It has served us well. It was developed by real people in response to real problems, who did the best they could with the knowledge that was available to them at the time. We can do better now. So a moment of silence, and let's get started with the next sprint.

Sunday, July 4, 2010

Scrum Breakfast/July: Virtual Cooperation with Social Media

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is one of the 12 Principles of the Agile M Agile Manifesto. A recurring theme in many Scrum discussion groups is that virtual meetings and web based tools are a poor substitute for a physical task boards.

Hans-Peter Korn was also convinced of this, until he took an the ScrumMaster role for the project "Basislehrgang Social Media," at the  social media akademie. Their mission was to produce the prerequisite materials for this program.

Although Hans-Peter lives in Switzerland, the Team was distributed throughout Germany. To minimize costs, it was necessary to hold all meetings virtually.

How well did these virtual encounters work? How did they maintain concentration? What tools did they use? Hans-Peter will give us an overview of his experiences and leave plenty of room for discussion on how a Scrum team can use social media to organize itself.

When: July 7, 2010
Where: SwissICT, Vulkanstrasse 120, 8048 Zürich
Time: 8.00 to 11.00, Coffee 8 to 8.30, Presentation and Discussion 8.30 to 10.00, Informal Discussion and Networking, 10.00.
Registration: Online at the SwissICT

And of course, the Lean Agile Scrum Group will meet afterward for the final planning of the Lean Agile Scrum Conference in Zürich. All interested parties are welcome!

Registration for the Lean Agile Scrum Conference Now Open

I am pleased to announce that registration for the Lean Agile Scrum Conference in Zurich is now open.

Readers of this blog know that this year's LAS Conference is focused on bridging the gap from that first Scrum/Agile project to becoming a Lean enterprise. To this end we have invited two thought leaders as our Keynote Speakers:
  • Henrik Kniberg, Swedish author of Scrum and XP from the Trenches, explores the core elements of both Agile and Lean, and how these toolboxes can be successfully combined: 'The Thinking Tool Called Agile.'
  • Mary & Tom Poppendieck, co-authors of the Lean Software Development books, questions the biggest fallacy in organizing work -- the idea that schedules or “plans” lead to predictable performance. The Tyranny of “The Plan”
Rounding out the event, we have received great tutorials and experience reports from Swiss, German, and International Speakers: Josef Scherer, Dr. Peter Kessel, Marcel Bauma, Ralf Wirdemann, Stefan Roock & Markus Andrezak, Joseph Pelrine & Adrian Honegger, Turgut Dogan & Alain Giulieri, Hans Neumaier, Urs Enzler, and Silvana Wasitov. See the conference program for details.

Lean Leadership Course

After the conference, Mary & Tom Poppendieck will hold a Lean Leadership Workshop for Managers and Thought Leaders: How to structure work in your organization to achieve much better results. Conference participants receive a 10% discount — register directly with the SwissICT.

Conference Details

Tennis Tournament Theory of Management Salaries

I just stumbled upon the prize money table at Wimbledon. The winner gets one million pounds sterling. The runner up gets 1/2 million. The 64 first round losers get £11'250 each and the 32 second round losers get £18'750 each. In total, those 96 losers earn £1.32 million. So the two finalists earn more than the 96 losers competitors in the first rounds together. Furthermore, the increase over 2009 was 17.6% for the top 16 players, but only 4.7% to 6.8% for losers of the first three rounds.


Are there any similarities to pay scales withing companies? Actually, I think I know the answer to this one. More interestingly, given that corporate pay scales do look like tennis tournament prize winnings, what effects does this have on cooperation and teamwork within the company, especially at the levels of top management or between the departments of the "Quarter-finalists"?