At some point, one would think I would talk about, you know, kanban, specifically, the kanban board. I’m getting to that.
But first, I want to talk about the concept of waste and how it fits in.
Now, within the Toyota Production System, the precursor of at least one version of Lean Software Development, there is a list of the 7 types of waste. This immediately makes me skeptical. Really? 7? Not 6? Not 8? We’re all geeks here, don’t there have to be 42? I don’t buy it.
Furthermore, as I mentioned in previous posts, the idea that there is only waste is, in my mind, obviously wrong. When I joined the yahoo kanban group, I raised this point immediately by pointing out the difference between waste and cost as it applied to the food industry, using shrimp as an example (David Anderson hated this, but fine). If you sell any dishes that have shrimp as a component, you have a food cost involved in buying the shrimp. There is also a cost in preparing the shrimp. These costs cannot be eliminated, thus it makes no sense *at all* to talk about eliminating waste. If you buy shrimp and throw it out later, that’s waste, but in the normal process of operation, you have a cost. This cost should be minimized, at all costs (pun) but it cannot be eliminated.
I think this applies to software development as well. There is waste (which should be eliminated) and there is cost (which should be minimized). Conflating the two is a horribly bad idea.
Having said all that, I think that the notion of waste is something that is very easy to understand within software development, and is a concept that *finally* makes clear why agile methods of software development can be superior.
But to explain this best, let me use an *entirely* hypothetical example, an example that we shall call “The Company.”
The Company
Joe: What is your estimate of the amount of time that we actually spend writing code, either code to implement new features or code to fix existing defects?
Alan: I’d say it was about 5%.
John: You’re kidding.
Alan: Well, I guess that might be a little low.
John: No, I was thinking it was more around 1%.
Joe: Do the math. You think you spend only 24 minutes a week on productive work?
John: Hmm, yeah I guess there was that month where we were implementing that major module re-write…
Joe: Throws the entire average off.
John: Right. Okay, I’m going to go out on a limb and say that 10% is about right.
Joe: When I was working at a start-up, I think we spent at least 80% of our time actively writing productive code.
John: Yeah, I think it was closer to 90% for me…Want to go grab a coffee?
Alan: Is that going to affect the numbers?
The Company has a very specific project planning methodology in place. It does what it does.
The group that talks to the customers is called Product. They are the only group that is allowed to talk to customers.
Product manages a ‘backlog’ of sorts that includes customer requests, along with known defects that are tracked in an internal system, which are ranked by priority. Calling it a backlog is probably a bit misleading. What actually exists is multiple lists of things that need to be worked on, and Product consolidates these lists and decides what needs to be worked on next.
For defects, Developers are asked to determine root cause, and if it requires any design work or just a simple fix. If it requires just a simple fix, then developers are asked to give a rough estimate of how long it will take to fix. If it requires more, the need for a design arises.
Things that require any design go down a different path. Particularly, if Product decides that certain items are of top priority, they get passed to the Design team (not to be confused with UI design) and BA team. They then start to determine exactly what might need to be done. This includes UI changes, code changes, and anything else.
This is obviously true of enhancements, which come from customer requests. Product works with the customers to get requirements, and then works with the BA team to start to develop more detailed requirements.
The design team works with Product through the BA team to come up with what actually has to be done, UI changes, code changes, etc.
As the design team does its work, it needs to record estimates of how much effort it will take to complete the tasks it identifies.
Once the design team is done with its work, it then passes on the actual work (as recorded in documentation) to the build team. Sometimes,the members of the build team have been involved in the design process, but this is rare. Usually, the build team is given a set of documentation that tells them what they need to do to.
As this process goes on, the QA team works with the BA team to construct the tests they need to run. These are based off of the initial requirements.
As the developers get the design documents from the Design team, they begin to implement the required changes. As those changes get implemented, they then need to be migrated to the various environments of the Company. Dev/Testing/Staging/Whatever. At each step, manual changes are needed to make sure the migrations happen successfully.
As defects are found, the developers work to fix them, but those fixes then need to pass through the various environments, Dev/Testing/Staging/Whatever, so there is a lag between when the defects are supposedly fixed, and when those fixes are verified by the QA team.
To make things really fun, imagine that there are multiple code bases, multiple streams, where code developed in one base has to be inevitably merged into a different stream, often at times significantly different from when they were originally worked upon.
Waste – Can we count the ways?
Now, as I’ve mentioned previously, the notion of waste runs up against the notion of cost. There is always a cost of getting requirements, doing design, doing development, testing the work of the developers, and moving code between environments. Even in the best of situations, there is always going to be some cost.
But what I think Kanban/Lean/Pull/Whatever does is highlight the notion of waste, and especially the notion of TIME wasted. The waste of Product managing the multiple lists of things to be worked on. The waste of co-ordination between Product and the Designers as they work on the various items. The waste of having developers who weren’t part of the Design process having to ask for clarification from the Designers when questions arise (since the documentation they are given is always incomplete), especially if the Developers cannot directly engage Product of the BA team. The waste of the QA team having to wait for the developers to complete their tasks before they are able to begin their own testing. The waste of moving code between environments involving those manual steps, where being manual, they almost guarantee mistakes, even with the best of teams. The waste of having fixes made by the developers which can’t be tested for a certain period of time until it gets deployed at a fixed date in the future.
And the list goes on and on. My *entirely* hypothetical example describes things to the extreme, but there are parts of it that I think most any experienced IT professional can relate to. Large pieces of work are broken down into supposedly manageable pieces, but these pieces move through the system in almost unmanageable blocks, all in the name of manageability. At almost every step, time is wasted waiting on some other step. QA waits for deployment which waits for development which waits for Design which waits for Product.
So, what can we do?
Needless to say, pointing out the flaws in software development, while fun, is somewhat easy. What is more difficult is coming up with ways of making things better.
Kanban/Lean/Pull/Whatever doesn’t promise to fix everything (and anyone who suggests it does is lying or selling snake oil). But, it does have ways of potentially improving these things, or at the very least, highlighting exactly where and when waste occurs. In the next few posts, I hope to describe how this is so.