Buyer stakeholders tend to want to get a reliable sense of how their work is progressing.

It is easier in a manufacturing environment because manufacturing floors have physical widget assemblies and components that anyone walking by can see. The manufacturing workplace is visual by default. Buyer stakeholders may visit a contractor’s factory see for themselves the status of the work in process (WIP) inventory at a glance.

However, unlike physical widgets, knowledge work is invisible.

The lack of visibility of knowledge work makes tracking its progress a little harder. Traditionally, project/program managers have tried to use status reports of varying formats to get a sense of how the invisible WIP is progressing. Many of these reports leave hidden issues that increase risk.

Lean asks us to make even knowledge work visible for all. So to make it visible to both the development team and the buyer stakeholders, let’s use an Agile Kanban board to make the WIP inventory visible. Say we use a white board and sticky notes for work items.

One of the biggest potential changes for buyer stakeholders is getting invited to the contractor’s/supplier’s Agile Kanban board. Some practitioners call them information radiators. Some call them Scrum boards. For the sake of consistency, in this book we’ll call them Kanban boards.

Now some project/program managers don’t like the idea of total transparency of our work in process. They only want to focus on the traditional monthly or quarterly in-process reviews instead. Data from the Kanban board can still be summarized for these longer term reports if desired. Yet the biggest advantage is that any buyer stakeholder can visually see the daily status of the work if they want to.

We include a later section that describes Kaizen,[1] a Japanese word for continual improvement. The development team needs the daily view for daily Kaizen while seeking perfection (Lean).

So if the buyer stakeholders use the transparency, this is what they will see.

First, let’s monitor a traditional waterfall (large batch) project on our visual Kanban board. We start with the backlog plan, what engineers often call the requirements stack.

AgileKanbanComparison1
Figure 1. Start Point - Course Batch Size

Then we move the entire batch in to WIP.

AgileKanbanComparison2
Figure 2. Traditional ADDIE Work In Process - Course Batch Size

Then we wait many days, or weeks or even months to see any movement.

AgileKanbanComparison3
Figure 3. Traditional ADDIE Done - Course Batch Size

Notice that with traditional, large batch ADDIE process phases the large batch size does not provide much information about how things are going.

So let’s compare that to the Kanban board in a small batch Lean-Agile approach instead. We start with the backlog plan, what engineers often call the requirements stack.

Note
Because this is a dynamic process, it takes a series of images to see the "movie", or to depict the motion across the Kanban board over time.
AgileKanbanComparisonIncrementBatch1
Figure 4. Increment 1 WIP - Increment Batch Size
AgileKanbanComparisonIncrementBatch2
Figure 5. Increment 1 Done Except for Rework
AgileKanbanComparisonIncrementBatch3
Figure 6. Increment 2 WIP
AgileKanbanComparisonIncrementBatch4
Figure 7. Increment 1 Rework is Done
AgileKanbanComparisonIncrementBatch5
Figure 8. Increment 2 Done Except for Rework, Increment 3 WIP
AgileKanbanComparisonIncrementBatch6
Figure 9. Increment 2 Rework is Done, Increment 3 is Done Except for Rework
AgileKanbanComparisonIncrementBatch7
Figure 10. Increment 4 WIP, Rework for 3 still WIP

And so on and so on. These figures were only an example. Actual work depends on many factors.

With the smaller batch view, much more information is available than with the course batch size example. You can go to smaller batch sizes to improve flow.


1. See later section on [Kaizen]
Image

Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview