Does Scrum Work? Hell Yes!!! Why

This is the second post in a series (thanks Mishkin for hosting the opener) – that discusses: Why does Scrum work? Why do any of the Agile Project Management methodology work? Final part here.

Teams

At the core of any successful development project is a team. The team can either work together as a group of individuals or as a high performance team. A high performance team is one that has a track record of both delivering high quality software and meets or exceeds their iteration commitments.

Nothing can guarantee the creation of high performance teams. The best you can do is put in place the conditions that will help them form.

Characteristics of High Performance teams

From “The Wisdom of Teams” by Katzenbach and Smith (Thanks to Mishkin Berteig for introducing me to this book):

• Small number of people with complementary skills.
• Committed to a common purpose
• Have a specific and challenging performance goal.
• Committed to a common approach which
  • Requires all team members to contribute equally
  • Demands open interaction
  • Uses Fact based problem solving
  • Uses results based evaluation
  • Provides for modification and improvement over time
  • Seeks fresh input and perspectives systematically from outside the team
• Mutual Accountability.

In addition as high performance teams form they find a sense of commitment to one and other – often a sense that transcends the boundaries of work.

How does Scrum help?

Through Events Artifacts and People. Let’s examine how these elements contribute to building high performance teams.

Events

Planning

Basics: At the start of every iteration the team gets together to discuss the goals (also called Stories) with the product owner. The team breaks down the stories into tasks and estimates the size of each task.

Values supported:

• We forge a specific performance goal for the team with the participation of the entire team.
• Use fact based problem solving to break the stories down into appropriate tasks.
• Gets team members to make a public commitment (“Influence: Science and Practice” by Cialdini – Chapter 3 Commitment and Consistency)

Daily Scrum

Basics: Once a day (preferably near the start of the day) the team gets together to answer three questions: What did you yesterday? What will you today? What obstacles are in our way?

Values supported:

• Keeps individuals focused by providing a daily reminder of what’s valuable to the team. It becomes the heartbeat of the team.
• Keeps everyone on the team in touch with what other team members are doing – which helps cross pollination and also demonstrate that all team members are participating equally.
• Problems discovered are solved offline – promoting both fact based problem solving and a greater reliance on your teammates. According to Karl Weick (author of “Managing the Unexpected: Assuring High Performance in an Age of Complexity”), surfacing problems is one of the biggest issues that organizations and groups face.
• Encourages team members to talk to each other a habit which usually extends beyond the daily scrum. Result: problems are solved more quickly and a better quality of architecture evolves.
• By talking about what we intend to accomplish we’re making a form of public commitment which helps motivate us (“Influence: Science and Practice” by Cialdini – Chapter 3 Commitment and Consistency). Yes this effectively a form of social pressure.

Review and Retrospective

Basics: At the iteration end review meeting the Product Owner demonstrates the product (new features and old) in front of all the stakeholders (team members and interested outsiders). After the demo the team discusses what went well and what poorly during the iteration with the intention of improving the next one.

Values Supported:

• The demo by the product owner is a form of Results based evaluation, they get to see the value they requested working.
• Mutual Accountability: The public demo in front of the team emphasizes the fact we succeed or fail as a team not as individuals,
• In discussing how to improve, we’re engaging in fact based problem solving and it reinforces the point, that the team owns and is responsible for the process.
• Inspect and Adapt – the entire purpose of the retrospective

The final part is posted here.