Purpose

These capabilities are used to manage the value stream. We want few delays, quick feedback, and quick delivery of value. Each capability contributes to one or more of these goals.

Description

Value stream management focuses on the work being done and the workflow that completes it. Its focus is on removing delays, having quick feedback, and reducing handbacks. The time from starting working on a description of value until the customer consumes it includes more than the time it takes to create the value. There is also rework caused by development mistakes, working on the wrong things, miscommunications, relearning, aging requirements, misunderstood integration agreements, and more.

Understanding the cause of waste in value streams

We need to understand value stream management to understand best the practices that help us manage. Consider how organizations are managed. They usually are in siloes where each silo has a manager at the top of it. The manager’s job is typically to see that the people under them are 1) working on the right things, 2) working well, and 3) fully occupied. This seems so natural we don’t even think about it. But it also means the focus is on the silo, not across the workflow.

  1. Edwards Deming said – “A system must be managed. It will not manage itself. Left to themselves, components become selfish, independent profit centers and thus destroy the system… The secret is a cooperation between the components toward the organization’s aim.”

The section on value streams discussed the shifts necessary for effective value stream management:

  • Shift our focus from people to work being done
  • Don’t manage hierarchies; manage the value stream
  • Don’t try to go faster; work on having fewer and smaller queues
  • Align people around the value to be realized
  • Shift from focusing on the utilization of people to removing delays in the workflow.
  • Don’t attend to local optimizations, but attend to the throughput of the value stream

We manage the workflow to have an effective and efficient value stream. We will look for handoffs, handbacks, large queues, incomplete work, and accumulated risk.

What is accumulated risk?

Accumulated risk is the term we use for all risks associated with unfinished items.  Work in process is not just the number of items in queues in the development area. It includes all artifacts that are in process. Look at the following picture and see why it’s not just the number of stories being worked on that indicate the amount of risk.

Why Amplio uses work-in-process and not work-in-progress

Intention revealing names are useful. That is phrases or names of things that describe what they are referring to. There are currently two phrases for WIP. The more popular one is “work-in-progress” whereas the more accurate is “work in process.” This difference is not academic as the usage of ‘progress’ can lead to bad practices.

Progress means “forward or onward movement toward a destination.” But WIP refers to work that has started but hasn’t been completed. Work may be blocked, that is, not progressing at all. Work in progress (in English) does not include blocked work. But it is WIP. This has led many teams new to kanban to not include items that are blocked (not progressing) towards their WIP limits. This is not effective.

“In process” means “of, relating to, or being goods in manufacture as distinguished from raw materials or from finished products.” English tells us that something blocked is not in progress but is in process.

It’s worth having our words mean what is inferred by their common definitions.

It is interesting to note that Scrumban (the first book on Kanban) used process, as does Don Reinertsen’s work.

 Capabilities covered in this chapter.

  1. Manage work-in-process
  2. Use pull methods to keep workload within people’s capacity
  3. Minimize incomplete work and accumulated risk
  4. Create visibility of both work and workflow
  5. Have a product backlog serve as an intake process
  6. Have an effective way of deciding what to do next
  7. Have work be interruptible
  8. Use DevOps
  9. Use automated testing to eliminate waste

1.1 Capability: Manage work-in-process to remove delays in workflow and to lower risk **core**

Objective

Manage how much people are working on to avoid being overworked or not having enough work to do.

“In product development, our greatest waste is not unproductive engineers, but work products sitting idle in process queues.” Don Reinertsen

Managing work in process does not mean just limiting it. It means to manage both what and where work is taking place. This includes workload levels as well as where the work is taking place.

Work that isn’t completed represents work-in-process. It is not just those stories that have been started and not completed. It includes all levels of artifacts that have been started but not completed, for example, features and MBIs. These unfinished artifacts represent risk. We may have feedback at the story level, but the feature or MBI has not been validated. When we get the feedback, we may find that we didn’t do everything right. Therefore, until we get the feedback, we have this risk.

It is also helpful to have work be interruptible. This way, the adverse effects of interruptions can be minimized.

Why this is important

Having a workload that is appropriate for the people involved is essential. When people are overworked, the following happens:

  • Multi-tasking
  • People are interrupted by other people
  • Delays occur in the workflow
  • Delays in feedback happen

All of these create waste. In many cases, much more waste than the actual valuable work. This extra work is, of course, unplanned, so cooperation is much more difficult and costly.

While people are busy, if we watch the work being done, we’ll see that it is waiting in queues.  Teams are more efficient when they are not overloaded. This enables them to get quicker feedback on what they are building, eliminating waste.

Artifacts representing the proper chunk of work to be completed before others are started are critical to avoid having many things in play. Too much work-in-process (WIP) causes delays in feedback and adds extra unplanned, unnecessary work. It is essential to understand the concept of accumulated risk. This is the risk represented by incomplete work. That is, work started that has not been completed and verified to be what is needed.

We get feedback on whether we are building the right or wrong thing sooner by completing small items. Common artifacts in the Agile space are epics, features, and stories. However, these are not usually deliverable items. Not all of an epic will be delivered since not all of it is needed. Features and stories are often too small to be delivered by themselves.

How to implement this when using timeboxing

For years timeboxing was synonymous with Agile. Find a duration, see how much you can do within that time frame, and then plan that work. This approach can limit the total amount of work-in-process to be no more than what the iteration can hold. The weakness, however, is that there is often little guidance on how to keep work-in-process low within the iteration.

When using timeboxing, managing the amount of work being done during the iteration is vital.

There are several ways to manage work-in-process:

  • Manage queues to lower the time between work ending at one step and starting at another.
  • not pulling more work than what you have the capacity for
  • looking to finish something after you’ve just completed something instead of starting something new
  • don’t analyze until just before it’s needed

Queues can also be managed. Larger queues mean more WIP and delays.  One of the biggest queues is the iteration backlog. This is one reason that shorter iterations are good. Starting only the necessary amount of work is another way to manage queues.  Having a well-defined input queue is essential for this. Without this, work is just given to teams, and the queue of work in front of them grows without any control.

How to implement this when using flow

When flow is used, items should only be started when none of the existing ones can be finished. It is essential to limit the work-in-process to manage queues. Have a focus on finishing.

One is not doing a plan for the iteration (or time of the cadence) when doing flow. The planning is done in real-time. An item is pulled off the product backlog, done, and the next one is done. A focus on finishing stories, features, and MBIs, before starting others will shorten the feedback time for each.

How to implement this when using either flow or timeboxing

The best way to minimize incomplete work and accumulated risk is to focus on finishing. Managing queues can assist here. An easy way is to have team members see what they can finish next after finishing something. It’s all too easy to start something new. But helping someone finish something that has been started will lower the amount of unfinished work.

Anti-patterns

Too much work waits between the different work steps.

Too many things open at once, with items being completed at the end of the iteration. If you are using burn-up or burn-down charts, the graphic will look like a hockey stick. That is, few things will be completed until the very end.

When planning and coordination of work are not done well, teams tend to get interrupted a lot.

It is helpful to have work be interruptible. This way, the adverse effect of interruptions can be minimized.

Note: There is more on this topic at the companion book Being a Professional CoachManage Work in Process (WIP) by Focusing on Finishing

1.2 Capability: Use feedback to attend to risk **core**

Objective

There are many different types of risk. At the team level, the most important ones to attend are:

  1. Risk of misunderstanding a requirement
  2. Risk of building the wrong thing
  3. Risk of creating bugs

We’ve already talked about some of these issues. Risk can often be planned for, but the best way to attend to it is to continuously see if you’ve gone off track. This is why quick feedback is so important.

Why this is important

While it would be great if we could stop making mistakes, the highest cost is the waste emanating from them. This comes from the cost of mistakes propagating, and the time (effort) it takes to fix them.  Both of these tend to increase over the time a mistake is made until it is detected (assuming it is). Therefore, detecting errors quickly is critical.

How to implement this when using flow

Quick feedback loops at all levels are essential. When something is started, it needs to be completed as soon as possible. This is true for all types and sizes of artifacts. Keeping the amount of work-in-process below our capacity is a way to assist this.

Anti-patterns

Errors keep happening, and things stay blocked.

1.3 Capability: Use pull methods to keep workload within capacity **core**

Objective

Keep workload within capacity. This has two different aspects. The first is more apparent when timeboxing is being used. Timeboxing is one way of keeping workload within capacity – you don’t pull more work than you have the capacity for. The second one is just as important and should be done whether you’re timeboxing or not. That is to keep the amount of work-in-process at any one time low. This avoids delays and increases cooperation.

Why this is important

Items in queues are waiting to be worked on. They represent delays, and delays cause waste both directly and due to slow feedback. Having smaller queues lowers the time to complete items, shortens the time to get feedback, and increases cooperation.

How to implement whether using timeboxing or flow

Timeboxing implements this to some extent. But attending to finishing should also be done. While required when flow is used, it is useful even when timeboxing is being used.

When finishing a story, feature or MBI, see if we can help a teammate finish a story or feature or MBI before starting on a new one. Doing this speeds up feedback at all of these levels. While timeboxing encourages this, it is insufficient, and most new teams upon up too many stories at the beginning of their first few Sprints. Knowing this principle can prevent this.

Using iterations limits WIP to be no more than the iteration. Managing queues directly and having fewer items in play can drop queue size dramatically.

Anti-patterns

New MBIs are opened instead of focusing on finishing those already open. New features are opened instead of finishing other features that are already open.

1.4 Capability: Have a product backlog serve as an intake process **core**

Objective

The team needs a place to pull work from when they are ready to do more work.

Why this is important

The product backlog is, of course, a queue. We, therefore, don’t want to have it be too big (which will cause delays) nor be too small, which will require last-minute creating requirements. Of course, small is ok if that’s how the team wants to create what to work on next.

While teams may be building in small pieces, it is essential to see what context the small pieces fit into. It is also essential to keep work-in-process visible, so people know what is being worked on. This is much easier to accomplish when all work has to go through a product backlog.

How to implement this when using timeboxing

The easiest way to manage this is to have a product backlog that contains what we expect to work on next. With timeboxing, it’s essential to have enough work pulled that will take the iteration to complete.

How to implement this when using flow

A product backlog can be used when timeboxing is used. However, when flow is used, one doesn’t need to have as much in the backlog to fill the next iteration.

Anti-patterns

There is no work to be pulled when the team is ready, o significantly more work is in the product backlog than necessary.

The product backlog can operate the same regardless of whether flow or timeboxing is used. However, if flow is used and enhancements to existing products are being created, it is even more critical to use MBIs so that the MBI will create the bigger picture needed.

1.5 Capability: Have an effective way of deciding what to do next **core**

Objective

To decide how to implement this, one will first have to decide whether you want to use timeboxing or flow.

Why this is important

People need to know how to coordinate to start working on new items.

How to implement this when using timeboxing

For years timeboxing was synonymous with Agile. Find a duration, see how much you can do in it, and then plan that work. This approach can limit the total amount of work-in-process to be no more than what the iteration can hold. The weakness, however, is that there is often little guidance on how to keep work-in-process low within the iteration.

How to implement this when using flow

One is not doing a plan for the iteration (or time of the cadence) when doing flow. The planning is real-time. An item is pulled off the product backlog, done, and the next one is done. A focus on finishing stories, features, and MBIs, before starting others will shorten the feedback time for each.

Anti-patterns

When planning and coordination of work are not done well, teams tend to get interrupted a lot.

1.6 Capability: Create visibility of both work and workflow

Objective

Making work visible helps people see what’s being worked on and coming their way. This helps cooperation.

Explicit workflow is nothing more than making the agreements between team members explicit. This does not mean that these agreements are immutable, just that they are the best way we have of working at the moment. This helps cooperation when everyone knows what’s expected of everyone.

Why this is important

Both are required for good teamwork.

This visibility is required for both what is to be released and the features and stories that make this up.

How to implement when using either timeboxing or flow

Make work visible to enable people to see what others are working on and if their involvement will be needed.

Make workflow visible so that people can see the agreements between the different stages of the work. This is done with an explicitly defined workflow.

Implications for the Team Board

Simple Scrum type team boards often look something like this:

This provides us with the status of the work but doesn’t describe how it moves from left to right. Explicit workflow would add a column for each type of work. This doesn’t imply a handoff, just that the story is being worked on differently. It is essential to realize that you don’t follow what’s on the board; instead, the board reflects what the team considers to be the best way of working.

Anti-patterns

When work is not visible, people will be surprised when it shows up for them to do it. It also makes it harder to trust each other since requests are unclear.

When the workflow is not explicit, people will work differently, and there is no baseline for improvement.

1.7 Capability: Use DevOps when useful

Objective

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.

Why this is important

Value delivery starts with the customer and is not complete until the customer can consume what has been delivered. If the team is not doing the delivery itself, it must work with those that are.

How to implement when using iterations or flow

DevOps can be implemented in several different degrees. At a minimum, the development team should work with whoever is going to deliver and support the system in the following ways:

  • Ensure ops and support teams have complete visibility on what is being worked on and when they will need to get involved
  • Include the ops team in your work if they believe that would be useful
  • Have one of your team members be with the ops and support teams when the work is handed off

Anti-patterns

Ops and support not being ready when the work is ready is a symptom of a lack of DevOps cooperation. Surprises by either team are also symptoms of this.

1.8 Capability: Use automated testing to eliminate waste

Objective

Most developers believe they spend a lot of time fixing bugs. However, if you ask a developer to trace their efforts, you’ll see something like this:

  • Time spent trying to reproduce the bug
  • Time spent “fixing” the bug
  • Discover it caused another problem
  • Time undoing the fix
  • Time spent again “fixing” the bug
  • Verifying the fix.

The reality is that they spend more time finding the bug than fixing it. This is not semantics. I say this because if the bug were identified immediately, there would be almost no time “fixing” it right after putting it in. This does not even count the added waste from the buExit Visual Builderg’s impact on others.

Why this is important

Not having automated tests creates a tremendous amount of waste.  Both for the people who had to correct the errors and those who assumed the code was working.

How to implement when using iterations or flow

The most effective way to implement automated testing is to use a testing framework.

Anti-patterns

  • Code being fragile.
  • Developers believe they spend a lot of time fixing bugs.

Go to Amplio@Teams: The Path to Effective Lean-Agile Teams

Go to Being a Professional Coach

 

New Workshop

More Info >>

Upcoming Events

None