The one common question that arises with almost every traditional and agile software project is: “can we ship this yesterday/tomorrow/next week/urgently/as priority number 1?”.

This question is usually brought on by tight deadlines and unforeseen circumstances in a feature/project delivery and it almost always forces team leaders to ask “how can I get the team to go faster?”.

When we look for ways to go faster we’re often under pressure by things around us - often stressed and frustrated by the situation we find ourselves in. This pressure often forces us to fall back to our instincts - telling the team to “just go faster already!” otherwise known (unfortunately) as “cracking the whip”.

Simply telling a team to “go faster” will most likely result in them going slower; it will impact morale and cause tension with you as their leader (or even worse, an outsider to the team) which will quickly spiral out of control. In many cases this will result in damage that cannot be easily reversed from your team/company culture.

Needing to “go faster” is an age old problem - but in this post I want to suggest the idea that the goal isn’t to “go faster”. The goal is to remove the things that slow us down - “going faster” is just a side effect. The real question we want to ask is “what is slowing us down?”.

Teams are much like living organisms; they grow, they move, they respond and sense change - each team is unique and no two teams work by the same rules. It makes answering the question “what is slowing us down?” non-universal.

The best way to answer this question is by sitting down with your team and simply asking them. This could be done during a retrospective, a dedicated session alongside your retros or just down the pub. The most important thing to remember during this is to be honest with your team about why you’re asking the question.

You may find some of the below themes come out during your conversation:

The team don’t feel like they have a goal to work towards

There are dependencies downstream causing delays and blockages in the pipeline

The team are context switching too much

The team don’t feel like they have ownership over the work that needs to be done

The team don’t know what work needs to be done to achieve the goal

Technical debt is holding the team back

Constraints the team are operating under - this could be technical or organisational induced process

Bugs and rework caused by low quality work - this could by the symptom of a team cutting corners

The team are cutting corners to meet the deadline, which is trading off against the “cost, quality and time” triangle resulting in firefighting or quality issues

The work that needs to be done isn’t well defined

The work is too large and whilst progress is being made it appears slow to those not directly involved

The team are working in silos - this can be caused by knowledge silos, poor team member performance and individual preference in ways of working

Morale is low

If you find the responses from your team do not conclude anything fruitful, or you’re met with a response of “huh, we’re confident we will deliver!” you may want to:

Ensure the team have an understanding of the amount of work you’d ideally like to have completed

Talk about the work to be completed as a team in a dedicated session- talking through work can often lead to team members thoughtfully considering the work to be done

Be honest about your concerns - quantify your thoughts and provide tangible observed evidence during conversations where possible

Sometimes deadlines are simply impossible to meet - if you can’t move the deadline or you’re reading this post to find out how you could work smarter, you could:

Sit down with your team and understand where the complexity and risk lies in the work to be completed - reduce the risk by spiking the work early, break off as much value as possible into separate pieces of work

Sit down with stakeholders and prioritise the work - doing this will allow your team to work through as much as they can within the time-period running up to the deadline (See Kanban)

Reprioritise anything that just isn’t absolutely necessary for an initial release and de-scope it as early as possible - things can still be added once you’ve shipped (this is a blog post all on its own)

Make sure work is split up as small as possible, this will make it easier when prioritising, try to split stories so they deliver user value

Don’t split stories into technical tasks, always make sure they deliver some kind of value to whoever is using your software

Have conversations early and often when things are not going to plan

Inspect and adapt at regular intervals. Don’t wait for a retrospective - talk to your team and stakeholders daily. Fix things when they are broken, don’t get stuck in a rut because that’s how things have always been.

Shipping software is an art - as Douglas Adams once said - “I love deadlines. I like the whooshing sound they make as they fly by.” Source: GoodReads.

The next time you’re pressured into meeting that deadline - don’t ask “how can I get the team to go faster?” - ask (your team) “what is slowing the team down”.