top of page

Four Principles About Software Development Team Speed Every Tech Leader Should Know

If you’re a tech leader looking for ways to speed up your development teams, you’re certainly not alone. What tech leader isn’t looking for ways to develop software faster without using more resources?


Software development team speed

In your role, you probably have pressure from all angles to deliver more software faster. Depending on the type of software you’re building, increasing your delivery rate could directly contribute to the bottom line or help create a competitive advantage for your organization.


However, tech managers wanting more speed out of their development teams often face pushback from those who say we should focus on value rather than speed. But know this—wanting to go faster is not wrong. In fact, going faster can be a huge help in getting feedback sooner, which is something we should be aiming for if we’re striving to deliver valuable things.


What is wrong, however, is when speed becomes the main goal. Because if you're not building the right things, then you've just increased the rate at which you deliver items with no value—and that can make the situation worse. That’s why agility and speed are two separate concepts, even though agility is often thought to be a solution to speed up teams (it’s not, but more on that in another blog post).


In this blog post, we’re laying out four key principles that will actually influence your software development team’s delivery rate and what you can do to leverage them.


Key Principle #1: The more things you have in progress, the slower each individual thing becomes


The amount of work you have in progress significantly impacts your delivery speed. The more items a team has started but not finished, the slower each item becomes. If you’re interested in the math behind this concept, we highly recommend learning about Little's Law—it describes the mathematical relationship between the number of items in progress and the time taken to complete them.


To understand how this looks in application, imagine you're tasked with two critical reports that each takes half a day to complete. If you split your time between them, switching back and forth, you'll lose time in context switching, and neither report will be done until the end of the day. However, if you focus on completing one report fully before starting the other, the first report is done by lunchtime, allowing for review and feedback while you finish the second. This is the essence of Little's Law in action. Every new item you start slows down every other item that’s in progress because now you have to divert resources to the new work items.


It’s tempting to want to start new items when stakeholders request new features and want them done as soon as possible. We want to be able to start on them so we can tell them that their projects are currently underway. But when we do that, we’re slowing down our current projects.


If you want to optimize your team for delivering value, you have to fight the instinct to start new projects for the sake of saying you’ve made progress. At the end of the day, stakeholders care about when you finish—not when you start or when there’s only some progress made.


A good way to start implementing this principle is to equalize your start and finish rate. In other words, don't start new items until existing ones are finished. This will make sure that your system isn't slowing things down by introducing new items at a rate faster than your team can actually finish them, which slows down all items.


If you’ve got your start and finish rate equalized and you want to take things to the next level you could figure out where the slowest link of the chain is and match your rate to that. Identify what stage takes the longest, whether that be because it takes a complex skillset, requires intensive work, or something else. There's no reason to start things faster than that specific segment can handle—at least not right now. After you’ve identified it and matched your rate to it, it would be a good idea to go back and focus on improving the speed of that constraint because your whole system is going to benefit from it.



Key principle #2: Put as many people as you can on the same item


Instead of spreading your team thin across multiple items, put as many people as you can on high-priority tasks to get them done faster. This principle could actually be another application of Key Principle #1. If you focus on your highest priority item, it makes sense to allocate the maximum resources to it. You don’t want to slow down your top priority just to start on lower-priority items. 


The goal is to concentrate your team’s efforts on the completion of your highest-priority task. If the item at the top of your list is the highest priority for your team, why would you not put as much firepower behind it as possible?


By allocating more people to the work item, you'll complete it faster. Once it’s finished, you can move those team members to the next priority item. This approach ensures that high-priority tasks are completed efficiently and that you’re not distributing your team’s efforts across multiple tasks, slowing down their completion.


To implement this, pair programming and mob programming are great techniques.


Pair Programming: Two developers work on the same task, taking turns typing and solving problems together. This method provides real-time code reviews and shared knowledge, ensuring that two people are intimately familiar with the feature.


Mob Programming: This takes pair programming to the next level by involving a larger group, potentially the entire dev team, to tackle a single task. This collaborative approach brings together diverse perspectives and speeds up problem-solving.


These techniques are some of the rarest that we see in organizations, which is unfortunate because it can be a huge force multiplier. Managers often hesitate to assign multiple developers to the same task, but having fewer items in progress and more people working on them results in faster delivery. If the idea of pair or mob programming is too daunting, a good starting point is to break down work items into sub-tasks and assign developers to each sub-task.


For example, a feature might have multiple components, such as a UI piece, an API endpoint, middle-tier logic, database persistence code, and various levels of automated tests. Different developers can work on these pieces simultaneously while collaborating to ensure compatibility and share knowledge.


By putting as many people as you can on the same work item, you harness the collective power of your team to push high-priority tasks across the finish line faster. This not only boosts productivity but also ensures that important tasks receive the attention they deserve.



Key Principle #3: Make work item aging a priority


When you’re thinking about who should work on which tasks, make work item aging a priority. Don't think that just because someone starts working on a work item that they have to stay on it forever. For instance, if there's an item that's been in progress for 27 days and another item that's been in progress for two, then the first question we need to ask is, “Is there anything I can do to get that 27-day item out the door?” 


Of course, the answer to that question may be “no.” It may be maxed out and that’s just as long as that work is going to take. But if there is something you could do to move it forward, then it is much more valuable for you to work on the 27-day item than to work on that two-day item. 


If you start looking at work item aging as you’re planning and allocating developers, a lot of efficiency problems are going to start vanishing on their own just because you’re paying attention to this metric.




Key Principle #4: Eliminating wait time gives you additional speed for free

How much time could you save by eliminating the time it takes for a work item to transition from one stage to another?


If you look at the life cycle of a deliverable from idea to delivery, it has to pass through several stages and, sometimes, different groups of people. As it makes these transitions, work items will spend time waiting for the next stage to pick it up.


For example, you might have a quality engineering team that receives work from your developers to test, but quality engineering is busy with something else at the moment they receive the work. That’s time that the work item will sit idle, which will count against your work item age.


In our experience working with organizations, it’s surprising how often work items spend significant amounts of days with no progress happening. If you could get rid of that wait time, you can deliver much faster—and with no additional resources! And if you haven’t noticed yet, that wait time often comes from a violation of the key principles discussed earlier in this blog. 


You want to have a system where developers are ready to go as soon as that work is ready to be worked on. You don't want a system where each link in the chain has its own mini backlog of things backing up because work items are coming in faster than they’re able to be completed.


Wait time could be for all kinds of reasons. But whatever it is, find it and address it. Because if you do, you will get an incredible increase in delivery. 


Conclusion


The drive to speed up your development teams is a constant challenge with pressure coming from all angles. Even though wanting to be faster can get a bad rap, speed is an important factor in software development in order to react quickly and create a competitive edge. But that need for speed must be balanced with the quality and value of what’s being delivered.


We hope the key principles in this blog help paint the picture of how you can speed up your team while keeping quality (and morale) high. Remember that the goal is not just to deliver more quickly but to deliver the right things quickly. By harnessing these principles, you can create a development environment where speed and quality coexist, driving your organization toward greater success.

Comments


Commenting has been turned off.
bottom of page