Agile Programming

When Scrum is introduced to an organization, it injects the company culture with a few concepts—self-organization, transparent communication—that may be somewhat foreign. Another idea that Scrum introduces that can rattle traditional managers is consensus decision-making.

Because Scrum asks that teams self-organize, that means that they must decide among themselves how to accomplish sprint goals. Invariably, not everyone on the team will agree as to what the best route to success is. When that happens, the team must reach a decision that everyone can live with, working toward a compromise between the team’s most extreme perspectives.

Unlike authoritarian decision-making, this process can take time. Instead of a single manager dictating a decision, the team must take into account a wider range of ideas and opinions and negotiate a middle ground that best addresses the problem. By considering so many points of view, the team is essentially consulting a wider range of knowledge and experience than a single decision-maker possibly could. It’s a process that certainly takes longer, which has led to some criticizing consensus-based decision-making as inefficient. But in reality, this approach yields decisions that are better informed and, consequently, drive results.

Posted: October 13th, 2008 under Scrum.
Comments: none

I recently read about an exercise that agile pioneer Boris Gloger created to illustrate how process flow in Scrum works. I haven’t had a chance to play it with my team yet, but it’s clear from reading about it that captures the basics of Scrum in a fun, memorable group activity.

To play, you’ll need as many as 20 balls (Boris recommends using tennis balls) and for your team to form a circle in an open area. The objective is for every person on the team to touch the ball once and to pass as many balls among the team as possible. The rules are: Every member of the team must touch the ball at least once.

1. Each ball must have “air” time.
2. Balls cannot be passed to neighboring team members.
3. Each ball must end with the team member with whom it began.
4. The entire process is time-boxed at two minutes and repeated a total of five times.

As you can imagine, it’s very difficult to pass even a single tennis ball among the team the first time. However, the team gets to see that, over the course of playing the game just five times, its performance improves greatly—and becomes more fun. It is recommended that the team debrief for 10 minutes after the five iterations to discuss what they observed. Usually, the team will note that its velocity improved with each iteration. It’s a simple game, which doubles as a great team-building exercise, but it captures how Scrum’s iterative development can lead teams to perform more efficiently than they thought possible.

Posted: October 13th, 2008 under Scrum.
Comments: none