Why developers are slow?

Development seems to be one of the slowest things on the earth – I hear so many complaints about it’s slowness every day. “Why we can’t do that in a day instead of a week?”, “We missed deadline because your developers are too slow, they should work faster!.”

Sometimes project managers think that the team they got is the slowest they can imagine. And they dream about making it 2 times faster (I mean “work 2 times faster”). But the fact is that there is a big chance the team is pretty average and managers don’t get the difference between “make the flow faster” and “make the team work faster”. They somehow think if the developers start typing 2 times faster everything would be fine with the schedule.

Reality

On one of our projects we used kanban and measured the time for each feature from “to do” to “done”.

An example of the measurements on the right.

After some period of time I started analyzing how much each task spent in each of the stages – we had “Analysis and design”, “Development”, “Testing”, “Done” stages. So “Development” appeared to be not the longest one. The most frustrating and long stage was “Analysis and design” – we changed our designs 5 times, discussed every item in the requirements with product owner, argued about the priorities, etc. Item could stay for 2-3 and even more weeks in Analysis, blocked, waiting for someone’s decision. And when it was “unblocked” we usually got the instruction from our PO – “Do this ASAP, we promised this feature 2 months ago and it is still not done!”.

When I came across the similar conclusion in the great post “Your developers aren’t slow” I realized I need to write a post about that)

Why developers are usually the ones who slow down the development

Because it is the easiest thing to do – find someone to blame. It’s very difficult for PM to admit that he is not a brilliant manager. And as there is a huge ratio of not great managers to the great managers – it happens to all the PMs I know, including myself. It’s much easier to blame developers, not think about what you are doing wrong as the PM.

Who really slows the development

On the management side:

• Unclear requirements, throwing them to the team without any analysis. Badly written user stories.
• Changes. Been flexible is great. And we have some great tools as agile frameworks to adopt to the changing environment. But we have to pay for everything – for been flexible too. As PM(or PO) you have to prevent the “infinite changes”, when project seems to be never ending and never released – as the infinite number of changes flow in. It always happens in outsoursing: you work on the project for half a year/year, process hundreds, thousands of change requests, some of the modules are overwritten not less than 5 times and client comes to you with a big complaint “Why we are not done yet, you told us in the beginning that it would take a month”. If you heard that at least once in you live you should remember that feeling when you would like to smash someone’s head with the hammer.
• Prioritization process issues. There are several main issues under that. You can’t do everything at once in a parallel with the highest priority. I always get these brilliant advice from the customers “Ok, let’s do the architecture and UI and that…what it was…UX? So let’s do that in parallel to make it faster.” The other is that you can’t change priorities
• Trying to reach the best utilization rate of the “resources”.  You try everyone to be full loaded and busy? You can’t be fast. The simliest explanation is that to make everyone busy you should crate buffers before each of the team members (to ensure they always have something to do)
• “Hurry up! Hurry up!” culture. If everyone is hurrying up there is no time to think, as you have to run. If there is no time to think – you make mistakes and a lot of crappy code. Additional effect is that to look always busy(and if they are not looking busy – manager will definitely give them more tasks) people can start working slower)

Developer’s daily routine

• Chaotic development  process. Development anarchy is great. But when it is a real development anarchy, not just an ill-managed process.
  QA can be the slowing stage too. There can be various causes from not setting the “definition of done” to the culture of assuming the task to be done when it is coded, but not tested yet.  You have probably seen teams pulling the stories one ofter another from backlog not finalizing the previous one and ending with 100500 stories “in test” in the end with 0 “done”.
• Low level of motivation. Who would work good if he hates his work?
• Wrong company culture. It is the cause of some of the issues above. Now, when I realize that it is the starting point to everything in the organization I put this in every post.On the development side:
• Crappy code, awful architecture. It slows down the development tremendously. If your developers are coding all the working day – it is not good. Actually, you have to do something immediately. As developers should spent significant time “thinking the task over” before the implementation.
• Developers watching youtube during the working hours. I just wanted to check if you are still reading 🙂

Take responsibility

So, let’s be honest – PM, it’s you who slows down the team. Not the developers (in 99% of cases. Let’s leave the 1% to developer’s sabotage).