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