5 Questions to Ask When You Hear “We Need to Accelerate Development”

No one calls me when things are awesome. Google and Facebook aren’t calling me. The people that call me need help, and one of the most common things I hear is that they need to “accelerate development.” It could be that they don’t have enough engineers or that their engineers are kind of slow. But there are a lot of things to consider that might be responsible for this seemingly sluggish development pace.

Does the team know what we’re trying to accomplish?

Teams that understand what mountain they’re climbing climb the mountain faster. If they don’t understand the vision and goals, they waste time trying to figure out what to do and arguing about it.

I’ve spent hours in rooms with executives getting them to agree to three objectives for a product. But once they’ve agreed and the team gets those objectives, the team is off and running without having to consult the executives on every decision. They also have an easy way to prioritize ideas; if the idea doesn’t drive the objectives, it goes straight to the backlog.

We need that high-level understanding, but we also need to know it on a story or specific level. What are we trying to do with this task? One of my team members was doing a customer interview with a client engineer observing. The engineer was taking notes during the session like crazy. After it was over, she asked what they were writing and it turns out they had spent weeks debating a feature. By understanding what the customer needed and why, the engineer figured out exactly what they needed to build.

Is planning taking up too much time?

I had a client who was concerned about speed, so I checked into things and found that the team was spending 60-70% of their time planning. The client was very concerned that we were building the right thing and minimizing rework. That never works – Twitter, Facebook, and many of our clients have had to re-architect their systems. It’s impossible to know exactly what you’ll need in two years. Instead, build what you need for today in a flexible way and trust that when you need to change something in two years, you can adapt as necessary.

Negotiating what’s in or out of a release or where a feature falls in a roadmap is something that takes a lot of time. This is worst during annual planning. I’ve seen team progress come to a screeching halt and executives spending hours and hours trying to decide which projects to fund.

The trick is to do enough planning to guide the team and manage waste without the overhead strangling progress. Once you have objectives, decide how much achieving those are worth to you and assign budget, then make sure there are checkpoints in place.

Is the team getting bombarded with requests and meetings?

A survey of Engineers found “All the non-design and non-coding tasks take up 22.4 hours per week out of the 41.5 hours worked in total.” It’s important for teams to meet and solve problems, but team members also need time to put their headphones on and get cranking. Plan out your team’s collaboration time so you can leave work time at different times of day depending on their preferences. Trello has a great post on schedules for makers and managers that is full of advice on this topic.

How effective is our process for managing ideas or requests?

Software development is kind of an assembly line. Public clouds, DevOps, Automated Testing, and development frameworks are speeding up the line but the management of ideas can slow everything down. Tracing an idea through to development should help you see where things are getting clogged.

Is there a trouble-maker who needs some fixing?

Creating clarity and putting the right systems in place will get you far but you still may have some people whose negative behaviors are holding the team back. It may be shiny object syndrome, negativity, lack of responsiveness, conflict or lack of focus. Explain how the behavior is hurting and help them fix it.

This post was originally published on Jessica Hall’s personal blog, Hallway Studio.