Agile Zone is brought to you in partnership with:

I help IT teams & managers adopt Agile/Lean/Kanban approaches to deliver great results in challenging situations. I'm a London-based consultant, coach, speaker, father and (uni/)cyclist Benjamin is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

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

  • submit to reddit

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

Published at DZone with permission of Benjamin Mitchell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Christian Schli... replied on Fri, 2011/07/29 - 8:39am

So lets all praise the old days of the Roman empire where you just needed a whip to make your slaves hurry up - sigh. ;-)

Benjamin Mitchell replied on Fri, 2011/07/29 - 5:01pm

Hi Christian, Thanks for leaving a comment. I suspect from your sigh that you've experienced this kind of mindset from a manager, is that right? My hope with this post was encouraging a productive conversation where the manager who thinks that the team needs pushing would be able to openly say why they think that, giving examples. I think this can be more productive than having the manager walk around and try to "encourage" the team but try to hide this. I've seen that situation many times. If you had an experience I'd love to hear it where you've seen "pushy" managers dealt with well or not so well, I'd like to hear about it. Benjamin.

Frank Kelly replied on Sat, 2011/07/30 - 8:41am

I always look at it two ways

1) Motivation

If you've hired motivated solid developers then ask THEM what is slowing them down or what could help them go faster. If they're any good they'll tell you. Address each and every one - one-by-one. The key has to be "work smarter" not harder - automation is key - tools like automated builds, continuous integration, and other tools to automate any manual or error prone tasks.

Sometimes removing demotivating team members is also required - when people see slackers being kept around (or worse rewarded) there is no motivation to work hard or do a good job.

In addition ask yourself - are the developers being used efficiently - how much time do the developers spend creating unused features or rewriting things when requirements change drastically (that's another bad sign).

2) Hiring Better

If you try #1 and it doesn't work then you need to look at hiring better developers. If you don't know how to hire good developers then YOU are the problem.

See more ideas here

Matjaz Muhic replied on Sat, 2011/07/30 - 11:56am

Nice article.

I had some experience with "pushy" bosses.

It was always like this: We received very pourly written specifications. Then we gave the estimation in hours (the best we could from that specification). Our managers/bosses always said this too many hours for this project and then they gave our clients less hours than we estimated (sometimes even only half of those hours). We always went over the deadline and it was always our fault then.

 I really think bosses/managers should trust the programmers more and value our oppinion. We know what we're talking about.



Lund Wolfe replied on Sat, 2011/07/30 - 2:42pm

I don't know that you can really directly speed up software development without working more hours with or without more developers, either of which can easily backfire.

You really want what we generally call continuous process improvement (maybe with an emphasis on productivity). The easiest way to increase productivity is to start fixing the choke points in your existing process. Your developers will probably be happy to tell you what slows them down and what alternatives may be better.

If this doesn't help and you really are going slower than you should be, then the problems are more serious. There may be problems with the corporate/work environment and developer motivation, or just weak developers, or being able to hire/keep good developers.

Nafees Sharif replied on Sun, 2011/07/31 - 7:55pm

Nice read. As someone mentioned in the comments, keeping around (or worse rewarding) slackers demotivates teams big time. In addition to that, I have personally practiced keeping a daily roster of any activity i do that takes 10 minutes or longer. At end of three months i was able to see _where_ i was spending/wasting my time. Its a nice exercise that any person can do and does not require expensive/complex software to do that (a simple spreadsheet suffices). --Nafees

Benjamin Mitchell replied on Mon, 2011/08/01 - 10:51am in response to: Frank Kelly

Thanks for taking the time to comment and share your view. I agree that aiming to hire the best people and give them a good job to do can be an effective approach. I also see the benefits in asking the team if they see a problem, or the same problem that the manager manager sees can be useful. I'm curious though, how effective is it telling a manager that "YOU are the problem"? Has this helped improve situations you've seen in the past?

Benjamin Mitchell replied on Mon, 2011/08/01 - 10:54am in response to: Matjaz Muhic

HI @matjaz. I've seen that before - a team being asked for an estimate and then that estimate not being used. Were you able to raise the behaviour with the manager? What did you say? What was their response? Were you able to try an approach like jointly designing a way forward? Lots of questions there - I'm interested to find out more about your experience. Thanks for contributing so far.

Benjamin Mitchell replied on Mon, 2011/08/01 - 10:58am in response to: Lund Wolfe

Hi @Lund. Thanks for contributing to the comments. I agree with you that simply working more hours or throwing more people can backfire. I also like the idea of focussing on choke points in your process (I wrote about this in a recent post on 'removing bottlenecks from a software development process'). I couldn't tell from your response what you'd actually say to a manager who held the view "the team should go faster?". Whilst I don't always agree with this position, or think that "pushing" is effective, I know a lot of managers who do. Would you be willing to share approaches that have been productive in your experience? I'm particularly interested in what people said. Benjamin.

Benjamin Mitchell replied on Mon, 2011/08/01 - 11:05am in response to: Nafees Sharif

I love the idea of keeping your own list of activities that take 10 minutes or longer, and especially the way you then used the data you'd collected to work out what was soaking up or wasting your time. We implemented this on a previous team by asking "what wasted your time?" at the end of the daily standup and then writing a short description and a rough "sizing" of how long it wasted on a post-it note that we stuck on the back of a previous board. I'll blog about this in future. I'm intrigued by your mention of "removing the slackers". I'm interested in how you worked out whether it was someone deliberately slacking (or lacking the skills to do the work) or whether it was something else that resulted in them not producing sufficiently. What's been your experience?

Lund Wolfe replied on Sat, 2011/08/06 - 2:49pm

Hi Benjamin. I have only had one job back in 1998 at a small software company where I ever heard "the team should go faster". They have probably faded into oblivion. I took the job because I wanted to get into Java and away from "C", C++, and Delphi. I was still a junior developer and naive about how clueless a company can be. The developers were impressed because we had a powerful computer and our own office. In retrospect I can only tell you why they could not go faster or what doesn't work. It is a positive sign when the company asks developers "how" the company can go faster but if I had any suspicion of a repeat of my experience, I would start running now. To answer your question, if the manager just told me to make the team go faster or asked how to make the team go faster, I would look for the bottlenecks as you mentioned but this will be totally different for any given company/team. If there are fundamental problems with the company/team and the company is open to change that is great but those issues, too, will differ widely by company/team and books are written on this subject and I won't pretend to summarize/trivialize it.

The team could not go faster because:
  • Java was immature and the Java knowledge of the team, including myself, was almost nonexistent
  • one (not me) of the two new excellent developers quit after three months because he realized that the team was on a death march
  • the ivory tower lead developer's qualifications were a plaque on his wall
  • the requirements were a joke (that person quitting or being fired immediately after requirements completion should have been our first clue)
  • the CEO/president/owner believed in over-promise and under-deliver (quantity and quality)
  • the other subsequent new hires and existing developers were weak (the first two excellent hires must have been sheer luck)
  • charts were posted comparing developers for features completed (supposedly to inspire healthy competition) but quality and difficulty were not factored in and it was meaningless, especially to the developers
  • development was a widget factory for features which were mostly thrown away over time
  • the company was happy that something was barely functional
  • no buy-in from developers or sharing of information or responsibility

My opinion and I believe the opinion of most developers and companies is that you will go as fast as the quality of developers that you can hire. The best managers that I've had have told me that they try to hire the best people and get out of their way and act as enablers and defenders when the company itself throws up roadblocks with anal processes and policies. Going as fast and as smoothly as possible was just implicitly assumed. Little was forced on developers, only suggested, which is good because those suggestions are often lame or sideways progress anyway. I respect the old policy of GE that companies should lose the bottom 10% of employees, retain the top 10/15% at all costs, and help the bunch in the middle to grow over time. This is easier said than done, though.

Hema Latha replied on Thu, 2012/02/02 - 5:12am

It is great to have the opportunity to read a good quality article with useful information on topics that plenty are interested on. eset codes

Lily Marlene replied on Thu, 2012/06/14 - 4:10pm

A friend of mine nearly lost all his data from the servers because one member of the "team" was upset on others and wanted to destroy all of the data the whole team worked in a week by placing a tiny virus on a server. Luckily they had installed a very good anti virus and it discovered the threat before it could spread to the other computers. First of all you have to be sure your software developers are a "team" that works together and try to help each other, if they are good specialists you won`t need to push them from behind, they will finish their job in time.

Lana Rina replied on Thu, 2013/07/25 - 5:55am

The software team must have a higher order thinking and they will manage to finish the project in time. If you worked a lot to maintain an intrinsic motivation in your company you won`t have to worry about deadlines, the team will do whatever necessary to finish it in time.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.