Maximizing Innovation While Minimizing Costs in Software Organizations

By Tamara Moona and Darryl Snow

Before you start reading, think to yourself:

How many people are in a typical software delivery team in your organization? How are you measuring their productivity today? How much visibility do you have on the processes required to get software into production? What are some of the things that incur the most cost when developing software in your organization?

The Ministry of Manpower in Singapore released an estimate that the number of retrenchments in 2023 more than doubled, due in part to the impact of global economic headwinds. In times of economic uncertainty, when interest rates are high, and when organizations are trying to normalize and re-adjust post-pandemic, we see precautionary cost-cutting and conservative investments in areas like work culture and productivity for software teams.

But are companies actually learning to operate more efficiently? Which costs can be effectively managed, reduced or even avoided? What are the largest contributors to cost and what can we do about them in the short, medium, and long term?

Software Organization Cost Drivers

We can broadly categorize the main cost drivers as:

• People: the number of individuals who are allocated to product teams for periods of time, along with the cost to hire, train, and retain those individuals
• Process: the tools, workflows, and governance involved in planning, building, and releasing software
• Operations: the platforms, infrastructure, licensing and support needed to keep the software running smoothly

When we surveyed CTOs and asked them which were the top cost drivers keeping up them up night, we learned that 85% of the costs they incur are driven by:

• People: The number of people per team

• Process: Delays in designing, building, and testing
• Operations: Delays resulting from approvals and release processes, managing and fixing bugs, and managing technical debt

Maintaining a Focus on Value

We can think of ways we might address these cost drivers – staff redundancies being one tactic we’ve seen in the tech industry recently. But we should care about costs in relation to value, and recognize the trade-offs. This is how we define value for a software delivery organization:

• Delivering business and product outcomes (not outputs)
• Solving end-consumer problems and needs
• Doing the right things instead of all of the things
• Enabling consistent and sustainable quality over time
• Maintaining a culture of learning, experimentation and innovation

In this article, we’re going to share some of the ways we’ve seen, in our 20+ years of experience, organizations successfully reduce costs in those priority areas while still delivering value.

Reducing People Costs

We typically see organizations with software teams of 9-10 people – Project Managers, Scrum Masters, Business Analysts, UI Designers, UX Designers, Architects, Front-End Engineers, Back-End Engineers, QA Testers, etc. – and sometimes far more! We also frequently encounter teams working on multiple projects simultaneously, especially those individuals in non-engineering roles like Design and QA.

The impact of having large teams, in often siloed functions, working on multiple projects at the same time is threefold:

1) Productivity Impact

When it comes to software teams, size does matter! We’ve known this since 1972 when Steiner published a study about the relationship between group size and productivity, indicating that productivity peaks at a group size of 5 individuals, and declines for larger groups. Essentially, the larger the group the more we face:

• Coordination losses, as alignment becomes harder
• Motivation losses where individuals start to give less than 100% due to “social loafing”.
• Unclear or diluted ownership of overall success

According to Brooks’ Law, adding more people late in the project only makes the project later. Conversely too few people on a team can result in capacity issues – not enough people to sustain a consistent pace of delivery.

We recommend a size of 4-6 individuals on a software team to optimize for productivity and more effective interactions.

2) Communication Impact

The more people on the team, the number of communication channels to negotiate increases – for a team of 3 people there are 3 handshakes, but add one more person and the number of handshakes becomes 6! For a team of 10 there are 45 handshakes!

Decision making and collaboration becomes slower and there’s a greater risk of information silos forming.

3) Focus Impact

According to the book Quality Software Management: Systems Thinking (1991), the author presents evidence that with each additional project an individual is given responsibility for incurs a 20% loss in focus time due to context switching. On top of that is the effort spent on hand-offs, documentation, and knowledge transfer, all of which represents a distraction and a divergence from the work to deliver value.

Building Skills Enables Leaner Teams

We’ve established that small teams of 4-6 individuals is ideal, but that doesn’t mean you can just cut half the team and get instant uplift. You still need to be able to deliver the value, which means the smaller team needs the skills and capabilities to do that themselves.

In a McKinsey study, 87% of leaders acknowledged skill gaps in their workforces, yet less than half had no plan to bridge the gap.

"A jack of all trades is a master of none, but oftentimes better than a master of one." – William Shakespeare

It’s certainly valuable to have deep expertise in one core skill, but it might not be the only skill a team needs. We’ve seen tremendous success resulting from building T-shaped skills in the teams we’ve led.

A T-shaped skill set is represented by an individual with deep and specialized skills in one or more narrow crafts in addition to broad interpersonal and soft skills that allow them to work effectively in multidisciplinary teams and adapt to changing situations and contexts. It doesn’t mean that someone has to be an expert at everything but just good enough to be able to add value.

As leaders in software organizations, we should reward, encourage, and incentivize growth in both specialist skills as well as broad skill areas that our teams need. If a team has clear outcomes to achieve, then this approach can enable them to be successful even with fewer individuals because they can effectively problem solve not only within their own disciplines but also across functions. These high-performers can boost an organization’s overall productivity and create resiliency in times of uncertainty.

Right-Sizing a Software Team at an Insurance Company

A large insurance provider in the Asia Pacific region came to us with a hypothesis that they could do more with fewer people. Their typical team size was around 8-10 individuals who were allocated to 2 projects simultaneously.?

We identified a few team members who were open to work in a new way – A Product Manager, a part-time Product Designer, and 2 Engineers. That’s 3.5 individuals instead of 8. The product we were working on was high-value, user-facing, and complex with several external integrations, so the stakes were high! Our role was to coach and enable those individuals to be able to deliver the desired value themselves.

Through building something real, we were able to level up their specialist skills (depth) and cross-functional skills (breadth) since they worked both within their craft areas as well as collaboratively as a cross-functional team to deliver a valuable outcome. As a result, we were able to deliver to production faster than expected, even with a smaller team.

This represented a 44% reduction in people costs. And it didn’t stop there – that smaller team is now able to sustain this delivery momentum and a lower ongoing cost.

In the case of this insurance company, they opted to take this approach to upskill the people they do have to increase productivity and value delivery rather than make anybody redundant.

Reducing the Cost of Delivery Time

Even with a smaller team, if they’re working for a longer time to deliver the value, then it’s going to cost more.

Consider the overall process that gets us from an idea through to working software in the hands of users. This is the software value stream, and it’s one big feedback loop. Whether using some agile delivery framework or not, you will likely recognize this sequence of phases:

Plan > Design > Develop > Test > Deploy > Release

If we expand this high-level process there are actually many many steps, each of which takes time to process – e.g. how long it might take to complete a feature, test something, or fix a bug –?and many of which might have a lead time before it can start – for example, waiting for someone to become available to review and approve something. We’ve seen organizations with value streams that involve more than 50 steps and take anywhere from a few months to a few years!

The impacts of a long-duration value stream are:

• Risk builds up as we’re not getting feedback from users. We may have invested a lot of money and expended all that effort building software that users don’t actually want or need.
• Opportunity cost if a competitor beats you to exploiting this business opportunity (a McKinsey study reports that, on average, companies lose 33% of after-tax profit when they ship products six months late).
• Increased people cost as additional time and effort is needed for communication, handoffs, documentation, and context switching.
• Idle time – delays between steps – is time that you’re paying for people to wait, when they may not be doing valuable work…
• Cascading delays as each single delay impacts downstream plans.

When we facilitated a Value Stream Mapping activity with one customer, we learned their overall lead time to value was 37 weeks, but the majority of that time was spent waiting for things to happen and a significant proportion of the time was also spent on non-value adding processes. That’s a lot of time that could have been spent on more valuable work!

Many of those steps in the value stream might be completely out of your control – e.g. highly regulated industry like finance – dealing with compliance and regulators. When some of those delays are not within your control, it’s especially important to focus on minimizing or eliminating altogether those that are, which are typically the earlier phases.

The Bulk of delays in the earlier phases of the value stream come from:

• Trying to build too much stuff: building a lot of things that aren’t needed right away. Teams often go straight into planning features and it’s easy to get carried away. Those features might not solve a real problem that we know the end user has, or might not be the best solution for that problem, so going ahead and building them could be a waste of effort that incurs delays. When teams have a big list of things they want to get built, they have a tendency to want to release all of them, or delay releasing until they’re all done. Sometimes, just knowing that the release phase is going to take so much effort in reviews approvals that you may as well just try to build everything so you only have to go through that painful part of the process one time.
• Inefficient communication & decision-making: the way we plan, communicate, document, and collaborate can have an impact as well. Any misunderstanding or misalignment can lead to wasted effort or rework.

Applying Agile Principles Enables Faster Delivery

Software teams need to be able to shorten feedback loops between themselves and their end users. Some of the practices we’ve applied to successfully reduce delivery time are:

• User-Centered Design: lean ways to test assumptions with end users directly to reduce the chance of building things they don’t need.
• Lean Planning: prioritizing and planning the smallest possible releasable chunk of value and, critically, measuring the impact on users. Each small chunk should teach us something (otherwise, there’s not much difference from just delivering 100 of those chunks all at once).
• Lean Governance: mechanisms to align on strategy, present data, and make quick decisions within the team and between the team and its stakeholders and investors.
• Automation: tools can help us to automate testing and deployment processes.

Releasing in Half the Time at a Healthcare Provider

A healthcare customer in our region estimated a piece of work would take 12 months based on the features they thought they needed and their existing delivery process.

We took those parts within our control and really tried to optimize them, without even touching the release process. We explored user needs, we tested prototypes before we built anything, and we planned short iterations, releasing something that works to a small portion of users in just 6 months. We didn’t deliver all the features they thought they needed, but we did deliver the outcomes they wanted. From there, the team was equipped with the agile practices to rapidly continue scaling the product and its features for more and more users without delays.

Reducing the Cost of Bugs amp; Tech Debt

Numerous industry reports (e.g. Boehm and Basili 1981, IBM 2002) and studies have corroborated the correlation between late defect detection and increased costs, and these costs compound exponentially over time ! The later you find bugs (i.e. software that was working as expected but no longer is), the more costly it is to deal with them. There’s the overhead to report and triage bugs and create and manage tickets. Engineers tasked with fixing a bug will have to context switch to work on something that may not be fresh in their mind or may even be unfamiliar to them if someone else wrote the code. Then there’s reputation cost if it’s customers finding the bugs! And how long does it take to fix a bug anyway? As long as it takes! Managing bugs just makes it more difficult to plan, prioritize, and deliver the value-adding features your software needs.

The impact of technical debt can be a lot harder to measure, and may only become visible after some time. We think of it as:

• Delayed maintenance: it’s like a house with a hole in the roof – on wet days it’s too wet to work, and on sunny days it just doesn’t feel like a problem! Deferring software maintenance tasks like refactoring code or addressing architectural shortcomings can result in reduced system stability, increased bug occurrences, and slower development velocity over time.
• Short-term solutions with long-term consequences: Choosing quick fixes or bypassing proper design and implementation practices might be the right thing to do sometimes – when rushing towards a deadline, for example, but it may lead to code complexity, decreased maintainability, and higher costs of future development efforts.

The impact of bugs and technical debt is magnified for organizations that partially or fully outsource their software development because they have even less visibility on the impact of the debt as it accumulates. And that’s in addition to what they’re paying for those ongoing vendor contracts!

It’s important to recognize at this point that we’re not actually talking about cost savings here! We should not see bugs and technical debt as costs that we pay down but rather curtailed capacity to deliver value. In other words, time spent managing and fixing bugs is actually time not spent delivering valuable features – that’s the real cost.

Extreme Programming Practices Increase Capacity to Deliver Value

We’ve been able to help teams we’ve worked with make significant savings by adopting discipline in two practices in particular:

• Test-Driven Development: writing just enough code to make tests pass and then refactoring enables us to catch bugs straight away. It involves ongoing refactoring and encourages us to write only the code we need, inhibiting the accumulation of certain kinds of technical debt. Furthermore, the tests serve as documentation for other engineers to more easily understand how it’s supposed to work, which reduces the impact of context switching.
• Continuous Integration and Continuous Deployment: this also gives us fast feedback and alerts us to anything not working as expected in every environment every time we deploy.
• Pair Programming: sharing context and ownership over the entire codebase as well as producing cleaner code that others can more easily understand further limits the cost of context switching and bug fixing while helping to identify sources of technical debt.

Compounding Value Delivery at an Airline

We worked with a team who were rebuilding the airline’s website, the primary sales channel for the company. The team would typically deploy new features once per month and their backlog was around 35% bugs. We co-delivered part of the website redevelopment with them, enabling the team with these Extreme Programming practices. During our engagement, the portion of their backlog that contained bugs went down to 0% and they were able to deploy around 6 times per month. That represents around 57 hours per engineer per month working on value-adding features instead of managing bugs – a huge saving! Furthermore, the team has managed to sustain these practices and continue to see those savings even years later, with a consistently high deployment frequency and a stable lead time that serves as a good indicator of well-managed technical debt. They’re seeing compounding results.

Conclusion

There are lots of factors that can drive up software delivery costs and how we address them has to be done strategically with a longer time horizon in mind. Here is how we recommend to get started:

1. Assess and measure your current state
2. Identify the priority cost drivers to be addressed
3. Intentionally invest in building the skills you need to enable leaner teams
4. Prioritize for value delivery & start small in applying agile principles and practices (focus on what you can easily control)
5. Experiment, measure & repeat