I recently received an email from a colleague seeking advice by way of suggestions for his focus for 2021 (I have paraphrased and anonymized the email):

From: A Client
Sent: 24 December 2020 15:17
To: Jon Ward
Subject: Ideas for 2021, please?

Looking ahead to 2021, a challenge comes up in my work environment, an insurance company of about 3,000 people in six value streams and five enabling shared service functions (four from IT and one from financial services). There are also numerous chapters or centers of excellence such as legal, privacy, compliance, and audit.

As a coaches community during 2020, we have created breathing and thinking space. We are nudging this organization to rely more on the network structure; investing in a more inclusive, listening culture. We have established a multidisciplinary guiding coalition; we have the hierarchy and leaders “listening” to more than business results metrics, etc.

Bottom-up, there are individuals and teams asking for more overall clarity of purpose and identification of the business value they actually deliver. We also have the IT domains aiming to create a service catalog to establish a demand-supply dialog between IT services and the value stream reality. Given the current situation, how would you recommend that I proceed in 2021?

This situation interested me, as the alignment of business functions in value streams is a premise of the network organization or dual operating model proposed by John Kotter and Stephen Denning. I have spent much of this lockdown year doing desk research and remote interviews with senior change managers and heads of operations collecting their thoughts and experience of the network organization. My research spans several business sectors, although there is a bias toward financial services. The subject of my investigation was how an organization can apply the “new direction” proposed by John Kotter in Accelerate:

The hierarchy part of the dual operating system differs from almost every other hierarchy today in one very important way. Much of the work ordinarily assigned to it that demands innovation, agility, difficult change, and big strategic initiatives executed quickly — challenges dumped upon work streams, tiger teams, or strategy departments — has been shifted over to the network part. That leaves the hierarchy less encumbered and better able to perform what it is designed for; doing today’s job well, making incremental changes to further improve efficiency, and handling those strategic initiatives that help a company deal with predictable adjustments, such as routine IT upgrades.

Denning, in The Age of Agile, talks about applying the lessons learned from uncovering better ways of developing software. When applied to the broader business, the principles of the Agile Manifesto require a reversal of some fundamental assumptions of 20th-century management. What if firms could create a workplace that drew on the collective intelligence of their people? What if organizations were redesigned to deliver extraordinary value to customers?

Denning suggests three laws for the new management paradigm:

1. The law of the small team — a mindset that work should be undertaken by small, autonomous, cross-functional teams working on small tasks with short feedback cycles.

2. The law of the customer — relates to the focus of Agile practitioners on satisfying the customer through the early and continuous delivery of value.

3. The law of the network — Agile practitioners see organizational structures as fluid, adapting to achieve the common goal of delighting customers.

Denning observes that C-level executives have the critical function of establishing strategy and direction in Agile organizations. With the whole organization aligned with these objectives, the link between the strategic plan and attainment of corporate objectives is strengthened.

Traditional organizations are organized by functions each with their business objectives, budgets, and KPIs (see Figure 1). The delivery of customer value is the result of the functions passing transactions from one to the other. The consequence is that strategy is disconnected for organizational reality. The organization design creates a lack of end-to-end accountability, delays in the process due to handoffs between functions. Overall a functionally aligned structure creates a loss of focus on the business imperative, the customer!

In contrast, in a customer-facing network, the organization is aligned to the value stream (see Figure 2). It is detached from the hierarchy, cross-functional, and is accountable for the process of delivery of products or services to customer end-to-end. In this format, the organizational design directly supports the business operation and the value streams that serve the customer.

The term “value stream” was introduced by James Womack, Daniel Jones, and Daniel Roos in The Machine That Changed the World. It is defined as the sequence of activities an organization undertakes to deliver on a customer request. The Scaled Agile Framework defines two types of value streams: operational value streams serving, customers as above, and development value streams, which develop solutions used by operational value streams. In all but a few types of companies (mainly organizations that sell software), the products or services customers buy are not produced by software engineers but by product managers (brewers develop new beer products, chemists new drugs, engineers new electrical components). So, depending upon the industry, an organization may have several development value streams aligned to their operational value streams.

Conway’s law states that “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” The consequence is that rather than having applications that support the end-to-end delivery of customer value, a traditionally structured organization will have created “islands of automation,” which do not facilitate the end-to-end flow of value to the customer (see Figure 3).

Typically, software teams will be aligned around applications rather than the end-to-end customer journey. So, the software teams supporting the operation are also not focused on the customer’s business imperative! As the network organization matures, the applications supporting the value stream will need to be optimized, streamlined, and integrated to create an efficient operating model.

In Implementing Lean Software Development, Mary and Tom Poppendieck introduced the seven lean principles, of which number seven is “optimize the whole.” They recommend that a lean organization should optimize the whole value stream, not just individual functions, or inefficiencies will result. Optimizing parts of the value stream will create bottlenecks and reduce the flow of transactions, meaning that the value stream will cost the organization more to operate and potentially reduce both customer and employee satisfaction.

In their book Learning to See, Mike Rother and John Snook suggested that an enterprise requires someone to undertake a value stream manager’s role. This role is a person or function responsible for value stream optimization and continuous improvement of performance. For example, this role would look at the business metrics of the value stream, the demand, the flow, lead times, and so on to increase customer satisfaction, reduce operational costs, or increase transaction accuracy. Based upon the “optimizing the whole” principle, this is an end-to-end responsibility that may initially result in changes across several application systems.  Referring to LeSS (Internal Product Development) “this individual should come from within the group which will use the system.” So, whether developers are internal or external to those delivering products or services to customers, improvements to the operational value stream are the focus.

One of the principles of Agile methods is the idea that the best way to organize teams is to create complete, multidisciplined, colocated teams having all the roles and skills they need to deliver a customer request from start to finish, without reference to other teams. Consequently, an organization may decide that the cross-functional team should be made up of people delivering products or services and include the people who will develop the applications that support the business operation.

I am currently coaching a team in British telecom that provides network monitoring. This team monitors the network and designs and develops the tools that they use. On the other hand, many organizations separate the operational activities from the development activity. This is obvious, as those people who, for example, write insurance policies, probably cannot write software and vice versa.

During my research, I found a Canadian bank adopting Agile teams with a value stream for customer service. The bank had 2,000 in a call center using General McCrystal’s team of teams concept from Team of Teams. All 2,000 were employed on the same value stream, but the work was divided between smaller teams working in concert. The Dunbar number suggests that 50 is the maximum number of people who can have a close working relationship and 15 is the maximum number for a close working group. So, in the Canadian bank situation, with more than 40 teams working in the same value stream, teams (although semi-autonomous) cannot be individually represented by a product owner. In this instance the value stream manager or function will act as product owner for the development team, providing priorities and requirements in the backlog based on their analysis and improvement suggestions from representatives of the customer-facing Agile teams.

My concern is that many agilists do not make the distinction between internal product development and customer product delivery. I am also concerned that the product owner role for internal development (which is most Agile development activity) is defined without reference to value stream optimization. I hope that these distinctions will filter across the Agile community during 2021.

A Reply to My Colleague

From: Jon Ward
Sent: 26 December 2020 06:20
To: A Client
Subject: Re: Ideas for 2021, please?

One challenge I have observed is caused by some Agile certification factories insisting that enterprise agility comes from IT. My local brewery, Adnams, introduces a new product approximately every eight weeks, and last had a significant software project two years ago! Adnams’s business agility has nothing to do with IT. Some agilists have stated that “every company is now a software company,” which can again be misleading. Many companies are software-enabled but their revenues are generated not from software (as, with Adnams, revenues come from beverages). This distinction is essential because, as agilists, we need to treat operational value streams with the same importance as development value streams if enterprise agility is the goal.

Given the scenario you paint, my recommendation is to focus on the non-IT operational value streams first. In particular, I would apply some of Mik Kersten’s Flow Metrics and Goldratt’s Theory of Constraints in the non-IT context. I suggest using elements such as value stream mapping, the Vanguard method, and Lean to identify evolutionary value stream improvements. Big picture–type improvements for insurance companies, such as data lakes and AI, eventually will need to be embedded in operational use or will be of little value. So, being clear about how these technologies will deliver better objectives and key results is essential.

The fact that some IT functions have developed service catalogs and are questioning the value they are delivering indicates to me a them-and-us culture between business and IT. The question I would try to solve is who owns the performance of each operational value stream? (By this, I don’t mean the revenue but the operational efficiency.) I would also clarify how improvement requirements from those responsible for operational value stream efficiency get fed into the development value streams. This will provide clarity over the provision of value.

Next, I would start to align the IT work slate with the operational value stream priorities. This would involve establishing the product owners as the agents of operational value stream improvement. Linking the product owners with the operational value stream will give you a bottom-up means of improving the dual-target operating model.

I hope this helps.

Jon