Bandit Software was founded in May 2009 by Chris Hefley, Stephen Franklin, and Daniel Norton. They all worked together once upon a time at the Nashville-based healthcare giant, HCA, Inc. and remained friend for years, long after leaving to pursue other opportunities. One day they just decided it was time. Time to strike out on our own and “own the company we want to work for.” So, one night they gathered in Stephen’s basement, and Bandit Software was born. Six months and many sleepless nights later, they launched their first product, LeanKit Kanban.
Related Podcast and Transcription: Chris Hefley on Kanban
An Excerpt from the Podcast
Joe: Why an electronic tool for Kanban? I mean Kanban; I just put it up on the board, right? I stick the Post-it-notes and I might use different colored Post-it-notes up there to signify different things. Why an electronic tool?
Chris: Well, there are actually several reasons for that. When I first started doing Kanban for my developer teams, we were doing it on the board with index cards and tape. But we also had developer in Nashville, Tennessee, in Italy, in the Bahamas, and in the Ukraine. So every morning on our call, I would get up and move their cards around, and they would tell me what it was. They never got to see the board except for some snapshot pictures that I sent them. So there’s the working with distributed teams.
One of our other co-founders works in a consulting firm here in town and moves around to client sites a lot. They ended up taking the science project boards, the folding cardboard things, and that was where they put their Kanbans. They would tuck that under their arm, load it in the back of the car, and take it with them to the client site and back and forth to the office.
So the distributed team aspect of it is great, and the communication you get from being able to interact with people on different time zones and continents, even if it’s just in different rooms is good. The other thing is, as developers, I like low fidelity tools. Most developers do. Scrum walls and card walls and just stories and those kinds of things.
Developers like that, but I have yet to meet a project manager that does. A project manager or functional manager usually sees that as lost information that I can’t write reports against. So with an electronic Kanban tool, the reports about how the work is going on is basically captured automatically as you move the cards.
You can get a lot of good information that’s actually more truthful than the information you get from a project management system where developers are coming along and giving you estimates and saying, “I’m 75 percent done, or I’m 95 percent done, or I’m 80 percent done on this particular task.” Because the statistics about what’s being done and how fast it’s being done are actually captured realistically.
I think we talk about project management systems being repositories for lies because everybody knows that last 10 percent of about 90 percent done is like the last minute of an NBA basketball game. It can last a lot longer than you expect. So doing away with some of the guessing involved and just capturing the work as it actually moves, there’s a lot of valuable statistics you can gain from that.
That’s one of the great things, too, about Kanban for software development. I think we’ve pulled in a lot of interesting new statistics and analytic tools into that methodology. Some of it has probably come from Six Sigma. I’m not that familiar with Six Sigma. But I think some of them do, like the statistical process control charts and things like that.
But some really interesting metrics that are easily understandable by everybody and really point out some really interesting things about how work is being done, cumulative flow, looking at cycle time and lead time, overall work in process, and how that changes over time. I think the statistics captured and the distributed team aspects are probably the two biggest things.
Joe: Well, I think you bring up an interesting thing because there is still a project manager that has to fulfill needs of other people outside the team.
Chris: Absolutely.
Joe: And that seems to be a great reason for it. But what do you lose by putting it on a screen? What do you lose by putting it into software versus on the board?
Chris: I think the constant challenge is to not let the software get in the way. With a board, anytime you want to add another lane or draw a diagonal line across somewhere or do any kind of change to your Kanban board that will help you get things done better, it’s as simple as walking up to the board and drawing that line. With a Kanban tool, a web based tool, the constant challenge for us is to keep it flexible enough that you could still do everything or almost everything you would want to do on a board. We think we’re doing a pretty good job of that.
The only one as far as I know among our competitors that can do things like horizontal lanes and splitting lanes vertically and horizontally several levels deep so you can break things down and do little sub?compartments in lanes, rolling the work in process when it’s up that chain, those kinds of things.
That’s something that you don’t want to let the software get in the way of making your continuous improvement efforts on your Kanban board.
Lean Sales and Marketing: Learn about using CAP-Do
Special Marketing with Lean Book and Program offers on Facebook