Rules Governing Software Innovation that do Work

October 6, 2016 — Posted by Tom Grant
In my last blog post, I talked about the parallel between designing a game and transforming an organization along Lean and Agile tenets. Both involve defining rules that people will follow; both may start from the assumption that you need a rule for everything. If you design the rules correctly, according to this approach (the technical term, in game design parlance is design for cause), you'll get the desired effect. 
 
I ended the last post by saying that there was an alternate approach to designing rules for games and for organizations. Since it stands in stark contrast to design for cause, it should be no surprise that the name for this other approach is design for effect. This approach, in game design, starts with the question, "What experience do you want to create?" It then guides the game designer to develop the minimum number of rules needed to create that in-game experience.  
 
I'll get back to Agile and Lean for a moment, but it's important to understand how design for effect works before we apply it to something for which it wasn't...er, designed. To go back to our WWII example from the last post, many designers have discarded the kitchen sink approach to simulating that conflict, preferring to focus on just part of it. The goal, in applying design for effect, is to create a reasonable simulation of that part of the war, not WWII in its staggering entirety.
 

Simple Rules for Complex Experiences

One of the most vivid examples of this approach is Churchill, a game that aims to give the players the experience of being one of the leaders of the "Big Three" Allied nations — in other words, Roosevelt, Churchill, or Stalin. Each turn in the game represents on of the conferences (Tehran, Yalta, etc.) in which the Big Three arm-wrestle over how to defeat the Axis Powers. The main "map" in the game is actually a conference table, across which the Big Three arm-wrestle over the issues of the conference. The winner of the game is the leader who sets up the post-war order most to their country's liking (Churchill wants to preserve the British Empire, Roosevelt wants to dismantle colonialism, and Stalin wants an iron grip on the USSR's spheres of influence). 
 
You might graft the mechanics of this game on to a more complex WWII simulation, including rules for submarines, bombers, industrial mobilization, etc. etc. But why clutter the game with all that complexity, if the goal is to depict just one important part of that huge conflict, the political tug-of-war and frequent distrust among the Allied leaders? The more unnecessary rules we have, the less likely people will be able to learn the game. Additionally, complexity can clutter up the experience of the game, diminishing the focus on what's needed to create the experience of being one of the Big Three leaders. 
 
We can apply the same approach when we design the rules governing software innovation. We want to create a particular experience, just the same way that a game creates a particular experience. In the case of disciplines like Agile and Lean, we want to create an experience that is most likely to lead to success at whatever the people creating and delivering software value are supposed to accomplish. Scrum, for example, offers a very minimal set of rules for establishing a team-based approach to dealing with common software innovation challenges, particularly when faced with a large number of unknowns. Kanban provides a less team-centric approach that solves a different problem, creating a stable, sustainable flow of work through a pull-based approach.
 
People have adopted Scrum and Kanban to solve a variety of different challenges. For example, the initial impetus for going Agile has, in some cases, been an impatience with the slow pace of software releases. In others, the motive was improving quality. Because the rules of Scrum are simple, they were not over-designed to produce a particular outcome. They were disruptive enough to change how teams worked, and allowed for different benefits arising from that change.
 
Simple is good, in the world of software innovation, whether you're talking about a discipline like Agile, or even something more expansive, such as frameworks like SAFe or CMMI. Having a rule for some activity doesn't necessarily help create the experience you want...Assuming, of course, you know what the intended outcome really is.
 

How Do You Win This Game?

The biggest problem with designing for effect, in the software world, isn't the rules themselves, or figuring out how much parsimony to apply to designing them. Instead, the biggest challenge is not knowing what sort of experience or outcome they are supposed to produce. There are plenty of examples of efforts to apply a new rules set for software innovation that failed, in large part, because there was no clear goal.
 
When I start working with clients, I usually run a short exercise to assess what their goals are. In the majority of cases, not only do different people in the organization give wildly different answers about the goals for Agile or Lean, but they people in charge often have no idea themselves what the strategic intent is. Take, for example, an IT department that had horrible relations with the business, which no longer trusted IT to deliver anything of value. In this case, the top executive behind the Agile transformation had not much to say about the point of going Agile, other than "to make things better." In this executive's mind, "better" could mean delivering faster, increasing quality, getting better at meeting commitments, or eliminating a lot of obvious waste. ("I want all of them!" the executive proclaimed.) None of these goals were necessarily pre-eminent; not surprisingly, everyone else was fairly confused about the goals of all the Agile coaching and training. Confusion and inertia reigned.
 
To be fair, the people applying specific methods, disciplines, or frameworks are not completely to blame. Often, it's not completely clear what specific outcomes the methods, disciplines, and frameworks are supposed to achieve. CMMI, for example, promises greater maturity, but maturity is not an end in itself. What's the positive organizational outcome of being more mature? Improved flow? Greater reliability of estimates and plans? Less waste? Something else?
 
People in the Lean and Agile communities don't talk about this anti-pattern, the lack of strategic clarity, enough. Simply put, if you don't know what you want, you're not going to get it — and many practitioners don't. That principle is just as true of implementing Agile and Lean as picking a board game that might appeal to everyone at your next family get-together, or whether a game is a good activity in the first place.
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