Advisor

Ingredients for Enterprise Agility, Part I: The Countdown to Enterprise Agility

Posted January 28, 2021 in Business Agility & Software Engineering Excellence
Ingredients for Enterprise Agility, Part I

This article is the first in a series of Advisors that will outline some of my lessons from leading Agile transformations. Enterprise coaching combines in-depth knowledge of contextual Agile with the use of cultural change techniques to create a path to enterprise agility. As an enterprise Agile coach, I am frequently asked: “How do I move our organization from traditional waterfall practices to Agile?” This question is often in the context of an IT function that, feeling the need to respond to business pressures for faster or better solution delivery or senior management, decides that their organization needs agility.

Many of the questioners know about Scrum and may even have a few teams but find the thought of making Agile their core functional approach daunting. This “Ingredients for Enterprise Agility” series provides a pragmatic guide to the introduction of new ways of working. Beyond Scrum, I will not link this series to any scaled Agile framework. Still, I will use some of the disciplined Agile principles, promises, and guidelines, as I have found these to apply to most Agile endeavors.

Getting started with Agile involves some organizational preparation; hence, the “countdown to enterprise agility” in this Advisor.

While becoming more Agile may be an imperative for an IT function, it is rarely a business strategy. It is fallacious to follow the Agile certification factories’ propaganda that enterprise agility comes from changing an IT function’s working practices!

As an example, the Scaled Agile Framework (SAFe 5.0) talks about business agility as “the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative business solutions.” It then goes on to assume that business solutions produced by IT will “use Lean and Agile practices to continually deliver innovative, high-quality products and services faster than the competition.” In most organizations, product and services are delivered not by software developers but by the business operation and functions that an IT function supports. In these organizations, changes to IT working practices will only indirectly influence customer journeys, value creation, and speed to market.

If enterprise agility is the strategic goal, the place to start is not IT but the business operation. However, we can make use of some of the Agile wisdom and apply this to business processes. For example, in Lean Software Development, Mary and Tom Poppendieck discuss mapping the software delivery process as a value stream and recommend that practitioners optimize the whole process. Although the origins of cross-functional teams is from the operations management discipline, the Agile practice has made this type of team organization more common. An Agile enterprise needs to revert to operations management practice to create customer-facing, cross-functional business teams responsible for paying customer journeys. These teams will use operational value streams created by the combination of manual processes and application systems. These operational value streams need to be optimized, which is where classic Agile approaches fail.

As proposed by the certification factories, most Agile practices ignore the relationship between the operational value streams and IT’s development value streams. Optimization is talked of in terms of software engineering practices and not business operations. Product ownership is often described with the premise that developers engage directly with customers. Outside of organizations that design and sell software, this premise is mistaken. Consider an insurance company, where customers who buy insurance are unlikely to realize their need for or the benefit of insurance as a result of their discussions with the developers. If discussions with customers are to be had, these will be relevant to the owners and designers of insurance products, not application systems. The fact is that the development team’s customers are the people who use the operational value stream to deliver insurance products.

It is the operational value stream that should be improved by development activities. This value stream needs to be defined and owned from start to finish. By improving and optimizing the operational value stream, the organization improves customer satisfaction and reduces operational costs, creating enterprise agility. I find genuinely incredible the fact that core Agile practices ignore this. Improving the development value stream merely provides changes to the operation faster and at a lower cost. Outside of software companies, if the improvements developed by the Agile IT teams do not directly improve the organization’s delivery of products and services to customers, then that improvement has little value.

This lack of clarity is worrying. The Agile certification factories proffer versions of Agile that have a single industry focus: the software industry. But the vast majority of enterprises are not software businesses but software-enabled organizations that sell other goods and services. This distinction goes to the root of Agile. For example, the product owner’s role is not described with responsibilities relating to the operational value stream, yet these exist. In shaping requirements, prioritizing work items, and planning minimum business increments of software, the product owner changes and improves the operational value stream. Care must be taken not to open the organization to operational risks as solutions are incrementally improved or delivered.

So how does an organization move toward enterprise agility? The starting point is usually an executive decision to use Agile methods to improve the target operating model (see Figure 1).

Figure 1 — The steps to agility.
Figure 1 — The steps to agility.

As alluded to earlier, the first thing to do is select an operational value stream to improve. In most organizations, products and services are delivered to customers by a value stream that crosses a functionally aligned organization. In truth, a functional hierarchical organizational design does not best serve customers but instead serves the enterprise’s management. John Kotter in Accelerate and Stephen Denning in the The Age of Agile propose an alignment of the organizational structure with the operational value stream. They propose a radical shifting of responsibilities from the traditional hierarchy to the value stream–aligned organization. Their arguments for aligning organizational focus with the serving of customers are logical and compelling. However, this type of change requires careful planning and creating a support model for the people as they transition.

Initially, an organization will create a value stream organization by assigning people from functions to the customer-serving team. Typically, they will continue working in the same way as they did previously, and then they will begin to transition. Without changing the ways of working, the organizational structure will be altered but the customer service and service cost will remain the same.

The next step involves the IT function, the product owner, and the development value streams. Initially, the application systems will be aligned with the objectives of the hierarchical functional organization. It is also likely that the applications do not support an end-to-end view of the customer journey, so development is needed.

A product owner is needed to map the end-to-end operational value stream and the supporting application systems. In this mapping, inefficiencies, lack of data, and management information will be revealed, and developments will be identified, prioritized, and initiated. The new ways of working will be established. As the organization beings to transition, coaches and training will be needed, and new operational KPIs will be required.

The last step will be to measure the benefits. If customer satisfaction or time to market are the organizational goals for agility, then progression metrics will be needed. In the case of customer satisfaction, net promoter score may be monitored; lead time can be measured in the case of time to market. Additional metrics will be needed to monitor the operational value stream’s cost, capacity, and operational efficiency.

This Advisor has outlined the differences between operational and development value streams. We’ve established that enterprise agility starts in the operational value streams in all but software businesses. And I have outlined that the classic Agile approaches need to be modified for most enterprises, particularly in the product owner’s role to develop support and optimize the operational value stream. The next article in this recipe for enterprise agility will talk about organizing and planning for enterprise agility.

About The Author
Jon Ward
Jon Ward is Senior Consultant with Cutter Consortium’s Business Agility and Software Engineering Excellence practice. As CEO for Beneficial Consulting, he focuses on the cultural and transformational aspects of implementing Agile. Mr. Ward currently acts as an Agile catalyst, producing significant bottom-line results for software and business change initiatives. Using Lean-Agile techniques, he redesigns target operating models for efficiency and… Read More