Over a million developers have joined DZone.
Platinum Partner

How can I push the software development team to go faster?

· Agile Zone

The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.

A common challenge I’ve heard from Development Managers or Product Owners is “how do I push my software development team to go faster?” Here are ideas on how to approach this topic and have more productive conversations.

Understand your own mind

Start by clarifying your own mind, particularly your intention and motive for trying to get the team to go faster. If there increasing external pressures on the project, or it’s becoming clear that it wont be possible to get everything you hoped for by the due date then these are worth clarifying and sharing with the team.

Take the time to understand where you’re coming from and why.

This step may seem obvious, but it’s worth slowing this down and even talking it through with a mentor or trusted peer and asking them to play devils advocate and try to see things from the team’s perspective.  It’s much better to get clear on your own intentions and motives than to mop up from an argument later.


Focussing on “fast” may have unintended impacts on quality

As the old saying goes, “be careful what you wish for” because you may get it, but at the expense of other goals.  Sometimes to go faster you may need to use indirect or oblique strategies, such as removing the causes of bad quality or delays.

Seek to understand the situation by looking for evidence

If you think that the team is going slower than it could be, then get clear on the evidence you’ve seen or heard that leads you to this view. If you tell a team “I think you can push a bit harder and work faster” but can’t use specific examples that they recognise and understand then it’s likely they’ll feel unjustly accused. See my post on handling a team member who talks ‘too much‘ for an example of using directly observable data.

If you can’t be specific about why you think the team could be going faster, then be open and say so – “this is just a hunch” – You could ask the team to help look for evidence, by asking “If you were performing under or over-capacity, what would we look for as evidence?”

Talk to the team, sharing interests and concerns

Talk to the team about why you want to help them get more done. Share your intent for bringing it up.  Start by sharing what you’ve seen or heard. Ask them what their view is of the evidence you’ve got? Do they see it the same or different?  If they see it differently then get curious and ask them what they see that leads them to their view.

Sometimes the conversation can get bogged down under an escalating game of “no, your approach is bad for this reason, we should do my approach”. One way to avoid this conversational log-jam is to focus on the interests behind the positions, or more simply, ask them what they like about the solution they’ve proposed.

I’ve found the best way of encouraging more productive conversations is to learn and model these more effective approaches yourself.

Jointly design ways to tests disagreements and move forward

If there’s a strong disagreement between you and team about the level of productivity, then focus on jointly designing ways that you could move forward. Think about what data would persuade you from your point of view and ask the same of the team.  Use work that is about to begin and come up with a way of collecting data that would make future conversations clearer.

This is a topic I may come back to in future and look at it from the team’s perspective.

Image Credit: gentlemanhog, on Flickr

The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Learn more about driving business innovation by leveraging Agile quality lifecycle strategies.


Published at DZone with permission of Benjamin Mitchell , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}