visualizing non-linear workflow using a kanban...

VISUALIZING NON-LINEAR WORKFLOW USING A KANBAN MATRIX 1

Managing and Visualizing Non-linear Workflows using a Kanban Matrix

Gerard Meszaros

[email protected]

Abstract

Many approaches to building a Kanban board involve mapping the workflow and

creating (at least) one column for each role or specialization. Each piece of

functionality progresses in a sequential manner across the columns. This report

describes the use of a different style of Kanban board, the Kanban Matrix, that can be

used when the work can be done in many different orders or the tasks are too

variable in size to achieve efficient one piece flow. Each cell in the matrix represents

a potential task (a work type involved in delivering one item) and the status of the

task is communicated using colour and text. This allows tasks to be done in any order

or even in parallel.


Introduction

I was working on the second draft of the book xUnit Test Patterns (Meszaros,

2007). The content was largely nailed down in the form of 19 smells and 69 patterns,

a couple of dozen sidebars, a dozen introductory chapters plus a number of

appendices spread across roughly 400 files. But there was an ever expanding list of

edits (kinds of “things to do”) to each chapter that I needed to keep track of. I

initially broke the work out by chapter and defined “Finished” for each chapter as

having finished the complete list of edits on that chapter. But as I worked on

subsequent chapters, I often found yet another edit to do to each chapter, including

all the chapters that I had already “Finished”. Also, many of the edits were fairly

small and were more efficient to do on a group of chapters than to do a whole bunch

of edits to a single chapter. But they were still too large to do to *all* chapters at

once. Furthermore, some edits (kinds of “things to do”) could be done at the same

time as others while other edits needed a different mindset. So I concluded that

neither the Chapter nor the edit (“kind of thing to do”) was the optimal unit of work

for single piece flow. As the number of edits climbed well past 10 and with over four

hundred files, the prospect of managing this work at the per edit per file level was

daunting.

Initial Solution

I started out by building a classic XP-style (eXtreme Programming) planning

board on the wall using Post-it™ whiteboard sheets. (See Cohn, Mike (2011) for more

information.) I put up a sticky note for each chapter and created task stickies for the


4 or 5 edits that I had identified. (See Figure 1 Classic XP-style task board.) I started

working on one chapter, applying each edit and moving it across the columns as each

edit was finished. When I finished the last edit, I moved the chapter sticky into the

“Chapter Done” column.

Figure 1 Classic XP-style task board.

Problems Encountered.

As I worked on subsequent chapters, I found additional things to do. Things like

“make the voice consistent by changing all occurrences of ‘You ...’ to ‘We ...’”. This

required adding additional edit stickies to my wall for each of the chapters. This was

especially problematic for chapters that were already marked “Done” since now they

had to be moved back to the Backlog column. Figure 2 - XP-Style task board with new

edit task added shows the board after the new Edit 4 was added. Note how Chapters 1

and 2 are already marked “Done” yet they have a task outstanding.






























Figure 2 - XP-Style task board with new edit task added

Also, there was no way to keep track of how much work remained because some edits

applied to all chapters while other applied to just a few.

Final Solution

The solution I ended up using was a matrix of Chapter vs. Edit. Each chapter

was represented as a row in a spreadsheet. Each edit was represented as a column.

The current status of the edit for the chapter was represented as both text and a

colour. (See Figure 3 Column per edit with color-coded status.) Text was used to

track the requirements of the step. “Yes” meant the work was required. N/A meant it

was not needed. The cell could also contain specific notes if there was something

particular to remember about it. Colour was used to track the status.Blue fill with

“Yes” meant it was not yet started. Green indicated the step was completed. Yellow

indicated it was in progress. Note that there is no “Chapter Done” column any more


since the status of the chapter is implied from the status of the individual edits on

the chapter.

Figure 3 Column per edit with color-coded status

Whenever I discovered a new edit to be applied to many or all chapters I would

add a new column to the table. Initially, this column would be blank indicating “I

don’t know whether it applies to this chapter.” (See Figure 4 - Color-coded status

with newly added edit.) As I worked on other tasks on a chapter, I would fill in this

column as I noticed whether a newly added edit was required.

Figure 4 - Color-coded status with newly added edit


Choosing Work

Whenever I finished something, I would update the colour of the

steps/chapters that I had just finished and then pick the next (set of) item(s) to work

on. When the individual steps were small, I would typically pick a set of files to apply

the same step to as shown in Figure 5 - Same edit applied to several files at same

time.

Figure 5 - Same edit applied to several files at same time

This would repeat until I had filled the entire column with green at which

point I would pick the next step. Some steps involved a lot more work (e.g. “Rewrite

chapter 5 to ...”) so I would do these one at a time and would start them when I felt

fresh. When I was tired, or had only a short period of time available I would focus on

the more mechanical edits. When the edits were small enough that the overhead of

opening the affected files was a large part of the effort (e.g. “Change all occurrences

of “we” to “I”) I often chose several similar edits to do at the same time as shown in

Figure 6 Different edits applied to same file at same time.


Figure 6 Different edits applied to same file at same time

Managing WIP and Levelling Work

As this experience predated the publication of software-specific uses of

Kanban, I did not explicitly model WIP limits on the Kanban matrix. But keeping WIP

low was a key goal behind its use. The strategies I used for choosing the next batch of

work implicitly kept WIP low because each batch consisted of a small set of

Chapter(s)/Edit(s) intersections, and often it was a single edit applied to a single

chapter. In fact, it was the desire to level the work by making the batches similar in

duration -- short enough to finish in a single sitting-- that that led to the use of the

Kanban Matrix. The 100+ by 20+ matrix allowed a large degree of flexibility in

choosing tasks that suited my time availability, energy level and mood while

maintaining a high level of discipline and making progress highly visible.

Other Applications

I have used the Kanban Matrix on several other projects including a systems

integration project and a team-based book writing project.


Integration Project Management

We used a Kanban Matrix for visualizing and managing work when integrating

SAP-based and PeopleSoft-based CRM functionality with an enterprise customer

database as shown in Figure 7 - Integration Project Archicture (some components

omitted).

Figure 7 - Integration Project Archicture (some components omitted)

We decomposed each integration into “stories” per scenario and “tasks”

representing various planning and development activities being done in parallel by the

SAP, PeopleSoft, Enterprise Customer and messaging-middleware resources. See

Figure 8 - Waterfall workflow. Each cell was coloured in as the work was completed.

Some resources worked story by story while others followed a traditional

waterfall/BDUF approach. The matrix allowed the two approaches to be reconciled

and managed.






omitted).








and managed.






omitted).








and managed.


Figure 8 - Waterfall workflow

Interestingly, when we first suggested a story-by-story approach, the ERP

resources involved in the project all rejected the approach as impossible. At the

insistence of the business sponsor they agreed to build a proof of concept by focusing

initially on one integration scenario that including all the components. After this was

built and demonstrated we were able to convince them to continue working scenario-

by-scenario (as shown in Figure 9 - Incremental workflow with implicit WIP limits)

rather than reverting to a waterfall approach.

Figure 9 - Incremental workflow with implicit WIP limits

The visibility provided to the business by the Kanban Matrix was a key

motivator to adopt this approach. While we did not explicitly model WIP limits on this

board, the board could easily be refactored to reflect the implicit WIP limits as shown

Scenario SAPHLD

CRMHLD

MOM HLD

SAPCoding

CRMCoding

MODCoding

IntegrationTesting

Acceptance Testing

New Customer ReqNew Customer ACK Legend:New Customer NACK In ProgressEdit Customer Work doneEdit Customer ACKNew QuoteEdit Quote

Scenario SAPHLD

CRMHLD

MOM HLD

SAPCoding

CRMCoding

MODCoding

Integration Testing

Acceptance Testing

New Customer ReqNew Customer ACK Legend:New Customer NACK In ProgressEdit Customer Work doneEdit Customer ACKNew QuoteEdit Quote


in Figure 10 - Incremental workflow with explicit WIP limits. Integration testing

was done by the devloment resources while acceptance testing was done by business

resources.

Figure 10 - Incremental workflow with explicit WIP limits

Team–Based Book Writing Project

When I was asked to join a team at Microsoft Patterns & Practices writing a

book on acceptance test engineering (Melnik, Meszaros 2011), we used a similar

approach on a whiteboard wall to organize the work. Initially, the tasks were “Write

first draft”, “Peer Review First Draft”, “Revise First Draft” and “PO (Product Owner)

Review First Draft”. Team members signed up for a particular task for each

chapter/chunk. As the content matured, we evolved towards finer-grained tasks that

were less of a workflow and more like the “kinds of things to do” described earlier.

The matrix ended up being roughly 30 columns wide!

Comparative Analysis

The Kanban Matrix represents largely the same information as a traditional

kanban board but it uses different visual clues thereby avoiding some of the

restrictsion of the traditional board.

Speciality:Scenario HLD Coding HLD Coding HLD CodingNew Customer ReqNew Customer ACK Legend:New Customer NACK In ProgressEdit Customer Work doneEdit Customer ACKNew QuoteEdit Quote

SAP (1) CRM (1) MOM (1) IntegrationTesting (1)

Acceptance Testing (1)


Workflow Definition

A traditional kanban board uses a single token for the deliverable and uses

columns to represent the different groups of workers between whom the work flows.

This requires that there be an order in which the tasks/columns are carried out.

The Kanban Matrix uses one row for each deliverable and columns for each task

in the workflow regardless of who does the work. Therefore we may have many more

columns than (types of) resources. In the personal book project, I had one column per

task type even though there was only one resource (I.e. Me!) In the team-writing

project, we also had one column per task type even though we had a pool of

resources for some task types while other tasks could only be done by our Product

Owner. In the integration project, we had one column for each workflow phase (a

macro task type) for each team (the resource type).

Tracking Progress

The traditional kanban board uses movement of the token representing the

deliverable between the columns as the indication of progress. Because there is a

single token, this imples that only one column can be active at a time.

The Kanban Matrix indicates progress through a change of colour. This allows

many tasks to be “in progress” simultaneously for the same deliverable.

Backlog (Todo) and Work Completed (Done)

The traditional kanban board only shows the deliverables being worked on and

the next few deliverables “on deck”. Availablity of “slots” in the “on deck” column is


often the trigger for the Product Owner to identify the next few deliverables, a

process sometimes called “backlog grooming.”

The Kanban Matrix shows all deliverables including those to be done at some

point in the future and those already completed. This allows the Kanban Matrix to act

as a Release Burndown chart but in a format more akin to an FDD Parking Lot diagram

(De Luca 2003) but it typically results in a much larger board. Filtering out the future

and completed tasks dynamically (when using a tool or spreadsheet) can reduce it to

a size more comparable to a traditional kanban board.

Tools Support Required

Traditional kanban boards are usually compact enough to represent on a

physical wall chart. Movement of deliverables is accomplished by moving the card.

A Kanban Matrix is often too large to post on physical board and updating the

colors of the cells is challenging when using felt markers. As a result, most Kanban

Matrices I have used were stored electronically and reprinted when a physical board

was desired. For usage by a single user, a simple spreadsheet may be all that is

required. Cell coloring can be based on conditional formatting or done explicitly. For

multiple users, the file locking problems associated with sharing a single document

may be an issue. In these cases, a cloud-based shared spreadsheet such as Google

Docs (Google 2011) may be preferable.

Limiting Work In Progress

Traditional kanban boards indicate a limit on the number of items that can be

in a particular state of the workflow by annotating a WIP limit on the corresponding


column. The number of items in that state can be determined by counting the item

cards in that column. The size of each deliverable is assumed to be similar enough

that the WIP limits are relevant.

A Kanban Matrix does not assume that items in each column are of similar size.

We can still annotate the columns with a WIP limit but it is less meaningful in that

there is no assumption that particular columns would be done by the same

resource(s). Instead, it makes more sense to apply WIP limits to a (team of)

resource(s). (See Limiting Work-in-Progress in the next section.)

Possible Enhancements

This report has thus far focused on actual experiences using a Kanban Matrix.

The following are some ideas about how the Kanban Matrix could be enhanced to be

more widely applicable.

Limiting Work-in-Progress

Since the Kanban Matrix doesn’t assume that the work items are a similar size,

it makes sense for a resource to aggregate several cells into a single “task”. This

makes tracking WIP difficult since we don’t want to count each cell as having the

same weight. One way this potential shortcoming could be avoided is to limit the

total size (rather than number) of all the cells taken on by a particular resource or

team. Each cell could have a numerical size estimate (as shown in Figure 11 - Two

teams pulling work based on own WIP limits) and the WIP limit for a resource or team

could limit the sum of these estimates that are selected and marked “in progress”.

When more than one heterogenious resource or team is pulling work from the same


Kanban Matrix, we would need to mark the “in progress” cells with that team’s “in

progress color” or “in progress pattern” to be able to know how much work they had

in progress as shown in Figure 11. Here, the Yellow team has a WIP limit of 8 points

and has taken on the first 3 items totalling 8 points in the row labelled “Pattern.1”

while the Purple Team has taken on the 3rd thru 5th items in the column labelled

“Edit.2” totalling 9 points.

Figure 11 - Two teams pulling work based on own WIP limits

Hybridizing with Traditional Kanban Boards

Many of the benefits of the Kanban Matrix could be realized by combining them

with traditional kanban boards. For example, a single column in a traditional kanban

board could be replaced by Kanban Matrix that breaks down the work into smaller

pieces that could be done in parallel. When the card for the item moves into the

matrix column, status on the potentially parallel activies could be shown using color

rather than card movement.

Chapter Edit.1 Edit.2 Edit.3 Edit.nNarr.1 Done Done Done Done WIPNarr.2 Done Done Done Done Legend: LimitNarr.n 1 3 3 2 TBD Unknown (TBD)Smell.1 1 1 7 3 0 Not NeededSmell.2 1 2 5 2 2 Size: 2Smell.n 2 3 3 4 Yellow Team IP 8Pattern.1 1 2 5 0 Purple Team IP 10Pattern.2 1 1 1 1 Done Work donePattern.3 2 2 7 2


Conclusion

The Kanban Matrix is a good way to visualize work when it is nonlinear. It

allows individual steps to be done in any order and for some steps to be skipped for

some work items. When individual steps are very small, they can be aggregated into

more manageable tasks easily.

One disadvantage is that it may make it harder to visualize the amount of

work in progress simply because the progress of many more items can be tracked at

the same time. These disadvantages might be overcome by merging Kanban Matrix

concepts into more traditional kanban board formats.

.


Conclusion









.


Conclusion









.


References

Cohn, Mike (2011) Task Boards. Training for Scrum Task Board use (website).

Retreived 14 March 2011 from

http://www.mountaingoatsoftware.com/scrum/task-boards

De Luca, Jeff (2003) Parking Lot Chart Example 1. Feature Driven Development

website. Retreived 14 March 2011 from

http://www.featuredrivendevelopment.com/node/630

Google (2011) http://spreadsheets.google.com

Melnik, G., Meszaros, G. (2011) Acceptance Test Engineering, Volume 1 – Thinking

About Acceptance. Redmond, WA: Microsoft Press

Meszaros, Gerard (2007) xUnit Test Patterns – Refactoring Test Code. Saddle River NJ:

Addison-Wesley Professional

visualizing non-linear workflow using a kanban...

Documents