Tuning Your Process for High Velocity Software Development

Velocity is an important metric for many software professionals. In a recent Forrester survey, 38 percent of the respondents reported that they use the number of user story points completed per sprint as a measure of agile effectiveness. Market forces can be brutal, and when competition is fierce, the innovators who move at speed win. Many of our clients face that type of competition, and for them, velocity in software development matters. One of these clients is a media company in a competitive market that wanted to innovate quickly. We needed to deliver a substantial amount of work in only a few months.

By John Jenson

Early in my career I learned that every project has three opposing aspects: Speed, quality, and cost, and when running a project, you can only achieve two of the three. Our velocity was already pretty good, but the client needed us to go even faster, while maintaining high quality within our existing budget.

Pushing the Velocity Envelope

Additional investment does not always help projects hit their critical dates. Even with an unlimited budget, there is still a point when adding more people to a project doesn’t make it go faster. In fact, adding more people to a project can actually backfire and do the opposite. Fred Brooks discusses this idea at length in The Mythical Man-Month. His ideas resonate with me. In my experience, onboarding new members initially adds more drag than thrust.

In our project, we considered adding more team members to achieve our objectives and accelerate software development, but we weren’t confident that we would realize contributions of a new developer quickly enough to give us a net benefit. Rather, we needed to find ways to enable our current developers to work more efficiently.

We turned our attention where we were spending our time. When we dissected it, we noted four specific sources of time expenditure that didn’t add directly to our production, and we set out determine if we could find new ways to avoid undesirable time losses in each area. In this blog, I’ll provide a quick snapshot of each area, and in subsequent points, I’ll drill down and provide examples from our project that might help other developers increase velocity.

Mental Context Switches

Meetings

Knowledge Sharing

Code Reviews

Reduce the Mental Context Switches

We are all familiar with mental context switches, which often come in the form of interruptions or distractions. While not all distractions are bad, many interruptions can be prevented and are within our control to do so. We set out to reduce mental context switches by first looking to reduce overall meetings. We also found more nuanced ways of minimizing the context switches by allowing developers to specialize, and changing the way that we did code reviews. My next post will go into more detail on this topic.

Optimize and Combine Meetings

Most organizations struggle with excessive meetings, and although our meeting lineup was pretty optimized, we found additional opportunities to reduce length and frequency as well as the number of attendees. This helped reduce time loss without giving up anything in return. We deviated from the typical scrum meeting cadence by combining meetings where the information and related discussion didn’t need to be separate. We also sent only one developer to do story grooming and estimating, and only holding retros when needed. The result? Optimizing meetings further led to a savings of 52 developer hours per sprint. More on that in my third post.

Embrace Specialization

Although knowledge sharing is vital to the long-term success of a project, we realized that while we were heavily steeped in the build phase of our project, it was most efficient to let developers specialize in their respective areas of the application. By specializing, less developers were required to know about each specific area of the app, and less time was spent explaining concepts repeatedly to developers who didn’t necessarily need to know about every area of the app. This specialization gave us another velocity boost, and for the purposes of our project, it made a lot of sense. Specialization enabled us to attribute a 15% increase in velocity to it. In my fourth post, I’ll go into more detail about why specialization increases velocity.

Use Code Reviews More Strategically

Code reviews have great benefits. They promote knowledge sharing, give multiple people a chance to add their perspectives on a piece of code, and ultimately, help promote quality. One thing I’ve noticed, however, is that all of these benefits come at a cost. And not just a small cost, but a significant one. We started the project with a mandatory code review process that required approval from two people. We eventually reduced this to single approval, and in the end, we removed the mandate. We let developers judge when a code review was needed and when it was not. You might think that our code quality tanked, but it didn’t. In my last post, I will explain the changes that we made to code reviews, and how it gave us another 15% increase in velocity.

Results

Each of the optimizations above added a little to the velocity – 15% here and 15% there. When you put them all together, those optimizations add up. We were able to take our team’s average velocity from 111 points per sprint to 155 points per sprint! That is a 40% increase! In addition to thrilling our client, our team members were happier because they loved seeing things get done and being productive.

If you feel like your team should be capable of getting more done than they are producing, you are probably right. The optimizations that I suggest in my next four posts might be a great way for you to get to the higher velocity that you are looking for.

Reach out to me at john.jenson@genpact.digital with questions or comments.

Velocity is a top metric in Agile. According to Forrester, 38 percent of survey respondents look at increases in the number of user story points as a measure of agile effectiveness. In a climate where market forces are often brutal, innovators who move at speed win. Many of our clients face significant competition from existing entrants.

By John Jenson

It is becoming more critical to increase velocity to head off these challenges. One of my clients is a B2C company that faced heavy competition from other providers and needed to add on-demand streaming to stay competitive. The strategy required us to deliver a large amount of work in an incredibly short period of time. The client needed to increase velocity, and traditional approaches were falling short.

Early in my career I learned that every project has three opposing aspects: Speed, quality, and cost, and when running a project, you can only achieve two of the three. Our velocity was already pretty good, but the client needed us to go even faster, while maintaining high quality within our existing budget.

Pushing the Velocity Envelope

Additional investment does not always help projects hit their critical dates. Even with an unlimited budget, there is still a point when adding more people to a project doesn’t make it go faster. In fact, adding more people to a project can actually backfire and do the opposite. Fred Brooks discusses this idea at length in The Mythical Man-Month. His ideas resonate with me. In my experience, onboarding new members initially adds more drag than thrust.

In our project, we considered adding more team members to achieve our objectives, but we weren’t confident that we would realize contributions of a new developer quickly enough to give us a net benefit. Rather, we needed to find ways to enable our current developers to work more efficiently.

We turned our attention where we were spending our time. When we dissected it, we noted four specific sources of time expenditure that didn’t add directly to our production, and we set out determine if we could find new ways to avoid undesirable time losses in each area. In this blog, I’ll provide a quick snapshot of each area, and in subsequent points, I’ll drill down and provide examples from our project that might help other developers increase velocity around software development.

Mental Context Switches

Meetings

Knowledge Sharing

Code Reviews

Reduce the Mental Context Switches

We are all familiar with mental context switches, which often come in the form of interruptions or distractions. While not all distractions are bad, many interruptions can be prevented and are within our control to do so. We set out to reduce mental context switches by first looking to reduce overall meetings. We also found more nuanced ways of minimizing the context switches by allowing developers to specialize, and changing the way that we did code reviews. My next post will go into more detail on this topic.

Optimize and Combine Meetings

Most organizations struggle with excessive meetings, and although our meeting lineup was pretty optimized, we found additional opportunities to reduce length and frequency as well as the number of attendees. This helped reduce time loss without giving up anything in return. We deviated from the typical scrum meeting cadence by combining meetings where the information and related discussion didn’t need to be separate. We also sent only one developer to do story grooming and estimating, and only holding retros when needed. The result? Optimizing meetings further led to a savings of 51 developer hours per sprint. More on that in my third post.

Embrace Specialization

Although knowledge sharing is vital to the long-term success of a project, we realized that while we were heavily steeped in the build phase of our project, it was most efficient to let developers specialize in their respective areas of the application. By specializing, less developers were required to know about each specific area of the app, and less time was spent explaining concepts repeatedly to developers who didn’t necessarily need to know about every area of the app. This specialization gave us another velocity boost, and for the purposes of our project, it made a lot of sense. Specialization enabled us to attribute a 15% increase in velocity to it. In my fourth post, I’ll go into more detail about why specialization increases velocity.

Use Code Reviews More Strategically

Code reviews have great benefits. They promote knowledge sharing, give multiple people a chance to add their perspectives on a piece of code, and ultimately, help promote quality. One thing I’ve noticed, however, is that all of these benefits come at a cost. And not just a small cost, but a significant one. We started the project with a mandatory code review process that required approval from two people. We eventually reduced this to single approval, and in the end, we removed the mandate on all code reviews. You might think that our code quality tanked, but it didn’t. In my last post, I will explain the changes that we made to code reviews, and how it gave us another 15% increase in velocity.

Results

Each of the optimizations above added a little to the velocity of their software development – 15% here and 15% there. When you put them all together, those optimizations add up. We were able to take our team’s average velocity from 111 points per sprint to 155 points per sprint! That is a 40% increase! In addition to thrilling our client, our team members were happier because they loved seeing things get done and being productive.

If you feel like your team should be capable of getting more done than they are producing, you are probably right. The optimizations that I suggest in my next three posts might be a great way for you to get to the higher velocity that you are looking for.

Interested in partnering with us?

Send a message and we will work with you to understand your needs.

Power Platform

Related Insights from Our Experts

Service Design is a hot topic in the design and business communities. Service Design is featured in blogs, books, conferences, and undergraduate/graduate school courses. It’s offered as a core service by agencies and consulting firms that consider the intersection [...]

Velocity is an important metric for many software professionals. In a recent Forrester survey, 38 percent of the respondents reported that they use the number of user story points completed per sprint as a measure of agile effectiveness. Market [...]

Many banks struggle to provide an exceptional experience across touchpoints, channels, and devices—which requires seamless connectivity from front-to-back office. Challenges like silos, fragmented data, and rigid workflows often stand in the way of opening new accounts or resolving issues.

Related Consulting Solutions

Visualize your customer’s pain points and gaps, and create the future state customer journey. We put our tried and true journey mapping methodology to work to align your organization around your customer and use our UX360 platform to help create, store and share these assets.