Grail Quest to find where went our productivity to (part three) ?
In Part one we talked about problems with productivity, when adding more resources, introducing better processes like scurm don’t help. In Part two we focus on Work In Progress, when paradoxically the more we want to do, the less actually work is done.
In order to fix Work in Progress of the team, we often what to help them. Let us split the team, so people are more focused on their work. Another fix is adding more people to the team (increasing the amount of work done).
Is that right?
Unfortunately, the truth turns out to be brutal and it is quite different. You may find that for some reason the work goes even slower: more people/focus but smaller WIP.
Why is that?
To be able to synchronize, you need to communicate. Quite often we do not realize how much time is wasted to communicate to each other. If you want to check the easiest way to do this is to measure the number of meetings. If you have a central system for booking rooms, just prepare and look at a simple report: the number of meetings per employee.
At one point I even investigated this matter and came to the conclusion that the more people in the meeting, the more expensive it should be to book such a room. The idea of course has not been realized, but if you want to provide such service, than I will be happy to try out such reservation system.
Everyone complains about the meeting, and then it turns out that anything in the company can not “moved forward” without meeting. Personally, I love my calendar today, because I do not have more than five hours in meetings per week. And even this is too much in my opinion.
Sometime ago I had conversation during a conference with one guy. He told me that, they had a “customer service center” in which they have KPI: “how many calls per minute” and it was something about 10 calls per minute. Well, as usually happens, someone “upstairs” stated that he has an offer from a company that can do it much more effectively. So their call center was canceled and all work was outsourced to the outsider. The first reports allowed “the board” to celebrate success. The new company supports about 100 calls per minute – 10 times better efficiency. Great decision!
You probably already feel trick here … because I wouldn’t tell a story here if it would not show another problem affecting our productivity. It turned out that customers called a dozen times for one problem. The operator wanted to handle (according to his KPI) them as soon as possible, very often by riding the client of. Client had to call several times to solve his problem, as a result the client were much less satisfied with the service. Not always the number of customers served goes in hand with quality of service.
The first quick lesson – what you measure is what you get. Measure more calls per minute, you get more calls per minute, It does not mean better service and in many cases things goes worser.
The second lesson is more important. It is worth looking for the problem at the source. Go to the source and start solving the real problem. Many times we use “tricks” to cover it – We can call it Failure Demand.
An example from IT sector is a team that increases its velocity (sounds good) but does not provide any value. WTF? It can easily happen when there are more and more bugs which even increase velocity (every bug get a certain amount of story points). This leads to the situation when the team only do bug fixing (by the way bugs was introduced by the team), so no additional value is delivered.
Quite often a remedy is to try to move part of work (eg. bug fixing) to different team, so development team can focus on delivering business value. We can introduce a team (QA) that will fix some of the errors, or will test whether the errors have been fixed, and so on. Sounds familiar?
In this way, specialized teams are born. Now the “poor” developer can produce even more code. The testers are testing instead of him, the release managers do deployment instead of him, the incident managers react to production problems instead of him …. and so on…..
This leads quickly to a situation in which the developer does not feel responsible and does not understand how his bad code affects the whole organization and work of others. The developer become detached, which become huge problem for organization.
Looking at the work of teams that improve some “developers pain area”. When we move work to different team, than it causes developers to increase their bandwidth. More developers bandwidth increases Work in Progress (WIP) in pain-killer-team. This causes these teams to become a bottleneck. The whole organization focus on them, because they do not cope with the amount of work – so they (eg. testers) are the problem not developers.
Interestingly – it hides the real people responsible for delivering the poor solution. Introducing such teams sooner or later creates siloses, which is very bad for organization. Furthermore we aren’t solving the right problems, and we are creating even more bottlenecks and more detachment in the organization.
You can also look at that as local optimization destabilizes the workflow on a global scale.
In conclusion:
- Workload up to 100% and the need for faster work has the opposite effect. The “worker” must have a moment to think and “sharpen the saw”.
- The more rules, the greater the focus on those rules. This causes us to blindly follow the rules and stop thinking, because rules do it for us (or at least we are safe). These are huge opportunity lost.
- The more work, the greater loss on context switching. This leads to the fact that everything takes longer. The cost of delays is increasing and many projects will never see the production environment.
- Hiding the problem (temporary solution) usually causes the problem to return with increased strength, and the cost of removing multiply (sometimes in exponential manner).
- You need to have time for unplanned work.
- If you do not have time because of (#1 – you are fully loaded),
- or you do not think because you have rules (#2),
- the “business” comes with next projects (unplanned), so you try to juggle between the projects (#3),
- so you need to hide many things because not time to solve real problem.(#4)
- This brings you to (#5) no time for unplanned work. The whole tightens the loop on your neck. R.I.P.
What can we do about it – the solution:
- Always have some loose time.
- The less the rules, the better – see experiment England Town turn off traffic lights
- Control the WIP and respond when it’s too much. Reduce the amount of work is better than slow down or even blocking the entire system. Remember: I love Lucy candy video.
- Solve problems at the source.
- Remember that always something happens, you have to have time to react.
And thats all Folks!
By the way, as Tech Rebels we help companies go through technical hurdles. Just hire us, and we will bring your organization to next technical level.