Most people within the Agile community seem to be firmly committed to the use of games and interactive exercises for training. I fondly remember first being introduced to the XP Game as a powerful way to demonstrate the values and principles of Agile Software development. While the use of games and play is growing in popularity, I fear that many people hit a roadblock. They frequently see games & play as limited exclusively to the “fun training” domain and don’t appreciate just how powerful it can be for actually solving problems. Indeed, the more I explore this domain, the more I realize that collaborative problem solving is their most valuable use!
So we have problems to solve, systems to build, and domains to explore. These are quite important goals, and one where Scrum is largely silent. I’m not saying that Scrum doesn’t work, so much as Scrum assumes we have this benevolent and omniscient Product Owner. The Product Owner decided what’s important, they maintain the vision of the product and they are the “Single wring-able neck”. Simultaneously a business expert, visionary, and pragmatic manager, the Product Owner is able to articulate a perfect vision of a product which is now incumbent upon our Agile team to deliver. Sure we may adjust as we start to build it out, but that will be based on the Product Owner’s wisdom and foresight. I have met only a handful of people who fit this bill. Frequently I find that the person tasked with managing the backlog for a team is a bright, capable, but very mortal person.
- There is no definitive expert
In many modern, complex business domains, no one person could hold a view of the entire problem. Chances are that if they see the whole thing, they are not in the trenches and only have an abstract view of what’s going on. Conversely, if they are on the front lines, they are so consumed by details they may not fully see larger patterns playing out over longer time horizons. Such is one of our key challenges: the act of determining “what” to build is more complex than cracking open some really smart person’s head and removing the collected wisdom within it. A further challenge is that even if you have an expert who perfectly grasps the domain, a growing body of research shows they will not be able to easily articulate that understanding to others. The very knowledge that helps us provides the expert with a context unavailable to others; something that appears patently obvious to that person may sound like Greek to others. The Heath brother’s dubbed this the “curse of knowledge“. For a good example, imagine a consummate fan of Star Wars, now put that person in a room with someone who has never seen the movies. Now imagine the awkward conversation that would ensure as the Star Wars “expert” tried to convey the key points of the movies. A dependence on an enlightened expert may simply degrade into the team being told to “do this” without really understanding what’s going on, preventing them from offering valuable feedback and being able validating what they build.
- Real Value is Derived from Interaction Between People
So if our systems are too complex for any one person to fully understand, we also don’t necessarily generate the value by simply stringing together a lot of narratives. Rather, fundamental value is derived from the interplay and increased perspective we get by having multiple people interact. One of the most powerful demonstrations of this is the “wilderness survival” exercises. The game comes in different varieties, but the general structure is this: you are stranded remotely in a forest / arctic tundra / tropical island (my favorite) and you must prioritize from a list of possible things to do which ones you would do and in what order. First set your priority as an individual, then do it as a group. After doing this, each group gets the correct answers based on wildlife survival experts. What’s most interesting is that in almost every version of this game, the group rankings are better than every single individuals decisions. The act of working together produced substantively better ideas than simply leaning on one expert or amalgamating everyone’s response. So we see that a huge part of the value discovery within analysis from a project emerges from the interplay of multiple people simultaneously playing with the same concept.
- Seeing the anatomy of something isn’t sufficient to understand it
A dinosaur fan growing up, I was recently heart-broken to find out that the triceratops never existed. Apparently, archeologists looking at the fossil record mistook what we now believe to be juvenile torosauruses to be an entirely different species. Think about that; for over 120 years – the triceratops was first documented in 1889 – we mistook a juvenile of one species for an entirely different animal because we couldn’t understand it within the context of the bigger picture. Of course, we can forgive our archeologist friends. They can only make observations of these creatures by examining their remains in a sterile environment completely separated from where they actually lived and interacted. But the question is, why would we ever want to do this with modern systems where we can touch, feel and play with them. My favorite, more business related example, is New Coke.
Inspired by internal taste tests showing people preferred the taste of the sweeter Pepsi, Coke sought to change it’s flavor in order to win blind taste tests. Of course, people don’t blindly sip soda, rather they drink a whole glass. While a majority of people preferred Pepsi’s taste for the first sip, once you drank a whole glass, more people preferred Coke (Gladwell, 2007). The way you ask your customers what they want is critically important.
Nearly 25 years later, we find ourselves continuing to face the challenge articulated by Fred Brooks, how do we know WHAT to build. Agile software development has added huge value in this domain by extolling the values of progressive elaboration, emergent design and iterative development. Still, we need somewhere to start and we need ideas to build upon. How do we maximize the value of the ideas we feed into our development teams? If our goal is to maximize ideas and generate innovations, we want an environment conducive to those points. At the risk of playing pop psychologist, let me walk you into the field of positive psychology. Barbara Fredrickson, in her pivotal paper, “What Good are Positive Emotions” observed that the bulk of research into human psychology focused on ailments and maladies. For the majority of its existence, the profession has been fixated on understanding the ways in which the human mind breaks down while neglecting what happens when we’re happy. Specifically, she identified several key benefits to people when they are experiencing positive emotions. We are all familiar with the idea of “fight or flight”, the moment of stress or fear when the human mind narrows all options down to those two and makes a split decision. We’re probably also familiar with the cliched comment that this probably was very valuable when man had to deal with the likes of saber toothed tigers.
What people frequently overlook is what happens to people when their emotions move to the other side of the spectrum. While anger and fear narrow our options, positive emotions broaden them. People in that state are more likely to experiment with new things, make more associations, and even solve problems faster! This is not to mention the massive amounts of social capital people build when playing with others, a major factor for personal and project success. It is too bad that many people in the business world continue to suffer with the bias that if people are having fun, they aren’t working hard or fast enough. Indeed, if the growing body of knowledge on human emotional states is any indicator, a high stress environment will indeed cause people to make poorly informed decisions as a rapid rate, thereby getting us bad software faster. I don’t think that is really our goal.
Innovation Games® to Answer Brooks
Earlier this month, I had the opportunity to attend Luke Hohmann’s Innovation Game® training class, and I must confess it was a bit of an epiphany for me. For those of you following this blog, you’ve probably been noticing a “serious play” theme emerging. If that didn’t do it, the fact that I’ve helped organize two Agile Games conferences may have been the tell. In spite of this personal journey, getting to use these techniques with a group of other professionals was a truly trans-formative experience for me.
One of the key take-aways for me was that serious play, like any form of analysis requires a significant amount of forethought in order to be successful. I have included a very simplified and roughly linear flow showing the progression we used as we dealt with different case studies.
The entire class was based on case studies where we would discuss an abstract problem and then figure out how we would go about solving it. I found it particularly interesting how we began the class by reading a case and jumping to the orange steps where we were discussing what type of game we would like without methodically working through understanding our problem and the question we were trying to get answered. Much like “The Hitchhiker’s Guide to the Galaxy“, we came to appreciate that the answers you get are only valuable if you know the question. (For those of you without a refined appreciation for classics such as “The Hitchhiker’s Guide to the Galaxy”, the entire first book revolves around a super intelligent race that has determined the answer to the ultimate question of life is “42”, but then they realize they don’t know what the actual question is.)
This is probably one of the big challenges in the Agile Software development field right now. With more people coming to appreciate the value of serious, collaborative play, the answer to more problems is “play a game”. However, if we haven’t planned the right game, and we don’t understand what we’re going to do with the information, that we may be wasting everyone’s time. So what type of questions could we get answered by a game? Well, let’s stick with Mr. Brook’s problem, what is the correct thing to build?
Let me offer a real example I’m going through right now, the PMI Agile Community of Practice. Within the Project Management Institute (PMI), I have worked with a number of committed volunteers to launch a virtual community – now 8,000 strong – of project managers looking to better align their craft with the values and practices espoused in the Agile Manifesto. The PMI has traditionally leveraged geographic groups, like local chapters, to interact with their members, and an entirely “virtual” community is something new for them. So what do our members want? What is value to them? How do we make sure we build out something of lasting value and don’t just replicated the various other online “communities” in this space?
In this case, the key question for me was “what do we want to do next?”. Actually, that didn’t quite cut it for me, it wasn’t until we moved to the next question that I got clarity: “what will you do with the information”. Well, we’re planning for the 2011 year, we are looking to figure out what initiatives and programs we should launch for the membership this coming year. That means, the key question we need answered is “what PROJECTS should we run within the community”, thus our rounds of play need to move us to concrete projects we can decide on.
Imagine our creative process being two funnels. First, we want to generate a lot of ideas. Part of picking the right thing, is making sure that we’re considering it in the first place. Once we have the ideas, we can craft them into concrete proposals and finally we can make a prioritization decision. At the end of this process, we should have a series of concrete proposals that we can prioritize for delivery. In order to reach this outcome, we selected 2 rounds of play. For the first round, we selected the game “Prune the Product Tree“, where people would use our proposed image of two trees growing together, one for the PMI community and one for Agile, and their job was to decorate it with apples representing the fruits they would hope to get from these trees going together. Armed with a series of ideas, we would then draft and estimate the relative size of a series of proposed initiatives the community could undertake.
In order to prioritize those decisions, we wanted to hear from as many people as possible, and we really wanted a decision that would reflect a whole. Thus, something like simple voting or a survey would not suffice. We selected the game “Buy a Feature“, where people jointly bid on the items they want to collaboratively purchase a single set of features. So there you have it, a 2-step collaborative process whereby we let our members propose ideas, organize & estimate them, and then have the membership jointly vote on complete packages to inform our priority. Now, there is one missing step that we’re not using a game to resolve. Namely the synthesis of those ideas on people’s product trees into concrete projects they can “buy”. Perhaps this will be something to explore for the next time we undertake an initiative like this. This has still been a relatively new process for me, and as we conduct the PMI Agile Member Engagement Initiative, I’m sure we’re going to have a number of lessons learned I will be happy to share at that point in time.