The utilities expect data to be stored in a data.frame. The first column must be named “Date” and have “Date” class. The second column is currently ignored; however, the intention is that it indicates the ticket category (usually represented on the board by ticket color), and so it should be a factor. Columns three onward (as many as you have flow steps) are tallies of each work flow step for the day, in reverse chronological order – starting with “Done” and ending with “Backlog”, in other words.

The easiest way to get this data into R is to store it in a CSV file and use read.csv to load it. Here is some sample data:

Date,Category,Done,QA,Development,Ready,Backlog
2009/10/20,Project,0,2,2,0,0
2009/10/20,Urgent,0,0,1,0,0
2009/10/22,Project,1,2,1,0,0
2009/10/22,Urgent,0,0,2,0,0
2009/10/23,Project,1,2,2,0,0
2009/10/23,Urgent,0,0,2,0,0

Load this into R with:

> my.data <- read.csv("my_data.csv")

An alternate method for maintaining your data within R is to use the fix() function on a daily basis, which is what I do. Two warnings, however:

1. Make sure to save your workspace so that you don't lose your stats.

2. fix() will strip the "Date" class from the Date column.

To re-add the Date class after using fix(), do this:

> my.data$Date <- as.Date(my.data$Date)

Plotting your CFD

Check out the rkanban sources into the "rkanban" directory under your R working directory and source the kanban.R file.

You can then plot your CFD from within R like so:

> source("rkanban/kanban.R")
> PlotCFD(my.data)

A significant portion of your activities aren’t visible to your management, possibly because

• you have become the “product expert” which consults with others or
• your products’ production deployments require significant developer attention

Therefore,

Divide your whiteboard up into columns representing your work flow (e.g. “Backlog,” “Ready”, “Develop”, “QA”, “Done”) and obtain a large supply of Post-It(tm) notes. Use separate colors for the items assigned to you by your management and the items which come to you as the domain expert. If necessary, track enough information to build a cumulative flow diagram.

Discussion

There is something visceral about this approach that conveys understanding in a way which is not possible by explanation or discussion. It may be the case that your management knows what is happening but doesn’t quite “get it.”

This is a minimum useful subset of software kanban and an instance of “Information Radiator.”

A cumulative flow diagram can be created by simply counting the number of tickets in each bucket each morning and entering these into a spreadsheet in backwards order. You can read your average work-in-process (WIP) and cycle time from this diagram, making it an incredibly inexpensive way to measure the amount of effort spent on visible work versus other work.

Observed Instances

One

[to be filled in]

• Each release of your product has some unique aspect to it, for example an intended customer-specific configuration.
• Releases of your product are frequently made which fail in some, though not necessarily always the same, downstream step.
• Verifying correct operation of each build empirically is time consuming or costly.

Therefore

1. Write a program which is the simplest possible wrapper for your release of the artifact consumed downstream.
2. Each time a failure causes a flow interruption, modify the program to detect this problem with the artifact and fail loudly, refusing to produce the artifact.

Discussion

This pattern operates on the general principle that a shorter feedback loop for failures will have less negative effect on effort hours and throughput. This is the same principle embodied by test-driven development applied in a slightly different context. To build on the analogy, consider instituting a policy of adding the automated release check to your artifact-builder before correcting the downstream problem, and verifying the release check by attempting to release a new build without correcting the original problem.

This is a kind of test-driven development which is fed by downstream regressions. It is an attempt to introduce a positive rachet effect.

If you do not have some unique aspect to each release, you could simply add unit tests which fail the build if in-repository artifacts are somehow inconsistent or incorrect. Even though we don’t usually think to add unit tests to verify, say, properties of configuration files stored in the repository, these unit tests provide a tighter feedback loop than this pattern and should be preferred.

Observed Instances

One

We have a product where frequent, customer-specific releases are made to an independent QA department. Two files are delivered, an installer exe and an ini file. The ini file is read by the installer exe and causes the installer to install the correct components and install the proper configuration into the registry. The install is a lengthy process (twenty minutes) on machines which have a lot of software installed, discouraging developers from running the installer. Also, verifying correct operation requires setting up a protocol emulator which may not be available.

The ini file layout is very brittle. It contains many options which must be consistent with other options. There are also many options which must be specified for every component in the configuration. Yet other options can cause some other options to be ignored entirely. The install itself rarely fails, it leaves the machine configured in an unusable state instead.

A significant portion of my time was spent in the QA lab troubleshooting failed installs. When I first started maintaining this software, it seemed like one third of a typical day might be spent in the QA lab. Since QA is on an isolated network, I went through many thumb drives, not remembering which machine I had last left it in.

I wrote a wrapper for building the install after reading the ini file. This also had the benefit of allowing us to remove unused components from an install. For each failure found in QA, I made it fail loudly and abort before building an install if the problem was detected with the ini file.

I haven’t been in the QA lab in more than four months. I have kept the same thumb drive for perhaps a year, though I’m no longer sure what’s on it.

This has had an unexpected compounding positive effect: The most likely causes of an install failing are now either procedural or due to configuration changes made for testing in QA. Previously, the most likely cause of an install failing was that it had been packaged incorrectly. As a result of this shift, development is no longer the first on the scene of a failed install. Instead, the techs responsible for deploying the software to the customer handle most QA installation issues.

It might seem that a more fundamental problem in this occurrence is the brittleness of the configuration format, that it admits self-inconsistency. This is probably true; however, I could not determine a way to re-engineering the format piecemeal, and customer commitments (as well as time logged in the QA lab!) made such a large project unlikely on a maintenance-mode product. Also, the current installer has all sorts of difficult-to-understand logic with undocumented intent. This solution was truly cheap to get running.