The Bag and the Kanban, part 2

You can view part 3 of this series here.

In my last post, I depicted the results of a workshop I attended at Kaizenconf called Driving Towards the Goal. Jef Newsom, our facilitator, had set up a little experiment  which we all voluntarily and happily participated in.

As a whole, the experiment simulated the creation of software from Goal to Code, each step being a column in a kanban board.

Even though it was a very enlightening experience, we quickly discovered that the further along you went, the longer it took to specify work items. For one, each work item became much more specialized the closer it got to being coded. Second, as they became more detailed, we needed a lot more work items to cover the previous ones.

In terms of workflow, you can think of it like a sandglass. The thinnest part, where only a few grains of sand can flow through at a time, is the coding part. The sides of the sandglass are time and resources constraining your team and the distances between the sides is how fast the task takes to perform.

Of course, specifying the goal can take years of efforts, but in terms of software development, since it is usually defined in advanced (I hope!), it is the fastest step.

The Bag

So how does one manage the flow in such a system? Well the idea came to me that the kanban in the previous post could be separated in two. The first part focuses more on the creative aspect of defining the problem, the solution, the people involved and their goals. Here, chaos can rule. People can jump in anywhere and add items to the board, prioritizing and moving stuff around. This is what I call the BAG, which happens to stand for BAck loG. It also makes me think of a bagpipe, where the player (the stakeholder) fills up a bag with air, which is then pressed into the flutes to produce a sound.

The Kanban

The second part of the kanban is where the more technical stuff happens. Here, work items actually have to be pulled from previous columns before any work can happen. This discipline and organization is important in order to maintain a good flow. Remember, since coding is the constraint, it must be protected at all costs. Any disruption in this part (called "kanban" from now on) will cause a drop in throughput.

The reason that the S.A.F.E scenarios are outside the cloud in the picture above is that I believe the entire team should be working on them at the beginning of every new iteration. This will give every member of the team a general understanding of what is going on in the project.

Playing the bagpipe

To play the bagpipe, you start by filling up your bag with air. Then, using your arm, you compress the bag so that it pushes just enough air through the pipes to make the sound you want at the volume you want.

Filling up our bag is fairly easy. You get your stakeholders together and use your favorite method for liberating the creative juices of every people in the room. When things have stabilized a bit, the developers can come in and pull a couple "features" from the personal goal column in the bag in order to create their first iteration.

It is then absolutely important that the stakeholders leave what the developers are currently working on alone during an iteration. They can come back to the bag and play with work items, but what the software team is working on is sacred, at least until the end of the iteration.

At the end of every iteration, when the stakeholders have a chance to try out their newest release. Then they will have a chance to introduce changes in the personal goals. Each change can then be pulled from the bag by the developers, perhaps with a higher priority than other regular features.

As this process advances in time, stakeholders will probably find themselves asking for change during iterations. This is fine, as long as the change doesn't affect what the developers are currently working on. Changes then go in the bag and await the next pull.

Now, I've never played the bagpipes but I'm pretty confident that that what I've described further up is approximately how they work. In the same way, I've never implemented this process, but is sure looks nice on paper! I've also been called lots of names, but as a programmer, being compared to compressed air flowing through a pipe is a first, I must admit.

This process has a lot of potential and I'd like to keep defining it. Unfortunately, my current work conditions prevent me from experimenting on it in the short term, but rest assured that as soon as I can claim ownership of a project, I will definitely use the "Bag and the Kanban" model and see how far is takes me. In the meantime, I must realize that it is just an idea.

In my next post, I will use what I've learned in a session given at Kaizenconf on activity modeling to go into more details about how to fill the bag.