Doing Kanban Wrong

Kanban is becoming very popular for a lot of great reasons. However, the more people who try it means the more people who will do it completely wrong then blame Kanban for their mistakes and project failures. Like countless tools before it Kanban will suffer the blame of many for their own mistakes. Here are a few ways my teams and I have attempted to give Kanban a bad name, hopefully these examples will keep you from falling into similar traps.

Honor Thy Value Stream

The value stream is an important concept in Lean development practices. In short, it is the various stages your work goes through from concept to delivery. You analyze your value stream by doing an exercise called a Value Stream Map (VSM). When doing a VSM you want to visualize how work moves through your system to help you identify possible wastes. Wastes could be large queues before a bottleneck in the system, or it could be a part of the system that sits idle, waiting for work. There are other types of waste, but the point here is to try to identify them early. A typical value stream for developing a feature would be: Ready for Development, Development, Code Review, Testing, and Demo to Customer.

On one team we had a pretty eye opening idea, put the Business Analyst (BA) portion of our project on the board ahead of the development process. There was only one problem that came out of this, we didn't stop and look at the BA value stream. We really had no idea what went into the BA value stream for this client.

We took a reasonable guess at it...oh who am I kidding, we were two people on a tight deadline with a week before the whole team showed up to get rolling and we shot from the hip. When we were done we had about five stages a feature would work its way through before it was ready for development. What we noticed as the project got under way was that items were only getting into about two of those five stages.

The fix was pretty simple. Stop what we were doing, gather the team (the whole team), and do our value stream map based on the first few weeks of work we'd completed. It was a one hour exercise and at the end we had a much better vision of our value stream, especially at the BA side of the equation. Not only did we fix the first half of the board in preparing the work, we got a better look at our development process and made some changes there as well.

Don't fit your process to the board

The temptation to take a 6 foot white board and put every little step on it is at times overwhelming. This happened to me, and I ended up with a convoluted board that was tracking story cards on the top half of the board, work items on the lower half, brining them all together for testing and the client demo. If it sounds discombobulated, awkward, or confusing to you then you understand perfectly. It was too much. Bringing a new team member on board required a 30 minute training session on how to move work across our board. We had completely defeated the ease of use of Kanban.

A couple of things came out of this. Since it was so "easy" (sarcasm intended) to understand how work was moved, people didn't move the work. I'm a big proponent of the morale boost that comes with walking to the board and moving a feature to the next stage. In this case, we lost that because we were going to the board way too often. Later in the project as folks got tired of walking up to the board all the time, they went less often and just moved work further through the system and we lost a major benefit of the board in its visibility into our project and project team.

Sizing is a big deal

In the project discussed above what we really should have come to realize was we weren't sizing our work correctly. I know, we were the first agile project in the history of software development to have trouble sizing our work, but it's true. I had two rows of work on the board because I didn't have the courage to stop and say, "This is too big. We need to break it down."

The top row was our minimally marketable features, or MMFs, but they didn't fit the term minimal at times as they encompassed large parts of the system. In some cases they should have been spikes, or exploratory features, to answer questions on how we should proceed with delivering what the client needed.

These cards, the large purple and green cards in the photo above, were also what we were tracking our cycle time against. Our MMF cards moved together through development, test, and demo so it made sense to track our cycle against them. But because we were taking in large, unknown features our cycle times varied wildly from feature to feature.

If we had taken the time to answer some of our questions and get a better idea around the unknowns we could have managed the size or our work, and there by the cycle time, much better.

Work towards the same goal

One more lesson learned from that same project had to do with splitting our features out as tasks. As noted, the top part of the board was our large feature cards, the bottom portion of the board were development tasks. Development tasks broken along the horizontal lines of the system, meaning UI tasks, business logic tasks, and database tasks. Admittedly, breaking the system along horizontal lines wasn't the norm for us as we usually worked on vertical slices of the system. However with the horizontal slicing, as we completed a development task we weren't delivering a complete piece of value to the customer. The value didn't get in the customer's hands until all the tasks for one of the MMFs was completed.

The issue here was that the team wouldn't always drive towards completing one feature. Swarming, the whole team working one feature to completion, fell by the wayside a few times. In order to give the appearance of "getting more done" the team would sometimes move a new whole new feature into development and start on its tasks.

The team as a whole wanted to deliver value to the client, but the near focus was on getting as many tasks done as possible. The main goal we should have all been driving towards got lost in the day-to-day of getting tasks completed.

Don't hide behind your buffers

Another core principle in Lean and Kanban is the idea of queue limits, many times referred to as Work In Process Limits, or WIP Limits. Limiting the work in a queue is a way to ensure you don't get too much work in the system for your team. Allowing the team to step over queue limits, or not having them, leads to context switching and other wastes that slow the features getting to the customer.

Queue limits are one of the more powerful parts of kanban, but you have to be careful with them. Going over a testing queue limit in order to "get more done" on the development side is basically lying to yourself since a feature isn't done until its in the user's hands. It is very easy to say not to go over your queue limit in a talk or in a book. But in practice with real developers with real short attention spans and real PMs breathing down their necks, it is not too difficult to slide one more card across the board into "Ready for Test" queue. After all, we are paid to write code and we're talking about an index card on a white board.

That exact thing was happening on a team I was on, and our first pass at clearing it up was to add another testing column. So we had a column for features that just completed development that were ready to be tested, and we had a column for feature that had failed testing, the bug fix column. What did we do? We didn't increase team capacity on the testing side, or figure out a way to lower the testing queue, we increased the amount of features that could be in the testing phase. We took our bottleneck and allowed it to hold twice as much work as before.

We added this column for all the wrong reasons. It was added for ego, politics, and getting more code written. We made it possible for features to sit longer before being done. We added waste to our system, the exact opposite of what we should have been doing.

Eventually we sat back and asked, "Why aren't features getting demoed to our client?" Realizing we had a large bottleneck, we shifted a developer into a testing role to get the work through the system rather than just waiting in a different column.

One thing to note here, we knew we were going to have a testing bottleneck just based on the make-up of the team. The real solution here was to get another tester on the team, and that happened later in the project. However, we learned a pretty valuable Kanban lesson by adding more and more capacity to the system rather than more capacity to the team.

Conclusion

These are a few of the ways I've managed to do Kanban wrong, but each of the projects used as examples above were successful for our teams and our clients. We still included retrospectives at various points in the projects to take a look at what we were doing successfully and what needed to be changed. If you're using Kanban now and something doesn't seem quite right, stop, take a look, and make a change.

About The Author

Tim Wingfield has been involved in web design and development for over 13 years and is a Software Craftsman with Pillar Technology. Tim grew up on the .Net stack, but has a budding love affair with Ruby for its testing tools and the web frameworks it provides. Recently he has put more time into practicing lean development processes to efficiently create quality software. In what time is left over, Tim enjoys coaching his sons' hockey teams, playing a little hockey himself, and traveling with his family.