Chapter 13: Introducing the VSM-DevOps Practice Leaders
In this chapter, you will learn about the current leading VSM practice leaders. We will start with an introduction to the VSM Consortium, a not-for-profit trade association funded by members (vendors and enterprises) and open to all to support the emergence of the value stream management market through research, learning, networking, and open source projects.
Next, you will learn about the Project Management Institute (PMI) approach to implement VSM strategies and methods via their DA-FLEX offerings. PMI acquired Disciplined Agile (DA) and FLow for Enterprise Transformation (FLEX), both well-established and recognized leaders in their respective fields, to build their Lean-Agile practices, training, and certification programs. DA provides PMI's Agile practices in software development. In contrast, but complementary, you will learn how FLEX is a framework based on Systems Thinking that provides a comprehensive set of portfolio, Agile product management, executive/management, and program and team patterns for success based on Lean-Agile principles and practices.
Next, we'll move on to learn about Scaled Agile's approach to value stream management as part of their Scaled Agile Framework™ (SAFe™). Specifically, Scaled Agile implements value stream management as part of its SAFe DevOps curriculum and training.
In this chapter, we're going to cover the following topics:
By the end of the chapter, you will have foundational knowledge about the approaches taken by the three leading Digital VSM practice leaders to implement effective value stream management practices.
The VSM Consortium
The Value Stream Management Consortium (VSMC) is a new organization established on March 3, 2021, to help organizations worldwide deliver customer value by adopting and advancing value stream management tools and practices. The objective of the VSMC is to serve the whole VSM community by helping drive value stream management standards and innovation through leadership and community.
Defining VSMC's purpose, mission, and goals
The VSMC aims to advance value stream-centric ways of working in technology teams to lead higher-performing organizations. The VSMC operates as a not-for-profit trade association. Its mission is to cultivate and nurture the emerging market for digital value stream management and help the community learn, devise practices and standards, and grow through its use.
The VSM Consortium is open to all people and organizations interested in applying value stream management as a business transformation and customer value delivery improvement strategy. Funds for the VSMC are primarily raised through its membership fees, but plans are underway to also include the resale of VSM-related learning products.
Structurally, the VSMC implements Lean practices and value streams as its operating model, while its funding supports VSMC Research, Learning, and Outreach value streams.
Though founded by several of the leading VSM tool providers, the objective is to let VSMC members drive the direction of future enhancements to VSM methods and tools. The VSMC members will also play a critical role in building a knowledge base of VSM practices.
Building the VSM industry through collaboration
The VSMC was founded by five technology leaders, Digital.ai, HCL Software, Plutora, ServiceNow, and Tasktop. The charter established for the VSMC by its founders is to help organizations worldwide improve performance and improve customer value deliveries through the adoption of value stream management (VSM).
Though competitors on the open market, these founding companies recognized that real and sustainable growth to the VSM industry required worldwide and industry-wide collaborative research to guide the VSM tool, platform, and services developed through the early adopter stage. No single company could take on the scope of this work by themselves. Moreover, the research had to be unbiased and vendor-agnostic.
The founders recognized the importance of extending their collaborations to organizational and individual practitioners worldwide from the start. As a result, the founders established the VSMC as a member association for both enterprises and individuals working with value stream management practices and platforms to meet this objective.
Helen Beal, Chair of the VSMC, offers the following value proposition for establishing the VSMC as a professional community of technologists and practitioners:
Delivering customer value through software
The VSMC is still in its infancy, but aims to become the foremost professional organization to drive VSM practices, innovation, and adoption. The purpose of the VSMC is to help the software industry deliver VSM products and services that help organizations achieve business transformations that deliver value in our digital economy.
VSM achieves this goal through a comprehensive software life cycle orchestration process that provides value stream managers, release managers, DevOps managers, product managers, and leadership with the data, visibility, and analytical tools necessary to improve software delivery pipelines.
Shepherding the VSM industry
The VSMC will serve as a central hub of information and education on the practice and adoption of value stream management. Ongoing research will help inform organizations on how to measure value and become higher-performing as a result. In addition, training and certifications programs will support member collaboration worldwide and help make VSM the industry-standard way of working.
The VSMC works with leading analysts to apply scientifically sound principles to its information gathering and analytical activities. The objective is to discover insights that offer solid guidance to teams and organizations adopting value stream management principles to improve their value delivery performance.
Offerings in progress
The Consortium's initial research offering will be The State of Value Stream Management Report, which will measure how teams apply value stream management principles, practices, and metrics to influence their value stream management outcomes. The VSMC Board has launched its first survey, and its initial findings will be available in June 2021.
Later in 2021, the VSMC will investigate value stream mapping principles and practices and work with their membership community to address their specific needs and priorities. The first VSMC online learning is the Value Stream Management Foundation course due for release in August 2021.
Though the VSMC is in its early days, The State of Value Stream Management Report alone will be a powerful tool to help organizations worldwide see how other organizations benefit from VSM methods, tools, and services and which approaches are working best with context-based guidance. The Value Stream Management Foundation course will help practitioners build the necessary skills to help their organizations employ VSM effectively. As practices evolve, the VSMC will create new guidance to inform its membership.
Findings from the initial VSMC report
As of the date of this writing, the first VSMC report has not been released. However, I have seen the initial draft and the summary findings are very interesting. The Chair of the VSMC, Helen Beal, was kind enough to allow me to share these summary findings in this book.
"While there are still significant challenges around the adoption of VSM, the following three key practices are evidence of a shift toward broader adoption:
- Organizations are identifying value streams and organizing around them:
As organizations need to continuously innovate, it is essential to understand the key value streams, gain visibility into them, and organize around them to then improve value delivery.
- Product-oriented teams are more popular than project-oriented teams:
Product focus binds the team more closely to the producer-consumer relationship. Value is determined by the products' consumer utilization, rather than abstract outputs defined by the project, or program.
- People have roles specifically focused on value stream-centric ways of working:
By defining organizational roles in terms of the value stream, individuals know their spheres of responsibility. Having specifically defined roles that own the adoption, thinking about and changing how value is managed is a significant step toward the adoption of this concept."
Full disclosure
The VSMC Board elected me to an advisory role in April 2021 to help them in the following three areas:
– Guidance around value stream roles and learning paths
– Connecting VSM to other digital delivery frameworks
– Networking through the enterprise and consulting community
These initial findings are exciting, and I look forward to helping the VSMC meet its learning objectives and participating in the journey of discovery.
PMI's DA FLEX
The Project Management Institute (PMI) is best known for its training and certifications programs around traditional project management practices. However, PMI acquired two companies, Disciplined Agile (DA) and Net Objectives, in 2019 to establish a professional training and certification path for their members desiring to learn and apply Lean-Agile practices. DA has a focus on implementing Lean and Agile practices in software development. At the same time, Net Objectives developed FLow for Enterprise Transformation (FLEX), a framework based on systems-thinking, offering a comprehensive portfolio, Agile product management, executive/management, program, and team patterns for success based on Lean-Agile principles and practices.
Rather than building these methodologies from scratch, the PMI wisely chose to acquire established companies and methodologies to accelerate the development of their Lean-Agile certification programs and offerings. The work ahead of the PMI involves integrating the two practices as a seamless offering. PMI refers to their combined Lean-Agile approach as DA, with their enterprise offering being the DA Value Stream Consultant based on FLEX.
PMI offers five training and certification programs in support of its DA FLEX acquisitions, which are as follows:
- Disciplined Agile Scrum Master (DASM) Certification
- PMI Agile Certified Practitioner (PMI-ACP)® Certification
- Disciplined Agile Senior Scrum Master (DASSM) Certification
- Disciplined Agile Value Stream Consultant (DAVSC) Certification
- Disciplined Agile Coach (DAC) Certification
DASM operates at the single and small team levels, while DASSM guides how to get multiple teams to collaborate. Additionally, PMI will soon release a multi-team coach certification. Finally, Disciplined Agile Value Stream Consultant (DAVSC) is an enterprise-scale implementation of DA FLEX.
Many of the DA FLEX certifications, though useful for learning Agile-based roles and practices, are not relevant to the topics of DevOps and VSM. As a result, the bulk of the information covered in this section centers around the DAVSC training and certification programs. DAVSC provides a combination of Lean, Flow, Theory of Constraints, and Organizational Development theories and practices and serves as the foundational learning behind PMI's approach to value stream management.
The relationship between DAVSC and FLEX is as follows:
- DAVSC is based on the job task analysis for a person attempting to improve an organization's ability to create value.
- The system that supports this is FLEX.
- The DAVSC workshop teaches these responsibilities and how to achieve them.
Now that you understand the scope of the Lean-Agile offerings in DA FLEX, we can start to drill down into the DA toolkit to see how the framework is put together and how it supports Lean-Agile practices. Let's get started with an introduction to Disciplined Agile's core philosophy, Choose your way of working (WoW)!
Fitting Lean-Agile practices to support your way of working
PMI does not promote DA FLEX as a framework. Instead, the organization promotes DA FLEX as a toolkit that includes practices that work together. The distinction between frameworks and toolkits is subtle, so let's take a few minutes to understand the differences.
Definitionally, frameworks provide a basic structure that underlies a system, such as software development and delivery. At a conceptual level, software development frameworks provide a structured approach to applying Lean and Agile practices. For example, SAFe™ and scaled Scrum-based frameworks provide a set of organizational structures, events, and processes to implement their Lean-Agile practices. They are both very prescriptive in their approach to implementing Lean and Agile practices by implementing small team roles, structures, events, and time-boxed development cycles. Scrum and SAFe practitioners apply various processes, techniques, and methods within their frameworks. However, the basic structures and events remain intact.
In contrast, DA FLEX takes issue with the idea that one approach to implementing Lean-Agile practices works equally well for all organizations. Instead, they promote the view that organizations must review alternative strategies and tools to evaluate which fits better with their needs and cultures. Hence, PMI promotes DA FLEX as a toolkit. The basic idea is that value stream teams choose the right tool for the right job. Also, as a toolkit, the PMI implements its DA FLEX toolkit as a standalone Lean-Agile approach to improve value streams and extend this to other frameworks.
Philosophically, DA FLEX incorporates the concepts behind value stream-based continuous flows, Lean improvements, Theory of Constraints, Organizational Development, and human behavior. At issue is the concern that hierarchical organization structures, based around business functions, are antithetical to supporting Lean flows around value delivery.
Before we discuss how DA FLEX supports value stream management, we need to spend some time reviewing each offering independently, Discipline Agile and FLEX, to understand their respective contributions to modern Lean-Agile practices.
Choosing your way of working with DA
Co-created in 2012 by Scott Ambler and Mark Lines, DA is a process decision toolkit that helps individuals, teams, and enterprises optimize their Way of Working (WoW) in a context-specific approach. Scott Ambler and Mark Lines are well known in the software development industry because there is no single software development strategy that works well in all customer situations. So instead, users of the DA toolkit can choose between six different software development life cycle approaches and between hundreds of methods and tools with context-based guidance on their potential applications.
The DA toolkit incorporates the concept of process blades to help teams and organizations guide their selection based on their unique software development needs. In turn, the process blades guide users on how to apply selected techniques to enhance critical organizational capabilities.
Each process blade provides information on its philosophical underpinnings or Mindsets, the roles and responsibilities of People applying the techniques, descriptions of streamlined business processes as Flows to improve business agility, and employment Options to address situational needs. Collectively, Mindsets, People, Flows, and Options represent four views into the DA toolkit.
Besides its four views, the DA toolkit also offers four levels of process blades, spanning Foundations, Disciplined DevOps, Value Streams, and its DA Enterprise. As shown in Figure 13.1, the DA toolkit currently provides context-specific guidance on 24 well-defined process blades:
Figure 13.1 – The DA toolkit
As you can see in Figure 13.1, the DA toolkit includes four layers: Foundations, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise. We'll look at these four layers in more detail in the following subsection.
Installing Lean-Agile practices on an enterprise scale
The Foundations layer of the DA toolkit guides the underlying principles and concepts that form the DA mindset. The layer also introduces the fundamental concepts and differences between Agile, Lean, and Serial (traditional) software development approaches, roles, and team structures, as well as the concepts behind choosing your WoW.
The Disciplined DevOps layer provides guidance and techniques for streamlining software development and IT operations activities. An important differentiator is DA's systems-thinking approach to visualizing and understanding the complexities behind DevOps workflows, as shown in Figure 13.2:
Figure 13.2 – The workflow of disciplined DevOps
A systems-oriented diagram, such as shown in Figure 13.2, is a bit more complex than a value stream map or workflow diagram. But you can use the knowledge you gained in Chapter 3, Analyzing Complex Systems Interactions, to work your way through it.
The Value Stream layer incorporates Lean-Agile principles acquired from FLEX, which you'll learn about in the next section. For now, understand that FLEX is a Lean-oriented approach to increase value realization. The process blades within this layer provide both a visual map and a guide to making value-based improvements across the organization's interconnected value streams.
The Disciplined Agile Enterprise (DAE) layer provides business management guidance to support the construction and sustainment of a Lean-Agile enterprise. DAE's process blades help the organization develop the ability to sense and respond quickly to changes in the marketplace.
Note
Readers who want to learn more about Disciplined Agile can read my previous book, Scaling Scrum across Modern Enterprises.
Now that you have a basic understanding of Disciplined Agile, let's understand how FLEX brings a life cycle approach to implementing Lean-oriented value delivery improvements within the DA toolkit.
Before we discuss the application of FLEX as a value stream management tool, we first need to visit the DevOps layer of the DA toolkit.
Implementing DevOps with DA FLEX
The DA toolkit devotes an entire layer of process blades to DevOps. The DevOps process blades include the following:
- Disciplined Agile Delivery (DAD): A people-first, learning-oriented hybrid agile approach to IT solution delivery
- Security: Describes approaches to protect your organization from information, cyber, virtual, and physical threats
- Data management: Promotes a pragmatic, streamlined approach to managing data as a critical asset that must support the rest of your organizational processes
- Release management: Encompasses planning, coordinating, and verifying the deployment of IT solutions into production
- Support: Outcome-based techniques to implement Help Desk or End User Support to help customers work with the solutions produced by your delivery teams
- IT operations: Outcome-based techniques to manage and govern your IT ecosystem
Scott Ambler and Mark Lines appropriately concluded that DevOps is now the minimum table stake that allow an organization to compete in our digital economy effectively. The competitive advantage of streamlining your organization's CI/CD and DevOps pipeline flows is impossible to duplicate via traditional, or even agile-based software delivery approaches.
PMI's contributions to DevOps do not lie in toolchain integration, automation, or orchestration capabilities. Instead, its DA toolkit provides comprehensive guidance on implementing and maintaining end-to-end DevOps infrastructures and pipeline flows.
Since this part of the book has a central focus on value stream management, let's move on to look at how DA FLEX, via the Value Stream layer within the DA toolkit, helps organizations work their way through Lean-oriented business transformations and improvements.
Achieving business agility with FLEX
FLEX gives the PMI an industry-leading approach to achieving business agility based on Lean-thinking and systems-thinking patterns. Al Shalloway, who developed FLEX, defines organizational business agility as the quick realization of value predictably, sustainably, and with high quality.
With FLEX, organizations use Lean principles to discover what's not working at a system level and why. But it's also important to note that FLEX is PMI's new approach to implementing value stream flows intending to improve value deliveries using value stream management techniques.
Enterprise transformation is such an essential objective of FLEX that it forms the basis of the acronym FLEX (FLow for Enterprise Transformation). In other words, FLEX enables enterprise transformation through the effective implementation of value stream flows.
DA FLEX connects an organization's strategies to the execution of activities at the level of value delivery. The DA FLEX approach helps organizations to streamline their complex business systems to expose more effective value stream flows, enabling you to make decisions for improving each part of the organization within the context of the whole business system.
While businesses need innovation to improve their competitiveness, they also need to improve value delivery. In this context, the process blades within the Value Stream layer of the DA toolkit establish end-to-end value realization activities supporting the organization's products and services.
As was I in my early career, Al Shalloway was greatly influenced by Eliyahu M. Goldratt's book, The Goal, A Process of Ongoing Improvement, which introduced us to the Theory of Constraints (Goldratt, 1984, 2014). While Lean improvement initiatives, like VSM, emphasize the identification of bottlenecks as choke points that introduce delays, Goldratt's work helps us look closer to evaluate the constraints that cause our production delays.
For example, maybe we have a slow process, or multiple work item flows through our pipelines. We might have too much work for the system's design or lack of visibility to see issues when and as they arise. Or perhaps we have overly bureaucratic processes and approvals that restrict flows.
The FLEX approach helps the value stream team identify bottlenecks, the wastes that cause them, and evaluate methods to eliminate or reduce those wastes and improve workflows. The FLEX approach is a form of VSM methodology that has the following steps:
- Define value-based workflows and organizational structures.
- Identify the impediments to achieving the desired flows and structures.
- Identify potential solutions to remove the impediments.
- Apply systems and Lean Thinking to define improvement priorities working within the organization's culture.
- Implement the proposed solutions in order of priorities and evaluate their effectiveness against the predefined goals and metrics.
- Continuously analyze, replan, and repeat the FLEX process.
As you read through this section, it's important to note that FLEX is explicitly designed to support knowledge-oriented work. Also, Al's current thinking on the role of value stream management encompasses a holistic view of the organization built on insights gained from his years of Lean-Agile consulting experience. The following section details those insights.
Defining values streams in DA FLEX
DA FLEX defines a value stream in a manner that is consistent with other Lean disciplines, such as that found in Wikipedia: https://en.wikipedia.org/wiki?curid=55610257.
Value streams
A set of actions that take place to add value to a customer from the initial request through the realization of value to the customer. The value stream begins with the initial concept, moves through various stages of development, and on through delivery and support.
As you learned in the mapping value stream exercises in Chapter 7, Mapping the Current State (VSM Step 4), and Chapter 9, Mapping the Future State (VSM Step 6), DA FLEX makes the point that a value stream always begins and ends with the customer. They also make the distinction between the work within a value stream and the people doing the work. Their concern is that conflating the two works against the organization as value streams have a singular focus while people may support work in multiple value streams.
Another critical point is that organizations must shift from focusing on keeping people utilized to the throughput of value. While functional organizational structures can improve local efficiencies around developing critical skills and competencies, at the same time, they create waiting, bottlenecks, and other forms of waste from the perspective of executing lean value streams.
Figure 13.3 shows a graphical display of work flowing across the value stream (green arrows) with a traditional hierarchical management overlay (red arrows):
Figure 13.3 – Work flowing across the value stream with hierarchical management overlay
So, in the traditional management structures, we have work flowing in one direction, horizontally, as cross-functional flows, while decision making and approvals flow vertically within functional hierarchies. So, the question DA FLEX first asks is who is managing the end-to-end flow of value delivery?
It's a great question to ask because no single person is assigned to manage product flows in the traditional model. Instead, it is management by committees, with conflicting agendas and objectives. So, first and foremost, we have to fix that problem – an organizational structural alignment problem. And then, we need to make sure that we have defined efficient and streamlined flows with minimal waste.
Ultimately, the objective of improving organizational value streams is to improve business agility. Since FLEX implements the Value Stream layer within the DA toolkit, let's review how FLEX helps organizations evolve their value streams to improve business agility.
Improving business agility with DA FLEX
DA FLEX defines business agility as having the ability to realize the highest business value in the shortest amount of time, consistently, sustainably, and with high quality. By delivering incremental value across all value streams, the organization can adjust when and as needed, changing direction at the lowest cost.
This level of flexibility leads to lower risks and stress to those who work to deliver value across the organization's value streams. In this context, DA FLEX teaches that the primary objective of improving value streams is to establish business agility.
Applying systems thinking with DA FLEX
DA FLEX takes a holistic view of improving an organization, using the same systems-thinking concepts you learned in Chapter 3, Analyzing Complex Systems Interactions. Recall from the previous chapter that system thinking evaluates complexity through the lens of interactions across all the elements that participate in a system. With more elements, the system's complexity goes up due to an exponentially increasing number of potential relationships and consequential impacts.
The FLEX approach with the DA toolkit's value stream applies the same principles of systems thinking. We need to optimize the whole across our business systems. Local optimizations almost always fail to meet expectations if we haven't done the work upfront to ensure the change addresses an area of waste that affects the system's performance as a whole.
In his discussions, Al Shalloway points out that we cannot apply Reductionist Thinking to address complex issues in systems. For example, Al notes that if we try to construct a car with all the best parts available and try to assemble them, we will fail to build a car that works. You won't even have an automobile because the parts simply won't work together.
The scenario Al uses comes from a presentation that Professor Russ Lincoln Ackoff gave in 1994 at an event hosted by Clare Crawford-Mason and Lloyd Dobyns to capture the learning and legacy of Dr. W. Edwards Deming. At the time, Dr. Ackoff was the Anheuser-Busch Professor Emeritus of Management Science at the Wharton School, University of Pennsylvania.
The presentation is entitled If Russ Ackoff had given a TED Talk: https://www.youtube.com/watch?v=OqEeIG8aPPk. It's worth spending a few minutes watching this presentation as he makes the case on why local optimizations can never work.
There is so much to unpack in Dr. Ackoff's discussion. For example, he speaks about the difference between continuous improvement and discontinuous improvement. The point he makes is that continuous improvements are for followers, and those followers can never lead. Instead, the leaders leapfrog the competition through discontinuous improvements. In other words, leadership positions come through innovations.
Another critical comment that Dr. Ackoff makes is that he agrees that the positive Japanese impact on the overall quality improvements across the automobile industry is undeniable. Still, he also points out that while the Japanese are doing things right, they are doing the wrong thing. He made this statement in 1991, taking issue with the amount of pollution and congestion in our urban cities. Ackoff's discussion occurred well before the issue of climate change became a foreground concern.
Dr. Ackoff notes that there is a difference between efficiency and effectiveness and that quality needs to be addressed in terms of the latter. He likens efficiency to knowledge, but effectiveness to wisdom. Therefore, from a system perspective, quality must address both efficiency and effectiveness in delivering value. That is to say, we need to apply wisdom along with our knowledge.
In short, what good is it to have higher quality automobiles to drive if, at the same time, they are destroying our environment and our overall quality of life? So, we need to take a holistic view of quality and its contributions to deliver the most valuable product from our customers' perspectives.
Building people into our frameworks
Across Lean and Agile practices, frameworks provide a system or pattern to accomplish work. However, DA FLEX takes issue with the concepts behind frameworks because they don't account for the people who use them. For example, frameworks that seem overly restrictive or work against an organization's culture and operating system inevitably lead to friction and resistance.
The DA FLEX approach implements its WoW concepts precisely to address the issue that overly prescriptive frameworks do not address the complex interrelationships between the people operating within them from a system-thinking perspective. In other words, regardless of the Lean or Agile approach employed, we need to address the interactions between people, processes, and events systemically. Thus, the DA FLEX approach implements their toolkit as organized process blades, each of which includes related sets of methods and tools that organizations employ situationally to fit their needs in the value delivery systems they operate.
Orchestrating value stream flows
Lean Thinking provides an approach to managing the complexity of systems by orchestrating the flow of information, people, and materials around value delivery goals. In other words, to the greatest extent possible, we eliminate the ability to have our system components participate in interactions that do not support our value delivery goals.
DA FLEX implements its Value Stream layer within the DA toolkit to help organizations recognize the flow of value, in multiple streams, across the organization. All of those value streams support product deliveries and must do so in an efficient and organized manner.
This means we cannot simply look at the components that make up our organization in isolation. Our value streams are systems, and we need to manage the relationships between the participating components. On the positive side, value streams bring visibility to our value delivery flows. They also uncomplicate the process of value delivery.
On this latter subject, Al Shalloway makes the following observation:
In other words, organizations develop cultures around the way they conduct business, which is highly influenced by their traditional hierarchical and functional organizational structures. As a result, business processes tend to support the localized goals and objectives of the people within the functional domains. While the processes may be optimized for the needs of the department, they probably aren't in terms of supporting value-based horizontal business flows.
But we also need to understand that the furthest upstream activities have the most significant impact on downstream activities. This means that problems at the start of a value stream, if not quickly caught, can disrupt the entire value stream delivery system, and it may be challenging to isolate the root cause of the problem.
Organizations typically have multiple value streams that support their overall product development and delivery capabilities, and these value streams are interconnected. For example, product management informs the intake process for the product backlog, which lies in a development-oriented value stream.
While it's reasonably simple to add, modify, or delete activities within a value stream, it's much more disruptive to the organization to add new value streams due to the number of potential cross-value stream impacts. In addition, the interconnected value streams create an even larger and more complex system of interrelated activities. Therefore, we want to start thinking about end-to-end flows at the start of our VSM initiatives.
Engaging executives and managers
Recall from our introduction to FLEX that it is fundamentally a business transformation activity to improve value delivery via Lean-Agile organizational structures and practices. It should be apparent then that DA FLEX operates at a strategic level and therefore requires buy-in and sponsorship from its senior executives.
On this subject, Al Shalloway offers the following observation:
DA-VSC graduates learn how to implement workshops for executives and managers to talk about their customers to support an organization's strategic business transformation objectives. Ideally, everyone meets in a room with at least one large whiteboard as the meetings sometimes involve 30 to 40 people.
The assembled team divides the whiteboard into two sections: one side for business-oriented value streams and the other for Implementation and Support-oriented value streams. In between is an Intake queue containing a list of business improvement work items that the organization needs to focus on to effect the desired business transformation.
Al Shalloway refers to the intake queue as a list of Minimum Business Increments (MBIs). An MBI represents the smallest increment of deliverable value in the form of a product, service, or result. The team assesses each MBI from a business perspective, wherein each deliverable meets the needs of targeted customers and fits within the approved strategy of the business.
As you see in Figure 13.4, the Business section is further divided into Portfolio and Product management functions. At the same time, the Implementation and Support side of the board has sections to display information on Development Intake, Development, Integration, and Deploy and Support activities.
Figure 13.4 – Disciplined Agile process goals by phase
The portfolio management value stream guides investments in support of the mission and strategies of the entity. Goals and metrics describe what the executives expect to accomplish with the strategies and the quantifiable measurements that indicate the achievement of the goals. Each investment spawns an initiative tracked across its life cycle in respect to its defined goals and metrics. The initiatives are managed in a Business Backlog.
The Product Management value stream involves a Discovery Workflow to assess value stream delivery needs to meet the organization's strategies, goals, and metrics. These discovered business needs define the necessary deliverable items at a more granular level to achieve the business transformation. These business improvement work items are evaluated and prioritized before managing them as tasks within the intake queue.
The intake queue forms a boundary line between the Business and Implementation and Support functions. From this point forward, the work items follow a Lean-Agile-based development and delivery pipeline flow.
Almost every value stream in our digital economy relies on software, hardware, security, and other infrastructure components to improve business agility. Therefore, DevOps is the preferred development and delivery pipeline strategy when digital enhancements can aid value stream flows as it is the most efficient IT value delivery system.
Still, regardless of the extent of involvement of the IT organization, value stream implementation and improvement activities follow a Lean-Agile process that involves pipeline flows across Development Intake, Development, Integration, and Deploy and Support value streams.
Focusing Solution Teams
The FLEX approach to implementing MBIs is to organize people around the Focused Solution Team structure. Solution teams are product-focused, operating in an agile manner. In other words, a Focused Solution Team is limited to defining the solution needed to fulfill the requirements of the MBI.
Frequently, an MBI is too large to be developed by a single small Agile team. When this is the case, FLEX breaks the solution team into Feature Teams and Core Teams. Feature teams are fully functional with all the technical skills and resources needed to develop the product features identified. In contrast, the core teams tend to contain specialists needed to augment the feature teams. For example, the core teams may work on platform configurations, integration, and the automation of toolchains and augment the Feature teams when necessary.
In some cases, it may be necessary to borrow resources or even contract resources temporarily. In such cases, the borrowed members remain with the feature or core team within the solution team, as assigned, and they participate in their borrowing team's daily standup meetings. However, unlike the core teams, borrowed members may also continue to support their customarily assigned duties and participate in the daily standup meetings of their home team.
Both feature and core teams use Kanban-based production control systems to pull work items from the product backlog. They also operate in collaboration to deliver the product of the MBI.
People operating within a solution team are 100% dedicated to the work of the solution team. Recall that task switching/multi-tasking are forms of waste that hinder productivity as people must take non-value-added time coming back up to speed from where they left off as they move from one task to another.
Now that we understand how Disciplined Agile and FLEX operate within the DA toolkit, let's move on to understand how DA supports the collaborative work of multiple product teams.
Aligning multiple teams with Lean-Agile thinking
This section explains how DA FLEX supports three critical principles of Lean Thinking — Systems Thinking, management creating the context for the teams, and removing delays – for software development. As you read through this section, recall that Lean value streams are the organization's value-added workflows from concept to consumption. Also, let's quickly look at the three principles behind Lean in DA FLEX:
- Systems thinking: Looking at the business as a complex and highly integrated system that requires the participating elements to work in an orchestrated manner to accomplish its purpose.
- Management oversight: Management must create and communicate the context guiding the teams' work to self-organize in ways that support the strategies and goals of the business.
- Removing delays: To eliminate the waste of waiting. In software development, this means we don't create requirements until we are ready to work on them, nor do we write code until we have defined the requirements, established its acceptance criteria, and have the infrastructure in place to integrate and test it with the mainline code base rapidly. We must also remove the delays from making an error until detecting and fixing it.
DA implements its principles as guidance, not mandates. In fact, DA is fundamentally about giving people and organizations more choice when it comes to supporting their specific situations. We'll explore how DA encourages choice in the following subsection.
Establishing a new kind of discipline
It's important to understand that the term Disciplined Agile does not at all imply a desire to install a heavy-handed approach to improving agility. On the contrary, DA FLEX acknowledges that too much management, over-planning, over-design, and overly large projects are ineffective, dooming software projects to failure. However, Al Shalloway also notes that undisciplined teams that use Agile as a justification to avoid doing what is necessary are also not effective … and, by the way, are not Agile.
The origins of Agile have their roots in so-called lightweight software development methodologies and evolved to coordinate the work of small teams to improve software delivery performance. But we also need methods to improve agility on an enterprise scale to improve our end-to-end value delivery capabilities, usually involving multiple value streams.
Cross-team dependencies require greater discipline to resolve enterprise-wide integration, automation, and orchestration concerns across value streams. Unfortunately, the team-of-teams model for scaling Agile has issues because it forms a new functional model. As a result, every team is disconnected from understanding their contributions to the flow of value. In other words, the teams tend to focus on resolving cross-team issues in isolation instead of looking at their participation in the value delivery system as a whole.
Along these lines, it may make sense that we can simply extrapolate the small team concepts of Agile and make them work in large or multiteam environments. But that view ignores the fact that the dynamics between team members are quite different from the dynamics between teams.
Therefore, we need to extend Agile's small-team models to address development and operations-oriented issues at a local level but implement Lean-oriented flows to coordinate and improve the speed of deliveries across all the organization's value streams. This strategy is the essence of the Lean-Agile disciplines.
The Lean-Agile approach improves organizational workflows to remove delays in receiving feedback, detecting errors, using information, and ultimately, delivering value. In this context, software development efforts must be directed to support the integration, automation, and orchestration needs of the more extensive business system and its value streams.
Focusing on value stream flows
DA FLEX is a scaled approach to enterprise-wide agility that applies Lean-Agile concepts to improve value delivery across multiple teams. DA FLEX implements Lean-Agile flows across teams. Multi-product, multi-team agility can be achieved by focusing on work and information flows and ensuring that everyone agrees to make certain decisions at certain places in the value stream.
While we may still manage people vertically, we need to manage value delivery flows horizontally. Recall our discussions around Figure 13.3.
The flow of value is always horizontal. Measuring the utilization of resources vertically, within functional departments, or even disparate teams, creates disconnects from the flow of value, leading to local optimizations with little chance to improve the organization's overall productivity. Therefore, our most essential measurements evaluate time to markets to discern the constraints responsible for delays and adding costs across our value streams.
Understanding the discipline behind DA FLEX
Two sections back, Establishing a new kind of discipline, we noted that DA FLEX establishes a new kind of discipline that enables multiple teams to collaborate effectively to improve flows. We didn't say what those disciplines are but will now. DA FLEX promotes three disciplines to improve multi-team performance, and they should look very familiar to you if you've read this book carefully:
- Discipline #1: Stakeholders cannot start more projects than the development organization can take on. And the best approach to ensure this happens is by employing pull-oriented production control systems, such as Kanban.
- Discipline #2: Teams required to deliver the selected value must work in unison. Large software organizations with multiple teams may split work across products, components, features, or large requirements. Split teams always have dependency issues.
Those dependencies become more challenging to address if each team maintains its product backlog and work pulls items in a manner that is efficient to them, which essentially is a form of local optimization. We need one product backlog and to have all the teams assigned to a product pulling from that one product backlog based on its priorities.
Moreover, each team's work must be integrated into a shared source control repository with new unit-level code tested regularly, usually multiple times a day, against the mainline code to ensure the new code does not introduce bugs. Those bugs become increasingly challenging to find and fix as the code grows around them.
Finally, we need the frequent release of increments to customers for review and testing. If we wait and customers don't like something we've done, the changes become much more challenging to make.
A Lean Thinking approach implements the shortest viable cycle times (from conception to consumption) and has the fewest delays along our value stream pipelines. Ideally, we want the rapid customer and product testing feedback loops built-in throughout our entire value stream systems.
- Discipline #3: Teams must let someone who sees the bigger picture decide what they should be working on. This sentence may seem a bit like a Duh comment. But it's easier to go wrong here than many might believe. Executives must communicate the business's strategies, priorities, and goals up and down the value delivery chain. They must practice Gemba to see for themselves what is going on at a tactical level. And they must seek input from those performing the work.
At the same time, the value stream operators cannot decide what work they should focus on or what their product backlog priorities should be. Only the product owner has that authority, and they will wisely seek counsel from the teams and their members before making product backlog priority decisions. Specifically, they must seek advice from the value stream teams to obtain real-time information regarding identified bugs and other issues of technical debt that can cause future state or downstream problems.
Allowing choice is a good thing
In this section, we address another issue regarding the use of a disciplined multi-team approach to improving agility. As it turns out, allowing choice is an integral part of a disciplined approach to build and maintain Lean-Agile business systems.
Enabling choice is not the free for all it may at first appear. Discipline is required to achieve an organization's whats consistently so teams can work together. But the hows of mandating predefined processes and tasks are left to those doing the work. Unfortunately, the traditional Waterfall-based project management practices approach was to mandate both the what and the how.
Too often, planners employed virtually all the practices defined within their corporate SDLCs – perhaps believing more is better. But it never is. The organization's SDLC processes and taxonomy and recommended activity dependencies often bloated project schedule plans with unnecessary and non-value-added tasks.
DA FLEX offers hundreds of techniques, but it would be rare that more than a couple apply to any specific software iteration. Therefore, teams choose only those patterns and techniques that best support their current needs. And only the teams evaluating the techniques have the information to know which techniques are helpful and apply to their specific needs. But it's also helpful to have a repository of predefined and contextually valuable practices that can be reused and situationally refined to suit each new application.
This section completes our discussion on the alignment of multiple teams with the DA FLEX approach to Lean Thinking. Now let's move on to review a proven approach to the successful enterprise-wide adoption of DA FLEX.
Adopting the DA FLEX model
The successful adoption of DA FLEX tends to revolve around a few core concepts, as follows:
- Focus on defining and establishing value streams from the start:
– You must move away from project-based or other push-oriented production control methodologies.
– Instead, adopt a product-oriented focus, use pull-oriented production flows, and improve value deliveries organization-wide.
– Suppose you've skipped a few chapters in this book. In that case, that means we seek more efficient flows of materials and information by eliminating waste, streamlining workflows around a steady cadence, and pulling products on-demand only when downstream capacity is available.
- Evaluate the proper pace of adoption in terms of the organization's culture and reasons for the adoption:
– For example, applying DA FLEX as a potential competitive advantage is one level of motivation, but quite different from those who are already facing a burning platform situation.
The former is a like-to-have situation, while the latter situation is a must-have.
- Create a tailored approach to your adoption:
– Remember, DA FLEX is a toolkit with guidance on using the information situationally; it is not a framework.
Use the tools that make sense to improve the success of your adoption.
- Guided continuous improvement starts from the beginning of the MBI initiative and continues throughout the life of a value stream without changing the improvement process.
- Focus on the workflow itself and not on DA FLEX:
– Again, the DA toolkit provides tools for situational needs you apply to address your unique situations.
Now that you understand the essential elements behind the adoption of DA FLEX, we'll take a look at the playbook that guides the adoption.
Implementing the DA FLEX playbook
From a conceptual point of view, DA FLEX promotes the view that value streams from different companies – even in different industries – are surprisingly similar. This is similar to the view espoused by James Martin in his book The Great Transition (Martin, 1995). But, on the other hand, the differences are what deliver value and competitive advantage. So, determine what's needed for your organization and recognize that there are no universal solutions.
Companies have products or services that they need to develop, improve, or change, and so they undertake work, expecting value in return. Organizations with additional constraints, such as the regulation of specialized hardware, have similar idealized value streams but with added factors to which to attend.
With these concepts in mind, DA FLEX starts with a description of fit for purpose and a way to continuously improve. The objective is to avoid being overly simplistic while not being complicated. Thus, its starting analysis method provides the basis for an organization to keep improving.
The DA FLEX playbook has the following steps:
- Understand the idealized value stream: To move from the current state to a desired future state. Understand what the idealized value stream looks like.
- See the challenges: What must be overcome, such as budgets, executive approvals, new improvements to processes and equipment, new skills, and other potential change items. Assess to understand your challenges.
- Identify actions: To solve your problems based on priorities that offer the most customer value for the financial resources, time, and people available to work on the change.
- Improvement backlog: To track identified and prioritized improvement objectives. Keep in mind your organization's culture, assign someone responsible for leading the change, and identify the opportunities for change.
Delay or avoid prioritizing proposed change items that are not in scope or that stakeholders will not support, and work items that create a cognitive overload.
- Keep improving: Continuously add to the improvements backlog, refine the work items, and re-prioritize to align with customer demands and market opportunities.
As your organization works through this iterative and incremental improvement process, constantly visualize what your idealized value stream looks like. Now let's look at how we go about planning a DA FLEX engagement.
Planning the DA FLEX initiative
At this point, the organization has decided to adopt DA FLEX. They have expective management buy-in and sponsorship. The adoption team and other involved stakeholders understand the DA FLEX playbook. So now it's time to plan the initiative.
Just as agile-based disciplines have product backlogs, the DA FLEX adoption team creates an improvement backlog that guides the activities of improving value realization for our customers. But, again, DA FLEX views prescriptive approaches as ineffective and therefore recognizes that customization is necessary. The customization is achieved by following the DA FLEX Engagement Pre-Planning Process shown in Figure 13.5:
Figure 13.5 – DA FLEX engagement pre-planning
The DA FLEX engagement pre-planning process is pretty straightforward, as you can see from Figure 13.5. First, the team performs an Assessment to determine the current state of product flows. Next, they assess Symptoms regarding challenges they face to transition from the current state to a desired future state with much less waste and better flows.
Since DA FLEX is essentially a lean-oriented improvement toolkit; the engagement pre-planning process also uses Pull-oriented control strategies to work on desired objectives from the playbook in order of priorities. Priorities are always established to ensure that the engagement team is always focused on improving those values stream activities that have the most significant positive impact on end-to-end flows. Then, as the team engages in the DA FLEX adoption, they choose their WOW from the options available in the DA toolkit.
With the DA FLEX playbook objectives chosen and desired WOW options selected from the DA toolkit, the team now identifies work tasks to move from the current state to the desired future state. Next, those work items are managed in an Improvement Backlog, with priorities again based on the most impact in terms of improving end-to-end flows.
Managing change through phases
DA FLEX implements a three-phased approach to facilitate change, including business transformations across an enterprise. The three DA phases are as follows:
Each phase includes DA process goals that help to guide users through the process-related decisions necessary to tailor and scale agile strategies. In addition, the process guides provide options to support each organization's unique operating environments, situations, and desired outcomes.
We won't dive any further into a discussion on the process goals, outcomes, and techniques available within the DA toolkit as there are too many to list here. However, those readers who wish to learn more can find additional details on the PMI's website at https://www.pmi.org/disciplined-agile/start-here.
Spanning all value streams
The roots of FLEX lie in the applications of Lean, Kanban, product portfolio management, and agile design to information technology. However, as a generic Lean-Agile approach to business transformations, FLEX also helps companies transition to Lean and Agile methods enterprise-wide.
In our digital economy, we cannot get away from the need to use IT as a business enabler. Still, lean-oriented value streams cut across all functional hierarchies, including the IT department. All of the methods employed by FLEX are based on the abstractions underneath – IT foundations of Flow, Lean, and Theory of Constraints. As a result, the practices of FLEX can be applied to all value streams.
Now that we've addressed the application of DA FLEX to value streams, we need to take a quick look at how DA FLEX categorizes its value streams.
Categorizing value streams
Many Lean practitioners talk about two basic categories of value streams – development- and operations-oriented. For example, both Scaled Agile and the Lean Enterprise Institute identify these two categories. But recall that James Martin was much more granular in his descriptions, identifying 17 common types of value streams. So, the difference is one of granularity. In the end, all organizations have more than 2 types of value streams, and most will have fewer or greater than 17 value streams.
DA FLEX introduces their Lean-oriented concepts around four types of generalized value streams – development, operational, enabling, and support. They define these four value stream types as follows:
- Development: Creating a product/service that provides value to the customer.
- Operational: How a customer goes about adding value.
- Enabling: A value stream that enables the output of a development value stream to be used within an operational value stream; for example, the internal IT shop building a software application or web-based system to implement product catalogs and product order taking.
- Support: A value stream to support an operational value stream. Here, we can use as an example a reseller or partner program that augments the sales and delivery capabilities of the organization.
DA FLEX is an approach geared to implementing Lean-Agile practices to effect business transformations that improve business agility. In this context, DA FLEX leverages software delivery value streams as critical enablers. But it should also be clear that DA FLEX looks well beyond the IT function to improve business agility across all organizational value streams. We'll now take a look at DA FLEX in this light.
Taking a holistic view of VSM
A central premise of this book is that VSM cannot simply be about the application of modern VSM tools to improve CI/CD and DevOps pipeline flows and software value delivery. In our modern digital economy, we use computing systems, highspeed networks, and software to improve everything – people's lifestyles, business processes, information access and analytics, product functionality, and control systems. Therefore, our modern VSM tools must help IT organizations improve value delivery across all these types of use cases.
As Al Shalloway worked with his clients, he realized that organizations must employ Lean-Agile practices across the enterprise and not just in software delivery. In short, Al realized organizations must take a holistic view of the organization as a complex and interacting system to successfully implement Lean-Agile practices that deliver value in our digital economy.
The following seven subsections document his insights on applying Lean-Agile practices supporting business agility in a digital economy. In addition, I've taken the liberty, with Al's permission and review, to expound on his initial observations.
Before we get started, let's understand the intent of the content in this section. In Al's words, the following list of activities and strategies represent 80% of what most companies need to learn how to do.
Portfolio management
This subsection highlights the activities and objectives within portfolio management that have the most impact on supporting the Lean-Agile enterprise.
- Implement Agile budgeting and Lean funding: Lean-Agile budgeting supports innovation strategies that are reviewable on at least a quarterly basis. Product funding is continuous, spanning a product line's entire life cycle, and allocated on a just-in-time basis.
In other words, Lean-based improvements require the funding of continuous value stream activities, the opposite of how funding is allocated on time and scope-limited projects. The primary issue is that project-based accounting hinders innovations due to the risks of missing planned scope, schedule, and delivery constraints. But, of course, project plans are invariably out of date – even before the ink dries.
In contrast, value streams live on to develop and deliver products. Both the products and the value stream activities improve over time through constant innovations. Therefore, Lean-Agile budgets are longer-term investments that require frequent assessments, adjustments, and fine-tuning.
- Fund the entire endeavor: All too often, companies focus on the value proposition without regard to the supplemental or ancillary factors required for the value proposition to be consumed by its intended customers.
- Coordinate CAPEX and OPEX expenditure: Develop CAPEX (depreciable assets) and OPEX (operating expenses) funding plans at the same time to avoid building something that is not financially viable. CAPEX also facilitates the coordination of development and operations that is often needed.
- Define strategies with measures: Metrics create clarity on planned investment areas and how to quantify them. The metrics, in effect, are the acceptance criteria that ensure the achievement of the business value propositions that justified the investments.
- Implement portfolio management to drive business strategies: Portfolio management is a discipline that looks across products and services to provide clarity on which investments provide the greatest value in supporting the mission and strategies of the business.
Portfolio management activities determine the investments and priorities necessary to achieve corporate mission, strategy, and goals, with many of those investments related directly to products. In the following subsection, you learn how product development and delivery activities are managed.
Product management
This subsection highlights the activities and objectives within product management that have the most impact on supporting the Lean-Agile enterprise.
- Implement discovery intake workflows: It's essential to implement a strategy to take high-level product requirements from initiatives to backlog items to a minimum viable product (MVP) and minimum business increments (MBIs).
- Improve the quality of the customer's experience: The quality of our customer's experience is directly proportional to the degree to which you attend to the customer's operational value streams and the value they provide. Again, user stories and acceptance criteria metrics define quality from our customers' perspectives or customer personas. A customer persona, or buyer persona, is a fictional archetype representing the critical traits of a large segment of our customers.
- Employ the use of MBIs and MVPs: MVPs are investments in new products where a return is not guaranteed. In contrast, MBIs are investments in existing products where returns are expected. All development and expansion of services should be done in small increments using MBI or MVP.
In other words, in each build iteration, construct just enough features to be usable by customers and then use their feedback to drive requirements for future product development enhancements.
The distinction between MVPs and MBIs is essential. MVPs guide the creation of new products where a marketing infrastructure is likely not in place. In contrast, MBIs guide enhancements to a product for an existing customer base, and the work may span multiple development teams and other value streams. Funding needs to be made available for both endeavors across the life cycle of the product.
- Define the 'definition of ready' for classes of service: Agree to Kanban classes of service (CoS) and then define a definition of ready for each. For example, define acceptance criteria or definitions of done.
Kanban employs the concept of CoS to help teams optimize the execution of their backlog items. Effectively, CoS implements policies governing development intake rules and always in consideration of the interests of customers.
- Sequence MBIs and MVPs: MBIs or MVPs are sequenced based on priorities within the intake queue. The highest feature-oriented priority work items deliver the customer's highest value from the customers' perspective, which always involves analyzing the development and delivery costs against the overall profitability or affordability of product deliveries.
Now that we know what's involved in managing product development and delivery activities, we need to understand how to inject new orders into our development and delivery systems.
Development intake
This subsection highlights the activities and objectives within development intake that have the most impact on supporting the Lean-Agile enterprise:
- Define the development intake process: The development intake process is a well-defined agreement on how to initiate work to be planned. The development intake process follows formalized governance policies that can be automated via machine-readable formats. Without well-defined intake workflows, organizations can't see what work is actually taking place. As a result, they tend to work on too many things.
- Plan value flow: Achieve an agreement on both the order of the work items and how to manage the identified dependencies. In a lean-oriented workflow, VSM initiatives seek to minimize dependencies, integrate and automate value stream activities, as well as orchestrate work and information flows across dependencies.
- Implement a program-level backlog: The program backlog includes MBIs, MVPs, features, bug fixes, and technical debt releases for development in the following value delivery flow or portfolio planning horizon.
New products introduced into our system follow specific product development flows. Therefore, we need to build our pipeline flows to support these products, as discussed in the following subsection.
Product development
This subsection highlights the activities and objectives within product development that have the most impact on supporting the Lean-Agile enterprise:
- Define MBI/MVP acceptance criteria. Anything we build must have quantifiable measures that indicate both the capabilities and level of performance desired by the product's customers. Through its VSM initiatives, the organization must evaluate the effectiveness of the acceptance criteria for every type of deliverable artifact.
- Implement small teams to improve work: The implementation of small teams supports collaborative work environments to minimize handoffs and hand-backs between value stream participants. People who work in teams have a shared goal and shared mission. With Lean-based flow and production control strategies, such as Kanban, they achieve higher throughput at the MBI, feature, and story levels.
Note
Disciplined Agile provides numerous Lean-Agile models to deploy and manage small teams. Additionally, my previous book, Scaling Scrum across Modern Enterprises, is all about scaling Scrum and Lean-Agile practices across multiple product teams and on an enterprise scale.
- Self-contained domain skills: The best team has members with overlapping and all-encompassing domain skills to ensure they have all the resources and skills necessary to build high-quality and maintainable products and services.
- Organize around value creation: Organize the development group to create an effective value stream. Large value streams that span multiple activities, distributed workstations, or geographic locations, as well as multiple knowledge domains, must employ team-of-team integration, dependency, and synchronization strategies.
- Create cross-functional teams: Cross-functional teams have all the skills, capacity, and resources to do the work assigned to them. It's also essential to build your teams with diverse work experiences and cultural backgrounds to bring a broader level of experiences and knowledge to problem solving. While small teams are ideal, they are often not practical or don't provide the capacity for larger and more complex product deliveries. FLEX introduces additional team structures to accommodate these realities.
- Shift-left with continuous quality verification: Development teams must verify quality after each step and automate the process wherever possible. In the traditional Waterfall model, testing is a late-stage activity that created all kinds of issues with defect and bug identification and resolutions, which often led to product release delays. Modern iterative and incremental development practices allow defects and bugs to be discovered and resolved earlier and easier, with minimal impacts on planned production releases.
- Design in product maintainability, resilience, and robustness: The architecture and design of the product or service must support its maintenance and enhancement at a low cost. The key to leveraging architecture and designs in Lean-Agile development environments is to maintain options in the face of uncertainty. Two terms are often employed to describe strategies for Agile-based architecture and designs. One is evolutionary architectures, and the other is emergent design:
– Evolutionary architecture concepts seek to incorporate changeability in a product's architecture to make it easier to change later to support previously unidentified functional and non-functional requirements. Nel Ford, Rebecca Parsons, and Patrick Kua outline evolutionary architecture concepts in their book Building Evolutionary Architecture: Support Constant Change (Ford et al., 2017).
– Emergent design is a concept that promotes a strategy to allow development teams to build functionality driven by requirements and lets the design emerge as an outcome. The emergent design strategy requires constant refactoring of software to merge redundant capabilities across released increments with a streamlined, simpler, and higher-performing code base. Emergent design should be guided by patterns-thinking.
Scott Bain of the PMI integrates design patterns, patterns-thinking, and the discipline required for quality design, as described in his book Emergent Design: The Evolutionary Nature of Professional Software Development (Bain, 2008).
- Change Vector Tracking is an iterative and reflective software engineering practice that supports emergent design. First, developers evaluate different design options in terms of a functional requirement defined as modifiability. Then, as business requirements change, they are tracked as a potential vector that may require software refactoring.
Product development activities work best when the people, skills, processes, and activities are integrated to create the efficient and streamlined use of organizational resources as Lean-oriented production flows.
Integration
This subsection highlights the activities and objectives supported by integrating people, skills, processes, and activities that impact the Lean-Agile enterprise:
- Leverage DevOps: The critical concept here is to have IT development and support teams working together. First and foremost, DevOps is a collaboration strategy to align the work of both IT functions. The benefit of having such collaborations is to minimize the potential for failed releases by getting the two sides of IT to work together and to identify potential problems and opportunities for improvements before a release goes out.
Of course, in its modern form, DevOps is also a software tools-based integration, automation, and orchestration strategy that effectively brings Lean production practices to the software development and delivery pipeline.
It is helpful to note that for all the well-deserved attention given to DevOps, it is merely applying lean-based value stream management principles to IT-oriented value streams at the end of the day. The same concepts are valid for CI/CD pipelines. Both are examples of lean production flows applied to a stream of IT activities.
- Implement continuous integration capabilities: In software engineering, CI is the practice of merging all developers' working copies of their code to a shared mainline repository, such as Git or GitHub, multiple times per day.
However, the CI concept is equally valid when implementing Lean practices generally. In such cases, multiple teams integrate their work into the whole product or service frequently. For example, the teams' work might involve integrating work items within a single value stream or orchestrating work items across multiple, but interconnected, value streams.
- Shared services pool: Most agile-based methodologies promote the concept of creating autonomous and fully self-contained teams to create products or deliver services. By self-contained, we mean they have all the skills and resources required to develop the product or service.
Still, sometimes new requirements may require skills beyond those available within the team. In such cases, the organization must have sources to provide specialized services on-demand to augment the teams' skills. In addition, if the new requirement is a long-term need, the team is expected to have one or more of its members develop the new skills.
- Provide system demos: In both the iterative and incremental development strategies of Agile and the continuous flows of Lean, the common goal is to deliver customer value. However, the definition of requirements and acceptance criteria is not an infallible process. If nothing else, many times, customers cannot envision what they need until they have a working prototype in hand.
As with all Agile practices, DA FLEX implements the practice of demonstrating end-to-end product functionality frequently, usually with every development iteration and release of incremental value. Even in a fully automated DevOps environment with frequent releases of business services directly into production environments, it's still a good practice to release each new increment of functionality to a subset of users who can evaluate its functionality in terms of their acceptance criteria. Those released services will have a limited impact if something is wrong, and they can be pulled back and fixed before allowing a full-scale release.
- Development coordinates with customer support: This concept is the premise behind DevOps. Development attends to their impact on customer support to provide visibility of what is coming down the pipeline. Developers also work with customer support staff (when and as needed) after release.
The objectives are to resolve potential problems before making their way into production and quickly resolve problems that make it into production. The joint teams should review the lessons learned to prevent future problems. The two teams discuss and resolve software defects, maintainability, sustainability, performance, failover, security, and potential enhancements identified by the support staff.
- Coordinate development with marketing: In several Lean-Agile practices, such as Scrum, SAFe, and Disciplined Agile, a product owner manages the product backlog activity to identify requirements, work item refinement, and set development priorities. While the product owners are ultimately responsible for all product deliveries, they must work directly with the development team, customers, and other stakeholders to make informed decisions.
Still, descriptions of the product owner function are highly simplified in virtually all Lean-Agile methodologies. Their role is tied directly to the much broader responsibilities of the product management and marketing organizations. Recall our discussions on Adaptive Marketing processes and activities in the Integrating value streams section of Chapter 6, Launching the VSM Initiative (VSM Steps 1-3).
- Bottom line: The development teams must inform the marketing and product management function on what is being released and ensure they have sufficient knowledge to build the products, capabilities, and features that customers want at a price point their customers can afford, or are willing, to pay.
Note how this coordination of different parts of the value stream is facilitated by using MBIs, which include the necessary players involved in creating them and ensuring they can be readily consumed. Finally, those organizations that employ Lean-Agile practices will always have a distinct competitive advantage over those that do not. So, let's now look at how we manage activities and objectives across value streams.
Across value streams
This subsection highlights the activities and objectives across value streams that have the most impact on supporting the Lean-Agile enterprise:
- Ensure visibility of all work across all workflows: The entire point of organizing around value streams is coordinating work around value delivery to improve flows and eliminate waste by eliminating delays in the workflow and obtaining quick feedback. That's hard to accomplish if we can't see the work or how it's performed. We need value stream maps, process guides, and metrics to get started. But, with modern VSM tools, we can also have real-time access and visibility to the flow of work and how well we are performing against our delivery goals.
- Establish safe work environments: This human element is critical to building sustainable work environments in both Agile and Lean practices. People must feel safe to 1) openly communicate their work-related issues and concerns, 2) showcase what they do visibly, and 3) not get crucified for work results or outcomes they have no control over.
Agile and Lean practitioners understand that we live in a stochastic world full of variables beyond our control that can, and will, impact our work. Therefore, both Lean and Agile practices implement techniques to identify variances to our plans, evaluate new opportunities, and explore methods to improve our work results.
When safety is missing, people tend to focus on local optimizations around their tasks. Unfortunately, this only strengthens the barriers that value stream management is trying to break down. By focusing on the end-to-end relationships across our value streams, we can avoid focusing on ineffectual local optimizations.
- HR and education departments must evolve to support business agility: HR and education policies need to enhance agility, not work against it. Those departments must encourage the development of a learning enterprise and make sure people have time built into their schedules for learning. Our employees also need access to resources for continued learning in the fields that support their work within the enterprise.
Organize people to work as teams around value delivery and do not pigeonhole them into functional departments. Similarly, management structures need to align with value delivery. Finally, we must create collaborative work environments that drive continuous improvements.
We need our people to feel safe when highlighting their concerns or when identifying opportunities for improvements. Therefore, we need to create cultures of respect and tolerance for diversity (race, genders, skills, experiences), even as we require excellence within and across our teams.
Compensation plans need to support growth in related skills and experiences, not just years in services. Compensation related to years in services is better tied to minimizing the adverse effects of inflation. At the same time, it's better to tie promotional pay raises to growth in skills and certifications that support the business needs of the enterprise.
Finally, organizations also need to use their bonus plans to drive team performance, not individual performance. Lean-Agile teams, not individuals, provide a competitive advantage in our modern digital economy.
As with any Agile or Lean-Agile methodology, roles must be clearly defined to understand responsibilities. Therefore, we discuss the roles involved in DA FLEX in the following subsection.
Roles
This subsection highlights the necessary roles and responsibilities required to support the Lean-Agile enterprise:
- Lean-Agile leadership and management: Lean-Agile leaders and managers focus on improving the environment people work in, providing adequate guidance, and avoiding micro-management.
The people performing the work often best understand the issues that hinder their work. Managers practicing GEMBA see the problems for themselves, and they can speak with the people who are dealing with those issues day-in and day-out and work in collaboration to define working solutions. Moreover, managers and leaders are in a better position to make informed decisions on required investments.
- Value stream manager: Each value stream must have a person who is responsible for the end-to-end delivery of customer value. The dedicated value stream managers help the Lean-Agile organization move away from local optimizations at a functional or local level to implement effective and efficient end-to-end production flows that deliver customer value.
- Business architect: Organizations must have a competent and influential business architect. The business architect has a focus on defining business structures that align implementation tactics with business strategies. Business architecture has its roots in business process reengineering.
The object management group defines business architecture as follows: Business architecture is a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands. Business architects oversee the organization's structure in the areas of business governance, processes, and information. In addition, they evaluate the organization's current capabilities to implement its strategies, determine a preferred future state, and define the roadmap to implement the future operating model.
- Enterprise architect: In contrast to business architects, who focus on process-centric alignments of business with strategy, the enterprise architect takes an information-centric view of the enterprise.
Enterprise Architecture (EA) evolved from a paper written by John Zachman in 1987 entitled A Framework for Information Systems Architecture. More recent EA frameworks include The Open Group Architectural Framework (TOGAF), the Federal Enterprise Architecture Framework (FEAF), and Gartner's Enterprise Architecture Framework.
Note
In the article entitled Business Architects versus Enterprise Architects: The Battle Must End, John Maynen makes the following statements:
"Simplistically, business architecture is about what a business does, while enterprise architecture is about what a business knows. And both disciplines are concerned about "why?" so that a business does what it needs to do and knows what it needs to know" (https://www.linkedin.com/pulse/business-architects-vs-enterprise-battle-must-end-john-maynen/).
- Product manager: For each product or service, there is someone who fills the role of product manager. Their role is different from the value stream manager in that the product manager has sole responsibility for discovering, articulating, and realizing the products customer's value.
Product managers establish the product's vision and create the development roadmap. They capture, analyze, and document customer needs, product capabilities requirements, and niche market opportunities. Critically, they must have the ability to see new or emergent product needs even before customers become aware that they have those needs.
Product managers analyze and consider the competition within their industry and product lines. Their assessments help build the business case for investments for a new product line or enhancements to an existing product. Finally, they present their business cases and ROIs to the organization's executives and portfolio management team.
Finally, they serve as product advocates across the company and promotions to customers, the media, and industry analysts.
- Program manager: A product manager attends to bringing all of the required pieces together for each product or service line, usually guiding activities funded as a strategic portfolio-level investment.
Product delivery seldom involves only one value stream, and many of those value streams have points of interaction. Just as we need to integrate, automate, and orchestrate work within a value stream, program management applies the exact strategies to cross-value stream operations.
- Product owner: Product managers must ensure that there are sufficient product owners to implement their product strategies effectively. In agile-based disciplines, product owners have sole responsibility for development outcomes and priorities.
That is not to say they do not obtain input from the development team, customers, and other stakeholders. They absolutely must have a clear understanding of what customers want, and they need to understand the development trade-offs in work related to functional versus non-functional requirements, fixing bugs, and working to reduce technical debt. And they must evaluate the cost-benefit relationships across work items within their product backlogs. But, in the end, only one person can be the ultimate decision maker on development priorities, and that person is the product owner.
You now understand all the roles involved in supporting Lean-Agile practices in DA FLEX. DA FLEX is not a one-time activity. As with any Lean or Agile approach, DA FLEX implements a continuous improvement strategy. We'll explore how that works in the next section.
Implementing a life cycle change strategy
Back in the section entitled Choosing your way of working with DA, you saw how the DA toolkit positions FLEX as the level that supports the implementation of value streams. The Value Stream level was depicted graphically in Figure 13.1 as a set of process blades that guide the 10 value streams identified by the purple hexagons.
Figure 13.6 offers a different view of eight of these value streams working in concert with six areas of focus from the DA FLEX DevOps layer. This section might be the most important in showcasing how DA FLEX integrates lean value streams with DevOps as a value stream management cycle of improvement:
Figure 13.6 – The DA FLEX life cycle
As you can see from Figure 13.6, the DA FLEX life cycle is a continuous improvement process that also operates as a flow. In Lean, we always start and end with the customer in mind, which is equally valid with the DA FLEX approach.
Starting with our customers, we work our way around counter-clockwise following this outline:
- Strategy: To develop a business strategy that supports our targeting customers' needs while also supporting the business's mission
- Portfolio Management: To evaluate investment strategies in support of the strategy
- Product Management: To define MBIs necessary to sustain the business
- Program Management and Disciplined Agile: To define a set of viable product offerings that deliver value by offering solutions to their needs
- Release Management and IT Operations: To properly sustain our developed products
- Business Operations: To realize value, learn from our experiences, and adjust to improve our way of working
- Support: To ensure our customers receive maximum value during the use across the life of our products
Using the five whys to get to the root cause
DA FLEX cites a use case where the 5 Whys of Lean are used to get to the root cause of a seemingly IT-related problem that turned out to have its roots in a process failure in an entirely different value stream. Let see how using the 5 Why questions technique helps the team get to the root cause.
As you read through this use case, bear in mind that the 5 Why strategy involves asking why something happened and then continuing to ask why, iteratively exploring the cause-and-effect relationships underlying a particular problem until we get down to the root cause of our issue:
Figure 13.7 – Five Whys use case
This process takes more time to execute than it takes to explain. But did you see how the questions started to address a concern that impacted the IT department and precisely why they needed to rework one of their software products? But, when all was said and done, the real issues turned out to be a value stream process failure in sales that prematurely ended their responsibilities without a proper handoff of server configuration requirements.
This section concludes our introduction to PMI's DA FLEX acquisitions and its applications to implementing DevOps and value stream management capabilities. It is one of two modern Lean-Agile methodologies presented in this book. The other is SAFe, which is covered in the next section.
Scaled Agile Framework (SAFe)
SAFe is the leading framework for scaling Agile across the enterprise. It provides four configurations to implement Lean-Agile practices in a large enterprise where the small team structures of traditional Agile approaches are insufficient to manage work in large economies of scale. With more than 20,000 enterprises worldwide practicing SAFe and more than 800,000 individuals trained to date, SAFe is the world's leading framework for scaling Lean-Agile practices across the enterprise.
Relevant to the topic of this book, value streams are a core construct of a SAFe portfolio and are woven into the fabric of the framework and provide execution guidance for all people and levels within the organization. In this section, you will learn how SAFe employs Lean-Agile concepts, including the alignment of human talent and business resources around delivering value as horizontal flows. You will also learn how SAFe implements value stream management as part of its SAFe DevOps strategies. Let's start this section with an introduction to SAFe's implementation of value streams.
Organizing around value streams
A value stream is the primary construct for understanding, organizing, and delivering value in SAFe. SAFe introduced value streams into the framework in 2013, which introduced operational and development value streams, along with value stream mapping to their enterprise community of users. Understanding and continually optimizing value streams is key to practicing SAFe effectively.
The development value stream is a long-lived series of steps used to create value—from concept to the delivery of a tangible result for the customer—and is the focal point of value stream management in SAFe. The development value stream identifies a chronological flow of activities, as shown in Figure 13.8:
Figure 13.8 shows that there is an initial request followed by a pipeline flow that delivers incremental value and that there is a lead time associated with meeting delivery expectations. The delivery flow as a process repeats for the life cycle of the product. The key elements defined in Figure 13.1 are defined in the list that follows:
- Trigger: An important event initiates the flow of value, such as a feature request or new solution idea. It ends when some unit of value—a product, service, or specification—has been delivered.
- Steps: The chevrons in the middle are the cross-functional activities required to define, build, validate, and release that unit of value.
- Value: The customer receives value when all the steps have been completed and the delivered solution meets their expectations. The organization may realize revenue, cost savings, customer satisfaction, or a combination of these in compensation.
- People and systems: Development value streams also include the people who do the work, the systems or equipment they operate, and the information and materials that flow from step to step.
- Lead time: The time from the trigger to the delivery of value is the lead time. Shortening the lead time accelerates the time to market. The easiest way to shorten the lead time is to identify and reduce (or remove) non-value-added activities and wasteful delays. That's the primary focus of Lean Thinking.
The flow of value in Lean moves horizontally across functional departments. As we've learned throughout this book, true customer value comes from aligning activities as efficient and streamlined flows from concept to delivery, which means we need to break down functional silos that generate waste, create waiting, delay deliveries, and increase costs. SAFe supports the horizontal flows of Lean production processes via its Agile Release Trains (ARTs).
This concept is shown in Figure 13.9 as a long-lived ART. Note that the larger arrow below the train depicts the flow of value horizontally, typically crossing such functions as software development, product management, information security, compliance, and operations. Also note, however, that the smaller return arrow indicates the process is iteratively applied to continuously provide incremental value deliveries:
Figure 13.9 – The cross-functional Agile Release Train
Figure 13.9 shows graphically that the ARTs implement product delivery flows; in this case, Define, Build, Validate, and Release activities. In other words, the ART is supporting value stream deliveries and is aligned around adding value. We'll look at the value-based deliveries of ARTs in more detail in the following subsection.
Aligning ARTs around value
SAFe recognizes fundamental team topologies (as defined by Skelton, Pais, 2019) to help with the job of team and ART design, which are defined as follows:
- Stream-aligned team: Organized around the flow of work and with the ability to deliver value directly to the customer or end user
- Complicated subsystem team: Organized around specific subsystems that require specialist skills and expertise
- Platform team: Organized around the development and support of platforms that provide services to other teams
- Enabling team: Organized to assist other teams with specialized capabilities and help them become proficient in new technologies
ARTs (https://www.scaledagileframework.com/identify-value-streams-and-arts/) guide the flow of value but are limited in size, typically consisting of 50–125 people. Limiting the size of an ART helps to minimize the complexities that come with expanding networks of people in large organizations. Figure 13.10 shows three possible scenarios for ART design:
Figure 13.10 – Three possible scenarios for ART design
Figure 13.10 graphically displays three value stream delivery scenarios supported by SAFe, as described next:
- A single ART supporting multiple value streams
- A single ART supporting one value stream
- Multiple ARTs participating in the development and delivery of large solutions
The ARTs support value stream deliveries in the form of a holistic solution or related set of products or services. The ART is a long-lived, cross-functional team of Agile teams that delivers value continuously. A goal of SAFe is to minimize dependencies between ARTs in order to minimize systemic communication, integration, and delivery issues. Thus, any given ART can release its solutions independently of other ARTs, maintaining a continuous flow of value to its customers.
In some cases, solutions require multiple ARTs working in tight synchronization. For example, delivering a new satellite system, complex medical device, or aircraft may involve thousands of individuals across many enterprise and supplier functions. SAFe implements its Solution Trains and the Large Solution configurations as shown at the bottom of Figure 13.10 to manage this level of complexity.
SAFe also implements a Lean-Agile model to improve business agility on an enterprise scale to compete effectively in a digital economy, which we'll look at more closely in the next subsection.
Competing in a digital economy with SAFe
Scaled Agile promotes its strengths as providing enterprises and partners with the value stream guidance, tools, and resources they need to succeed in the digital age. This includes identifying and mapping value stream activities, to managing and optimizing them. SAFe incorporates Lean, Agile, and DevOps practices that enable value streams. Along with their global community of 450+ partners and 12,000+ SAFe Program Consultants (SPCs), Scaled Agile has developed significant expertise at applying all these concepts in concert to support digital transformation initiatives.
However, unlike James Martin, with his 17 common value streams, SAFe aggregates value streams into just two types, Operational and Development value streams, although it does provide examples of each type of value stream, as defined and identified here:
- Operational value streams: The sequence of activities needed to deliver a product or service to a customer. Examples include manufacturing a product, fulfilling an eCommerce order, admitting and treating a patient, providing a loan, and delivering a professional service.
- Development value streams: The sequence of activities needed to convert a business hypothesis into a technology-enabled solution that delivers customer value. Examples include designing and developing a medical device, developing and deploying a CRM system, and an eCommerce website.
SAFe is another organization that realized that DevOps capabilities are key to competing in our digital age. As a result, they were quick to include DevOps within their framework.
Leveraging DevOps to support the digital enterprise
In 2018, Scaled Agile released its SAFe DevOps course with the aim of providing DevOps education and value stream thinking for the entire organization, not just CI/CD guidance for technical practitioners. The SAFe DevOps course involves technical and non-technical practitioners and leaders across functions in value stream mapping, bottleneck analysis, and value stream optimization. Consistent with the software industry's current VSM tool concepts, SAFe includes value stream management as a core DevOps practice, defined as follows:
Value stream management
VSM is a business practice that focuses on increasing the flow of business value from customer requests to customer delivery (Kirsten, 2020). VSM provides lightweight, end-to-end governance of the continuous delivery pipeline and optimizes it for maximum value delivery, as opposed to maximum adherence to fixed delivery plans.
VSM includes specific practices such as value stream mapping, analyzing flow efficiency through the end-to-end delivery pipeline, and setting targets for delivery speed, quality, and value. VSM also involves specialized software platforms that integrate with other tools throughout the pipeline to collect and reveal real-time data regarding the health of the value stream: https://www.scaledagileframework.com/devops-practice-domains/.
SAFe employs a specific VSM methodology, in the context of both mapping and management of value streams. The SAFe VSM approach covers the entire value stream – from customer request through the delivery of valuable, digitally enabled technology solutions that goes beyond CI/CD or DevOps pipeline applications. In other words, the SAFe VSM methodology supports Lean-oriented improvements across all organizational teams and functions, not just development and operations.
In this broader, enterprise context, Scaled Agile defines VSM as follows:
"Value Stream Management (VSM) is a leadership and technical discipline aimed at maximizing business value flow through the end-to-end solution delivery life cycle. VSM implements Lean, Agile, and DevOps values, principles, and practices across functions in the continuous operation, measurement, and optimization of value streams, from customer requests to solution delivery."
As you know from reading this book, value stream management is fundamentally a mechanism to make Lean-oriented improvements across an organization. So, let's take a look at how Scaled Agile employs Lean practices within their framework, while also accruing the benefits of dividing work among numerous small Agile teams.
Making Lean-Agile improvements with SAFe
Recall that Agile, as expressed in the Manifesto for Agile Software Development, is fundamentally a set of values and principles to guide small teams in their quest to deliver customer-centric value. The values behind the Agile manifesto place a premium on individuals and interactions, working software, customer collaborations, and responsiveness to change. The 12 Principles of the Agile Manifesto lay out objectively how an Agile organization operates: http://agilemanifesto.org/.
Still, the authors behind the Agile Manifesto were solving problems related to the traditional Waterfall model, which was not responsive to meeting customer needs or building software efficiently. So, the focus of the authors was primarily limited to the scope of authority given to relatively small software development teams. Therefore, appropriately, SAFe implements Agile practices at the small team level.
However, organizations must also deliver value across all organizational value streams as cross-cutting processes that operate horizontally and efficiently across all the departments and functions of the business. That is the focus of Lean production concepts, which SAFe also implements.
To achieve business agility, SAFe value streams require the employment of all the skills necessary to deliver products and solutions. This necessarily includes other business functions such as finance, contracts, quality, HR, security, product management, and marketing, to name a few. And for SAFe's cyber-physical systems builder customers, that extends to hardware teams, parts suppliers, and logistics partners.
In other words, value stream management supports Lean improvements across the organization, not just IT. But information technology, and particularly DevOps, is a critical enabler of value stream improvements. The trick is to align the efforts of DevOps teams to support value stream improvement across the enterprise in a coordinated and effectively prioritized manner.
Note
Scaled Agile is in the process of expanding their beyond IT guidance in this area. It currently includes workshops and articles for hardware, marketing, HR, and compliance (quality, security, and so on), each explaining their role in a Lean-Agile, value stream-focused organization.
The SAFe approach to VSM balances the thoughtful application of Agile and DevOps practices, supporting tools, and metrics, while also supporting Womack and Jones' five principles of Lean Thinking across the enterprise. This book introduces the Five Lean Principles in the next chapter, Chapter 14, Introducing the Enterprise Lean-VSM Practice Leaders, in the section on the Lean Enterprise Institute (LEI).
Given SAFe's focus on the implementation of Lean practices, value stream identification is integral to implementing SAFe and it is an early activity on the SAFe implementation roadmap. Additionally, Scaled Agile embraces Karen Martin and Mike Osterling's method of value stream mapping.
So far in this section on SAFe, we have learned that Scaled Agile promotes Lean-Agile concepts to compete in our modern digital economy. We've learned that SAFe guides businesses to organize around development and operational value streams. And we've learned that SAFe embeds value stream management concepts throughout the framework, both in its DevOps guidance and beyond. There is a lot more to SAFe than this, but before we go any further, we need to understand the four configurations of SAFe.
Selecting the right SAFe configuration
For this section, refer to Figure 13.4. At first glance, the SAFe for Lean Enterprises diagram appears to be fairly complex, but we can simplify the information contained in the diagram by breaking it down into SAFe's four constituent configurations:
- Essential SAFe: The basic configuration that implements iterative cadence with incremental releases leveraging a long-lived team of Agile teams (Scrum, XP, and Kanban) organized around Agile Release Trains (ARTs).
- Large Solution SAFe: Multiple ARTs can work in concert as a solution train for very large product development efforts.
- Portfolio SAFe: Established the Lean Portfolio Management discipline to align product and infrastructure investments over multiple planning horizons, and consistent with Lean accounting practices.
- Full SAFe: Installs all four configurations to enable business agility on an enterprise scale:
Figure 13.11 – Full SAFe for the Lean Enterprise (SAFe™ 5.1)
Looking at the left column of the Full SAFe diagram (Figure 13.11), you can see that SAFe implements more roles than those commonly found in other Agile frameworks. But there is also some consistency with roles found in Scrum in that Agile teams, ARTs, and solution trains all have three key roles:
- Scrum Master / RTE / STE: Servant leaders for Agile, ARTs, and solution trains, respectively
- Product Owners / Product Managers / Solution Management: Responsible for product backlog priorities for Agile teams, ARTs, and solution trains, respectively
- Development Teams / System Architect/Engineer / Solution Architect / Engineer: Develop products at the Agile team level, and design or engineer products and solutions at the ART and Large Solution level.
SAFe also makes sure that business owners remain involved in guiding product development and delivery activities. Business owners typically have Return on Investment (ROI) responsibilities in their value streams.
At the Portfolio Configuration Level, SAFe implements Epic Owners and Enterprise Architects to guide strategic investments in products and infrastructure and resolve technical debt at an enterprise level. Where the other roles operate on relatively short program increments, typically 8–12 weeks long, the Portfolio level executives plan over 1 to 3+ year planning horizons.
There's still a lot more to learn about SAFe, but more than we can cover in this book. Readers who want to learn more about SAFe can read my previous book, Scaling Scrum Across Modern Enterprises (Rupp, 2020). But let's get back to the subject of improving value via SAFe's DevOps concepts.
Achieving continuous value delivery
We're now going to dive more deeply into SAFe's approach to DevOps in support of an organization's continuous delivery pipeline. As depicted in Figure 13.12, Scaled Agile breaks out pipeline flows into four parts – Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand (RoD):
Figure 13.12 – The Continuous Delivery Pipeline (CDP)
There's a lot going on in this diagram, so I'll break it down in the following bullet list:
- Continuous Exploration (CE) focuses on creating alignment on what needs to be built. Here, the focus is on understanding market opportunities and customer demands. The objective is to identify the requirements for a Minimum Viable Product (MVP) and Minimum Marketable Features (MMF). This work also includes architectural and existing product modification assessments leading to a refined understanding of the capabilities and features required to meet customer and market needs, which are then prioritized and managed within the Portfolio, Program, and Team backlogs.
- Continuous Integration (CI) focuses on taking features from the Program backlog and implementing them. Here, the work has a focus on product designs (for example, designing a user story map), and may include development of prototypes for user feedback. As specific features are clearly understood and refined, the Agile Teams implement them according to a typical Agile approach, such as XP, Scrum, or Kanban. All products and associated artifacts must be maintained under version control, built, and integrated into a full system or solution, and tested end to end before user and performance validations in a production-like staging environment.
- Continuous Deployment (CD) takes the changes from the staging environment and deploys them into production. Even though the products have undergone continuous testing, production deployments must be monitored and verified to meet all acceptance criteria. This step migrates new functionality to production, but the business determines the appropriate time to release it to customers. Controlling rollouts also allows the organization to respond to issues and rollback or fix forward when necessary. All artifacts associated with a specific release must be maintained under configuration management controls to ensure maintainability of the products and solutions over time.
- Release on Demand (RoD) is the ability to make value available to customers all at once, or in a staggered fashion based on market and business needs. This strategy allows the business to release new products when market timing is optimal and minimize the amount of risk associated with each release. For example, changes to enterprise software applications usually affect business processes, and we need to make sure that we communicate with and train affected employees and other stakeholders on the upcoming changes. RoD also encompasses critical pipeline activities that preserve the stability and ongoing value of solutions long after release, for example, IT Service Management (ITSM) and IT Operations Management (ITOPs) processes. Finally, RoD contains critical measure and learn activities, which close the loop on hypothesis-driven development and fuel continuous learning and experimentation.
The CDP represents the workflows, activities, and automation needed to guide a new piece of capability or functionality from ideation to an on-demand release of value to the end user. The objective of CDP is to optimize pipeline flows. So, let's take a closer look at how the CDP process works.
Improving pipeline flows in SAFe
SAFe implements processes for pipeline flow improvements that will look very familiar after reading Chapter 6, Launching the VSM initiative (VSM Steps 1 - 3) through Chapter 10, Improving the Lean-Agile Value Delivery Cycle (VSM Steps 7 and 8) of this book, where we applied the generic VSM methodology to improve a CI/CD pipeline flow. The improvement steps in SAFe include the following:
- Map the current flow.
- Capture relevant metrics:
– Process time, lead time, delay time, and percent complete and accurate (%C&A)
- Align current workflow to the continuous delivery pipeline:
– Exploration-related activities
– Integration-related activities
– Deployment-related activities
– Release and post-release-related activities
- Identify opportunities for improvements.
- Build continuous delivery capabilities via Portfolio, Solution, and Program Kanbans. The work item types flowing through them are Epic, Capability, and Features, respectively.
Note
Note that SAFe employs the same general pipeline flow improvement and continuous delivery strategies at the Portfolio, Solution, and Program levels.
Also, SAFe implements the concept of Architectural Runway to identify and manage technology investments that improve delivery capabilities, for example, making investments in DevOps toolchains.
- Relentlessly improve through continuous measurement, reflection, and learning.
The online SAFe guidance on value stream mapping does not explicitly address future state mapping. However, Scaled Agile promotes future state mapping as a critical exercise and includes it in the value stream mapping exercises within the SAFe DevOps class. Scaled Agile is also developing a broadly consumable (not just for DevOps customers) value stream mapping workshop, which will include detailed guidance on future state mapping.
Scaled Agile understands that there are several reasons why we cannot ignore mapping the desired future state. So, let's take a look at some of the issues that arise when we fail to map the future state when identifying opportunities for improvement.
Mapping the current and future states
Though we will often start with high-level current and future state maps, ultimately, we must get down to more granular levels of detail and identify lower-level activities involving work and information flows, tools and tool configurations, decision making, and manual interventions.
With detailed and accurate current state maps, we can identify unnecessary activities that can be aggregated and improved through new tools and configurations. We can identify activities that can be improved through automation, and we can explore better methods and tools to orchestrate work and information flows. In short, the future state maps can look very different from the current state maps, and there can be more than one future state map as the VSM team evaluates their options.
Future state maps provide visibility to an idealized state so that all value stream members, executives, and other stakeholders have a shared vision of their target objectives. Some changes can occur with little cost and effort, but others may require investments that span multiple planning horizons. We don't want to lose that vision, which the current state maps won't show.
Finally, the metrics that indicate our areas of waste and unbalanced flows that cause queuing, waiting and additional costs don't tell us a thing about how to fix our problems. We have to do the work, evaluate alternatives, and create future state maps showing our improvement options, including time, resource, and cost estimates to implement each proposed alternative. In this context, future state maps are very much part of the improvement identification and assessments process.
You should now have a general understanding of how SAFe implements continuous delivery pipelines across all SAFe configurations. Now let's move on to understand how SAFe DevOps improves continuous delivery pipelines.
Enabling the CDP with DevOps
This is the point where SAFe diverges from traditional VSM concepts by positioning DevOps as a critical enabler of success, as well as extending its application of DevOps to the entire value stream. Of course, you now know that DevOps is the critical enabler to compete in our digital economy; and that is the position that Scaled Agile adopts, too. In this context, SAFe DevOps follows the VSM tool initiatives we discussed in Chapter 11, Identifying VSM Tool Types and Capabilities.
In this subsection, we're going to get into the details of how SAFe DevOps supports improvements to continuous deliveries. This topic will also take us back to the discussion of value stream management as it's applied within SAFe. As you will find, SAFe DevOps encompasses a number of concepts that we will only briefly cover.
For this section, please refer to the following figure:
Figure 13.13 – DevOps enables the CDP
The first thing you should notice in Figure 13.13 is the outer rings depicting the four components of the previously identified CDP, to include continuous exploration, continuous integration, continuous deployment, and release on demand. But now we see that SAFe DevOps includes pipeline activities for each CDP stage.
At the center of SAFe's DevOps meta-model is SAFe's CALMR approach to DevOps, which is a continuous delivery mindset that guides all decisions and actions throughout the CDP. The CALMR acronym stands for Culture, Automation, Lean flow, Measurement, and Recovery. Let's look at each of the elements of CALMR in a bit more detail:
- Culture of shared responsibility
- Automation of the CDP
- Lean flow accelerates delivery
- Measurement of flow, quality, and value
- Recovery reduces risks and preserves value
The focus of SAFe DevOps and its CALMR approach is to center the ARTs on achieving extraordinary business outcomes. Those outcomes don't arise from simply automating tasks in the pipeline. The real benefits come from applying automation, Lean, measurement, and recovery techniques in a way that builds a thriving continuous delivery culture.
The internal rings of the SAFe DevOps diagram highlight the component capabilities required to establish a mature DevOps environment. These include, from the center outward:
- Value stream management: The approach used to make lean-oriented improvements across value stream flows. In SAFe DevOps, the goal is to increase the flow of business value from customer requests to solution delivery.
- Continuous quality: Ensuring we deliver products and services and conformance with requirements and their defined acceptance criteria. Under SAFe, quality is built in early in the pipeline and continually managed throughout a solution's life cycle. Quality practices include specific practices such as hypothesis-driven development, behavior-driven development (BDD), test-driven development (TDD), A/B testing, and exploratory testing. Automation is used to enhance the speed and accuracy of testing throughout the value stream.
- Continuous security: Helps ensure the safety of our information, products, and services not only for our own organization, but for our partners, stakeholders, and customers. Security practices include security by design, threat modeling, security-as-code, and automation in vulnerability scanning, penetration testing, and intrusion detection.
- Version control: Ensuring proper processes are in place to rigorously identify all the artifacts created in our value stream flows. Artifacts include application code, server, network, and firewall configurations, database scripts, requirements, and test scripts. All versions need to be stored in a common repository to ensure solutions and environments can be built, deployed, repaired, and decommissioned on demand.
- Configuration management: Ensuring proper processes are in place to rigorously identify all the artifacts associated with each and every product release. Where version control emphasizes how to manage different versions of artifacts, configuration management emphasizes what to manage for each release. In a modern DevOps context, configurations tend to be managed as as-code – infrastructure-as-code, security-as-code, and compliance-as-code.
- Infrastructure management: Ensuring we have a robust, sustainable, secure, and supportable infrastructure in which to develop and deliver our products and services. The objective of infrastructure management is to ensure the stability and resiliency of deployed solutions so that maximum value can be realized. Where configuration management installs a set of design-time practices, infrastructure management installs a set of runtime practices.
- Agile product management: Places a focus on continuous learning, but also encompasses customer centricity, hypothesis-driven development, design thinking, Lean Startup, and market research practices. The goal of this domain is to ensure that the CDP is always calibrated to deliver specific, measurable business outcomes.
The outer rings within the inner concentric circles indicate four critical practice domains that represent a solution's path through the system. The three practice domains include the following:
- Agile planning and design: Provide inputs to development, including desired business outcomes, solution scope, architecture, and design, to improve continuous deliveries.
- Deployment pipeline: This is the CI/CD portion of the software pipeline delivery model.
- Continuous monitoring: Includes full stack telemetry, observability, proactive issue detection, visualization, AIOps, and analytics to measure and maintain business value with a high degree of precision.
SAFe customer use cases
Scaled Agile makes the point that you can't really do SAFe without value streams, and they believe that many of their case studies speak directly to this. All of the SAFe customer stories can be found at the following URL: https://www.scaledagile.com/customer-stories/.
And more specifically, the use case located at this URL, https://youtu.be/02IPXgYlNkY?t=2331 (minute 39), speaks directly to the power of value streams.
Scaled Agile presented the following use case describing how PCCW Global/Hong Kong Telecomm implemented ARTs to support the launch of several newly implemented value streams:
Figure 13.14 – PCCW Global/ Hong Kong Telecomm use case
This section ends our discussion on the Scaled Agile Framework and the chapter as a whole. In this section, you learned how SAFe supports implementing value streams through their agile and solutions-oriented release trains. SAFe provides direct guidance on leveraging the resources of a large enterprise, taking advantage of their economies of scale while supporting their digital transformations through Lean-Agile improvements. Like Disciplined Agile, SAFe includes DevOps as a critical enabler to improve software value deliveries in support of the organization's digital improvement objectives.
We'll now end this chapter with a summary, followed, as always, by questions.
Summary
In this chapter, you learned about three organizations supporting the implementation of the VSM concept in a modern Lean environment, specifically leveraging improvements to DevOps pipeline flows to streamline an organization's software value delivery capabilities. First, you learned about the VSMC, a not-for-profit trade association funded by members (vendors and enterprises) to conduct research, learning, networking, and open source projects related to value stream management methods and tools applied to software delivery improvements.
Next, you learned about PMI's new DA FLEX acquisitions as its approach to helping organizations install Lean-Agile practices on an enterprise scale. In this section, you've learned that the DA toolkit helps you, your teams and your organizations choose their WOW best supporting their unique circumstances. You've also learned how FLEX is PMI's approach to implementing value stream flows and improve value deliveries using value stream management techniques.
The third Lean-Agile/VSM implementation approach you learned about is SAFe™ – the current leading framework for scaling agile practices on an enterprise scale. You've learned that SAFe DevOps is Scaled Agile's approach to implementing VSM concepts as part of DevOps to maximize business value flow through the end-to-end solution delivery life cycle. You've also learned how SAFe DevOps implements VSM, Lean, Agile, and DevOps values, principles, and practices across functions in the continuous operation, measurement, and optimization of value streams from customer requests to solution delivery.
Now that we have covered the leading VSM methodology providers supporting DevOps-based improvements, we will move on to Chapter 14, Introducing the Enterprise Lean-VSM Practice Leaders. In that chapter, you will learn about two of the leading Lean methodology and training organizations, Lean Enterprise Institute and LeanFITT. These two organizations defined the original concepts behind value streams and value stream management, respectively.
Questions
- What is the purpose and objective of the VSMC?
- Structurally, the VSMC practices what it preaches by aligning its work around three value streams. What are they?
- What is the initial research offering provided by the VSMC?
- PMI acquired two companies to jump-start its Lean-Agile practices. What were those two companies, and what were their offerings?
- What is Disciplined Agile's approach to assisting Lean-Agile teams?
- What is the purpose of process blades within the DA toolkit?
- What are the four layers of the DA toolkit?
- What role does FLEX play within the DA toolkit?
- State the importance of value streams within the Scaled Agile Framework® (SAFe®).
- What are the key elements of Lean value streams within SAFe?
- In a broader, enterprise context, how does SAFe define value stream management?
- What are the flows that contribute to SAFe's Continuous Delivery Pipeline (CDP)?
- What is the relevance of DevOps to SAFe's CDP?
- What does the acronym CALMR stand for, and what is its purpose?
- What role does value stream management play in SAFe DevOps?
Further reading
- Ward, Allen (2004), Lean Product and Process Development (video). Lean Enterprise Institute, 2004.
- Kirsten, M. (July 2020), The Rise of Value Stream Management (VSM): https://www.linkedin.com/pulse/rise-value-stream-management-vsm-mik-kersten/.
- Skelton, Matthew, and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.