The agile values and practices we all hold dear give us more than the ability to tackle problems associated with software development. They give us the ability to tackle Awesome Superproblems. These are problems that are bigger than an one person and get worse through inaction. However, when we make progress on solving Awesome Superproblems we find that new patterns that can be applied to solve classes of similar problems.
In this keynote Luke will show the collaborative, social, and serious games that have their roots in the Agile Community have blossomed into multidimensional frameworks that are being used by agilists around the world to solve awesome superproblems. Without any special superpowers except a willingness to try.
Luke is the Founder and CEO of Conteneo, Inc. Conteneo 's collaborative frameworks and data analytics helps enterprises optimize decision making. They span areas of strategy, innovation, business agility and market research. Luke is also co-founder of Every Voice Engaged Foundation, a 501(c)(3) nonprofit that helps citizens and governments tackle technical and wicked social problems.
Speaker 1: I would love to introduce Luke Hohmann, and I hope you all enjoy.
Luke Hohmann: All right. Good morning everyone. Thank you, for coming. In 2009, I found myself on an American Airlines flight. That's not uncommon. I'm a permanent platinum guy. I'm in the exit row, and I'm sitting next to a wonderful person, Kim Walesh. We start talking, and she starts talking about what she's doing with the city of San Jose, and helping it grow, but this is 2009, and the city is still dealing with the aftermaths, of all of us, as we all were, of the recession. Of course, I'm talking to her about innovation games, because that's what I do. I carry a book on the plane. She starts talking about some of the problems that she's having with the city. What I'm gonna try and do is take you into what happened, in a fraction of a second.
Think of "Bullet Time". Kim said, because I was telling her about the work that we do with helping corporations, and agile teams, prioritize backlogs, and features, and understand their customers. Kim said, "City had a 100 million dollar budget deficit". I first thought, "WTF?" Then I thought, "OMG". I can do both, because I'm from California. I thought to myself, wait a minute, we know how to ... Okay, I gotta slow down on my clicks. We know how to prioritize features, and backlogs, and epics, and technical debt. We do this all the time. We can help prioritize the city budget. We can help.
In that fraction of a second, I said, "Kim, we can help". Then the moment the words left my mouth, I went, "Oh my god", because we kind of don't know how to do this. I mean, think about it. We're all worried about our backlogs, and the city's worried about 100 million dollars. Hmm. Kim said, "Thank you for the help, don't worry about it, Mayor Reed believes in community input. Every year, he runs a community based budgeting process". I'm thinking, "Wow, I'm an agilist, customer collaboration over contract negotiation. This makes me super happy". I told Kim, "This is great. This is what we believe in, in the agile community. You're collaborating with your customers, with your citizens. This is great. I want to go." And so, Kim says, come.
This is the best photo I have from the session. The flight was in 2009, and this is January, 2010. You can see Kim, if you look hard there, and there I am, and we're kind of walking around. What they did, was they had bunch of PowerPoint, and the city talked, and the mayor talked, and the city manager talked, and then they handed out to the residents, a roll of nickles, because they were talking about five budget priorities. They said to the residents, "Go ahead and put your nickles in to five glass jars, about what you want the city to prioritize for you".
I'm thinking, this doesn't look very collaborative. In fact, this was a survey. Surveys suck! Especially, when you're dealing with a hard problem, and you need to talk about it, and you need to collaborate. After the event, Kim said, "What did you think?" I said, "How about we actually make this a collaborative experience? Let's do that".
To have a collaborative experience, it's different than a survey, and it's different than other forms of interaction, or meetings, with often suck too. To have a collaborative experience, you need a goal. You need a field of play, and you need resources for the participants, but participants need to know how to interact with each other, so you need a set of rules, and a way to keep score.
Finally, the most important part of this experience is that you have to have voluntary interaction. Are you guys just advancing me? Because I'm not. You have to have voluntary interaction. It turns out that these qualities that make collaboration effective are the same qualities that are in a game. If look at games from a game theory perspective, those qualities of a goal, and a field of play, and rules, and resources, and involuntary participation, those are what make a game.
There's lots of different games to play. Some people do like to run around a field, out in the open, kicking a ball around, and not using their hands. Other people like to take a little ball, put it on the ground, hit it with stick. I attempt to make words out of seven letters randomly chosen from a bag, with my wife, quite frequently. I usually get my butt kicked. Yes, indeed, last week, I did pick up the "Q" on my last turn. Seriously.
We look at games, and we look at game theory, and we can do more because a serious game is merely a game that is designed for a primary purpose other than entertainment. That means that games, themselves, are the ideal collaboration tool, because if you look at the qualities of a game, and you look at what we're trying to do when we're collaborating, we want to achieve a goal. We want to know how to work with each other. We need to understand our resources. Games are, in fact, the ideal collaboration tool.
We have lots of games. There's "Product Box", which is really good at discovering unmet needs. We have "Remember the Future", which is really good at goal driven planning. We have "Spider Web", which is all about understanding, and making, and forming relationships. We have "Start Your Day", which is really good at understanding patterns of use in your products and services. We have "Speed Boat", which many of you know, is retrospective technique to help identify impediments.
I'm looking at our collection of games, and I'm thinking, will any of these really help the city? And not really, because the city's got a prioritization problem. We have a game called "Buy a Feature", and in "Buy a Feature", you take a list of items, you look at their cost, you allocate a limited subset of that cost to the players, which represent your available resources, and they collaborate, not compete, but they collaborate to buy the items that are needed. I thought, maybe we could use "Buy a Feature" with the city to help them understand what the citizens' priorities are.
Then I realized, wait a minute, the city's 100 million dollars in debt. If I walk up and say, what do you want to buy with a bunch of money? That doesn't match the city's problem, so we put on our game mod ... Right? Game mod. Game designers, game modders, we decided to mod the game.
We ended up with "Budget Games", and "Budget Games" starts with the green sheets. This content was developed with the city over a three month period. The green sheets represent desirable proposals that citizens might want. The red sheets represent budget cuts the citizens could make to get money to buy things that they want because the city had no money. Green money, things you want. Red sheets, things to cut to get money. Once you had the money, you could spend it any way you want.
When you guys are thinking backlogs ... As a product manager for a software company, I feel the same way that all the people in the room. You stress over your backlogs. Am I building the right thing? I want to make sure that we're building the right thing.
Let's consider some of the items on the green sheet. Things like, would you rather fund libraries, or park rangers for safety, or pavement maintenance? Because the roads in San Jose were deteriorating. These are pretty serious items in a serious game. How do we get there? Would you like to eliminate the police helicopter? Would you like to reduce the number of people in the fire truck from five to four? That would save five million dollars.
Once we had the content, we still needed other components. We needed a team, and superheroes come in teams, right? We needed to assemble a team, and you'll find some of these people at the conference, and you can ask them about their experience. We assembled a team of facilitators, people who were willing to contribute their time. Then, we sat them down at tables. This is Brett McCallon, and we said, here's the game. Here's the green sheets, here's the red sheets, you must have unanimous agreement on a red sheet item before the facilitator gives you money. Once you have a unanimous agreement, you can buy what you want.
The participants were San Jose residents. They were typically the Neighborhood Association Community leaders. Understanding the city of San Jose, is there's 10 districts, each district has a collection of neighborhoods, the neighborhood association leaders were coming to the event, and then we balanced the tables so that there were no more than one representative from a given district at a table, to make sure that the city had balance.
Then, subject matter experts, like Fire Chief William McDonald answered questions from the citizens. "Fire Chief, what would happen if we did remove a fire person from the fire truck? If we go from five to four, is it still safe? How does that affect us?" Notice the posture that they have. They're really listening to the residents.
When we were done, we collected the results, and then when I presented these results to Mayor Reed, he actually called me up. He said, "Are these results accurate?" I said, "Yes, I can give you the raw data from what people purchases". He said, "Do you have any idea how radical these results are?" I said, "No, I'm a market researcher. I just get the data and I tell you what happened. I research lots of stuff". He said, "The San Jose residents chose pavement maintenance over libraries". I said, "Yes, that's what the data said". He said, "Well, Luke, that's what San Jose needs, but if I, or the city council go out and say, 'We're not gonna fund libraries, we're gonna fund pavement', the 'Friends of Libraries' will come out in force. But there's no 'Friends of Pavement'". I said, "You know, my software architect tells me the same thing about software "-ilities".
What happened? Well, we had an impact. We were part of the process. We helped give data that was actionable. For those of you in the room who are looking at qualitative research, or quantitative research, or statistically significant, et cetera, throw that all away. What you want is, can you take action on the data you've acquired? Does it allow you to move forward? This helped the city move forward, in a number of very powerful ways.
Being an agilist, we baked in a retrospective. In that retrospective, what we learned was that we can take, you can use agile frameworks that are designed for collaboration to accomplish much bigger goals. You can do this. Of course, in our retrospective, we talked about how it went. Citizens, "We love this! This was great! It was interactive, we had conversations, we learned things. Can we add ideas? Can we talk about what we want to do? What about a sales tax? Maybe we should look at tax improvements, because now we can see what we can do with our money if we have money".
In 2012, we did it again, and we changed the format. In the red sheet we did add a sales tax increase. We added more sophistication in the items, where you could buy one or none, and we added a write in candidate for the citizens, so they can add their ideas. This time, I'm excited to say that the city did video tape the event, and I'm gonna show you a tiny little part of that video right now. Could you cue the video please.
Mayor Reed: This is a kick off of a six month long process of developing a budget for the city of San Jose. We been doing this since I became Mayor, as part of our community based budgeting process.
Ed Shikada: We've got many of our key staff here, who are also very interested in hearing the questions, the discussion, and taking that as inputs, as the city manager puts together her proposed budget.
Luke Hohmann: The goal of this session is to understand your priorities, as Mayor Reed described, to spend on the proposals that are in the green paper. The facilitators at the table, will help you manage the process. They will handle the distribution of the money to you, but if you buy an item, or if you want to fund a proposal, you must, as a table, give the money back to the facilitator. It's like your spending real money.
Ty Greaves: It's the first time where my experience of it was very positive. I was engaged in the conversation around the table, watching the participants to the degree that they were willing to put forward their ideas, articulate their rationale for them, but in the final analysis was what they were willing to negotiate and interact with one another and come to a consensus position. I was surprised how quickly that happened with respect to the priorities because I was expecting some people to be binary, in terms of something that I consider trivial, but for the most part, I was surprised the level of agreement they across there.
Luke Hohmann: All right. That gives you a sense of what collaboration at scale looks like. Continuing that theme, in 2012, we thought, we'd like to see if we can make this bigger. Let's create a non-profit, and a colleague of mine, Martha Amram and I got together, and we decided to create a non-profit.
For those of you who have ever done this, naming something is so important, giving it the right name, and we were struggling. There's a woman in our community who is just wonderful, Lyssa Adkins, and many of you know her. I will be forever in her debt because she gave us the name for our non-profit. She said, "You know, Luke, you want to have every voice heard, every voice engaged". We look, "Every Voice Heard", that sounds great, and that was taken, but "Every Voice Engaged" was available. I have this great debt to Lyssa, who's just so wonderful, and she's right. We want every voice engaged, to solve the problems that we're tackling.
2012 went so well, that the city said, "Can we make it bigger?" I said, "Yes. Let's make it bigger. Let's do the San Jose Convention Center and get 5,000 citizens collaborating. Of course, the moment I said it, I went, "Oh my god, how am I gonna get that many facilitators?" The city said, "We can't afford that, but how 'bout we go to the Rotunda?" I'm like, "Okay".
This is a photo of the Rotunda. We expanded, we went to 19 tables, with more citizens. We started to publish our results, and we started to talk to the community. It expanded globally. Jürgen de Smet, over in Europe, in Belgium, said, "I can do budget games with my city, and if you look carefully, Jürgen points out that the refreshments are a little different, and he recommends that we consider these for American politics. I tend to agree with him. I don't yet know if we can pull that off, but we started to expand globally.
In 2014, the city came to us and said, "We want to get more people involved, but we can't afford to go bigger. Can we do the Rotunda, and could we go online?" I'm thinking, "Come on, this is Silicon Valley. Of course, we can go online. We have a platform for that". We assembled a team of facilitators, and we went online. I can not tell you how meaningful it is that the facilitator for the San Jose budget games came from around the world. We had facilitators in Sweden online, facilitating games for San Jose residents.
I know that there is a lot of discussions about distributed teams, and collaboration, and how people feel, so what did the San Jose residents think about the online forums? Because hey, co-location is important. Davide. This is actual, unedited chats from the chat logs.
Davide: "Interesting exercise. I've done it in person at City Hall once before, worked very similarly".
Jean: "This is better than the in-person game".
Facilitator: "What did you like about that, Jean?"
Jean: "Not noisy, could hear everyone. Real-time updates of the balances, no side chatter. Better focus on task.
Davide: "It came down to the facts. No body language, no prejudices, just ideas and dealing.
We've all had that opportunity to participate in a conference call with video. We've also had the frustration of wondering why our meetings start 15 minutes late, when we're trying to do it. Here, we didn't use video, and we saw compelling engagement. More importantly, we were online with distributed teams. This makes it interesting, right, because a lot of people in the agile community say things, "All team should be co-located", but then, a lot of people say, "We need distributed teams to scale".
Curiously, it appears that we have both. There's a phrase that is often used in the agile community called, "Yes, and ... " Maybe we should use that "Yes, and ... " phrase here, even if it conflicts with dogma or some consultant's income. You can clap on that one, I'm okay with that.
I want to point out, in San Jose, it was not a one-and-done, it was 2011, 2012, 2013, 2014. What this means is that you can repeatedly use agile collaboration frameworks to accomplish much bigger goals. The goal isn't one-and-done, the goal is to keep at it. To keep looking at these issues.
Over the course of those four years, as you can imagine, the San Jose residents got a little tired of cutting, cutting, cutting, cutting, and the said, "Can you help our city grow? Do you have any games that do that?" That's kind of like the question, "Can you help your product grow?" Can the question becomes, can we take the things that we know here, and can we move them over here?
We have a game called, "Prune the Product Tree". This is a photo from outside McLaren, in London, and as you can see, you can make trees and shrubs, kind of look like whatever you want. Even a Ferrari, or a Formula F1. We've got this game, use "Prune the Product Tree" to help people grow, and the tree represents the growth of your product and service, you have time horizons. Apples represent tasty features, you can put apples in the roots to represent your nutritious infrastructure, that of course, powers more tasty features.
There's lots of these. If you just go online, and Google, you can see, for example, my friend, Mitch Lacy, has a wonderful blog post, where he used "Prune the Product Tree", among other techniques, to help an agile transformation grow, help a company grow. People draw their own trees. This is a post from an Oracle product manager, about a product at Oracle, and it's international, right? Trees exist around the world. This is a tree from France.
In addition, the Scrum Alliance, a few years ago, contacted us and said, "Can you help us identify how the Scrum Alliance could grow, but we have to do this online, because we want to engage a global community of CST's". We played five games with 35 CST's, and we identified a number of ways in which the Scrum Alliance could choose to grow. I tweeted the results of that, and you could see the results, and you can also see that the Scrum Alliance took those data, and they acted on it, and they implemented many of the ideas that the CST's gave them.
The question becomes, we know how to help products grow, we know how to help organizations, or companies grow, could we help communities grow? We worked with the Spanish neighborhoods, in Hispanic neighborhoods, in San Jose, and we did a project that we called, "The Great Neighborhoods Project", where we used "Prune the Product Tree", both in person, and online, to engage citizens, in helping their community grow. Once again, we found you can use agile collaboration frameworks, to accomplish much bigger goals.
Along the way, you'll notice that there's some changes here, right? There's some core things that we're doing in business, and there's some things that we've changed a little bit, so I have a really important question for you right now. Are you a Monopolybut? "What?" What happens when you land on "Free Parking when you're playing Monopoly?" According to the rules, what happens, according to the rules? Nothing happens on "Free Parking". How do many people play Monopoly? You get money if you land on "Free Parking". That's the number one mod in the game of Monopoly.
There's other mods. Some people mod Monopoly by saying, "You can only trade cards on your turn". That's actually not in the rules. In fact, the whole point of Monopoly is to trade and keep trading, and wheel and deal. Some people say, if you land on a property, you don't want to by it, then we move on, but in Monopoly, if you don't buy it, it goes up for auction. A normal Monopoly game takes about 30 to 40 minutes. The games that we tend to play with Monopoly, as our family members is we add changes to the game, we mod the game, because we're having so much fun to play, that we want to play longer. This means that if you've done anything like that, that you are, in fact, a game designer.
Amy Cuddy has done some really interesting research on body language. Everyone stand up to the person next to you, put your hands on your hips, assume the superhero pose, and say, "Hello my name is", and your name. "I am a game designer".
Every one of us ... Every one of us is a game designer. Why is this important? Well, because we have games here like, "Scrum", that has a guide that says, "The rules of the Game", but if you don't follow those rules, somehow you're called a "ScrumBut". I say, "ScrumButs unite". By the way, I'm not picking on "Scrum", I changed it to "Method Modder". I don't care what method you're doing. In organizational theory, there's always espoused theory, and actual practice, and there's always a little bit of a gap. Most of the time, that gap is a good thing because you are a game designer. I say, "Keep calm and Scrum mod on".
The question becomes, if we, as a community are game designers, and you didn't realize it, but you are. If you are a game designer, the question becomes, how far can we push to mods? How far can we take this? Before the conference, we invited people to participate in an online "Buy-a-feature" game, as a simulation so you could experience this on what school programs should we fund? We imagined a hypothetical school system, and we looked at some of the programs that you could fund, and this was the results from the games that we did on the 30th. We see here that way at the top are things like, STEM teachers, and hiring grants, and some other things are done, and this would be representative of what a community would do, a prioritization game. That's good, and we know how to do that.
What if the question is a different kind of question? How do we deal with school overcrowding? Think about that for a moment. Think about how you're feeling, and how you're thinking about that question. One question is, here's some money, how do we allocate it, and another question is, how do I deal with school over crowding? What you're gonna find is if you give yourself a moment, you're thinking, what are my options? How do I deal with this? What choices do I make, and what's the impact of these options? If I choose an option, and it has certain impacts, does it have any drawbacks? How do I think about this?
What you're finding is that you're dealing with technical problems on budgets. Technical problems tend to be pretty clearly defined. They tend to have shorter, and often repeating time horizons, where this word is "failure", which we love to talk about in the agile community. Failure isn't catastrophic in a technical problem. Right? You set your budget for your company, or you set your budget for your project, six months in, you adjust it. They tend to be knowledge and economic driven. How much is the ROI? Et cetera, et cetera.
Wicked problems, and [inaudible 00:29:30] right now is finishing up a project for the Los Altos School District, which is in fact, facing an issue of school overcrowding. Wicked problems tend to have a long time horizon, and they stay the way they are because of inertia, but failure is often catastrophic. If we don't start addressing these problems, bad things really do happen, and they're hard because there's multiple actors involved, and they're not so much, economically driven, as driven by our values and beliefs. These wicked problems, exist at all levels of society.
We have the Los Alto School District, and other school districts who are facing similar problems. In California, where I live, we have the drought. A really hard, wicked problem. In the US, and I know there's people internationally, but I'm just gonna talk about the US for a moment. We have healthcare, we also have things like immigration reform, but globally, right, for everybody in the room, IBM's Watson says that 40 percent of knowledge workers may become obsolete. How do we prepare our children for a future of work if the meaning of knowledge work itself, is changing? There's a growing, and rampant, issue with alcohol and drug abuse. Obesity around the world is skyrocketing. How do we deal with these issues? How do we deal with these wicked problems?
The question is, do we have wicked problems in business? If we do, then maybe we can look at the way we're tackling wicked problems in business, and bring those over into the social sector. I'm just gonna give a few that I think are relevant for the technical side. Late software, massive technical debt, low adoption rates of my software, or how do I scale agile? You look at these, and you think, "Ah, I do have wicked problems in business". We can help. We can help, right? We're really good at this.
Not so much. If you look at the research on wicked problem solving in business, by people like Paul Nutt, you'll find that 50 percent of strategic business decisions fail. The fail because we don't consider options. We decide that there's one way to do it, and we're gonna go for it. We don't assess the actions required to put a given option into play, and we don't look at the drawback. Meaning, we don't deliberate. We don't collaborate.
What if we went the other way? What if we looked into the social sector, and said, "How are they dealing with these problems? Maybe there's something that we could do in business from that".
In 2012, I was fortunate to speak at South by Southwest, and my talk was the work that we're doing, and budgeting, and it was fixing broken governments through serious games. At the talk, I met Amy Lee, a program officer from the Kettering Foundation in Ohio. What Kettering does globally is they study what it takes to make democracy as an institution, function and work as it should. She started talking to me about how budget games was really good, but it's technical, but Kettering focuses on wicked problems, and the way they do this is through a deliberative forum.
They build an issue guide that lets citizens look at different options for solving a problem, and different strategies and actions. Let's look at one for California drought. One strategy we could use is creating and capturing more water. Another strategy we could use is increasing conservation, and you'll notice that when you're building an issue guide, there's two options, or two strategies that are kind of opposite to each other, and then there's a third, which has you think a little differently. For the California water drought, the third option is not looking at getting more conserving, but looking at the patchwork quilt of laws and regulations across the state, that has no coordination. Maybe we should modernize our governance.
There's actions associated with this, actions for dealing with this. We could, for example, create a desalination plant. We could change the levee system to get more water where it's needed when we want it. We could build more reservoirs. Those actions come with drawbacks. Building a desal plant, that costs a billion dollars, and it creates highly concentrated waste water. Are we willing to accept this? The fragile ecosystem of the California delta might be harmed if we change the structure, and we could actually hurt agriculture instead of helping it. The reservoirs, that sounds good, but it's even more expensive than a desal plant, and it may not move the needle enough.
We know how to deliberate, and what Kettering came to us and said, "Is there a way we can scale deliberation? Because we need to have a conversation, and we need to show the shape of the opinions of the people". Working in collaboration with the Kettering Foundation, we took their in-person process, and we built an online platform. It's called, "Common Ground for Action". I'm just gonna give you a couple of screenshots. This is a screenshot where participants are examining the actions that they might take, and deciding, "Do I support this action? Am I conflicted, or do I not support this action? Am I willing to accept the drawbacks of those actions?"
When we're done, what happens is, we bring people into the collaboration event, and remember, I didn't say this, but collaboration is five to eight people, so if you want to collaborate with 800 people, you're gonna have 100 forums. If you want 80,000, you're gonna have 10,000 forums, because large numbers of people do not collaborate. Collaboration happens in small groups. What we build through this process is we build a visualization of the group's opinion of where common ground might exist, and now we start the deliberation. Through the deliberation, if someone changes your mind on a given topic, you can change your ranking, and see the visualization change in real time. When we're done, looking at the different options, you see a result that gives you some insight into what might happen when we look at where common ground exists. You really could clap on this one.
My own personal journey in building this software with Amy Lee, and the Kettering Foundation, is that Kettering looks at this picture, and says, "This is great. People are deliberating". As a business person, as an agilist, you look at it like, "Wow, how do we now make forward progress?" Because there are different choices that people are making and that's the nature of values. They're hard to discern, but if you do this at scale, you can find patterns that allow people to take action. The goal now becomes, taking frameworks and processes that work in the civic sector, and applying it to our world. I'll give you some options here.
One is technical debt. That's on everyone's mind right now, right? It's kind of cool, it's like "pivot". "I'm pivoting my technical debt. It's really cool. Yeah, I have a hypothesis about that too. Very lean". Right? You think about, what are my options for technical debt? One is rewrite. Rewrite the software. You might find yourself susceptible to Lundy's Law. Ron Lundy was an architect who worked for me a long time ago, and he coined, "Lundy's Law". Lundy's Law states, "That any team of programmers, if given enough time, will eventually justify a total rewrite". Right.
There's another option, though. That's one option. Another option is to maybe not write software at all. Maybe you should just go buy it. Notice how these are kind of opposites. Remember the framing? Is designed to have something, and then something that's kind of opposite. What's the alternative?
My experience is that most technical debt is not really technical debt. It's a sign of bad collaboration between the business, and the technical people because the technical people don't know how to talk to the business people, and the business people don't understand the technical people, so rather than having a collaboration, they scare them. "Technical debt". "Oh my god, I better let you do that".
Maybe the right way to attack this problem is to do collaborative road mapping, and bring people together in a way that they can understand technical debt. I'm not saying technical debt doesn't exist. I am saying that, as a community, we better be a lot more careful about how we sling that term around. Let me give you an example from our own software.
When we started building our software, we connected to PayPal, for payment processing. Along came Stripe, and we were having some issues with PayPal. It wasn't always so easy. This isn't a ding against PayPal, but we were having some challenges. My CTO, Dan, said, "I want to try this thing called Stripe. Can I have a backlog item to just do an investigative task for this?" "Sure, Dan. Go for it". At the end of the sprint, I said, "Dan, how'd it go?" He said, "I had it completely implemented, and I'm done". I said, "I thought it was an investigative task?" He said, "Yeah, but it was so easy to use, I'm just done". That was on another platform that we had built.
Now, I have two platforms. Platform one, Stripe. Platform old, PayPal. "Oh, technical debt". No, it's not technical debt. It's learning and a choice. Eventually, we created a road map together when we chose the right time to unify into a single payment processor. That was through collaboration. It wasn't like, "We've got to do a massive rewrite", or, "We should stop writing software". It was collaboration that gave us the opportunity to move forward.
What about scaling agile? That's the thing, right? We want to scale agile. You want to scale agile? Scale agile. Let's look at the options. There's a lot of frameworks out there now for scaling agile. You've got LeSS, you've got SAF, you've got Nexus, and you've got DAD, and I apologize to anyone who's preferred skilling method, I didn't list. I do, because there's a set of them. There's more to it than that, right? If you adopt one of those methods, you're also writing a multi-hundred-thousand to multi-million dollar check to get there. Is that the right way to spend your money? Is that the action you want to take? Is that the drawback that you want to accept? What could be another option?
We have a framework, that we call, "Best Five" and "Worst Five", where we engage teams, as part of the work that we do, and we say, "Tell us across your entire work experience, the five best things, or practices in this area, and the five worst". To me, most of agile is doing more of the best, and less of the worst. What we find repeatedly is, these teams are really wise. They get a lot of things that they need to do.
One option is, adopt a named framework, invest that money here, choosing not to invest that money on new product development. Choosing not to invest that money on better service. That's maybe the right choice. Another option is, go to your teams, continue to retrospect, keep the methods you have, keep moving. Right? Those are two opposite choices. Maybe there's a third choice? Maybe Conway's Law is really what's killing you, and what you need to do is not adopt a method, but you need to actually re-architect parts of your system, not massive technical debt, but re-architect.
It's curious to me, how often developers tells us that we need to refactor our organizations, and yet, when the business leaders try to reorganize their teams, they get freaked out. It's just refactoring. If the business leaders would say, "I want to refactor our company", and if the technical people said, "I want to reorganize my software", they might actually communicate better. What we've learned through this process is that we have business problems, and we have social problems, and collaboration frameworks, work in both dimensions.
This leads us to ask questions like, "What other problems can we tackle?" Sometimes, it's not even the problems that we're after. What other opportunities can we create for ourselves, and our communities? A great way to start, is to go back to the agile manifesto, a set of values and a set of practices. One of the practices is that everyone of you knows how to do, is a retrospective, because at regular intervals, we're going to retrospect. By the way kids, the agile manifesto, never said, "Run a retrospective every sprint". It said, "At regular intervals". That's an important thing, I'll come back to in a minute.
A great technique for doing retrospective is "Speed Boat". These are photos where you represent your processes of boat, and you want it to go fast, but there are anchors holding it down. How do I cut those anchors? What are the propellors that make that boat go fast? Jason Tice over here, in the front, he's actually adapted "Speed Boat" to performance reviews in a really novel way.
We have this framework that can be modded, in very interesting ways. You can tell, obviously, that these boats were created by a team, because they're Post-it Notes, and single [inaudible 00:43:48], it's just great. If you're gonna scale, then scale, and to scale, eventually you're gonna have to go online. You're gonna have to have teams go online, play "Speed Boat" and analyze the results. This is a project that we did for a company, B.WinParty, and I think it's really nice that people in the agile community are saying, "Let's scale retrospectives. We can do 30 people, or we can do 40 people". We're doing 400 people in retrospectives.
We're doing truly enterprise retrospectives. In this picture, it represents 42 Scrum Teams, about 350 people, where each dot, represents an anchor, or a propellor. The redness of the dot is the worseness of the anchor. The greenness of the dot is the power of the propellor. What we found was that the teams were cooking. Oh, and the dots are analyzed. I should explain the analysis framework.
Diana Larsen has a brilliant way of looking at feedback called "Circles and Soup" where inside the circle is what the team can control, and in the soup is what is out of the team control, but it does influence them. The soup is what you care about when you're dealing with the enterprise, so we analyze all of those things, and we code them. "People Process Technology", "Circles and Soup". We find the enterprise opportunities are in the soup.
Now, this is really powerful, and we've been doing a lot of large scale retrospectives, enterprise retrospectives, to find enterprise impediments. What if we did something more? What if we, all of us who know how to do retrospections, took it to our neighborhood, or our community center, or our city? What if we could have a city do a retrospective by all of you facilitating it, and find out how to improve our city?
I've been talking pretty big. San Jose, for example, is one of America's ten largest cities. It has over a million people. Maybe, though, we should look at something smaller, because we're agilists, and we believe in teams, which are social units. Maybe we should look at the smallest social unit, but possibly the most important of all, our family.
I'm so proud to share with you something that I've seen now for a few months. Kathleen Grant, is in the front row, and she, and her colleague, Laura Osborne, have written a book about using the games that we've developed for business, and therapeutic situations. If you can read the sticky note, it says, "Priorities for sobriety, using the game '20/20 Vision' to help a family, who's recovering, along with an alcoholic father, how to get out of that". In the bottom, there's a family who's struggling with financial issues, and they're playing the game, "Remember the Future", to understand how they can work together to get out of these financial crisis that they're facing.
When I created Innovation Games, I never imagined that they could be used for this kind of impact, and yet, it just illustrates one more time, the power that you have as game designers, the power that you have as agilists, to use collaboration frameworks to solve both wicked and social problems.
So, now what? Now what? We have a conference. We have superheroes. You work in teams, like The Avengers, and you might think to yourself, "Wow, I want to be a collaboration superhero". Then you look at the picture, and you go, "I'm not green, and I'm not the smartest engineer on the planet. I'm not even a god, and I'm certainly, don't have the cool shield. I can't do this". But if you look closely ... You could see Black Widow. She's a ballerina. If you know a little bit about my past, you know that I have an affinity to things like ballet. Hawkeye, he doesn't have super powers. He's just gutsy, and a pretty good shot with a bow.
Just like these people, are agilists like you, and these are the pictures of the people who assembled for four years, to help the city of San Jose prioritize budgets. These people are you. You can do this. My request for you is to play two games to change the world. That's my request. Two games, on something you care about. Something that matters to you.
When you say, "Let's play games", you have to be careful, because if you walk up to your boss and you say, "Hey, let's play!" Your boss may not react positively. I'm gonna now dip into, "Luke Speak". This is what my wife says that CEO's say when they're not saying anything important, or when they're saying something really important with many more words than they need to say. Are you ready? We'll make sure that this slide gets to you.
You're not gonna walk up to your boss, and say, "Boss, I want to play a game". You're instead gonna say, "Boss, I want to engage my team, in a goal directed activity with clearly defined rules of engagement. Progress towards achievement of the goal will be tracked through clearly communicated status indicators". I know, it's pretty good, but some of you might be working in a place where this woudn't even be enough, so you're gonna add it, you're gonna spice it up. You're gonna say, "Strategic", because if it's strategic, it's gotta be important. Then to make sure it's work, you're gonna say, "Exercise". Finally, to add that agile zip, you're gonna call it, "An information radiator".
I'm from Silicon Valley, and that means we need a curve based on Excel, that grows like this. Using a seed of a thousand people, roughly, half the people at this conference, if you play two games a year, with five people in the game, and you, through that experience convince them that this is important, in 25 years, we will have 200 million people around the world playing games. With that number of people playing games, we can attack the problems that we're facing. You need to do this, because the world needs you. Thank you.