Monday, October 08, 2018

5 Ways to Improve Developer Productivity and Quality on Agile Development Teams

Highly productive developer
Many leaders that are new to scaling agile ask me about measuring individual developer and tester productivity since most agile metrics such as velocity are aggregate measures around a team's performance.

These leaders support team dynamics and some promote agile's self-organizing principles. But they also have significant demands from business stakeholders on the speed and quality of their deliverables. Even the larger sized organizations have relatively tight budgets and want to make sure they are getting value, productivity, and quality from the developers and testers on their team. Leaders ask questions on individual performance regardless of whether their teams are fully in house employees, a mix of employee and contractors, or are heavily outsourced.

When individual productivity is not the right metric

There are several reasons why the question of developer productivity comes up when it's in fact the wrong question to be asking or issue that needs resolving. Some examples:

  • When project managers apply classic resource management to an agile program, they may be seeking developer productivity metrics to better align resources to teams or looking to better understand development forecasts. Classic resource management approaches are not optimal tools for managing agile teams that are selected and balanced using a number of factors that align with team performance, skills required, diversity factors, and other considerations.  
  • Product owners looking to micromanage their teams and circumvent the agile process may try to measure and use developer productivity so that they can hand pick their team and process. See my previous post on other bad behaviors of product owners.
  • Leaders seeing greater velocity on difficult or strategic projects may try formulating a team of super stars, but again, this is unlikely to yield positive results. See my older post, 5 ways to improve agile team velocity for better approaches.
  • Team members seeking more control may look to "boot" members for a variety of reasons including personal preferences and job security. Their interests may not align with leaders seeking diverse, balanced teams. They may highlight individual productivity (and possibly undermine it) to influence team selection.  
  • An impossibly complex architecture (ie, a Frankenarchitecture) will have a dramatic impact on individual performance especially for new team members or people with less technical experience. 
  • When logistics is a factor then it might impact individual productivity. For example, if some team members are not colocated with the rest of the team, then their productivity may be impacted. See my previous posts on improving agile meetings as another approach to address productivity and work around team logistics.

5 recommendations to improve productivity of agile team members

When asked about developer or tester productivity, I look back at leaders and managers at the types of activities that they can control and lead to productivity improvements. Here are some of my recommendations 

Improving agile productivity
Improving agile productivity, a theme in Isaac Sacolick's book, Driving Digital

  1. Measure your developer onboarding process - How fast does it take new developers from day one of onboarding to the day they are productive, to the day when they are fully contributing to the velocity of their teams? 
  2. Address technical debt especially around the application architecture, continuous testing and CI/CD, and documentation quality. All of these areas of technical debt contribute to developer and tester productivity.
  3. Review top performer assignments to ensure they are working on the strategically most important features or the more complex technical debt. It's often easier to identify top performers, and making sure that they are working on the tougher assignment ensures that their teammates are more likely to be productive with less challenging work. 
  4. Version control provides better indicators of poor developer quality and productivity. Teams should be conducting code reviews and retrospectives to help identify areas of improvement. If one or more individuals are contributing many production defects, then that's a concern especially if they are not following development standards.
  5. Measure teaching and learning activities as a way to address the team's culture. Rather than focus on productivity, ask them to improve both productivity and quality through programs they select, administer, and participate in.

Many times I'm asked questions around productivity as one person's effort to control a process that they can't easily influence. It's a symptom of bad and possibly a toxic culture. Change the thinking. Focus on making people and teams successful. Become an agile organization and focus on agile management practices that drive transformation.


  1. Major problem in agile teams is most of the times managers try to manage resources in a classical old way while they themselves enjoy benefits of agile. It is better to create more transparent structure in agile systems, we use TaskQue to assign tasks and then oversee all the activity.

    1. Thanks for the comment. Teams that use tools rigorously will be able to capture better metrics but I don't advocate using them as a primary indicator of performance. Again, most of the people asking me this focus on the individual instead of the team and the underlying culture/process/architecture that drives success.

    2. You are right human element is above all but if things are not managed in a systematic manner there is no record to defend the work done.

  2. Really an interesting blog I have gone through. There are excellent details you posted here. Sometime it is not so easy to design and develop a Agile Methodology for imrpove productivity without custom knowledge; here you need proper development skill and experience. However the details you mention here would be very much helpful for the beginner.

    Know more here: Agile Methodology


Comments on this blog are moderated and we do not accept comments that have links to other websites.