As part of the preparation for my workshop, I spent a while today trying to create Value Stream Maps for some of the projects I’ve worked on. It was a revealing exercise, and I got really stuck on one point…
In some software development processes, the same group of people carry out more than one ‘phase’ – for example, on a recent project of mine the same small team did an initial design, then did all the development of that design, and then tested the results. The natural thing to do was to map this as three processes, with inventory piling up between them as features get designed or coded. But in all the books I’ve read so far, when a single operator runs a connected sequence of machines the whole sequence (flow) should be mapped as a single process. So should I draw one process or three?
On one hand, the design-code-test flow is a single process, because it has only one operator. There is no design coming down the line while testing is in progress, because the designers are manning the testing. But if I draw only one process, I can’t use the lean thinking tools to look inside it and make it better.
And on the other hand, inventory piles up between the steps, and this inventory could be reduced or removed by reducing batch sizes (ie. the number of features in each release). So I should draw three processes. But because they are operated by the same people, I now seem to lose the ability to calculate things like takt time.
I’m coming to the conclusion that takt time etc are not meaningful for software development, and so drawing three processes to explicitly show inventory will be the most useful approach. But I expect to encounter more difficulties next time, when I try to add in the fact that the same people also write the documentation…!
Mary Poppendieck
August 18, 2004
Hi Kevin,
Very interesting dilemma. I don’t know why takt time matters for software development, so I would separate the processes, if they really are separate, and join them if they are not. For example, say the team designs a bit of code, writes tests, writes code, runs the tests, integrates the code and moves on, all in a half day. Then one process is sufficient. But say that the team takes a weeks to design some code, a week to write it, another week to test it, and then integrates it later. Well, then this definitely should be written as separate steps.
Back to takt time. I think of takt time as a necessary number for line leveling, and it can probably help a sophisticated lean organization know how much work to release into a development organization. But for most development organizations, the critical measurement is cycle time from start to finish; that is, how long does it take on the average to go from customer request to deployed code fulfilling the request? I define cycle time this way knowing that some equate takt time and cycle time, but I do not.
Anyway, in the end, what you want to do is reduce that cycle time. You have to level your resource load and have a certain amount of slack, but initially the time sinks in the cycle are so great that worrying about load leveling is probably not useful. So takt time would also not be that useful, far as I can see.
Cheers!
Mary Poppendieck