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


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

Book review: The Business Value of Web Performance

Web performance is always very important to me. Browser need to download more and more resources to render full page. On one hand we want our pages look gorgeous on the other hand this means more images, more bandwidth and of course more time.

In todays mobile world this become even more important, we are in the hurry and if page didn’t show up in 1-2 second we’re swipe away. I read over a book  “Time is Money” by Tammy Everts. It is very short one (about 100 pages) you can read it in one day. I recommend you to get this book and read it.

In first two chapters, author shows a lot of case studies and scientific background to convince us that performance is important. Fast websites create happy users – lot of  case studies proves that we perceive slow webpage even slower than it is. Research show that there are two really important aspects of our brains:

  • Short term memory – which is very poor and decays quickly
  • Need to feel we are in control – if we have to wait, we feel powerless, so we’re starting to frustrate.

That means that 0.1 second give us illusion of instantaneousness; after 10 seconds we lose focus. We need fast application to gain “Flow”, otherwise we are getting tired.

100ms is Google stated goal to page load times

In the book there are plenty of examples how few seconds can change conversion rates of our site. So finally I think this quote get to the point.

“First and foremost, we believe that speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it.”

– Fred Wilson, VC, Union Square Ventures.

Digging deeper we find out that the problem is latency and bandwidth. Important thing to know is that increasing bandwidth by 1000% we improve page load time by about 50%. We should consider that many browser has limit of simultaneous connection, and this limits may vary depending on version and OS. That means latency is what we should care about. The big problem with latency is that it’s unpredictable and inconsistent. It can be affected by almost everything from the weather 🙂 to what your neighbours are downloading.

Regardless how much money we invest in building out the infrastructure – latency will continue to be one of the greatest obstacles in web performance.

Next we are moving to optimisation layers, where we can measure and optimise response times. These layers are:

  • Servers
  • Load Balancers
  • Content Delivery Networks (CDNs)
  • Frontend Optimalization (FEO)

This layers has different optimization purposes, but the rule of thumb says that 80%-90% of the end user response time is spent in frontend, so it is good idea to start there. Mobile optimisation are VIP here, so we should always figure out how to decrease request count and how to minimise response size.

To know where we should put our effort, to optimise proper page, or part of our application we have to measure it and we need to know which pages are more important from the customer conversion point of view. There are a lot of different measurement tools available: mainly two types Application Performance Management (APM) and Digital Performance Management (DPM)

It might happen that cart page is not so important than welcome page or vice versa. We should figure out what impact does web performance have on Customer Lifetime Value (CLV).

The very important question is “How Fast is Fast Enough?” and let me cite the author:

“optimising performance is like painting the Golden Gate Bridge: it never ends.”

Let summary this, performance is very important. Carrying about performance gives us better conversion rates from our customers and makes them happy. It is very important to build culture of performance in your company. To do this, it is good to show them use cases to demonstrate the value of performance – and the best are your own case. Building such wide knowledge on both business and technical side.

Finally everyone who touches a web page from people on the business side – looking to add third-party analytics tags; to people from the marketing team, wanting – to add high-resolution hero images ; needs to know that their decisions has impact on performance. Impact on performance is the same as on revenue – we can increase or decrease it.

And one final quote:

Remember that performance is a journey, not a destination.