One thing in advance: Agility is always about creating added value for customers. Agility puts the end customer at the center of all decisions, just as we learned with the basics. This is certainly one of the biggest differences for business management as opposed to other management methods. And thus most certainly a major hurdle for any differently oriented company. These added values to be created for the end customer within a company process are mapped in the value stream. With this background and the basics of Lean Management covered in the previous lessons, the name Value Stream for this agile tool also becomes clear.
I can imagine that you are now asking yourself: A Value Stream is the same as a value stream? You are undoubtedly right about that. However, we make a clear distinction here between the value stream, which was created on the basis of a value stream analysis and is usually prepared graphically, and the agile tool Value Stream.
The value stream of a company is managed in the value stream, regardless of the granularity in which the value stream is recorded. For the company, every added value to be created for the end customer in the Value Stream is a challenge that is described with requirements and met with one or more solutions in the form of new value stream sections or the adaptation of existing value streams.
This exclusively end-customer-centric foundation works quite well for small agile companies that have had agility in their DNA since the company’s establishment and, ideally, are directly controlled by the company’s founder without much external influence. But even companies like Google, Microsoft, Apple, etc. with innate agile DNA eventually reached a size and ownership structure where additional challenges drive a company’s overall strategy. Whether we have a strategic challenge, an operational challenge, a regulatory challenge, or a sales-driven challenge, management is faced with a challenge that needs to be addressed with solutions in the business process. These challenges are therefore also included in the company’s Value Stream, with shareholders, regulatory requirements and even employees being viewed as customers by management during implementation and valued accordingly. Management serves as a performance partner to all internal and external customers.
Fig.: Challenges – *Source reference: 07
As a rule, a company or its management is confronted with more than enough challenges from all directions, which subsequently have to be solved. Nevertheless, it is necessary to also actively approach the customers to be served (whether they are end customers, shareholders, employees or others) in order to capture challenges that would remain undetected to the detriment of the company without active investigation, thus providing a competitive advantage. For large companies in particular, this active identification is a major challenge because the service portfolio, customer structure and employee needs are very complex. Some questions and methods help to approach the identification of undiscovered challenges:
- What sets us apart from the competition – both positively and negatively? And the whole thing from the end customer’s, shareholder’s and employee’s point of view.
- What are the goals of our competition and what are our goals?
- How do our end customers, shareholders and employees describe and receive the added value delivered by the company? Here, the classic survey is a good way to determine.
- In addition, there are then industry-specific issues that are gradually developed and periodically reviewed within the company
All challenges together are handled in one or more Value Streams.
Fig.: Value Streams – *Source reference: 07
In this graphic, the Value Streams are represented with gray arrow bars. In this example, we symbolically consider 2 challenges below each other, which are implemented in several steps. In the agile Value Stream tool are many challenges, but also values that a company imposes itself to comply with for whatever reason. The special feature of the Value Stream is that the challenges remain permanently in the Value Stream, are implemented in the value stream of the company and therefore remain permanently implemented and also permanently in the view of the management. A challenge only falls out of the Value Stream when the challenge no longer exists for whatever reason and therefore no longer needs to be supported in the company’s value stream.
Fig.: Value Stream Life Cycle – *Source reference: 07
In agility, the Value Stream is a tool for top management, which enables an always up-to-date information about the basis of decisions and instructions for action – a good overview of all permanent entrepreneurial tasks. It helps management understand, organize and, after a series of implementation steps, actually deliver the added value they expect. Conversely, this also means that the Value Stream must be worked through constant review, revision, expansion, cleanup, and coordination by management. From the large volume of challenges, management must constantly reassess where to direct operational capacity and with what priority to address which challenge. An unmaintained Value Stream tool and an unmaintained value stream in the company no longer reflect the actual situation in the company, are thus neither the basis for optimizations nor decisions, and have thus lost their task and effect. In contrast to the agile Value Stream tool, the value stream documentation is of course an important working tool for all employees for orientation and optimization.
Fig.: Silos – *Source reference: 07
The organization of one or more Value Streams in the company is free and depends on the individual requirements in a company. For example, in a large company it is conceivable that there is a large complex common Value Stream for all business units in which the challenges from the supervisory board are maintained. In addition, there could be a separate Value Stream per business unit with the challenges of the business unit. Or, the Value Streams in the business unit are again divided into sales-driven (i.e., customer demand-driven), operational, regulatory, and strategic Value Streams. Or the Value Streams are managed on a product-by-product basis. In extreme cases, a single Value Stream can even be maintained for each challenge – but then the mass of Value Streams in a large company becomes very confusing and the interfaces between the Value Streams become difficult to understand. What we definitely want to avoid when organizing Value Streams is the creation of silos, which is how we usually operate outside of agile today. An example to avoid would be organizing Value Streams by board departments or divisions. The background to this is that agile follows total solutions from start to finish, where previous silos work closely together in an agile way. This then also means that all silos together have a common goal and therefore also common Value Streams. Typical problems with the traditional silo organization are
- many handover interfaces and the associated
- waiting times and delays triggered by this,
- often too large work packages that need to justify an effort to use an interface between silos,
- handover error between the silos and
- different organizational processes in the silos –
- in extreme cases, also the refusal of silos to cooperate.
Instead, agility has the goal,
- to establish long-lasting and stable teams,
- focused on rapid delivery of value rather than processing tasks in a project,
- that team members learn from each other across silos and understand the requirements of other areas, through this deeper understanding can deliver faster and better solutions,
- and only thereby enable a leaner and faster development organization.
If you compare the agile organization with the classic silo organization, then you will also quickly realize that an agile transformation in the company is inevitably associated with a comprehensive reorganization in the company. From the very top to the very bottom, in its entire breadth through the company, hierarchies must be dismantled and thus delegating functions must be transformed into value-creating functions. Agile transformation does not, as is often assumed, merely involve revising the project organization, but is a far-reaching change process that extends all the way to redefining the corporate culture. And with that, it’s also clear that it will be a long-term evolution toward agility – but one that always starts at the top and is passed on by example from the top down.
For the overall understanding of agility, it is also important to understand that the Value Stream concept, which also includes the Solution and Release Trains included in the following lessons, replaces (not supplements!) the classic overhead organization for projects – and instead describes a leaner and closely collaborating cross-silo organization. But as already said: the organization is relatively free, is based on the needs in the company and is mostly individual and company-specific consulting content in the agile transformation. The Value Stream(s) and the Solution and Release Trains derived from them together form the organizational backbone of agile organization in large enterprises.
A challenge in the Value Stream is described with one or more requirements to solve the challenge. In the case of a requirement from management, the requirement object is “Portfolio Epic”. The management of a large company develops only Portfolio Epics, not lower-level requirements objects. This makes it clear to everyone in the further course of the project from which hierarchy in the company a requirement originates and what granularity the requirement thus has. It is still formulated in very general terms, does not contain any details or subject specifications, and primarily attempts to describe and narrow down the challenge as best as possible.
If a challenge cannot be described by management because it is not yet clearly identifiable but is already foreseeable, then the requirement is described with the Enabler object as a basis for clarification or investigation. The same applies to challenges that cannot be described by the company itself due to a lack of internal knowledge, but are developed by external consulting, for example. The result of the Enabler object then yields the description of the associated Portfolio Epic.
The agile Value Stream tool of a large company is very extensive and therefore not necessarily clear at first glance. In addition to new challenges that have not yet been solved, there are predominantly solved challenges in the form of Value Streams that require constant monitoring to determine the extent to which the solutions implemented still meet the challenge. In order to enable efficient monitoring given the large number of challenges, one or more KPIs are defined per challenge with value ranges that must be adhered to in the company’s operations. If a KPI value then falls outside the defined acceptance range, the value and thus the challenge must be visibly marked in the Value Stream (whether in a list or in a graphical representation) so that management can take corrective action in good time. Ideally, there is even a color gradation from green, yellow, orange to red to signal the initiation of the need for action. But don’t worry: management doesn’t have to sit at this tool constantly now, because with Lean Management well implemented in the company, management is supported by Lean Experts and Lean Managers in monitoring and optimizing the operational value stream. The management then only has the control function. By the way, agile project teams are responsible for controlling and optimizing the development value streams themselves. You will learn more about the distinction between these two Value Stream types in a moment.
As an aside, it should be noted that with well-implemented Lean Management and Six Sigma, there is almost no additional expense for DIN-ISO certifications. Both methods deliver the necessary foundations and processes free of charge as a by-product. This advantage is not so relevant for OEMs, which are at the top of the value chain and thus only serve consumers. However, the advantage is very beneficial for the majority of all companies that sell products and services to companies that use them is all too often forgotten.
Fig.: Value Stream Types – *Source reference: 07
So, now to delineate the 2 Value Stream types mentioned earlier: the Scaled Agile Framework (SAFe) defines 2 Value Stream types that have nothing to do with categorizing challenges:
- The operational Value Stream type contains the requirements, systems, and people that deliver end-user value by influencing the outcome of the
- development Value Stream type, that provides solutions to challenges from operational Value Stream.
The development Value Stream is therefore the basis for the operational Value Stream, whose solution describes a section of the overall Value Stream of a company. The development Value Stream develops the solution, and the operational Value Stream uses the solution. The development Value Stream is the foundation for a project. The operational Value Stream is the foundation for practiced business processes that ideally correspond to the value stream for the subarea. Ideally. They should.
The very first question a management team should ask when adopting agility is whether there is already a maintained view of all the business challenges and business values that have already been solved and whose solutions are in long-term operational implementation. A company that has implemented Lean Management should actually have up-to-date documentation of all value streams in the company, because that is the basis of Lean Management. If so, these can be transferred to an operational Value Stream without much effort and equipped with KPIs for efficient tracking. If no – and this is the rule even in companies with supposedly practiced Lean Management, then the structured recording of the challenges from all the sources mentioned as well as the detailed recording of the entire existing value stream is the first task or project in the agile transformation of a company. Without this foundation, there is no basis for all subsequent steps based on it.
Fig.: Development Value Stream Overview – *Source reference: 07
The second question is whether there are existing challenges whose solutions are not yet in long-term operational implementation – either under development or yet to be resolved. The definition of these development Value Streams is one of the most critical tasks in agile transformation, because it is also the basis for all subsequent steps that build on it.
For all challenges not yet solved
- the previous value stream for the affected subarea must be identified and completely recorded – as it actually is and not as it should be!
- The systems, plants, equipment and interfaces to neighboring value streams used in this process must also be recorded for the existing value stream for solution development,
- then the people must be identified, together with their role and functional description, who have developed the previous value stream, keep it running and implement it operationally.
- The next step is to define the requirements of the new challenge, together with the people and systems involved, in a development Value Stream – the value stream of a project that describes the value creation of the solution.
- The people and infrastructure in a project to implement the new overall solution in the Solution Train must also be described and organized
- And finally, the timing and implementation must also be described in the Release Train.
- At the latest when the solution goes live, the operational Value Stream must be supplemented with the challenge, solution, definition and regular updating of KPIs. The development Value Stream, which serves as a common ground for subordinate project teams, is maintained throughout the operation of a solution. Only when the operational Value Stream is no longer used and therefore maintenance and optimization are no longer necessary, the underlying teams are dissolved and the challenge in the operational and development Value Streams is cleared.
We will go into more detail on the last 3 points in the following lessons. In this lesson, we will focus entirely on the Value Stream.
Fig.: Development Value Stream Example – *Source reference: 07
An example of a development Value Stream includes
- the trigger for a challenge – in this case: I need content for a new article
- the steps to solving the challenge
- the definition of the added value – here: the item content to be delivered
- the gathering and organization of the people and infrastructure needed for this purpose
- the definition of the lead time, i.e. the expectation in which time span between project start and delivery of the solution the project should be implemented
Fig.: Multiple Operational Value Streams – *Source reference: 07
An example of multiple operational Value Streams includes
- several departments where solutions are implemented
- several areas through which the value streams run (and in doing so, it also becomes clear why the value stream organization in a company is of strategic importance and should be well thought out)
- also includes several products per area
- and on the outside, the requesters or agile customers in the form of end customers, shareholders, regulatory requesters, but also service partners.
- from below, in this case, the product-oriented value streams run through all departments
Now please look at the red bordered area of the chart in the Consumer Banking section, the Loans product.
Fig.: Example of Operational Value Stream – *Source reference: 07
Accordingly, the Consumer Loans Value Stream could look as follows.
Fig.: Example of recording an operational value stream – *Source reference: 07
To capture this value stream, the following simplified template could be used.
Fig.: Acquisition systems for value stream – *Source reference: 07
After that, it is necessary to identify the systems required for this purpose, which support the previously identified individual steps.
Fig.: Recording roles for value stream – *Source reference: 07
It then captures the people, roles, and job descriptions involved in the solution.
Fig.: Integration of development value streams – *Source reference: 07
Based on this, the solution for the value stream can then be developed using new or adapted value streams.
Fig.: Capturing roles of the development value streams – *Source reference: 07
And who builds the solution or is involved in the solution development with their expertise? This is also captured in the Value Stream.
Fig.: Distributed organizational structure – *Source reference: 07
In large companies, an internationally distributed organizational structure is common.
Fig.: Distributed organization in the value stream system – *Source reference: 07
This circumstance must also be taken into account in the composition and organization of teams as well as the delivery of the solution – also with regard to the method and tools used.
I hope that the last two examples have helped you to understand the instrument of the Value Stream and to position it correctly in the company. We talked about challenges and solutions in this lesson. We have included the challenges and company values for long-term processing in the Value Stream and you may now be wondering where the solutions are that we have mentioned again and again. This is exactly what the following lesson is about. So, let yourself be surprised, see you soon.
