Why is your dev team soooo slow? 5 reasons.

I spoke to a startup CEO last spring who was looking for product help. He had an established team that had been working on their platform for a few years, and seemed to be slowing down. In a call, he said:

I don’t get it. My dev team used to be really fast, but lately they are struggling to finish their work. They’re doing Scrum but they don’t deliver on their sprint commitments, and yet when I go to their area at 5:30 in the evening, it’s a ghost town. Everyone’s gone home! How can I get them to work harder, to show some initiative?

It was a big mystery to him. He wanted to believe in his team, and was really reluctant to conclude they had all become lazy. And the truth? They weren’t going slowly because of laziness.

They are going slowly because they are not allowed to go fast.

Specifically, the rules of your culture force them to work very slowly, and this saps their motivation. If a software team seems really slow, the cause is nearly always these 5 things:

They are working on too many things at once.

Right now, most development teams in the world are working on too many projects. If a team’s capacity is 6 projects at once, they are trying to do 40. Everyone is constantly stopping and starting and blocked waiting for help. It is very likely that nobody is even aware of the full list of work in flight.

The single fastest way to speed up your team is to fix this. Make the work visible. Priortize the current projects. Stop many of them. And physically place yourself in the way of new projects, so nothing gets started until something is finished.

They are discussing too many new ideas.

With one team, I found they were actually spending about 60% of their time discussing new project requests and about 40% of their time on implementing solutions. Of course, it is necessary for the dev team to talk about the future. But if everyone in your company can interrupt every engineer with discussions about possible new projects, you can quickly destroy all of your productive capacity.

Designate someone to evaluate incoming requests before distracting the development team. Batch them up so you can get developer feedback once every week or two instead of every day.

You are not letting them finish things.

If every project is rushed, and the team is never given the time to do things right, they will slowly destroy their architecture and toolset. If the team can’t maintain the system they will slow down more and more over time.

Give the team the time to leave the system better than it was before they started. Make it safe for them to be honest about this.

You are starting projects that you can’t afford

It is easy to get excited about a prototype. If your team is using modern development practices, they can define a thin slice of value that can be delivered quickly. And this is a critical skill. But there is a difference between an MVP and a sustainable product. Often, it is the 8o% of the work, the boring but necessary cases outside of the happy path, that makes a difference. If you pretend this work is not there, you will trick yourself into taking on projects that are beyond your means. You’ll start grand rewrite projects that seem to be going great until they appear to grind to a halt.

Assume half of your project ideas are actually out of your price range. Ignore sunk cost. Cancel ideas that prove unaffordable.

You are yanking the team around

If you are experiencing any of the above situations, it is likely that you have tried to solve them by ‘multi-tasking’ — moving individuals between projects or dicing projects into the backlog. Teams are delivering fruit salad rather than whole meals. Context-switching can happen at many levels — task, project, or even the strategic level. If your strategy is unstable or insufficient, you will yank teams or departments back and forth between orthogonal strategic goals and not achieve any of them.

Be realistic about how many strategic goals you can do this year. If you are capacity-constrained, favor serial over parallel strategies.

—

These problems are driven by your culture. The drivers are often unspoken. If your leadership team wants to, you can change this culture, but it’s hard work. Best to recognize that the way you gain speed and flexibility in dealmaking is not the same as the way you do it in product development.