Striking the right balance between innovation and risk when developing software products can signal the difference between success and failure. It may seem counterintuitive, but at the same time they mitigate risk with effective software development risk strategies, product leaders can also avoid risks with software development innovation.

Lacking Innovation While Managing the Wrong Risks

One of the best-known examples of poor risk management and lack of innovation comes from outside of the software development world. Harvard Business Review highlights the organizational failures that led to the massive 2010 Deepwater Horizon oil spill in the Gulf of Mexico.

At the time, BP, the builder of Deepwater Horizon, considered itself an innovation leader. When Tony Hayward became CEO in 2007, he told BP employees that safety was his top priority. He instituted many new rules, but few were innovative. They included a ban on texting while driving and putting lids on coffee cups.

None of the rules contributed to the leadership and line worker problems that led to the Deepwater Horizon disaster. U.S. investigators following the spill concluded that management was responsible, and “individuals involved failed to identify the risks they faced and to properly evaluate, communicate, and address them.”

Fortunately, there are a variety of strategies to balance innovation and risk management that can guide your projects through to success.

Tech Debt And Other Internal Risk Management Strategies

Some risks involved in software development projects come from within organizations and teams. These internal risks can come from project delays and also cost overruns. The sources of these problems often come from scope creep, feature creep, and technical debt.

Technical debt can be intentional. With looming deadlines, you may choose to leave aspects of your project unfinished with the plan of returning to them later. However, nearly every software guide points out that technical debt can be a “black hole.” Some project advisors even call tech debt a “vicious death spiral” as a seemingly small bug can create dozens of others.

How bad can tech debt get? According to the Consortium for Information and Software Quality (CISQ), the cost of deficient software quality in the US reached $2.41 trillion in 2022.

You probably remember Southwest Airlines grounding all flights in 2023. The airline experienced a similar incident in 2022. It turned out that faulty, outdated router systems and a massive tech debt caused the failures. One development analyst commented, “Southwest’s system meltdown is an example of the detrimental consequences of technical debt going unaddressed for years, which resulted in an IT disaster and loss of customers and revenue.”

Southwest Airlines ultimately lost over $1 billion because of their software tech debt and the company has also been sued for its outdated technology.

Knowing what to fix and what can be left behind can be a delicate balance in software development risk management. However, it’s possible to decide what tech debt is smart to take on, and which things must be fixed before proceeding with a project. This is where agile methodologies and Scrum come into play.

Agile Teams, Process, and Scrum

Using agile strategies and methods, development teams shouldn’t move on to the next story until the current item truly works well. Agile focuses on preventing tech debt so that ultimate horror stories like Southwest Airlines don’t happen. The longer bugs last, the more difficult they are to fix, and ultimately, they may become unfixable, a common situation that’s costing many businesses far too much money, if CISQ’s estimates are even close to accurate.

In an agile development scenario, the product owner can focus the product’s scope so that it can be truly user-ready before moving on to the next story or feature.

It’s likely that the IT teams for Southwest Airlines were aware of the large tech debt that ultimately led to flight groundings, massive financial losses, and hundreds of thousands of angry customers. However, it seems equally likely that they didn’t have the decision-making power or means to fix the problems, assemble teams, identify tech debt, and begin to work on the problems before the whole system imploded.

They also may not have known every problem that led to ultimate failure. Identifying unforeseen issues is one of the strengths of using scrum tools and roles to manage software development.

Forming Scrum teams with ScrumMasters, product owners, and development teams works. Scrum and agile work together, but scrum focuses on continuous learning and adjustment as projects proceed. A look at a sprint cycle wheel shows how this works. The wheel includes the following essential inner segments:

  • Sprint planning –> product backlog
  • Daily scrum –> sprint backlog
  • Sprint review –> increments/demos
  • Sprint retro –> review

The continuous cycle helps teams to focus on essential activities.

Scrum sprint cycle

Image by Atlassian.

Responsive, Responsible User Feedback

Where does the end user come into the process? With a strong agile methodology and a capably-led scrum team and tactics, market research and user feedback will help you to avoid risks with software development innovation.

Using these methodologies, product leaders can build a product strategy to limit risk. Market research and user feedback are also the basis for any product innovation. Feedback and iteration are essential for effective product design. Ultimately, if you don’t understand the story that your users want to have told, it becomes extremely challenging to executive the technical steps required to tell a story at all.

If we think about the StoryBrand model and methodology, this concept means that the user should be the hero of the product’s story, not your company or brand.

Viewed in this light, stories like the Deepwater Horizon disaster and Southwest Airlines’ scheduling failures are even more tragic, and also avoidable.

Software development risk management doesn’t mean product business leaders should consider every possible source of failure, it means that they should direct their attention to the risks that matter. Products can also be developed in a more robust way from the start by using Scrum to identify tech debt and pay it off before it becomes an unmanageable problem.

Ascendle can help you to develop the product strategy that’s right for you and your team, and which provides a robust StoryBrand structure that makes your end user the hero of their own story. Schedule a call to talk with us about your product strategy today.

Share This Article