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 effort spend on local optimizations. In retrospect, I didn’t spend 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 where we just stated that local optimization was bad and I met only one guy who was able to give me an example why it was harmful in his environment. But 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 things worse -** when it is not part of the global improvement initiative**.
This 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 to develop and deliver a work item) 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 effect 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.
If the different teams have the same goal, the cycle time reduction can have a positive effect on the lead time, but unfortunately it is very common that they don’t. Here are three different scenarios as an example, where the cycle time reduction has no positive effect on the lead time.
First scenario: Team 2 manages to reduce the cycle time in Phase 2. Reduced cycle time means that the work items arrive faster at Phase 3. Since the improvement was done only in Phase 2, Team 3 cannot operate at the same speed as Team 2, so the work items pile up between Phase 2 and Phase 3 on the side of Team 3:
In situations like this, the lead time won’t be shorter, because the valuable time that was previously spent on the work items in Phase 2 are now transformed into waiting time between Phase 2 and Phase 3. Additionally, if the pressure increases on Team 3 due to the increasing amount of waiting work items, they will probably cut down on quality so that they can speed up. Quality reduction means more turn-over in the flow - teams working on later phases or the customer will send back the faulty product -, which may increase the lead time.
For example, this happens when an Agile methodology is introduced only in one team - Team 2 in this example -, and the rest of the organization still operates by following a different methodology. Another example is when Team 3 has to cooperate with more than one team. Even if one of the teams speeds up Team 3 cannot take over their work items, because Team 3 are still busy with the work items from the slower team. Team 2 accomplished its goal, however the rest of the organization is not ready to pull the work items as quickly as Team 2 delivers them. So, they keep the deliveries of Team 2 waiting until they can be pulled.
Second scenario: in the previous example, Team 3 might have wanted to pull the new work items, but couldn’t. Unfortunately, there are cases when the** next team is not allowed to pull before the agreed delivery date.** In this case the work items will pile up in Phase 2 on the side of Team 2:
This is a very common project management mistake. Certain project managers have no trust in teams, so if the work is finished earlier, for them means that it hasn’t been done properly. So they force the teams to use the time left for more - unnecessary - internal re-testing. Honestly, I don’t know what they expect from this additional test phase. Moreover, according to them, we cannot deliver earlier to the customer or to other teams/organizations, because either they will expect us to do the same the next time, or they won’t pay as much as we want them to pay, because our contract is based on the time spent on development. The goals are clearly different here: developers want to deliver faster and project managers want to have a good looking project.
Third scenario: Team 3 is more than happy to pull the work items from Team 2 faster, and with them comes all the time saved up by them – thanks for the additional buffer, Team 2!
It is still common that teams have some kind of bonus system. For example, I worked in an organization where the test team’s bonus was in correlation with the number of reported - not necessary valid - defects. So, if a team has better chances to achieve its money-related goal when there is more time available, then the team will take this time no matter what the other teams are doing. It is a bit similar to the previous scenario, but here, instead of project management, Team 3 has its own goals/agenda.
I’m pretty sure that there are other examples out there (if you have any, share with us in the comment section). As you can see, improvements can be made, but they rarely have effect on the whole organization. Do an organization-wide value stream mapping exercise and try to discover the real goals and priorities. If many different goals are found, work on them until you have just one that is clear for everyone. When you have that, you can start thinking about how to improve your organization and teams in order to achieve it. Good luck!
comments powered by Disqus