Exploring the economics of decision making in SAFe? through gamification

Economic thinking and principles

In the popular Scaled Agile Framework for Lean Enterprises (SAFe) we strive to "apply a comprehensive economic framework" through Principle #1: Take an Economic View. Certainly, part of how we deliver on this framework is through the natural decentralized decision making process that occurs when real Agile teams hypothesize their way through optimizing batch sizes, building quality in, and relentlessly improving. Breaking down work into slices of working software/deliverables/efforts that are potentially shippable (i.e. features) each iteration. 

I believe that the dominant paradigm for managing product development is fundamentally wrong. Not just a little wrong, but wrong to its very core. It is as wrong as we were in manufacturing, before the Japanese unlocked the secret of lean manufacturing. I believe that a new paradigm is emerging, one that challenges the current orthodoxy of product development.

Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 1). Celeritas Publishing. Kindle Edition. 

At scale, we apply the same core thinking to how we invest in Epics and Features. Run experiments.

Product Management (PdM) is faced with decision making in the Continuous Exploration loop of the Continuous Delivery Pipeline as they explore and manage the connections between what customers want and what the team of teams can deliver. How Product Managers traditionally accomplish this is usually through a mashing up of ad hoc practices/methods and heroes with a strong arm approach to getting more features jammed into the system. Chaos usually ensues in a relentless death march of waste and long decline in culture and the morale of the people in the development organization. 

As Reinertsen aptly points out in the remarkable gem, "The Principles of Product Development Flow," the people who practice product management usually do not have any connection to, or understanding of how any performance or objective measures in place affect delivery and quality. They merely work the system to suit their own needs ($?).

As obvious as this may seem, this economic view of product development is surprisingly uncommon. Instead, product developers create a large number of proxy objectives: increase innovation, improve quality, conform to plan, shorten development cycles, eliminate waste, etc. Unfortunately, they rarely understand how these proxy objectives quantitatively influence profits. Without this quantitative mapping, they cannot evaluate decisions that affect multiple interacting objectives.

Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 27). Celeritas Publishing. Kindle Edition. 

How to actually apply the principles - practice, practice practice

We know how to influence culture. There are plenty of books on the topic. This article is about how to help product managers understand the economics of their decision making and why it is important to build a network that has many cognitive and collaborative connections both within the product and development organizations, as well outwardly to the customer. How do you determine whether or not you are going to build the right thing? Even if you do build the right thing, will anyone buy it? For how much?

One of the biggest challenges SAFe Program Consultants will face (or any Lean-Agile consultant for that matter) is teaching, then later consulting the product management team/individuals/function on how to actually build out a Lean Product Management system based on the principles. The knowledge is fairly straight forward. However, setting the stage for success here with new ways of working and thinking is a big ask. As an SPC, we must coach/mentor the PdM to also apply the knowledge so that they may development an understanding of how to build the system.

Without this understanding in their context and the application of the principles -simultaneously- you will more than likely only have accomplished helping people learn new words that simply reapply the same old thinking. Obviously this applies to almost anything we teach but is particularly damaging on PdM and Lean-Agile teams.

Gamification

I am a big fan of using games at work (serious play). In the past I have used various Lego building simulations to teach Scrum, Agile, and also for team building exercises. The power of gaming cannot be overstated. People love it and the collaborative nature of gaming brings out many of the instincts of learning that we need to anchor knowledge into an understanding in context and application.

Understanding the Economics of Product Management with Trains

I have always been a gamer. Monopoly, Risk, Axis & Allies, Poker, Chess, you name it and I've probably tried it. One game that I tried out for the first time last year was Sid Meier's Railroads! In this game, you build railroads and an economy. The game isn't particularly exciting, but it does make you think. And if you want to think, you have to think LEAN.

As you can see from the video and screen shots the critical decisions made about the distance, economy of the market/goods, timing, and batch size all play directly into an algorithm that determines your success.

It works basically the same way in the real world. Surprised?

Fun with Trains

The first place we start is with the system. What are we building from a greenfield? Or are we changing an existing system?

Architecture is, of course, incredibly important but for the purposes of this article we will set that topic aside. Let's understand the economics of how we build out the features in our train system.

Setting up the system, big up front design or incremental design thinking?

In the video above, we have only the basic elements of a potential train system. If we build a working version of the system how do we know whether or not it will work? Or if any customers would buy it? Let's run an experiment.

Too many trains, not enough architecture.

Now, in this video we built some tracks and launched some trains. But there is a problem. This example points out how our system has too many trains for a single track. Another way to consume this metaphor is to consider for a moment that our initial architecture did not account for the desired two track, eight car experiment. In SAFe terms, the architectural runway was insufficient to feed the train.

Additionally, we can observe a batch size problem in our systems flow. There is way too much work in process in some cases, and too little in other parts of the system.

Too much runway!

In the "too much runway!" example we see a game based example of an extreme amount of up front design (BDUF) and consequent architecture investments. We may often find ourselves faced with pressure to "over-architect" or commit too early to design or architecture decisions before we have run sufficient experiments.

In these scenarios we wind up with plenty of bandwidth in the system but we invested way too much money early in the incremental life of the system. Three tracks may wind up being one too many once we have optimized the system to meet market demand.

Additionally, we have made a poor economic decision to over invest in the additional unnecessary tracks because that money could have been used to improve or build features that the market demands.

Balance is the key. But establishing flow and balance in a system is not free. We have to build systems in a way that sets the stage for experimentation (Heath & Heath - script the important moves) but also does not create waste.

The Knee meets the Jerk

Quick, do it now... put a bigger train and more cars on the track!

Many system builders and organizations find themselves here. The realization that we over-invested heavily in too much up-front design and/or architecture. So what does leadership and management do? What they were trained to do!! FILL THE SYSTEM UP to the max.

They immediately press the teams to put a bigger and better amount of WIP into the system and force an overload of train cars in this analogy. The only goal in their mental model is to get a reprieve from the pain and realization of failure. Maximizing the WIP in the system provides lots of movement. Movement is good, and plenty of it, because leadership and management may then create reports about all the movement.

But the system is still far from optimized and has an enormous amount of waste.

Now people get burned out and start complaining. The system is having a immune reaction.

Let's go back to the old system.

The immune response causes rollbacks and even more pain and suffering. Now everyone is spinning their wheels restoring the last version of the system. Which was also NOT optimized and also contained enormous waste. But they told us to do it. So we do.

Once again, there is no big picture view of the system. The leadership and management team cannot see the system because they are focused on the wrong things.

No sweat man.

This is the classic cut the tail off the dog optimization. Let's keep the new innovative engine (platform, et cetera) but let's not make it work very hard. Because that's a great way to test a system.

Super size me please

The giant batch size problem

Waiting is one of the wastes of lean. Often we see system builders design the system to work in giant batches. The problem with giant batches is that the customer and the next station in the system is waiting while the prior station is still working. Waiting is waste.

Quality. Oh, quality how I miss you.

Until this giant batch is delivered we will have no idea what the quality is. And when we inevitably find defects in the batch most or all of it will be sent back, creating more waste in the system.

Markets change

Market conditions also affect the choices we make about batch sizes. Economic factors teach us that market conditions change. The decisions we made before we released this giant batch are now based off of stale information. The market may have dramatically changed. The prices of the widgets or feature(s) you are building in this big batch may no longer be as valuable as they were at the beginning.

Really slow with extra waste please

Another long video showing how too much WIP slows the system down. It crumbles under its own weight and struggles to move fast.

Economics of decision making

We have explored some examples of how our decisions result in a system that is far from optimized, has lots of waste, and also make not even be working.

Next let's explore some of the tools that we can build into our systems to help us build tools, processes, even mental models that can help us build optimized systems more reliably.

a train with 28% wait time

As you can see in the screen shot above this train example in flow, live, had a wait time of 28%. When playing the game, this is a very useful metric to understand where the constraint is in the system. 

It is also a direct indicator of the economic costs of our design and architecture and development in our system as the wait time affects the profitability of the line.

A profitable train is a train working in flow

The train pictured above is operating nominally in the system. It has zero wait time and is profitable. The constraint is clearly not located here. Move on to something else.