Rules Governing Software Innovation That Don't Work

September 23, 2016 — Posted by Tom Grant
Serious games are a powerful tool for Lean and Agile transformation. Games also provide a good analogy for what is happening in software innovation, since both games and organizations are systems. The way in which we define the governing rules for one type of system, such as a game, have a lot of relevance for what happens when you define rules for the other system. Aside from many other lessons one can learn and apply through this analogy, we can gain some deep insights into why even the best-designed systems don't fit every situation exactly, especially ones as complex as software development and delivery.
 
Before we dive into this topic, let me make my agenda clear. My chief targets, in this post, are people often want to have a blind faith in off-the-shelf rules governing software development and delivery. I've worked with clients in the past who have made differently-worded versions of the same plea: "Just give us the template for how we should act, and we'll run with it." These are, not coincidentally, often the same clients who under-invest in coaching, and don't give much thought to the upstream and downstream effects of Lean-Agile transformation. The rules of the software game should be, in their minds, invariant, and if they've worked correctly in other organizations, they will work just fine in theirs. 
 
These people are displaying an unjustified trust in the ability of the rules to create the right outcomes every time. They are not thinking of software development and delivery as a system; instead, they are looking at the components of the system, and just trying to copy into one organization what worked in another. We can see exactly problematic this blind faith can be, by looking at how people design a different set of rules, games that depict important historical events. 
 
Suppose you have a deep interest in World War II, and you'd like a game that simulates that conflict from the perspective of the Allied powers involved in that conflict. You crave the excitement and challenge of playing Roosevelt or Churchill, fighting the good fight against the Axis powers. How do you select a game that might give you that experience?
 
You might look for a game that has the largest number of moving parts, a.k.a. game mechanics, that simulate what happened in World War II. The more of these mechanics it has, you assume, the more credible the simulation. Infantry? Check. Tanks? Check. Submarines? Check. Fighters? Check. Bombers? Check. Factories? Check. Home front morale? Check. The list would continue for quite a while, tallying all the elements of actual historical events that might be important for a World War II simulation.
 
Such games exist (here's an example). Not surprisingly, in many cases, you need a computer to help you run a game with this much breadth and depth. Rather quickly, you create so much complexity that it creates three problems:
 
  1. Very few people will want to master your game. There's a very small niche market of people so interested in World War II that they want to zoom out into an entire theater of operations, and then zoom into the fighting around a French town. Even fewer people would want to control all the pieces on the simulated board of history.
  2. No one will be able to understand your game. The game's complexity will exceed the ability of the human brain to comprehend all of it. As a system, it's too detailed, so there's no way to learn its operations, let alone master them. How much of a difference will it make if you invest more in battleships than bombers? It's impossible to say, perhaps even after you've witnessed the effects of these decisions. The game gives you a bewildering array of buttons to push, and dials to adjust. All of them seem to matter...Or none of them.
  3. The model is too complex to get right. Games are a lot like software: you have to test and adjust until you get the intended behavior.  The mechanics for simulating air power might look right, until you find out that, in every game played, they yield implausible results, such as strategic bombing forcing the Axis to surrender by 1942. Unfortunately, the set of interrelationships among the mechanics may be too complex to avoid creating problems in other parts of the simulation if you fix the air power rules. You might easily find yourself trading between undesirable results.
  4. The model isn't portable. Now that your WWII game is a big success, you want to borrow components for a game about the Napoleonic Wars. Unfortunately, the underlying mechanics are so precisely designed to model 20th century, heavily industrialized nations, and the technologies used during that period, that they're effectively useless for other eras. There's no simple starting point, such as a simple way of modeling the recruitment and training of new troops, that you can transfer outside of World War II. You have to either (1) force the WWII-based mechanics into the early 19th century, and accept the ugly consequences; (2) add more complexity to the model, to make it "work right" for a different era; or (3) start from scratch, building a brand new model.
 
There are definite lessons here for the rules that govern software innovation, such as whatever methodologies and frameworks may be in vogue at the moment.
 
  1. Methodologies and frameworks are sets of mechanics. Therefore, we're not making a courageous leap when comparing games and ways of developing software. In fact, some considerations, such as complexity, have immediate relevance.
  2. Complex mechanics create many problems. If the "rulebook" is too lengthy, you're going to lose a lot of people. (Hence the sorry fate of many SDLCs.)  In contrast, one of the virtues of both Agile and Lean are their simplicity. It's not hard to gain a superficial understanding of them, enough to get started. Deeper learning, in the same fashion as mastering chess, happens over time. As you master them, you don't want to be wrestling with second- and third-order effects, or lots of other mechanics that don't have immediate priority. While I'm working out how to streamline the internal developer references to make it possible to finish sprints, for example, I don't want to have to satisfy three different governing boards, or worry whether the tool that we're mandated to use can create a Wiki-like reference. If your streamlining strategy turns out not to work, complexity makes it harder to try a different approach. Imagine having to deal with all the headaches with the governing boards and tools all over again...
  3. You won't get the rules right the first time. The "core mechanics" of Agile and Lean are not only simple, but battle-tested. For many people, their prescriptions seemed counter-intuitive: for example, I've seen many people struggle with story, or Lean pull-based methods. However odd they might appear at first glance, Agile and Lean approaches do work, in contrast to many "sensible" methods that made a lot of sense on paper, but turned out to be disastrous in practice. 
  4. You need some level of portability. Why doesn't Company A just copy the SDLC that Company B uses? Because, as we all know, no two companies are alike, and the differences are significant enough to make a strict methodological copy-paste a foolish effort. For any set of mechanics to work across organizations, it has to be simple enough to be portable, which means "the rule for everything" approach will never be portable.
 
This approach to designing both games and methodologies that I've described is, fortunately, not the only option. The alternative, designing for effect, starts with a much different set of assumptions than designing for cause, which is what I've described here. Designing for effect, both games and software innovation strategies, is the subject of my next blog post.
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Tom Grant

Tom Grant is an analyst covering software development and delivery. His Specific focus areas include Agile, Lean, application lifecycle management (ALM), requirements, serious games, and the innovation process. Some of the serious games he has developed are teaching tools, often for people learning Agile software development practices. Others are simulations, intended to help people try out different innovation strategies. He has also taught political science at UC Irvine and Chapman College.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban