Category Archives: technology

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:

  1. 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”.
  2. 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.
  3. 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.
  4. Hiding the problem (temporary solution) usually causes the problem to return with increased strength, and the cost of removing multiply (sometimes in exponential manner).
  5. 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.

Grail Quest to find where went our productivity to (part two) ?

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

Where:

  • 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.”

Steve Jobs

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.

 

Grail Quest to find where went our productivity to?

I had talked with friend, he was worried that his team was not delivering so fast that he was expected. He used to be a programmer, he is a manager today, and he remembers that “at that time” he delivers much faster, than it is delivered right now.

He is confused because after all, the developer world is getting easier … He works in a company that takes time and attention to make the programmers life better: continuous deployments with the right platform, automatic monitoring and much more.

In addition, the open source movement brings value, most of the time we just choose solution for our needs. The OSS ecosystem is huge today, just name a few:

 Why is this happening? Why is friend’s team productivity suffers?

The problem is not trivial, it seems that today’s software engineer has everything. In addition to open source libraries, he has tools available to deliver the product quickly and in excellent quality. An extensive development environment (IDE) with support for automated code refactoring that measures its quality and prompts us to code as we type.

All of this comes with tools that support continuous integration, code deployment, and support for multiple cloud environments. The developer does not have to wait weeks for a new server or software installation.

Looking at portfolios of cloud providers we can agree that the developer has everything he or she needs to get the job done. From machines (IaaS), storage, databases (various types), queuing systems, even algorithms, specific types of services (such as speech or image recognition) and ending with solutions for processing large data sets. You can go and check one of cloud providers:

What else do we need?

To go deeper into the problem, I cite two other friends who expressed doubts in “fast delivery of the value”.

The first one:  after hours he works on various contracted products. Talking recently he said something that made me think. Doing after hours brings more value in one week,  than his whole team together. The team is about 7 developers and we can assume that”after hours” means about 50% of the standard time of work. It means he is 14 times more productive. Puzzling!

Another one during the conversation said: “You know Pedro, there is work for a few hours, unfortunately as we pass it through SCRUM, it will take us two weeks.” Hmm … again assuming that a few hours is less than a day’s work, and two weeks is 10 working days – it means we are 10 times less productive.

Scary! What goes wrong? What is the problem?

While the statement of the first colleague does not give us a hard evidence. The second statement clearly points to the scrum methodology. It points, that certain ceremonies or procedures cause the “same work” to last longer.

Scrum is a great framework to organize and build software products, however, I have seen many times what things went wrong. What is it like? I would point out a number of distortions which, from a reasonable set of rules (eg. SCRUM), create “the RIGHT to success rules, which you must OBLIGATORILY follow, otherwise you and your project are DOOMED”.
Characteristic for these rights are:

  • If you follow these laws, your productivity will increase (hmm … doing daily meetings solves all problems)
  • If you do not follow a “law,” you should be punished (a cap or t-shirt that reads “I was late for daily”  and so on).
  • You follow the law, you should be proud of it – you are doing (surely :/) a good job (it does not matter that the implementation delayed another week – important that you were on the planning).
  • Did not succeed? Still not working productively? – it means that you do not follow the law or follow it in wrong way (daily at bad time … daily not in the morning …, or did not do grooming …., or did grooming to late/to early …. etc)

The side effect is that since we have “a set of rights” and have to follow them. We measure our success in the context of correlation with the laws we introduced. The “Institution of Measurements” is formed. After a while we start to measure our busyness – no matter if what we do make sense, what is important that we follow the law and all the indicators show that we are doing it wonderfully! 😉

“If We Measure Busyness, We’ll Create More Busyness.”

Applying these rules often leads to running with so-called “empty wheelchairs” where it’s important to run, because that’s what it’s all about. In this way, “accidentally” we reach the essence: the disposal of the resource (human one).

Resource Efficiency principle: If you can not finish the job, switch to the next task. Do so, until you find yourself in all the time switching from task to task and/or waiting for others to finish the task you waiting for.

From business owner point of view, the best utilization is when a person is working 100% of the time without a break for coffee. Once I heard from C-Level “You have to tell your people to work faster.”,  but in my experience such a situation is ridiculous, as there is usually something in the system that causes the work to be slow down and the “work faster, do more, get more people” change nothing in this situation (many times things go even worser).

Pretty good analogy is the highway. If there is a refurbishment works or narrowing of the motorway, more cars will only slow down the number of cars that are able to pass (work done) and increase speed is a high probability of accident and complete blocking of the motorway. The more cars, the slower, and finally total traffic jam (business projects to be realized).

Paradoxically less cars and less speed increases the throughput (work done). If worker do not work we can say that, in both situations, velocity is the same (close to zero), with quite different utilization (close to 0 versus close to 100%).

The first part ends here.

Next time you want to add more people to move faster – stop – and think what bottlenecks are in your environment. It might be one huge codebase with several teams develop different features get in their way, or lack of knowledge, or lack of automation in micro-services world. There are not one solution to fit all yours needs…

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.