In Part one we talked about problems with productivity instead of great support from community, adding more resources, introducing scurm or other lean processes.
We end up with resource efficiency (engineers), today we follow the next problem with throughput. In every company there are more project, more important things to do than people.
The number of projects we are working on (WIP) is growing. Worst of all is when the project with V.I.P. priority shows up guided by C-Level (board, owner). I saw the company that had assigned more than one project to developer. I saw the company, which switch from the “only one important” project to another “only one important” project.
As you can guess the work of developers is not easy in such environment.
It reminds me my sister current problem with “developers”. She decided to build a house and so she hired a “crew”. Quite soon, she noticed that the work was not going as fast as she had expected (as scheduled). It turned out that “Team” has learned that from time to time they have to wait for materials (eg. cement, bricks, etc.), or her (the client’s) decision. So the team worked on more than one construction site (sells time to different client) to be fully utilized and to fulfill needs from different clients. Theoretically, a brilliant idea, in practice susceptible to all kinds of “deadline missing” or unforeseen events both positive ( bricks came earlier) and negative (delay in owner decision).
This causes a lot of tension between clients and the “team”. It ends up in losing trust. You probably smile now: how many times IT (“team”) is taking orders (“additional work”) from different departments: marketing, sales, CTO, CIO (“clients”).
IT tries to juggle from project to project, so they appear to move forward. Usually not fulfilling its promises, and many of the solutions are makeshift. This situation negatively affects mutual relationships. On the other hand developers themselves are also unhappy because many of their solutions are not implemented, has poor quality, with technical debt growing exponentially (this is story for another post).
The conclusion is one: it is necessary to control the amount of work performed at the same time. Switching the work kills your productivity. It makes many things “not production ready yet”, and the code not on production is WASTE.
With greater focus we can deliver things much faster and in efficient way, and after delivery move to the next task. We may say that the more things you do at the same time, the less things are done.
Here we have “Little’s Law“, the law is completely unrelated to IT, but it is useful to determine the relationship between work is progress (WIP) and the speed of execution (Lead Time). We can define it as follows:
WIP = λ * LT
- WIP = how much task is to do (work in progress)
- λ = how fast new task comes
- LT = how much time the task is in queue (on average)
Assuming we have constant processing speed. As λ can be assumed as proportional to our throughput, which gives us the relation LT = WIP / Throughput. We can conclude that the more tasks we have, the longer it takes to finish them.
Please watch this movie now. After that even my grandmother understand WIP.
This movie reminds me how often we try to accelerate the development of software. We announce deadline and watch if developers can do it (even they are saying it is impossible). The quality of this software is very similar to that what you have just watched. In the end Project Manager comes and say: “hmmm you did it, let’s go faster” 🙂
“Deciding what not to do is as important as deciding what to do.”
Let’s remember this: it is worth paying attention to the amount of simultaneous work and the pace of adding a new one.
In this part we focus on work in progress. It shows up from both direction. From the team, which try to utilize their time, and from clients, who tries to push as much work as their can. Stay tuned for final third part.
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.