Let’s talk about increasing your software delivery speed, which means productivity.
We’re just now getting into productivity, but for a significant reason. With quality problems, it diverted our team to diagnosing and fixing those bugs rather than working on fresh changes and features. Stability problems divert our team’s attention from updates, as the production environment is a priority.
Even with dedicated systems engineers, they typically can only operate a stable system for high-scale systems. Constant changes to the number of servers or cloud CPUs or Kubernetes pods based on the load are normal. And it’s normal to watch the queue length as data flows to be sure that the messages are being processed within the established SLAs.
But when errors are happening and when the system is not behaving, then those issues are just escalated back up to the software team. And this is where development capacity leans on the power of prioritizing quality and stability.
The result of prioritizing quality and stability is that 100% of your team’s capacity goes toward delivering new functionalities. After achieving this, we can look at what causes the team’s software delivery speed; now the team can work on new software changes.
The First Step to Master Your Software Delivery Speed
From an oversight perspective, I like to paint a picture of how to think about your team’s productivity or throughput or pace. So, let’s take an analogy of the Baja 1000 desert race. To do well in this race you need to pick a pace that will not cause your drivers or your machine to expire to break down. And then you need to navigate it well.
If your drivers get lost or go off course, they may drive many more miles than necessary and run out of fuel. So, picking a good course and staying on that course shortens the miles necessary to finish the race. And an obstacle may emerge (and likely will emerge) that leads to change. The driver changes the course they’re traveling on because of new information that they learned while driving. And finally, the drivers must drive fast along the chosen route.
Now let’s apply this analogy to the software team. The team alignment template has given us a tool to ensure everyone is clear on where we’re going – what business outcome we want to achieve. This is the finish line. “Feature A” or “feature B” is not a finish line.
Any individual feature is akin to a particular route on the racecourse. And we’re choosing “feature A” because we reasonably believe that changing the software in this way will push us towards our goal. But as we move along, we need to watch out for new information that will help us learn. That may mean “feature A” might not be the progress toward our goal we hoped it would be.
How Executives Lead for Software Delivery Speed
Let’s take a break and address a misconception that our industry heavily promotes. I’m referring to the product owner. According to the Scrum curriculum, the product owner is the only one who knows the customer well enough to prioritize the backlog correctly. These features are deemed to be the right software changes to make as the product owner has prioritized them according to the Scrum curriculum. Few teams have been able to find a person with that good of customer knowledge that the role of product owner hasn’t worked for our industry.
The 2018 state of DevOps report by Puppet Labs shared a study that teams using product owners had a batting average of about 0.333. They achieved the desired outcome only once in every three attempts when the teams implemented the changes.
What’s interesting is that another 1/3 of the time the change put into production yielded no progress towards the desired business aim. And the final 1/3 of the changes hurt the performance of the software and moved the business away from its objective. Hurriedly backing out these changes was necessary because they were causing harm.
As an executive, don’t rely on anyone to be so prescient that you trust them implicitly to decide what changes to prioritize. Instead, think about it like any other department in the company. Measure the result and adjust based on the actual data that you collect. And this is another reason for prioritizing stability ahead of moving faster. We can use stability practices in feature analysis to achieve the desired results.
Measuring Your Software Delivery Speed
Now that we have a good mental model for how to increase your software delivery speed towards the goal, we need to measure the current speed.
You’ll want to add more measures to the team scorecard. Add weekly numbers that represent progress towards the software’s business purpose. For example, if it is an ecommerce system, you may add daily revenue. In inventory systems, you can include numbers that appear on executive team scorecards for inventory and warehousing.
This gives your software team ownership of targets that other executives understand are important for the business. They can take part more fully in improving those business measures.
As far as software specific measures on the scorecard, I suggest these as a minimum:
- desired number of issues delivered per week
- current number of issues that are being delivered this week
- average time an issue spends in each of the statuses
Okay, that’s progress!
If you’re just starting this type of measurement, you might not know what target to set for the desired number of issues delivered per week. That’s fine. Defer that until you’ve measured actuals for about a month.
Good Measurements Depend on Commonality
An important principle on which these measures are dependent is commonality. I’ll give you an example. The shipping industry can deliver any size or shape of object to a destination. There are envelopes, small boxes, long tubes, pallets, and more. There are no two features that are the same in software either.
But the shipping industry has figured out how to send ships with a bunch of uniform shipping containers. They have packaging standards. So, at the ship level, they don’t care what size the packages are.
In previous decades, and still today, software teams have attempted to treat every application as unique. They are searching for methods to estimate and get reliable numbers to determine the amount of backlog work. But no method of estimation today has succeeded, and it always hurts software delivery speed.
The “Single Day” Unit of Measurement
Other departments know that the work needs to be made common a size to empower the team to shine and deliver at an increased rate; known as “work breakdown structure.” Feature decomposition is necessary for software development. Breaking down units of work into smaller tasks is widely used to make work more approachable, as well as manageable.
So, guide the team to break down software changes into tasks that they can reasonably complete in one day of effort. For some features, you’re going to be challenging the intended design to accomplish this. The result will be development tasks that are all roughly one day of work in the size of labor.
With a common sized unit of work, you can measure the throughput of your team. But measuring throughput isn’t the only reason for doing this. Large software changes that are not broken down are typically where other problems exist. Faulty analysis, undefined architecture, incorrect assumptions, and undiscovered unknowns.
Breaking down development work ends up exposing those hidden problems and further increases the quality of what they deliver. It forces more design work upstream of the coding activity because design decisions will have to be made before the initial coding begins. When writing code on a feature that’s already too large, it mixes misanalysis and design conversations right in the middle of unfinished code.
If the developer finds a question without an answer, they must stop work and have unplanned meetings. This stops progress on those features because these pieces are blocked.
You can safely assume that a feature or change that is expected to take several days to complete will not take several days. It’ll take two times or five times that or 10 times longer than that. The several days estimate is an estimate of no confidence. You can only be sure that they have identified and understood all the work when you estimate they can complete it in a single day.
Do you want to empower your software team
to be effective:
moving fast with high quality?
Minimum Practices to Increase Your Software Delivery Speed
In this process, you’ll see more detailed design diagrams since more knowledge will flow throughout the team. And as you increase the team’s software delivery speed, here are some minimum practices to implement:
- kanban style work tracking board
- feature decomposition, or work breakdown structure
- design diagrams for everything
- refactoring
The last item on the list, refactoring, is a mature practice. You can find some good books on this practice. Refactoring recognizes that since we’re going to learn from how our users use the software, we need to expect more changes based on that learning. It is our method for making those changes.
We’re going to learn that once in production, we should have designed a feature to behave differently. Refactoring is the practice by which we change the software so that the feature becomes designed in a new way, as if we had been designing it that way from the start.
And here’s a suggested question to ask when you learn something new from users in production. Since we need to change this feature, what other parts need to change so that the outcome is as if we had intended to design it this way from the start?
Refactoring ensures that the code is always easy to understand immediately. And as you measure your team each week, look for the current number of issues delivered each week to increase. When using a Kanban board, you might see bottlenecks in areas where items are taking longer in certain stages. And when bottlenecks are discovered, you’ll resolve them. The lack of tracking time per status, if you don’t do it now, is what allows bottlenecks to stay hidden.
Taking Command of Your Software Delivery Speed
With all this, you have a very strong oversight position and responsibility for your software team. It’ll be important to keep quality, stability, and speed in the proper order.
Schedule pressures can tempt teams to forget about this order and allow quality and stability to slip by taking shortcuts. But it doesn’t take long for shortcuts to accumulate, resulting again in poor delivery speed.
Whenever production issues happen, reinforce to the team the importance of acting so that this kind of bug or issue can never happen again. It’s not just about the team trying harder or gritting their teeth tighter. This is about real cause analysis and solving the problem at the root.
