A couple of weeks ago, I mentioned at the office during my measure and manage flow in practice talk that we should invest more in optimizing the whole flow and reduce the efforts spend on local optimizations. In retrospect, I didn’t spent too much time on explaining why, because it had a very loose connection to the subject of the talk, and I assumed that the audience would understand what I meant anyway. Well, I have to admit I was wrong. Since the talk, I’ve participated in several discussions were we just stated that local optimization is bad and I met only one guy who was able to give me an example, why was it harmful in his environment. However, I think it is not too late to make this right. Local optimization is not a bad thing, but it won’t make any difference - or will make it worse - when it is not part of the global improvement initiative.
This is is what I think about local optimization:
First of all, optimization means that an organization does certain improvements, and as a result, its lead time (the time the whole organization needs to finish the whole process) gets shorter. Second, local optimization means that a team, which is in connection with at least one other team, reduces its cycle time (the time needed to finish a certain phase in the whole process). Most probably, this improvement won’t have any affect on the lead time when the other teams have different goals.
This is a common flow in a software development process:
The blue rectangles are the phases in the process. For example, analysis (1), development (2), testing (3), and integration (4). The width of the rectangle represents the cycle time. Team 1 is working in Phase 1, Team 2 in Phase 2 etc.
