5 images Tracking and Monitoring Program Flow

Historically, projects and programs have been tracked and monitored along the triple constraints: scope, schedule, and cost. Using these as sole measures of progress has proven to be quite problematic, as scope is often variable, schedules are usually assessed through unreliable artifact-based milestones, and costs vary in tandem with changing scope and schedule. In fact, even as triple-constraints thinking has dominated the project management space, we have struggled to ensure on-time delivery of product scope within cost and quality constraints. Tracking and monitoring project or program progress in a traditional triple-constraints regime has thus been an enormously challenging and thankless part of project managers’, program managers’, and PMOs’ jobs.

Gradually over the years, and especially with the advent of agile methods, we have learned some lessons the hard way, including the primary epiphany that product scope cannot realistically be locked at the project level. If product scope is locked at a high level, it has counterintuitive and unintended, damaging consequences. Rather than aiding the delivery of desired business outcomes, locking scope causes enormous amounts of waste; including obsolete features, unnecessary complexity, and wasted time and money. It has also dawned on us that tracking document deliverables is a fool’s errand, because we are relegated to tracking and monitoring things that do not provide correct insight into the progress of product scope delivery and we have no way of determining our true progress toward business outcomes. For instance, the delivery of requirements documents, design documents, and test plans, while important, provides no clear indication of progress toward the development and delivery of the product, let alone its business outcomes.

Agile pioneers such as Bud Phillips, who was vice president of Decisioning Services at Capital One in the early 2000s, came to this realization early on and forged the way to a flexible outcome-driven approach rather than getting locked into a rigid waterfall iron triangle. In a 2006 interview with our colleague Bob Payne, Bud laid out many of the ingredients of his “secret sauce.”1 Realizing that their business group was both slow and not flexible enough, his colleagues and he decided to begin piloting experimenting with lean and agile. They partnered with their IT colleagues to develop a faster, flexible approach that brought customers in from the very beginning of their solutioning. In doing so, they reoriented the relationship between operations and IT, creating a shared definition of, as Bud puts it, “what’s valuable is not functional perfection, but the total outcome.” Their approach, which is widely prevalent today, applied some simple but powerful techniques. Realizing that flow is what really matters, customers worked in the same room as their agile teams in interdependent exploration toward a shared business outcome. They changed the relationship from “We’ve got to have a big, detailed plan to We have good business sense, so let’s get started and the future will unfold with a high degree of predictability.” As Bud eloquently describes it in his now-classic interview, there was fun, energy, and excitement even as they became 10 times more productive with agile than with waterfall.

images

Figure 5.1: From the iron triangle to the agile triangle

Bud and his team were so successful because they focused on business outcomes and applied lean fundamentals along with agile practices in their problem-solving. As we saw in chapter 4, sequential waterfall delivery also generates rework and waste by forcing us to work with large batches: large batches of requirements, large batches of design elements, large batches of product to engineer, and then of course, large batches of the final product to test and release. From lean, we know that these large batches cause all sorts of inefficiencies and wastes, including costly handoffs from people in one silo to another, product defects, and the inevitable schedule and cost slippages. Drawing on this lean fundamental, agile methods have institutionalized the concept of incremental product delivery to enable small batches, causing value to flow much faster to the customer, and upending the traditional iron triangle, as illustrated in figure 5.1.

Making this transition to the agile triangle has brought us several benefits. The old model forced us to work in an opaque environment without clear insight into dependencies between different silos, and with very little knowledge of where true bottlenecks might exist. Now we can realize measurable business outcomes as our project and program leaders closely track and monitor the flow of value from idea to delivery, manage dependencies to coordinate this flow of value, and aggressively identify and eliminate impediments to delivery. In chapter 4, we saw that this model enables us to shift our thinking to conform to value instead of complying to plan. Our next mindset shift is from project to product, from large to small batches of work, and to tracking actual product value and outcomes instead of just project document output.

Our old model had its traditional tracking mechanisms similar to Gantt charts on a project schedule. While familiar and visually appealing, these artifacts unfortunately provided inaccurate insight with the illusion of control, based as they were on interim project outputs like document deliverables and not on the final product itself. Compounding the issue is the fact that we as humans are highly visual creatures and it is difficult for us to understand and manage what we cannot see. So in addition to tracking the wrong things, traditional tracking methods did not provide any sort of bird’s-eye view to visualize and rapidly understand the big-picture overall status. Now, with our new incremental, value-focused delivery, we also draw on lean to incorporate visual management and visual management systems to rapidly communicate vast amounts of information in standardized ways.

Understand Visual Management Systems

Visual management is a core foundational element of lean thinking (see sidebar), derived from Toyota’s lean management system and a popular management technique employed worldwide across industries. It is based on the fundamental concept that we as people process information better visually and that we learn faster from the visual presentation of information than by any other means of information presentation.

In a product delivery or program management context, visual management systems (VMSs) are used to accomplish the management of work by visually communicating the work being done along with desired business outcomes, expectations, standards, performance, and alerts. Fundamentally, because these systems help us make visible and visualize all the work in progress; they eminently enable tracking and monitoring the flow of value. VMSs also help us identify any impediments to flow and can help us resolve them in a collaborative manner. Some fundamentals that are key to the proper application of VMSs are the lean concepts of visualizing flow and limiting work in progress and incorporating the newer concepts of objectives and key results (OKRs) and minimally marketable products (MMPs). These fundamentals are described next.

Visualizing Flow

Flow means moving along steadily and readily in a continuous stream. In a lean or agile context, flow is how our work progresses through our program or product development system. To track the flow of work through our system, we need to visualize our work as it flows through our product development system and organization, beginning with when a customer requests a product feature and ending when we realize business value by having that feature delivered to the customer.

When our system is working well, or has good flow, value tends to move steadily and predictably. When that flow is interrupted—when work starts, stops, or is blocked—waste increases, and the delivery of value to our customers is interrupted and delayed as well. Our agile mindset thus calls for a steady, consistent flow that results in the reliable delivery of value to our customers, teams, and stakeholders. Thus, visualizing and managing our flow is essential to achieving faster and more consistent delivery of value toward business outcomes.

At the Motley Fool, a decidedly unconventional financial advisory firm that prides itself on its quirky culture, visualizing flow begins from their team configuration and workspace.2 When they redesigned their workspace, flexibility was the driving factor. So now employees can dynamically reconfigure their teams according to emerging needs for the flow of work. They regularly adapt to match the flow of work by adapting their team configurations along with their workspaces by moving their tables and workspaces around. Mobile physical whiteboards and their digital facsimiles make the work and the flow of work visible, even as teams are adapting in real time to align with that flow.

Limiting Work in Progress

Imagine a crowded highway at rush hour in a major city. Traffic is bumper to bumper, and nobody is getting anywhere quickly, as illustrated in figure 5.2.

The highway, however, is being efficiently utilized; almost every square foot of this very expensive resource has a car on it. Given this highly efficient utilization, why are cars not able to move faster? The reason is that utilization and throughput are negatively correlated, as illustrated in figure 5.3.

images

Figure 5.2: High utilization, low throughput

images

Figure 5.3: The effect of utilization on cycle time

That is, the higher the shared utilization of a scarce resource, the slower we go. Traffic systems, networking systems, and queuing theory in general predict this behavior. However, we in management have not thought to apply this same thinking to tracking and managing program flow until fairly recently. From queuing theory, Little’s law tells us

cycle time = work in progress ÷ average completion rate

To get the work in our systems moving faster, we can either reduce work in progress (represented by the total active work in the system) or increase the average rate at which we complete work. Increasing the rate at which we complete product work is a fairly difficult endeavor. The most straightforward way to reduce the cycle time of work flowing through the system and to increase the throughput of value through the system is to limit work in progress. Limiting work in progress and improving flow in the system is best done by chunking product increments into MMPs.

Improving Flow with MMPs

As we learned in chapter 4, an MMP is a deployable set of minimum product features that address customers’ immediate needs, deliver value back to our business, and allow us to test and learn. We can dramatically improve time to value by chunking product releases into MMPs. That is, instead of carrying massive project inventory to deliver product functionality in one big bang, we deliver products in increments of MMPs and improve lead time as a direct result.

Using OKRs to Quantify Value

From chapter 4, we know that OKRs are a collaborative goal-setting mechanism used to set challenging, ambitious goals with measurable results. OKRs drive us toward progress, create alignment, and encourage cohesion around clear, quantifiable goals. OKRs help us quantify value and track its flow through VMSs.

Track and Monitor Program Flow with VMSs

As we’ve learned thus far, VMSs allow us to see knowledge work flowing through the value stream toward delivery. Blockages and delays in flow become readily apparent when they are made visible. Combined with flow-based metrics, leaders get a real-time sense of where value is flowing, where it is blocked or delayed, and what we as leaders might be able to do about it. The two major elements of program flow tracking and monitoring using a VMS are design and institute the VMS and measure and improve flow. We’ll explore these elements in detail next.

Design and Institute VMSs

Our goal with a VMS is to set up a system that enables the steady, consistent delivery of value by allowing everyone to understand the system at a glance, assess the status of value delivery, and identify any issues that are impeding progress toward business outcomes that can be specified using OKRs. From a business perspective, success is judged by whether we meet our business outcomes or not, and any system that gives us insight into progress toward meeting these business outcomes is critical. As such, a VMS provides the link between the people and the data needed to track and monitor the delivery of value toward business outcomes. An effective VMS displays product or program status and performance information, communicates standards and work instructions, and makes problems and issues as transparent as possible. When problems and impediments to the flow of value are visible and transparent to all, immediate corrective action can be taken to ensure the continuous delivery and value and progress toward business outcomes.

To enable easy visual communication and management for a team that is primarily collocated, a VMS typically employs a large wall with standardized visual controls, labels and signs, color coding, and other markings instead of written instructions, as illustrated in figure 5.4.

Practically, designing and instituting a VMS involves these considerations:

• determining a physical location for the VMS and, optionally, an accompanying digital tool

• coordinating with facilities staff to mount and secure the board

• identifying key roles and responsibilities: a VMS owner, a core team to drive the VMS effort, and an extended team with representation from customers and other stakeholders

• identifying the process, program, or product flow from inception to delivery

• recording OKRs as clear indicators of business outcomes

• creating a guide that describes the VMS key elements

• establishing an operational process that includes regular in-person review, as well a process to capture issues and to ensure their resolution

images

Figure 5.4: Physical VMS visual design and standardization

In addition to the physical representation of the VMS on a wall, we can capture its facsimile in digital tools like Planview Leankit, Jira, or Azure DevOps, as shown in figure 5.5. When our teams are primarily distributed, it is common to operate exclusively with the digital VMS.

images

Figure 5.5: Digital VMS design and standardization

images

Figure 5.6: Program-level VMS: A simple program alignment wall

We can deploy VMSs at many levels, including the team and program and portfolio levels within our organizations.

At the team level, we can use a VMS as a team dashboard and capture essential information needed for each team. Items tracked on a team dashboard VMS might include Sprint burndown and velocity, high-priority issues, continuous integration and continuous deployment results, and team assignments.

At the program level, we can accomplish tracking and monitoring across teams by creating a VMS similar to the program alignment wall (PAW). Illustrated in figure 5.6, PAW was introduced by our colleague Bob Payne some years ago and evolved by a client of ours to manage the work across a bimodal agile and waterfall program of 21 teams in total, with 4 agile and 17 waterfall teams. This VMS creates a simple but granular view into delivery by chunking the work of multiple teams into one feature at a time. The feature represents the one piece of business value that needs to flow from the customer; through development, testing, and deployment; and back to the customer as quickly as possible without interruptions. Specifically, the PAW tracks the flow of work through the system by laying it out in a two-dimensional format:

• rows represent swim lanes of functionality

• columns represent Sprints or iterations

• cards represent epics (large chunks of work) and are laid out as an overall release plan

• dot labels on cards capture interteam and interproject dependencies

Note that everything on the PAW is also simultaneously maintained in an agile life cycle management tool like Jira or Microsoft Azure DevOps.

images

Figure 5.7: Program-level VMS: A more detailed program alignment wall

If your tracking needs are more complex, a more current and detailed version of the PAW is illustrated in figure 5.7. This detailed PAW tracks features, subfeatures, and tasks along with target dates, dependencies, owners, risks, and any other relevant notes.

Measure and Improve Flow

By making all work totally visible, a VMS affords us insights into flow and impediments to flow that would not otherwise be possible. In an agile environment, a VMS also enables rapid end-to-end feedback that drives continuous learning. As features flow through the system, we can measure their lead time, or the time it takes to go from initial idea to actualization of value in the customer’s hands. As MMPs are delivered to customers, we have the opportunity to get their feedback and measure desired business outcomes as specified in our OKRs.

Flow metrics like lead time are based on the value propositions of MMPs that can be incrementally delivered and evaluated, and thus they provide excellent indicators of progress toward value delivery. So rather than focusing on project outputs as in the triple-constraints world, we can instead establish business outcomes using OKRs and continuously measure the realization of product and business. If MMPs fall short of their business cases, as assessed by frequent and thorough inspections (preferably with real target users), we can retarget or clear them from the portfolio.

images

Figure 5.8: Lead time and cycle time

Tracking lead time is the most basic VMS flow metric and an excellent place to start. As shown in figure 5.8, lead time is the total time elapsed between the initiation and the completion of an item, while cycle time is the time taken for one cycle of an operation within the total process. In a product development scenario, it is useful to differentiate between end-to-end lead time, MMP lead time, and development cycle time. Development cycle time is the time from putting a story in development to having a story ready for deployment. MMP lead time is the time from when the MMP is created to when the MMP is delivered to end users in production. End-to-end lead time is the total time from when an initial product or service idea is created to when it is delivered to customers. In this example, development cycle time is simply the time it takes to deliver a user story within the larger MMP.

The next task is to identify what types of items we should track and measure on our VMS to apply the lead time metric. In his Flow Framework, Mik Kersten recommends tracking features, defects, risks, and debts as MECE (mutually exclusive but comprehensively exhaustive) items.3 Tracking and measuring the lead times of features, defects, risks, and debts yields a multidimensional picture beyond that of just product features and therefore provides a more comprehensive picture of overall progress toward business outcomes.

In addition to measuring lead time, visualizing and measuring flow using a cumulative flow diagram (CFD) is a great next step. A CFD can help us identify and resolve bottlenecks to flow. A CFD is an area chart that depicts time on the x axis and the quantity of work in each step of a workflow on the y axis. It captures arrivals, time in process, quantity in process, and completion time.

CFDs help us visualize how work in our system builds up in queues along our process stages over time. We can build a CFD with different bands showing work queued up in various columns of our VMS. Each band represents a column, clearly showing how much work is queued up at each stage of the process, as illustrated in figure 5.9.

Figure 5.10 shows a CFD that illustrates the differences between a system that has bottlenecks that impede flow and prolong lead times and one with smooth flow and fast delivery.

images

Figure 5.9: Cumulative flow diagram

Drive Continuous Learning and Adaptation

What is the higher purpose behind tracking and monitoring program flow? Agility, or creating and responding to change, requires us to continuously learn and adapt, even as we navigate our turbulent business environments.

Implementing the tracking and monitoring techniques discussed in the preceding allow us to drive toward a higher goal: business agility. With VMSs as organizational sensors and knowledge-creation and decision-making instruments, we can track and manage program flow to continually learn and adapt and drive business agility.

Summary

Transitioning from the iron triangle to an agile triangle enables a mindset shift from project to product, from large to small batches of work, and to tracking actual product value and outcomes. VMSs allow us to see knowledge work flowing through the value stream toward delivery. Blockages and delays in flow become readily apparent when they are made visible.

images

Figure 5.10: Cumulative flow diagrams with ragged (top) versus smooth (bottom) flow

VMOs can deploy VMSs at multiple levels, including the team and program levels, to track and monitor program flow. Flow-based metrics like the lead time for features, defects, risks, and debts provide a real-time sense of where value is flowing and where it is blocked or delayed.

VMOs can also drive continuous learning and adaptation for business agility by tracking and monitoring program flow using lean and agile techniques like VMSs rather than industrial-age tools.

Try This: Measure Development and MMP Lead Time as a Percentage of Total

It might come as a revelation to some that as much as we obsess about efficiencies in product development and delivery, the major obstacles to business agility lie elsewhere. Most commonly, they exist up the value stream on the business side or downstream in deployment.

To identify where your true bottlenecks exist up and down your value stream, first measure development lead time as a percentage of total end-to-end lead time, then measure MMP lead time. We guarantee you will be in for a surprise.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
54.81.33.119