Let’s face it… there are a lot of risks when it comes to creating software.
There are risks of overspending, risks of missing timelines, risks of technical failures, risks of market denial, risks of competition, risks of… it goes on and on and on.
It’s no wonder that IBM research shows that fully two-thirds of all mobile software projects fail. You could even say that limiting software risk is a key factor of a successful project. For the most part, these software risks fall into three main categories:
- Building the wrong product
- Building the product wrong
- Not knowing when it will be done
Luckily, there are ways to mitigate each and every one of these risks for your software development team. And most of them start with identifying – and adhering to – the right set of processes.
Building the Wrong Product
Many companies think they already know the product that customers want.
Most of them are convinced enough to start building that product. And maybe they’re right – maybe people do want it. But at the end of the day, there’s only one true measure that matters: will people buy it or not?
With manufacturing and hardware projects, you’re kind of stuck. You need to actually make the product and get it to the market to see if it sells. Sure, you can build prototypes and gauge demand with limited runs… but that’s not always an accurate forecast. History is littered with immensely expensive, failed hardware products – see Google Glass, the HP TouchPad and the Facebook Phone for recent examples.
But with software you have a tremendous opportunity. You can build a “starter version” of the product (often called a minimum viable product) and get it into the hands of real users. This can limit software risk by reducing the time (and cost) it takes to determine if you have a winner on your hands. If not, you can go back to the drawing board and allocate your dollars and resources elsewhere. If you do have a winner, however, you can shape and grow that product based on actual user feedback, rather than what you imagine customers might want.
An Agile methodology such as Scrum permits this type of rapid, real-world testing of software products. It achieves this through short iterations, a focus on building the most important features first, and keeping the product at a shippable level of quality at all times.
Building the Product Wrong
How many times have you seen software released that everyone wants, only it falls flat because it’s unreliable? Here they had an audience eager to buy their product, but they missed the opportunity because they built it wrong. Talk about the worst possible fate for a software company!
How does this happen? And why does it seem to happen over and over and over again? It’s because many software companies “test at the end,” waiting until just before shipping to ensure everything is working. You can guess what happens next. More often than not, they realize too late their product is riddled with bugs – bugs that will take months to fix. So they throw a few bandages on the critical problems, promise some future fixes, and heave it out into the market anyway. And then they wonder why they get poor customer feedback and scathing media reviews. Go figure.
It’s easy to see how even when you do have the right product, building it wrong can still cause it to fail.
Scrum is all about limiting software risk by building software right. It’s about building quality from the very beginning and ensuring your product remains shippable at all times. During each fixed-length production cycle of 2 to 4 weeks (called a “sprint”), the product is fully tested as a part of that cycle. So every time you complete a sprint, you already know the product—including any new features completed during that sprint—is ready for the market.
Not Knowing When It Will Be Done
Software schedules are famously hard to predict. That’s why some companies admit their software estimates are little more than shots in the dark. There are so many factors, so many changing requirements, and so many “gray areas” in the middle, that it’s no wonder companies struggle to set accurate timelines, let alone allocate proper costs.
But with Scrum, you finally have the tools and techniques needed to quickly estimate your work. And, more importantly, you can predict your software schedules based on how fast the team is actually moving.
Not only that, but Scrum also relies on estimates from the engineers actually doing the work – not from business managers who want it done in a certain arbitrary timeframe. This translates into more accurate estimates for each piece of your project – which, of course, limits your software risk by giving you a clearer holistic view.
The Scrum process also relies on priorities established by the business team. If you get caught by a task taking longer than expected, and you need to make a hard deadline, you simply remove the least important features from the active list. Those features can then be reprioritized into the next product release, if desired.
This is important, because there will always be a degree of uncertainty when building software. The difference is that Scrum can limit software risk by anticipating and providing the flexibility to deal with those uncertainties.
Contrast this with the methodology of saving your quality process for the end of a project. If you haven’t performed quality tests and fixed any bugs along the way, you have no ideahow much more work remains. You could be months away from done, and you won’t even know it until you get the defect report back from your QA team. This introduces a tremendous amount of schedule risk and makes it difficult to plan, launch, and market the actual shipping of your software.
Limiting Your Software Risk With Scrum
To recap, the three greatest risks in building software are:
- Building the Wrong Product
- Building the Product Wrong
- Not Knowing When It Will Be Done
The most effective way to minimize these risks is to follow an Agile development methodology such as Scrum. Read my article Driving Business Results with Scrum to learn how Scrum can limit software risks, provide more accurate estimates, and produce better software. At Ascendle, we believe in helping start-ups and on-going concerns create and deliver world-class apps. So no matter what stage of the development process you’re in, or what set of development needs you have, we stand ready to help you. From Agile coaching (where we share all of our secrets with your development team), to doing all or part of your software development, we practice what we preach using the techniques I outlined above. Why not get in touch and see how we can help you get your app to market?
