Trouble in Scrum City

Disclaimer: This is not a critique of Scrum.

Instead of designing a thing, we need to design a way of doing, and this way of doing must make some choices now but leave other choices to a later time.
– Guy Steele, 1998 ACM OOPSLA keynote, “Growing a Language” (video)

If you’ve attended many Agile conferences and/or user group meetings, then you’ve probably played or heard of a game designed to teach the elements of Scrum by having participants iteratively design and build a city, following the Scrum model as they work. The game is widely used in the Agile community in training classes, workshops, client events, and so forth.

Many variants exist, but they are all based on the same basic principles. Here are a few of the numerous descriptions of the game you can find online:

• Lego4Scrum
• TasyCupcakes
• Agile42

I have played, observed, and facilitated this game many times. Invariably, people have fun with it. Sometimes, they learn a little bit about Scrum, even if not much about Agile.

Iterative Process, Waterfall Thinking

In just about every case I’ve seen, the facilitators of the Scrum City game predefine what a city is before game play even begins. The solution is implanted in participants’ minds ahead of time.

Whether you want to use Scrum in particular as a tool, and whether you want to give “design a way of doing” a special name such as “agile,” the assumption that the solution is known in advance and all we have to do is decompose it into Backlog Items runs contrary to the direction of business and the needs of society in the present era.

Take a look at the LeadingAgile Journey and try to visualize your organization operating effectively at, say, a Basecamp 4 or 5 level if all your staff knows how to do is burn down a Product Backlog populated by predefined “features.” Good luck getting past Basecamp 2 with that mindset.

The problem isn’t inherent in the Scrum Game. The problem lies in the way nearly every Agile consultant in the world presents the game. They talk too much before the game starts. They describe in detail the elements they think a city must include. They pre-load the minds of participants with the 19th century romantic vision of the Shining City on the Hill…a model that has not meet the needs of humanity and that is starting to come apart at the seams all around us.

I understand the point of the game is to teach Scrum and not to design an actual city. Still, if we believe we are showing people how to function effectively in the future, shouldn’t we encourage them to think accordingly?

A Beautiful Plan

In the case of a real design problem, even our conviction that there is such a thing as fit to be achieved is curiously flimsy and insubstantial. We are searching for some kind of harmony between two intangibles: a form which we have not yet designed, and a context which we cannot properly describe.
– Christopher Alexander, Notes on the Synthesis of Form, 1964. (pdf)

Planned cities like Brasilia and planned suburbs like Levittown have proven to be ill-suited to occupation by humans. They look good on paper. They are elegantly designed. They don’t work.

In wealthy locales like Hong Kong and in less affluent ones like Nairobi, real people living real lives re-shape their environments in ways urban planners cannot anticipate. Neither form nor context can be planned in detail in advance.

Some planned cities have fared well, but not because their original plans worked the way their designers envisioned. Washington, DC started life as a planned “federal city” built on reclaimed swampland. But the planned part of the city would never survive without the surrounding areas of Maryland and Virginia, which were not explicitly designed. Even with the careful planning and the surrounding affluence, the city still has substantial poor areas that arose spontaneously.

This is not a new pattern. For example, the ancient city of Teotihuacan is thought to have been planned (there are no surviving written records to tell us for sure). As a center of government, religion, and commerce, it attracted many people from surrounding areas, who built shantytowns all around the perimeter within walking distance of their places of employment in the city. Eventually, the system collapsed and the city was burned and abandoned around 600 AD, probably by its own poorer residents.

Archaeologists have determined the well-known site, Angkor Wat, was once the planned center of a sprawling, densely-populated city that grew up dynamically to meet the needs of the people who lived there. Ultimately, nothing remains except the temple complex struggling against the jungle.

Notwithstanding all the lessons of history available to us, we continue to chase the dream of the Shining City. The ambitious Masdar City initiative in Abu Dhabi may the the most dramatic example, but it is not the only example. Those are meant to be practical; there are also visionary concepts for cities that can be breathtaking, but may not actually be livable. It remains to be seen whether these planned cities will prove out.

So What?

So, when we’re showing people methods and techniques and tools to help them address contemporary needs in a flexible, dynamic, effective way, doesn’t it make sense to help them approach problems in a similarly flexible, dynamic, and effective way?

We don’t need to re-build the past over and over again. We’ve been there and done that. We need to build the future. The game teaches a method that can be used to do that. Remember Wikispeed?

Instead of dictating the elements the Lego® City must contain, why not let the workshop participants imagine, brainstorm, and iterate through ideas for living and working spaces that people can adapt as their needs evolve? After all, isn’t that what we’d like them to do on the job, when they’re iteratively developing software to meet people’s ever-changing needs?

As far as teaching Scrum is concerned, the players would be constantly revisiting and refining their Backlog, constantly questioning their ideas, constantly refreshing their thinking, constantly collaborating, constantly “refactoring” their designs. It would be a far more dynamic experience than just burning down a Backlog of 19th century city “features,” and much closer to an “agile” software development process.

It would be a completely different experience from the sort of “mechanical” Scrum that we see all too often in organizations that paste contemporary methods on top of obsolete thinking. It might even help people break free of old habits of mind for problem-solving.

Isn’t that better?