“It’s not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”
— Charles Darwin
“Change before you have to.”
— Jack Welch
“I think Smithers picked me because of my motivational skills. Everyone says they have to work a lot harder when I’m around.”
— Homer Simpson
Why start a discussion on business agility with “change”? Because one core principle in business agility will determine your level of success: Agility is based on being able to react faster, deliver value sooner, and reduce accumulated risk. The teams who develop a foundation and toolset to adapt to change will outperform traditional “command and control” teams.
This article is extracted from a presentation I give on “Embracing Business Agility” and co-developed with Ryland Leyton. Here I want to focus on three key concepts that are critical to becoming more agile and responsive. Download the full presentation for more guidance on business agility.
- Defining what is your Minimum Viable Product (MVP) is key to knowing when “done is done”
- Shortening review and release cycles improves value earned and reduce accumulated risk
- Using the Cynefin Framework helps identify areas where agility matters the most
Defining your Minimum Viable Product
What is a Minimum Viable Product? Ask 3 people and you might get 7 examples. One of the challenges with MVPs is deciding at which point the product is “viable”. Is it the first prototype the team can react to? Is it the first product your customer can use? When is “done,” done?
Maybe the problem comes from trying to define the product and not the goal.
If we define the goal as building a car, we’d start with wheels and build a frame around them. Then we’d add a chassis. At some point, we’d have a completed car. After all this work, we’d finally have the first MVP we could test or sell.
Instead, what if we define the goal as a transportation solution? Now our first MVP might be a skateboard that increases our mobility. Once we see how the skateboard solves the transportation need, we can define what the next critical steps are to produce a scooter. After producing the scooter, we add more value by creating the bicycle. The bicycle MVP now allows us to add an engine and build the motorcycle. After the motorcycle, we finally know what the car should be. (Thanks to David Lee and Mark Pearson for the skateboard analogy.)
There are two important differences when we take the “skateboard” approach. First, we have viable products we can test internally or sell externally while we are working toward the car. This means we are gaining value at an earlier date and for a much lower investment. Second, before we produce the car, we have a whole history of learning and refinement before we get to the car. This also means that our car is going to be far better than the ones produced all at once.
Decreasing our time to value delivered through shorter iterations
In an ideal world, we could maximize our effort expending to value received, which is represented as the green dotted line. This means that for every amount of effort or investment we make, we achieve a value earned. The steeper the line, the higher value to effort ratio. Unfortunately, no real-world process can remove all waste or deliver 100% value for all effort.
When we look at traditional project/product delivery, we expend most of our effort with very little value earned (Red Line). As we start development and testing, we begin earning value through lessons learned or reusable work, but still don’t have anything ready to ship. It isn’t until the end of delivery that we attain the desired value.
Since this curve is standard for almost all efforts, our best choice is to shorten the cycle and find more releases where we deliver earned value. The blue path has the same delayed value curve and more opportunities to reach the value earned line. In this case, the delivery at the end of each cycle is represented using our skateboard path, with each MVP cycle delivering earned value. Our MVP and shorter cycles define when done is done for each step.
The gap between the blue line cycles and the red line cycle is waste or missed opportunity in our traditional delivery model.
Reducing accumulated risk through shorter cycles
We can look at the same cycles as they apply to our project/product risk. In our traditional delivery, we continue to accumulate risk as we expend more effort without delivering value (ready to ship). Once we get into development and testing, we quickly start reducing risk as we validate the solution and viability. At the end, we have a viable product that can be tested or sold. If anything goes wrong during the process or we cancel the effort, we’ve lost most of the investment up to that point. We may have some lessons learned or reusable components which would then affect the shape and height of the delivery curve and risk (lost effort) accumulated.
Instead, if we apply our skateboard model and use smaller delivery cycles and MVPs, we dramatically reduce the risk accumulated before we validate the solution. Our delivery still has the same risk curve, but we dramatically reduce the height and duration of the risk before we start reducing risk by validating the solution and having something we can ship. Again, each cycle can be tied to our MVP skateboard model to define when we can deliver the solution and remove risk. And again, the gap between the blue line and our red line is the additional accumulated risk and waste in our traditional delivery cycle.
Cynefin Framework – Identifying where smaller iterations add the most value
To help identify which business areas are best for an iterative or more agile approach, we can use the Cynefin framework. For more information on using this model and understanding the business areas, refer to Wikipedia or a number of YouTube videos from the framework creator Dave Snowden.
Let’s start with Simple in the lower right and work counter-clockwise.
In a Simple environment, we are dealing with “known, knowns”. In this case, we sense the change, categorize it into our pre-defined groups or processes, and then respond based on our policy or procedure. This model is typical of your customer support network and routine operations. We already know what will happen and how to handle exceptions. All we need to do is identify, sort, and act. Agility and shorter cycles don’t add value here because we’re not responding to an unknown change with high risk.
Complicated is similar to most of our projects. We generally know what we don’t know and have an approach to define the unknowns. Here we follow the pattern of examining, analyzing, and responding. By taking areas of unknown risk and analyzing them in shorter cycles, we gain a benefit over a one and done approach. Think about building a car. We generally know what we will need to solve for, but whenever we can validate it in smaller chunks or find earlier products that can ship, we’re reducing risk and delivering more value.
In Complex environments, business agility dramatically outperforms traditional or waterfall approaches. These are typically emergent or disruptive areas where we don’t know what we don’t know yet. In this case, we must probe, sense, and then respond. This becomes our iterative skateboard cycles. We are likely to go through many internal review and validation cycles before having a product or service that is ready to test in the market. Similarly, we may have Complex challenges internally such as shifting work patterns to use social media-based communication tools. The business agile approach is to use smaller teams and then employ different tools to probe and sense how the teams are benefiting. Then we respond by expanding the proof of concept until we find the right tools for each team’s culture.
If we are in a Chaotic space, then our goal is to move the domain to become Complex. There isn’t enough stability or information to setup learning cycles. Act, see what happens, and respond accordingly. Once we stabilize the situation, we can follow the Complex model.
In conclusion
We’ve only hit a small portion of the business agility discussion, but hopefully this will give you a perspective to start from.
- Look for smaller iterations and deliveries where you have a product you can test, use, or sell.
- The more effort you put into an iteration, the more risk you are accumulating.
- Domains where you have “Known, Unknowns” or “Unknowns, Unknowns” are good places to use shorter iterations.
- The goal of business agility is to be able to respond to change faster and more effectively.
Good luck, and keep adapting to change.
