5 ways an agile team manager can improve velocity

A common question we hear from managers and senior leaders is how they can improve the velocity of their development teams. Many agile professionals redirect that manager’s attention to attributes other than output, commonly toward value, because they assume the wrong question is being asked. I totally agree one has to examine the value a team delivers. I also agree that typical velocity metrics can be gamed to make the numbers look bigger to satisfy the boss. Fast delivery of valueless features is silly. Applying pressure to improve metrics leads to gaming metrics. However, if you trust the team and you’ve figured out what is valuable, how do we get more value faster? This is a fair question. So, I’m going to answer it. Instead of trying to go faster, remove everything that makes the team go slower.

Skill can improve velocity

Does your team have the right skills for the task at hand? Would they benefit from training or the knowledge of a consultant? It’s amazing how much quicker you are at solving problems when you have the knowledge and experience to solve them. Tread lightly here since people’s pride and ego can be quickly shattered when you suggest they don’t have the right skills. Though it’s fair to ask: “is there any training or resources we could provide to improve velocity?”

Team Dynamics can improve velocity

Look closely at the team. Do they get along? Do they even like each other? Do they have the power to make a change if they don’t like each other? Team dynamics can play a huge role in productivity. If a team has the skills, works well together, and also has chemistry they’ll produce great things. Many musical groups succeed or fail for this reason. Great bands produce a lifetime of hits. Bad chemistry, and the band can’t get past a first top 40 hit. Ask the team “do you have the right chemistry as a team to be successful?”

Better tools can improve velocity

Could tools be purchased to improve speed? Do your teams spend measurable extra time because of slow computers, servers, internet connections, etc.? This is common and often ignored. If your team spends an extra 30 seconds in team meetings every time they refresh JIRA, the team is slower, and it adds up. Every time they check in code and it takes 20 minutes for the build server to run, the team is much slower, and it really adds up. Ask them “what tools can I buy for the team to reduce unnecessary waiting to improve velocity?”

Paperwork reduction can improve velocity

I once worked in an organization where it took three days to deploy code changes to our test and/or production environments. The reason was valueless and unnecessary paperwork. The idea of the approval process was good in spirit. It was to ensure developers weren’t putting harmful code changes into production. However, no one in the approval process was looking for malicious code. They weren’t looking at the code at all. The process was there simply to ensure someone more senior than the coding developer signed off on the code before it went into production. I was horrified to learn there were no teeth behind this time-consuming policy. If you want your teams to go faster, ask them “do you have any paperwork or approval processes slowing you down that can be removed without sacrificing safety or quality and improve velocity?”

Better location can improve velocity

When individuals on the same team don’t sit near each other or even work in the same building, they rely on email, Slack, HipChat or other digital means to communicate. Information flows more slowly with text than face-to-face conversation. One of my favorite teams that I’ve worked with knew this. They had 6-foot-high cubicle walls which were in different areas of the building from each other. They decided to take over an unused area of the office and bring their laptops. They spent half-days working together as a team. They didn’t ask permission, they just did it. This creative solution improved communication, reduced delays getting vital information, and sped things up considerably. So, managers, ask your teams: “Do you spend extra time communicating with team members because they’re too far away?”

In closing

The above solutions are simple, maybe even obvious to improve velocity. And if you can’t implement all of them some improvement can still be made. As organizations grow, boat anchors get tied to the ankles of software developers. The onus to speed things up gets placed on those same developers. Look for impediments. Depending on the maturity of the team, they might not even realize they have impediments. If they’re not looking at their burn-down chart in their daily standup, they might be overlooking them. The real trick to speeding a development team up is removing everything that slows them down.