Practical Simplification in Agile

We humans like to simplify complicated things. Simple things are easier to understand than complicated ones. Simple problems are easier to solve than complicated ones. Simple goals are easier to achieve than complicated ones. It’s understandable. It’s practical. It’s useful.

Like anything else, simplification can be taken beyond the point of diminishing returns. It’s easy to fall into the trap of binary thinking. Have you heard (or said) things like this?

• The only customer that counts is the “external” customer.
• There is only one metric that matters.
• We either succeed or fail in our work; there are no mixed outcomes.
• If you focus on the big picture you lose track of the details, and vice versa.
• Once we’ve implemented X, we’re Agile.
• It’s all or nothing; either you’re fully Agile, or you’re nowhere

I’m sure you can see how easy it is to fall into that trap. I’ve done it, you’ve done it, we’ve all done it. That guy behind you, trying to sneak out of the room to avoid this topic, did it just this morning.

I’m not suggesting this degree of simplification is automatically or always a Bad Thing. It can be a Good Thing when we do it to help ourselves focus on a goal, problem, or learning opportunity. It can become a Bad Thing when we lose sight of the larger context of our work.

Only One Customer?

Is there really no other customer besides the “external” customer? Clearly, the external customer is the one who experiences whatever level of service we provide, and they’re the one paying the bill. That’s the customer whose needs drive everything. If the “external” customer isn’t satisfied, then it won’t matter how well we do everything else. So, yes, that’s the most important customer.

But is the “external” customer literally the only stakeholder whose needs must be met? When we oversimplify and forget context, we may not pay appropriate attention to other stakeholders. Ultimately, that can lead to poor results for the “external” customer, as the underlying systems and processes we use to provide value become ineffective.

If we sell a software product, or we sell a service that is supported by software systems behind the scenes, we have “internal” customers as well as the “external” one, such as:

• Operations
• Technical support
• Software testers
• Software developers/maintainers

If we ignore those stakeholders, how long will our systems be able to support our “external” customer effectively?

Only One Metric?

Is there really only one metric that matters? There is some value in approaching it that way, if you do it mindfully and with specific intention. For instance, we might deliberately apply the One Metric That Matters (OMTM) model as a way to focus on a specific area of improvement and expose the next most important area. But this doesn’t mean other metrics are literally without value, and can safely be ignored; nor does it mean the metric we’re focused on today is the one we should focus on tomorrow.

The Fitness for Purpose Framework suggests there are four categories of metrics, all of which are important:

• Fitness criteria (KPIs) with thresholds
• Health indicators with a healthy range
• Improvement drivers with a target
• Vanity metrics to make us feel good

Of these, the fitness criteria are directly relevant to customer buy decisions and customer satisfaction. We have to identify who our customer is and understand their needs accurately in order to know which KPIs are important and what their thresholds should be.

We can apply similar thinking to ensure we’re satisfying the needs of secondary stakeholders or “internal” customers, as well. If our systems provide what the “external” customer cares about, but they do so in a way that isn’t manageable, sustainable, or supportable, we will not be able to keep our customers happy for very long.

It’s a Good Thing to focus on the “external” customer so that we properly understand what to deliver. It’s a Bad Thing to take that line of thinking so far that we forget about other stakeholders.

It’s a Good Thing to focus on a single selected metric (probably temporarily) to help us home in on a problem area and drive improvement. It’s a Bad Thing to drive all our effort toward making a single number look good, at the expense of other aspects of the business.

Only One Flavor of Success?

It’s a commonplace to say that we learn from failure and not from success, and personally I’m tired of arguing against that sort of binary thinking. So, I’m not arguing; I’m just making a statement. In a 2014 blog post, I wrote:

–start–

…anything we do has an outcome. From the perspective of any given stakeholder, that outcome may be

• life-altering
• very positive
• somewhat positive
• mixed
• somewhat negative
• very negative
• irrelevant and uninteresting

When we consider the perspectives of all stakeholders, any given outcome is likely to be all of the above at the same time. Whether a stakeholder deems an outcome to be a “success” or a “failure” depends on how the outcome affects him/her.

–end–

I also suggested that our definition of “success” is merely that the outcome we achieved happened to correspond with our expectations, and our definition of “failure” is merely that the outcome happened to differ from our expectations.

I still think that’s true. Reducing every outcome to a simple pass/fail is an example of taking simplification beyond the point of diminishing returns. Outcomes are more nuanced than that.

We can say a “very positive” outcome is success and leave it at that, but if we do so we may be missing a learning opportunity. We may say a “very negative” outcome is failure, but if we do so we may drive an emotional response that inhibits people’s ability to learn from the experience.

Besides that, how do we categorize as binary success or failure an outcome that is “very positive” for stakeholder A, “very negative” for stakeholder B, “mixed” for stakeholder C, and “irrelevant and uninteresting” for stakeholder D?

A simple pass/fail assessment may be useful at times. It can help us focus on how well we met a specific goal. But that single perspective doesn’t come close to truly understanding a complex situation.

Only One Level of Detail?

Whenever someone discusses the Big Picture, others will be quick to complain that they are overlooking important details and edge cases. Whenever someone discusses a particular detail or edge case, others will be quick to complain that they are losing sight of the Big Picture.

I suggest it’s important to cultivate the ability to zoom in on details and edge cases and compartmentalize our thinking to handle them appropriately, as well as to zoom out and contextualize those details within the Big Picture. When we’re doing one or the other in a given moment, it doesn’t mean we’ve completely forgotten the other perspective.

It’s key to learn to recognize when to shift our focus in or out. If we get stuck at the detail level, we’ll do just what the critics fear: We’ll lose sight of the larger context. If we can’t focus on a detail without being distracted by concerns relevant in the larger context but irrelevant to the detail of the moment, we’ll constantly churn and be unable to resolve anything.

Only One Step to becoming Agile?

It’s been my experience that many client organizations assume whatever they happen to be doing is “good enough,” and that when they “implement” or “install” or “adopt” some sort of “agile” framework or method that they’ve flipped the switch and become an agile organization.

But that isn’t how it works. Agile thinking includes the ideas of continuous improvement, frequent introspection and reflection, and dynamic adjustment of goals, funding, and practices to maintain alignment with the organization’s mission and objectives.

You can’t “implement” Agile, unless by implement you mean change the way you think about the business. If “implement” only means adopt some buzzwords and go through the motions of a few rituals, then you’ve missed the point.

Consider this model of progress toward greater organizational agility, based on an Expedition metaphor:

When we help a client move from the Predictive-Emergent quadrant into the Predictive-Convergent quadrant, toward Basecamp 1 according to our Expedition model, they often assume that they’ve flipped the switch and become an agile organization; that they’ve transitioned from a well-functioning traditional model to a well-functioning agile model.

But what we often find is that organizations operating in the Predictive-Emergent quadrant don’t quite know

• what their products are
• what their value streams look like
• who their customers are and what they want
• what their market is and how it’s evolving
• what their overarching mission is
• what their strategic plan is
• which of their activities is mission-critical
• what their actual software delivery capacity is
• the true cost of cost-saving measures in operations and support
• what systems are running in their environment and how they’re related
• approximately how much any given initiative will cost or how long it will take
• whether they should halt work in progress to start a new initiative for good reasons, or just because a different wheel starts to squeak
• how to manage funding in an agile way
• why they should limit WIP or how to do so
• the difference between maximizing utilization and maximizing throughput
• when and why to change priorities and how to make the shift smoothly
• how to measure what they’re doing or what to do with such information if they had it
• where they ought to be headed and what steps to take next

For larger, established companies, the journey from the starting point toward Basecamp 1 isn’t a question of shifting from a well-functioning traditional environment to a well-functioning agile environment. It’s a question of reining in the chaos, identifying customers and their needs, understanding the market and how it’s evolving, setting some business objectives and learning how to assess opportunities and prioritize work, visualizing the current process, getting appropriate measurements around things, establishing a predictable system of delivery, and setting the stage to enable the organization to begin moving toward greater business agility.

It can be a Good Thing to celebrate having reached this milestone. It only becomes a Bad Thing when you assume you’ve finished. You haven’t. You’ve just begun.

Only One Valid Operational State?

When people first learn about Agile concepts, methods, frameworks, and so forth they become enthused and excited. That’s understandable. Many Agile consultants, coaches, and trainers are highly enthusiastic and want their clients to achieve the best results possible. Sometimes, they can underestimate the difficulty of going from Here to There.

A mantra in some parts of the Agile community is: “Change isn’t hard. It’s like adding milk to coffee!”

If you’re talking about adding a tablespoon of milk to a cup of coffee that isn’t already filled to the brim, then sure. If you’re talking about adding milk to 100,000 cups of coffee of different sizes and shapes, all of them already full, some cracked and leaking at different rates, doing it without interfering with people who are drinking from the cups at the same time you’re trying to add milk, and each cup requiring a specific amount of milk of a particular type and at a desired temperature, keeping each cup at the temperature its drinker prefers throughout the process, when you don’t have enough equipment or infrastructure to service that level of scale or variety, and your organization has no established procedures or institutional knowledge of working with massive quantities of coffee and milk, then no. It’s hard.

It’s hard, and it doesn’t happen in a single step. Hence the Expedition metaphor. There’s a progression of steps to take, and logical places to stop, rest, resupply, and reassess the plan.

And there’s more. Different business operations within the same enterprise may need to interact with their markets differently and build their products differently. Some areas may need to operate similarly to a Lean Startup (corresponding roughly with our Basecamp 5). Others may need to stabilize a more-traditional pace of delivery, stopping at Basecamp 2. It depends on business needs. There’s no single, simple answer.

For instance, in a large bank we work with, the target Basecamp for customer-facing mobile and web apps is Basecamp 4; close to a Lean Startup model, with a fully-automated CI/CD pipeline requiring only a management “Go” to release. They want to be able to turn changes around in the mobile and web apps in a matter of minutes, with full safety and compliance. The same company aims for Basecamp 2 in its backend core banking system area, as those applications are stable and rarely change. They want to be able to deliver changes in 3-4 months.

If they wanted to switch their main corporate database system from, say, Oracle to DB2, what value would be added if the programmers interacted directly with people who have checking accounts at the bank; the “external” customers?

When Agilists tell you your development teams must interact directly with “external” customers rather than with any sort of proxy or “internal” customer, they’re thinking about the ultimate, pristine Agile model. They may not be considering the realities of your organization.

A company operating at the Basecamp 1 or 2 level probably can’t achieve that pristine goal. Imagine a large company that makes network switches. I’m imagining one in particular. Every release of their hardware and software must be backward compatible with all the equipment currently in use in the field. The company I’m thinking of operates at 10 locations in 7 countries. It’s common for their projects to involve 750 people, with multiple teams contributing from multiple locations. Do you think an “external” customer of network switches in, say, Brazil will interact directly with Engineer #7 on Team #345 in Hungary and with Programmer #13 on Team #764 in China? How would that help?

The insistence that developers interact directly with “external” customers takes the simplification of organizational structure beyond the point of diminishing returns, and it becomes silly.

Most Basecamp 1 organizations haven’t fully transitioned to cross-functional teams. They still have functional silos that aren’t aligned with products or value streams. The “customer” for the Programming team is the Testing team. The “customer” for the Testing team is the Integration Team. The “customer” for the Integration Team is the Deployment Team. The “customer” for the Deployment Team is the Production Support team. It won’t remain that way forever, but for the moment it’s the reality. Each team performs best when they treat the downstream team as a “customer” in the true sense, even if from an enterprise point of view they are not actual customers. We have to be realistic and flexible in such matters. And of course, eventually all those activities will be handled by a cross-functional Development Team. But not today.

You might wonder if it’s even possible for internal development teams to work directly with external customers. I’ve seen it, but only when a young company is in the starup phase. A company I know of makes IoT devices that monitor the health of industrial equipment in situ. During their startup phase, their engineering/programming team (20 people) collaborated directly with two early adopter customers to prepare the initial production release of their product. Now that they’ve outgrown the startup phase, they have more than 20 engineers/programmers and more than 2 customers. The pristine Agile vision of developers working directly with “external” customers is no longer feasible.

In this section I’ve harped on just one piece of Agile dogma; the requirement to work with “external” customers. There’s a laundry list of things Agilists would prefer we do, and the feasibility of each one depends heavily on the situation at hand. It isn’t helpful to be dogmatic about what is or isn’t Agile across all contexts. It’s a process of continual improvement. As long as you’re introspecting and improving, you’re on the right track. Beware of binary thinking.

Conclusion

Simplify when simplification helps you achieve an objective, but take care not to start to think of the simplified model as the Real Thing. It isn’t.