3. Managing the Workflow - Success Engineering

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. These will help us see how to improve our value creation structure.

Manage work in process
Use pull methods to keep workload within capacity
Minimize incomplete work and accumulated risk
Create visibility of both work and workflow
Have a product backlog serve as an intake process
Have an effective way of deciding what to do next
Have work be interruptible
Use DevOps
Use automated testing to eliminate waste

3.1 Objective: Manage work in process

Manage how much people are working on to avoid them 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

Why this is important

Manage queues to lower the time between work ending at one step and starting at another.

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

Multi-tasking
People being interrupt by other people
Delays in the workflow
Delays in feedback

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

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

How to implement this when using timeboxing

There are several ways to manage work in process:

not pulling more work than what you have capacity for
looking to finish something after you’ve just completed something instead of starting something new
don’t do analysis 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 important to limit the work in process to manage queues. Have a focus on finishing.

Anti-patterns

Too much work waits between the different work steps.

3.2 Objective: Use pull methods to keep workload within capacity

Keep workload within capacity. This has two different aspects. The first is more apparent when timeboxing is being used. Timeboxing is one way of keep workload within capacity – you don’t pull more work than you have 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 time to completion of items, shortening feedback time all the while of increasing 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.

Manage each queue that represents a constraint on flow. Manage Work in Process (WIP) by Focusing on Finishing. This minimizes WIP at all levels.

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 that are already open. New features are opened instead of finishing other features that are already open.

3.3 Objective: Minimize Incomplete work and Accumulated Risk

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.

Accumulated risk is the term we use for all of the risk associated with unfinished items.

Why this is important

Artifacts that represent the right chunk of work to be completed before others are started is 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 important 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.

By completing small items, we get feedback on whether we are building the right or wrong thing sooner. 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 two small to be delivered by themselves. This is why MVPs and MBIs should be used as the artifacts to drive the teams.

How to implement when using either timeboxing or flow

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 also 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 many things open at once. A burn up/down chart looking like a hockey stick – that is, few things are done until the very end.

Add concept that managing queues is not the same thing a managing work in process. Putting WIP limits on queues is one way to manage queues, but is not necessarily the best way to manage

3.4 Objective: Create visibility of both work and workflow

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 as well as 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 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 there is a handoff, just that the story is being worked on in a different way. It is important to realize that you don’t follow what’s on the board, rather the board is a reflection of 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 not clear.

When workflow is not explicit people will work in different ways and there is no baseline for improvement.

3.5 Objective: Have a product backlog serve as an intake process

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 important to see what context the small pieces fit into. It is also important 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 to potentially work on next. With timeboxing, it’s important to have this have about enough work pull from that will fill the iteration.

How to implement this when using flow

A product backlog can be used as when timeboxing is being done. When flow is used, however, 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 or there is significantly more work in the product backlog than necessary.

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

3.6 Objective: Have an effective way of deciding what to do next

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 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 has the advantage of limiting the total amount of work in process to being 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

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

Anti-patterns

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

3.7 Objective: Have work be interruptible

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

Why this is important

Planning is often needed in order to coordinate work with other teams.

How to implement this when using timeboxing

How to implement this when using flow

Anti-patterns

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

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

3.8 Objective: Use DevOps when useful

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 has the ability to 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 use 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 full 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/or support teams when the work is handed off

Anti-patterns

Ops and/or 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.

3.9 Objective: Use automated testing to eliminate waste

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 actually spend more time finding the bug than fixing it. This is not semantics. I say this because if the bug were identified immediately, right after putting it in, there would be almost no time “fixing” it. This does not even count the added waste from the impact of the bug on others.

Why this is important

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