Our Developers are too Slow!!!

In a previous company I worked for, the VP of Sales approached me and asked me “our developers are too slow… how do we make them faster?” I had observed how their product development worked and I answered “Well, if we build the feature right the first time, then we would be faster”. Before we place blame on development we should really be objective and look for the root causes anywhere. Here are the three most common reasons for development of products being slow.

Technical Debt

When I worked as a developer in a past life I have never encountered a product without technical debt. There is a rule we try to follow when we develop a product, we keep the code cleaner than it was before, otherwise known as “refactoring”. When we refactor, we improve the readability and the maintainability of that piece of code. If we ignore it, we accumulate debt which will become harder to pay back later.

In an ideal world, code is like a block of legos. We make it easy to add, change or remove pieces from the product. The less we care about code design and quality, the code becomes more like a bad game of Jenga, where pulling out pieces become a guessing game if the product will work or remain stable. Most developers I met care about quality of code, so why do we accumulate so much technical debt? It is because we generally use the full capacity of engineers on building features only. How can we fix this?

1. Add an extra 20%-30% on estimations for dealing with technical debt, depending on how bad it is.
2. Work with developers to figure out where the speed is affecting their work and invest time where you will gain that time back.
3. Dedicate time for technical debt. I used “The 6th Day” of a sprint to work on tech debt only.

Being Reactive, Not Proactive

One of the hardest thing for stakeholders to see is how a reactive approach impacts the team. I have seen two scenarios of a reactive team.

The first, had many interruptions due to a short Service Level Agreement (SLA) for bugs. We had to drop everything when a high or critical bug appeared. The customers were happy because we reacted quickly. At the same the team were delivering a feature while managing the interruptions from bugs. What the stakeholders saw was a very slow development of the feature, however, when they did work on the project they were not slow. What they didn’t see is developers being pressured to fix bugs quickly so they can continue with the project. To resolve this, I had presented to the stakeholders:

1. The percentage of work into the feature vs the bugs. How interruptions impacted their speed.
2. Fixing bugs quickly only fixes the symptoms and not the cause. More dedication is needed to reduce the bug influx.

The second scenario is the changing of priorities. When a priority changes developers leave what is unfinished and move to something new. We have in fact left “feature debt”. The more changes in priority made, the more feature debt we introduce. The more features we build, the more complex the product gets. The more complex the product is, the harder it is to prioritise new work vs gaps. In this scenario I would invest in:

1. Vision — Create a vision that sets the future of the product and help prioritise features. I believe in doing one thing and doing it great.
2. Strategy — Dedicate time in the roadmap and creating a product strategy that lasts.
3. Prioritise problems — Have clear idea of the priority of problems you want to solve against the vision and roadmap. Solutions can be easily dropped and changed over time. Problems are more long lasting and can encapsulate 100s of ideas.

Building the wrong thing

If you have your vision and strategy in place with the team building great quality software, there is still a critical point of failure. The VP of Sales had put blame on the development teams that they were too slow. In fact the cause was closer to home. Product and the stakeholders had not put too much emphasis on building the right thing. This mistake results in rebuilding the feature again. The process usually goes as follows:

• 1 or many stakeholders say they need a specific feature or capability
• Product specs the solution
• Engineering delivers the solution
• Product launches the release and finds out customers cannot use it.

We had assumed the stakeholders were right. By the time we found out it was wrong, it was too late. This result helped give us the power to change. After reading about “Design Sprints” we decided to change the way we do product management. What we changed:

• Focussed on researching the problem. From market to competitive to customer and user research.
• Validate solutions with prototypes early with real users. Used as little engineering resource to build it.
• Collaborative approach to design. Including Product Manager, Designer and Tech Lead to identify risks and creating solutions.
• Keep scope small and manageable for teams to deliver in 4–8 weeks.
• Know when to focus on discovering solutions and when to support delivery. We ensure that we discover 2 months ahead of a release.

Our Developers are just fine

From our stakeholder’s perspective developers are too slow. However we need to understand that there may be other factors affecting their speed. The fault can belong to other parts of the organisation too.

In the company where the VP of Sales once complained to me had seen amazing results. They can release every 8 weeks without delay. This was once a company where stakeholders complained about the speed of development being slow. Now they are a company with stakeholders who say developers are delivering too fast. I would say it is a luxury and this was achieved with a change to product process and without any change to developers.