Defining Strategies That Lead to Initiatives

Strategy is a huge topic, and we will not attempt to cover it here. What we will explain is how to factor agility into one’s strategy.

The Fiscal Basis of Agility

Agility is the ability to change quickly—change one’s implementation approach of even change one’s strategy. Thus, the value of agility is the value of unanticipated opportunities that one can capture because of one’s agility.

The phrase “unanticipated opportunities” seems pretty nebulous. What we mean is opportunities that might arise, which would cause us to change our current direction.

The value of agility is the value of being able to capture unexpected opportunities

Of course, we cannot anticipate an unanticipated—by definition. But we might nevertheless be able to conclude that unanticipated opportunities will arise, and we might impute a general value to those. That value is the value of agility.

For example, suppose that world events suddenly make it infeasible to obtain parts from one of our suppliers. We could not anticipate those world events, but now we need to change suppliers. If we have already paid our current supplier in advance, in order to obtain a low price, we now might be short on funds and might not be able to change to a new supplier. Instead, we might have to wait things out, hoping that things will change soon and we can resume business with the supplier. While we wait, we lose money. That loss is the opportunity cost of the lost business. It is also the value of being able to switch suppliers—an ability that we did not have.

Let’s consider a slight variation on the above example. Suppose that we would like to switch suppliers, and we have the funds to do so, but our logistical and digital design systems are connected to our current suppliers systems. Changing to another supplier might require a large IT effort to “plug into” the systems of another supplier. If our IT capabilities have technical agility, then we might be able to make the switch very quickly, thereby capturing the opportunity that we would otherwise lose. Thus, our technical agility translates into being able to shift our technology rapidly so that we can track market opportunities.

Types of Business Agility

Business agility is usually one of,

Financial commitment agility: long term leases, supply chain contracts, and labor contracts lock you into your current strategies.
Funds agility: financial assets that are not liquid cannot be rapidly diverted to new uses, although it might be possible to borrow based on non-liquid assets.
Market agility: if you need to pivot to new customers, you have a very long climb. Thus, if there are markets that are adjacent to your current products, shifting your products might be easier and faster, since they would be the same customers.
Product agility: the ability to rapidly make changes to one’s products and services, and be responsive to customer feedback about those products and services. This is what the “Agile community” is talking about.

Currently, Constructive Agility only seeks to address number 4, product agility. We may expand it however to encompass some of the others. Our example above of “plugging into” the systems of another supplier is an example of product agility.

Strategy Manifests Through Spend, But Also Through Behavior

A strategy is not a work plan. It is a set of choices about how one will proceed—choices that will maximize one’s chances of success in one’s overall endeavor. Those choices should include actions, such as investments in new initiatives, as well as choices about how to perform the actions.

For example, entering a new market niche might be a strategy that exploits one’s access to particular customers. Along with that strategy, one might have a strategy of using a very customer-focused approach: that’s a choice about how to perform strategy of entering the niche market. As such, it is a go-to-market strategy.

Agility is a strategy. If one values agility, one will approach things differently than if one does not. For example, if you want to retain flexibility about which suppliers you use, then you might make sure that your systems for connecting to your suppliers are very well understood and maintained well, so that your teams can rapidly switch to another supplier. This should affect the behavior of those teams: they need to make the maintainability and flexibility of the supplier connections a priority when they work on those systems.

In planning your initiative, and any subordinate initiatives, identify strategies for ensuring that the right approaches are identified and pursued. Challenge those who lead each initiative to identify a running list of strategies.

Do Not Fully Commit Capacity

Agility requires preserving capacity so that when you need to change things, you can. If everyone is fully committed based on promises made, then there is no room to pivot. Leaving some capacity uncommitted is therefore a strategy for agility.

Not being fully committed does not mean that people are not well utilized. It means that decisions about priorities are pushed out, rather than decided way ahead of time.

Plan In terms of capabilities

Commitments should be at the capability level, not the feature level. That way, if priorities shift, one can often remove some features to get back some capacity, while still being able to realize the promised capability. The farther a commitment is in the future, the more vague it should be. This is known as a rolling wave planning approach. Commitments in the future should be general and flexible, so that a managers can make decisions about specific features tactically without affecting commitments.

Treat Strategy as an Experiment

Like any decision, your strategies should be seen as tentative—as “experiments”. What we mean is that you should always be watching for events and new information that change assumptions that went into your strategy formulation. Revising strategies should not be a calendar-based process: it should be continuous. Sometimes an event occurs or new information arrives that invalidate a strategy: in that case, adjusting strategy might be urgent.

Be evidence-based, and be event-based.

A strategy should therefore have metrics that indicate if the strategy is working. If you do not have metrics for a strategy, then the strategy is ad-hoc. As an example, if you maintain a strategy of preserving capacity to maintain tactical flexibility, as we described above, you might track the times that product managers change the priority of features in the course of development: if changes are frequent, then they are making good use of the flexibility. Remember though that a metric is seldom proof: it is an indicator. There is never proof: there is only evidence. Certainty is a scale.

Choose Partnership Over Transactions

A customer-supplier relationship is inherently adversarial: each has an interest in exploiting the other. In contrast, partners share a common interest. Therefore, try to create a partnership with each stakeholder. That includes third parties who supply you with components or services.

Dr. Dan Rasky is director and co-founder of the Space Portal at the NASA Research Park, whose mission is “to be a friendly front door for emerging and non-traditional space companies”. Rasky’s office works to create partnerships between NASA and aerospace contractors, rather than traditional vendor-supplier relationships. His work has been highly successful, one of those successes being SpaceX.

In a recent interview with Agile 2 Academy, Dr. Rasky explained,

“[public-private partnerships are] really an effective way to operate and we're seeing more and more programs and solicitations using this public-private partnership approach which we really pioneered with COTS and with the CRS programs…”

The keys to making a partnership possible with a supplier are,

The supplier has to have funds at stake: if the ultimate outcome of the overall endeavor is successful, they need to share in that success, and if it is a failure, they need to share in that failure.
The specs given to the supplier need to be based on capabilities, not detailed requirements. That way, the specs can remain fluid, and optimized for mission success instead of being tightly controlled.
There needs to be active technical leadership that works proactively and collaboratively to resolve integration issues that span the system and the components being designed by suppliers.

It is not always possible to create a partnership with all suppliers. For example, if there are many systems using the components being developed, it might be necessary to lock down specs ahead of time. But if a more partnership-like relationship is possible, it helps to naturally align everyone around mission success.

Properly Balance Opportunity, Risk, and Cost

Organizations used to treat risk as something to eliminate. Traditional risk management approaches focus on having a risk mitigation plan that is expected to remove each risk. Systems are assessed for risk, often using a risk control framework, and if a risk remains unaddressed, the system either cannot be deployed, or a business stakeholder must “sign off” on accepting the risk.

That approach treats risk as binary: the risk is there, or it isn’t. But that’s not how things actually work. Risk is always a matter of degree. One can rarely entirely eliminate a given risk: one usually can only reduce the risk to an acceptable level. The question is, what is that level?

Risk needs to balance opportunity, and also account for one’s risk tolerance. A large opportunity might justify a large risk, if one has high risk tolerance.

Balancing opportunity and cost is more intuitive than balancing opportunity and risk. But for both, people tend to have built-in cognitive biases that cause them to evaluate risk poorly.* The alternative is to analytically model these things (see “The Mathematics of Agility and Risk” in the panel at the right), but that takes a great deal of effort, and an even bigger obstacle is getting the data that such a model would need. So we really need to refine our ability to assess opportunity and risk intuitively, or at least logically but informed by educated guesses about likelihoods.

The key is not to treat risk as binary. Risk is a chance that something will go wrong. Choosing the amount of effort to put into mitigating certain risks must be balanced against the alternative uses of that effort to increase the likelihood that the opportunities will be realized.

Here is how this affects strategy: A strategy is an approach for achieving something. The strategy should not include removing all risk. It should be based on balancing risk and opportunity, weighted toward one or the other depending on your risk tolerance.

* This is the main thesis of the book Noise: A Flaw in Human Judgment, by Daniel Kahneman et. al.)

Create a People Strategy

Your people strategy needs to embed your decision about how important and fungible human skills are for your initiative. In the high tech arena, human skills tend to be a primary constrain on the speed of getting product to market, and thus people are highly valued. That is not true in other industries.

People should always be treated with respect. The variables pertain to the efforts made to retain, train, and hire, and how those will be done. Your strategy should address those three things. Your retention strategy should be integrated with your strategy for your culture and leadership: remember, having a difficult boss is the number one reason why someone leaves a job, and your culture determines how people in leadership roles behave.

We cover defining a people strategy in the panel on the right, and defining a people function in step 4, in the subtopic Define a People Strategy.

Create a Data Strategy

According to Andrew Ng, former head of the AI teams at Google and Baidu, “we need to shift in mindset from big data to good data”. His point is that data quality is very important for a digital organization that wants to be able to leverage its data for machine learning. He also says that it is important that we have the right data, and to ensure that , we need to include machine learning experts in deciding what data to collect.

The time to start thinking about that is at the beginning. If you suspect that you will be creating data that will have value for machine learning, bring in a machine learning expert and a data architect, and have them start collaborating on the kinds of data that need to be collected and maintained well. And have them collaborate with the development teams to develop technical strategies for achieving that in a way that still enables everyone to go fast.

See Defining a Data Strategy.

Subtopics

Coming:

Technique: Collaborative strategizing.
Technique: Goal Portfolio Management - to define strategy
Technique: Developing the behavioral components of a strategy
Technique: Planning for capabilities. [ref EDGY]
Technique: Defining a strategy as a Lean experiment
Technique: Defining a Rolling Wave roadmap
Technique: Define a business model that balances opportunity, risk, and cost
Technique: Define a people strategy
Technique: Define a data strategy

Of Ancillary Interest

The Mathematics of Agility and Risk

The value of agility is pretty intuitive. Risk is intuitive as well. Both agility and risk can be modeled mathematically. We do not advocate trying to do that in most cases: among experienced managers, human judgment can be pretty accurate if one is trained to avoid certain cognitive biases, and is a lot faster. But for those who are interested, we offer Chapter 11 of the book Value-Driven IT, by Cliff Berg. This chapter delves into mathematical approaches for modeling the value of agility and risk, using “real options analysis”.

Quick Links

Intro