Value Streams in SAFe: A new way of creating Lean Flow

Value Streams and SAFe® are almost synonymous.  Without the former, the latter would struggle to deliver business value.  But, since the inception of SAFe way back in 2008, we have learned a great deal about how to view these value streams, and how to organize around them to promote true lean flow of value to the enterprise.

SAFe ® Value Stream Alignment

Before diving into this new learning, let’s review what a ‘value stream’ really is.  We start with understanding our Operational value streams, which are the set of interconnected steps that we go through to deliver value to our customers.  These value streams start with the concept, or the trigger or reason for delivering the value.  For example, when a potential or existing bank customer learns they are going to have their first child they may start thinking about purchasing a new house.  The trigger is the need for the value that the enterprise wants to provide.  The steps the enterprise goes through to deliver that value successfully to the customer are the operational value stream steps, such as marketing the mortgage offering, accepting the application, processing the customer’s credit and information, and providing and servicing the mortgage.  As the customer pays off the mortgage, we get to the other side of the operational value stream, the Cash.  This term is often used a bit ambiguously, but essentially means the fulfillment of the value stream to the satisfaction of the customer and the enterprise, resulting in both the customer and enterprise receiving benefit for the value.  Very often the actual money is transferred from customer to enterprise during the value stream (not always at the end), such as when the customer continues to pay the mortgage payments and the bank receives the mortgage principle and interest, but the operational value stream continues to flow as it services and eventually closes the mortgage.

While SAFe ® can be used to assist operational value streams to deliver, the sweet spot is really in supporting the Development value streams.  Development value streams are the set of steps we go through to support operational value stream steps.  They consist of the people, systems, and processes we use to support these operational steps.  For our mortgage example, there is most likely a credit review system for the credit approval step, and a set of systems that support the mortgage servicing steps. 

A Different Way of Thinking

SAFe ® was originally designed to organize Agile Release Trains around these systems to allow lean flow of value to increment and improve these systems.  E.g. If we want to improve the Credit Review System, we would organize an Agile Release Train around the development of this system.

However, as we learn about the application of the virtual organization of an ART to deliver value, we have discovered that very often this does not promote lean flow of value.  There are many reasons behind this issue, but the most prevalent is that very seldom does a single system alone support the Operational value stream step.  There are almost always other aspects, such as Compliance, Regulatory, Marketing, Sales, Legal, Research, etc.  To promote true lean flow, we need to rethink this paradigm and focus on all of the steps needed to improve these operational value stream steps.

The new way of thinking starts with a new way of identifying value streams.  Traditional SAFe guidance helps us find the Operational value streams, then discover the Systems that support these steps, and then to find the people that support these systems.  Dr Alan Ward defined Development value streams as the set of steps we go through to Create, Update or Deprecate Operational value stream steps, and he included all steps in this process.  Applying his work and this new way of thinking we look at all steps we go through to positively impact these Operational steps, such as Business, Infrastructure, Research, Marketing, Legal, Sales, etc. 

Lean Flow

Let’s discuss a simple example from manufacturing.  If a car maker is building cars, they are using an operational value stream to handle orders, bring in raw materials, create and assemble the parts, and ship and sell the car.  In manufacturing the steps to create a part are typically called a recipe, which includes all the specific steps to heat, form, stamp, etc the material to create a part, such as a hood.  The operational value stream step already is capable of producing this hood (via the recipe), but lets say we want to improve this hood.  What are the steps we would go through to improve the strength of the hood?  To improve the aerodynamic properties?  To reduce the amount of metal used in the production?  These steps are probably fairly similar, and would require the same people: designers, metallurgy specialists, marketing (for shape), compliance/legal (for safety), etc.  These people would go through a somewhat generic set of steps to improve the recipe to create the hood.  As they design, test, review, validate and confirm this new hood design, they update the Recipe, hence they are updating the Operational value stream step.  We then repeat these same steps for the next improvement we want to make to this Operational step, such as reduce the cost of the hood, make it lighter, etc.

Software and Hardware development is no different.  The end result is still that we want to improve the operational step, and we need a variety of people to do so.  In software we typically need the people in the SDLC process, but we also need people from Legal, Compliance, Marketing, Sales, Design, Infrastructure, etc to improve this Operational step.  Hardware/Firmware is similar in that we also need the people that actually create the product, but also all the other players that are needed to actually update the operational step.  These are the people we include in our virtual organization in the ART.

The Island

While coaching this method to a past client, I had the pleasure to work with a true Change Agent, Phil Purrington.  As Phil came to understand this method, he explained it this way.  “Imagine we have a deserted island, and we need to bring all the people needed to solve similar business problems to this island.  This has to include all the skills needed because, well, we’re on an island!”  This is a great visual as we understand the importance of having all the skills and experience needed on the ART to deliver value, and not just update a system.  Having this island mentality will definitely promote lean flow!

The Tradeoff’s

While this method creates true lean flow, it does not come without it’s cost as we have to make some tradeoff’s.  When we focus an ART on a specific system we can create a high level of architectural integrity and consistency, as the same people are always updating the same system.  Using this lean flow method we lose some of that singular focus on a system, but this can be easily overcome and compensated with good architectural design (loosely coupled, micro service based systems are great ways to relieve this issue), Community’s of Practice to distribute knowledge and proper usage, and clear strategic direction from leadership for a common vision to build upon.  In reality, less focus on organizing around the systems leads to better architectural development out of necessity.

A Different Focus

The result in focusing on this wider scope is that we reduce all the handoff’s and delays created when we have to wait for legal, compliance, marketing, or other inputs.  And, after all, that’s what we really want to focus on, Lean Flow. If there’s anything that the Toyota Production System, Don Rienertsen’s work, or any other lean expert will teach us, focusing on true lean flow of value will provide significant increases in value delivery.  And, after all, isn’t that what SAFe ® is all about?

Quality is Management's Responsibility

Yes, you read that right.  Quality is management’s responsibility.  Most agilist’s reading that statement would spit out their coffee and then declare “But, quality is the Team’s responsibility!”.  While that statement has merit, it is far more important to have a system in place that ensures high quality, and systems building is a management responsibility.  This is one area where traditional agile thinking meets with traditional lean thinking to create the best outcome.

Wisdom from Dr. Deming

Tim Stevens of IndustryWeek magazine had the privilege to be the last to interview Dr W. Edwards Deming about management’s responsibility.  One of the first questions Mr Stevens asked Dr Deming was “What can you say to IndustryWeek's readers that they might benefit from and apply to the way they are running their businesses?”  To which, Dr Deming replied “Management today does not know what its job is. In other words, [managers] don't understand their responsibilities. They don’t know the potential of their positions. And if they did, they don't have the required knowledge or abilities. There's no substitute for knowledge.”  Dr Deming continued with this explanation “Quality is the responsibility of the top people. Its origin is in the boardroom. They are the ones who decide.”.  Dr Deming, with all his experience and knowledge, wanted to illustrate that management’s (leadership’s) main responsibility is to build a system that creates and ensures quality.

Taking a Systems View

As a manager or leader one of your key roles is to create an environment that encourages rapid delivery of the right solutions for the customer.  This requires stepping back from the traditional command and control (telling people what to do) and instead focusing on creating a system that allows people to innovate while ensuring the right level of quality and governance is applied at the right points.  This is a difficult transition for most managers and leaders that have grown up in the Tayloristic work break down structure approach.  But what really creates value is the focused system that good people thrive in, not a failing system that good people try to work around.  In short, managers need to move from managing people to managing systems. 

Applying Systems Thinking to Ensure Quality

Taking this leap towards focusing on a system that ensures quality can be a daunting task.  I have found that starting with understanding the system is a critical first step.  To best understand a system, there is no substitute for a post-its-on-the-wall value stream mapping session.  (see my blog on the three reasons for value stream mapping in SAFe ® or some of Al Shalloway’s work on this subject).  For the sake of this article, let’s assume you have gone through this initial work (value stream mapping is an ongoing exercise), and have a decent understanding of how value flows through your system.  As a manager, your challenge is to begin to understand the bottlenecks at each state in the system, but also to understand how each state ensures Percent Complete and Accurate (%c&a).  One of your key objectives in applying systems thinking is to increase this %c&a at each critical transition or hand-off.  Definition of Done is an important tool to assist in this critical task.

The Importance of DoD in Increasing %c&a

True quality comes from a system that encourages transparency along each step of the process and incorporates the Andon chord approach to determine when/if to halt production when an issue is found.  In many cases the Dev Team does not have visibility or ability to change these systemic issues, but management can and should.  Using a clear Definition of Done (DoD) at specific points is a critical part of the quality system.  DoD’s are not checklists that we mindlessly go through, they are living contracts between teams, PO’s, PM’s, and the rest of the ART and its stakeholders as to our quality and accuracy validation.  If you are working in a scaled environment, the SAFe® recommendations on Definition of Done are a great starting point to improving the system to achieve Built In Quality. 

DoD is Measured at each Increment

In SAFe®, DoD is purposely used at various granular levels.  The team meets the Team DoD to ensure that the value added is worth demonstrating and reviewing.  The System Increment DoD ensures that it is integrated into the system and is worthy of Release consideration.  And the Release DoD ensures we have met our customer readiness and impact standards and are ready to put it in front of the customer.  Each Definition of Done is essentially asking “Are we done enough to go to the next state?”, which is a key part of our quality control to ensure our %C&A.

It is hugely wasteful to meet Release DoD on a story that may never be in the customers hands.  As Peter Drucker said "The worst thing we can do is do something well that should not have been done at all".  We increment towards a true state of ‘Done’ (in the customers hands and they are happy) through a set of ever expanding DoD increments.

The System needs to work even if a critical person is out.  Just because Dinesh is out sick today should not mean we have lesser quality that day.  The system should have its checkpoints that ensure that we are still following our agreed upon contract with the next step to consume the value.

Managements Role in DoD

As already stated, far too often teams are held accountable for quality when they have little to no ability to change the system that should be ensuring quality.  Agile teams are described as Self-Organizing and Self-Managing, but as described in another post, teams are not really self-managing.  We need management and leadership to provide teams with solid systems to work within, and these systems need to be built to deliver and ensure quality.  Built In Quality Is not just a phrase on the SAFe® Big Picture, it is a way of working and thinking that ensures quality at each step.

Iterative Growth on DoD

Building a DoD is not a one and done.  We need to start with a set of validations that we believe to be correct, measure the outcomes using this set of validations, and then iterate on the set.  We will almost certainly not get it right the first time, only through inspecting and adapting will we get to a solid set of DoD’s.  One good way to ensure that we are iterating on it is to capture any exceptions we deal with and determine if the DoD needs to be updated to prevent in the future.  E.g. If a system issue slips by our current DoD and into the customers hands, is there something missing from the DoD that would have caught this?  Whenever we are in crisis “it has to be fixed yesterday” mode we have to also capture the underlying data that allows us to improve the system once the crisis is over.

Footnotes

(1) Percent Complete and Accurate (%C&A).  A quality metric used to measure the degree to which work from an upstream supplier is determined by the downstream customer to be complete and accurate (or error free).  https://www.ksmartin.com/lean-terminology/

Crossing the Chasm with Scaled Agile

Like any successful business, Scaled Agile Inc. Has 'Crossed the Chasm' from Innovators, through Early Adopters, and has moved into the mainstream Early Majority stage. 

https://dwaynenesmith.com/book-review-template/

As experts like Geoffrey Moore and Ash Maurya pointed out at last week’s SAFe® Summit, it takes different leadership models to navigate your business in these different stages.  The 2018 SAFe® Summit pointed out just how well the Scaled Agile team is adjusting to this growth.

The week started off with the SPCT (SAFe® Program Consultant Trainer) session on Monday, where the SAFe® experts gathered to teach each other the subtle but significant changes to version 4.6.  The session capped off with an Epic generation session based on an SPCT view of the needs for 2019 and beyond.  The next day these ideas, focused on furthering the quality and effectiveness of training and the impact of SAFe® beyond the typical IT Systems Implementation, were presented to the partners for input and voting.  This is a great example of a company listening directly to its customers and key stakeholders. 

The release of version 4.6 was highlighted by the 5 Core Competencies: Lean Agile Leadership,  Team and Technical Agility, DevOps and Release on Demand, Business  Solutions and Lean Systems, and Lean Portfolio Management.  Each of these competencies highlight new learning and application of that knowledge to the framework.

https://www.weforum.org/agenda/2015/04/how-should-disrupted-businesses-plan-for-the-future/

The main conference was highlighted by Geoffrey Moore's great keynote on the 4 zones, and further illustrated how Scaled Agile is supporting the current body of knowledge with the existing framework (zones 1 & 2) while looking to the future (zones 3 & 4). 

In short, this is an exciting time to be part of this community.  It feels like we have come a long way already, but the week further highlighted how much more there is to learn and apply.  It was clear to me that Scaled Agile Inc has their Profit motive firmly moored to their Purpose motive.  Exciting tines indeed!