_edited.png){kind=logo}
Speed is something of a software development holy grail. Developer teams want to know how to go faster. Managers of developer teams want to know how to go faster. Customers of developer teams wish they would go faster. The vast majority of conversations that happen around software development besides the requirements of the software itself revolve around when something can get delivered and if it could possibly get delivered, sooner.
This makes a lot of sense, because nobody gets any value out of software until it is delivered. This is a primary reason agile, incremental approaches are often selected in software development these days - I'd rather have some of my working software today than all of my working software a year from now. So, speed isn't an irrelevant consideration - the rate at which valuable software gets into the hands of a consumer is a vital piece of the entire reason you have software developed in the first place.
It's not surprising, therefore, when discussions about improving the software development process revolve around increasing speed. I would argue, though, that asking how to increase delivery speed is not the right question.
It's sort of like a board of directors getting together for a strategic meeting and someone asking the question, "How do we make more money?" On the one hand, that's an important goal, but on the other hand, the question is so high level that, unless you're starting up a completely new business, it's not valuable to focus on it. There are a lot of factors that roll up under the topic of how a business makes money. Instead, you would focus on the mechanisms that are involved in making money, such as, "How do we attract more subscribers in this demographic?" or, "How could our product be more useful than the competition?"
Software delivery speed is similar in that way. Software development speed depends on a lot of factors and mechanisms, and your time is better spent uncovering those and talking about those. If you can achieve improvement in some of these underlying areas, greater delivery speed will follow. This is a short list (but not comprehensive) of some areas you could examine and some questions that could help you find improvements in those areas.
Flow
How many hand-offs occur in my development process?
Is the work sufficiently broken down and moving through the process incrementally?
Is there anywhere in the process work is bunching up instead of sailing on through?
Are we adequately staffed at every point in the process to handle the capacity we want?
How much communication is there up and down the line? How could we increase that communication?
Are any of our points in the process buried under too much work or sitting around with too little?Do we fluctuate between periods of being way too busy and hardly busy at all?
How do we prioritize, escalate, and resolve impediments?
Variability
Are we getting work items down to their smallest, valuable size?
How are teams getting their assigned work?
How often do our priorities change?
How often do we change the teams working together?
How many different kinds of jobs do we expect the same team to perform?
How do we manage interruptions?
Do teams ever get competing instructions or priorities from multiple sources?
How do we know everyone is doing the most valuable activity at any given time?
Re-work
How many bugs are we finding in our software?
How much time is spent on fixes?
What are we doing earlier in the process to improve quality?
Do we have a definition of acceptable and unacceptable results, and does everyone understand it?
Learning
How long does any point in the process go without getting feedback/confirmation on what they are producing?
How do we know if a feature has produced its intended value?
On what basis do we prioritize our work?
What are we doing to allow teams to reflect and improve on their processes?
How are we verifying our return on investment?
What are the operating costs of producing software versus the value we are getting out of our software?