11 Self-organizing Teams Teaching Themselves Agile at the Same Time

In a previous post I talked about how I came to learn that I could teach Agile to lots of people at the same time. In writing that post I realized that it was a great illustration of self-organization. That realization was in the forefront of my mind as I ran the session "Hands On Agile Immersion" on March 10th at Agile and Beyond 2012 .

Although I've trained large groups of people on Agile many times over the last few years, it never occurred to me to create a video of the experience. This time, I decided to do it to illustrate large-scale self-organization in action. There were eleven separate teams with no appointed leader.

All I did was set up the learning environment, provide the materials, and give just a few instructions for each activity. The participants did all of the learning/teaching as a self-organized team on their own.

In the span of only an hour and a half, all 11 teams taught themselves the basics of 9 Agile practices as follows:

• Form cross functional, collocated teams
• Pick a software product to "build"
• Write 12 User Stories for that product
• Put the stories into a backlog ordered by business value with the help of a Product Owner
• Estimate the stories in story points using Planning Poker
• Plan a release using 2 iterations worth of stories
• Do all of the above as independent self-organized teams

The teams did self-organization so well, I was able to do capture lots of video clips of the session and only had to answer 4 or 5 questions about the mechanics during the whole 90 minutes of the session.

As always, one of the favorite things that people learned was "Planning Poker," an Agile estimation technique involving special playing cards. I told people I didn't need them back and I also gave away all of my extras. I brought 48 decks and they were all gone at the end of the session. Not even a single card was left behind!


A short video (4:10) of the session is available on YouTube .


Some folks from Macomb Community College made their own video (3:58). The "Hands on Agile Immersion" part goes from 1:25 until the end.

Agile is a Game

While attending a presentation at Agile New England last night on “Gamestorming” by Todd Lombardo I was reminded that Agile is a game. That may seem a bit uncomfortable for something that is done as a professional activity, but it is actually a very good thing from a business perspective. After all, what is a game? A game is an activity that is governed by a set of rules, has a goal, has a scorekeeping system, and is fun to do.

The Rules of the Game
Nobody really likes rules, but what is the first thing you ask when you are about to play a new game? You ask “what are the rules?” You want to make sure you understand all of the rules and that people are “playing fair.” When these two conditions are met it is a lot easier to learn how to get good at the game and have fun.

The rules in Agile are deceptively simple. They are things like "iterations should be no more than 4 weeks" and "all iterations should be shippable." Following the rules mostly involves unlearning years of what you will later realize were bad habits.

The best part of the rules in Agile is that they are so clear. Don't ask me what the rules are in traditional development. I have no idea and I played that game professionally for more than twenty years!

Winning the Game
The next question you ask when learning a game is “how do I win?” This is the goal of the game. It is important to know what the goal is so that you can work within the rules to achieve the goal.
In all of this, it is important to know how to keep score because it is usually how you know how close you are to your goal.

There are aspects of software development that make it difficult to know the actual score, which is the amount of value produced. Value is a lagging indicator which you don’t really know until after somebody has used what you have provided and given you back something in return. Most of the ways of “keeping score” within Agile, such as burn up and velocity, are really only a proxy for the real score (value produced), but they are still important to know and monitor.

The Fun of Playing
You may wonder what “fun” has to do with a professional activity. Well, I don’t know about you but if I have my choice between working in a “fun” environment or a not-fun environment, I’ll pick the fun environment every time. Another way to look at fun is “doing something that is satisfying.” I believe that most people want to gain satisfaction from their work and that usually comes from feeling that you have provided something of value that benefits others in some way. In my experience, high job satisfaction corresponds directly to personal productivity.

The game of Agile development is simple to learn and to play, at least in comparison to traditional development. As a result, it is much easier to reach the goal and provide a high degree of job satisfaction. In my book, that’s a win-win.

Cooperative Play vs Competitive Play
One last point on this subject is that Agile development is both a team game and a competitive game. It is a team game within your organization and it is a competitive game that your organization plays in the marketplace. Now, get out there and win, win, win!
Tweet

Learn the rules of the game: Boston, March 20th, Agile Whole Team Training .