All startups have some element of risk and never more so when you have an idea, but no technical co-founder. Atlas is a bespoke software development company that has acted as that missing technical co-founder for startups in the past and here are our insights on how startups can reduce software project risk if they approach a software development company to be their technical co-founder.
Atlas have been in business for over 10-years and in that time, we have discovered what does and doesn’t work to reduce the risk of software projects failing. We personally favour the agile methodology for bespoke software development and we will explain why, however it’s important to understand that an agile approach to software development can, in some instances, highlight project management issues, but it doesn’t resolve them.
Before diving in to advocate agile software development, let’s first review the traditional method of software development, commonly requested by most of Atlas’ customers – The Waterfall Model.
The waterfall model is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance. It originated in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Because it was created in a time when no formal software development methodologies existed, this hardware-oriented model was simply adapted for software development.
The waterfall model for all its flaws has been used successfully across a range of industries including the military, space development and healthcare. Such industries are tightly controlled, regulated environments where decisions are made by experts and peoples’ lives depend on decisions being right first time. There isn’t any room for,
Whoops, that didn’t work – hide the bodies and let’s try this another way.
This figure provides a visual representation of the waterfall model. You will instantly notice that it’s impossible to return to the start once the software development process begins, and herein lies the ultimate problem with waterfall. Many of the application development projects undertaken this year and next will be started, and funded, by people who do not understand the complexities involved in writing software and do not know all their software requirements upfront. No matter how many software requirements gathering techniques we have tried at Atlas to extract comprehensive software requirements from our customers, if the product owner doesn’t know what they don’t know, they cannot provide the correct information. This is not their fault, it’s unfortunately just a fact.
Now let’s imagine for a moment that the software development team ignores the above issues because the customer is waving a fist full of dollars at them. They gather the incomplete software requirements as best they can and hurl themselves down the waterfall (model) using a functional specification the size of the complete Encyclopedia Britannica as a floatation device. The customer is stood by the waterfall (model) watching and he’s hyped. He’s positive that between himself and the software development team, they’ve nailed down all the requirements and then BOOM, they hit the bottom of the waterfall (model) and begin to drown. Turns out the functional specification had holes in it, and no amount of paddling or bailing water is going to help. Furthermore, the customer has seen a preview of the application and they have a bunch of last minute changes they wish to make.
With the pressure of a fixed deadline, and fixed budget too, the software development team now find themselves having to paddle and bail harder to meet the deadline. They produce a sub-optimal application that exactly meets the customer’s specification, but could have been so much better if only a more iterative approach had been taken.
So this brings us to the agile methodology as shown in figure. Do you think agile is the way forward? Well agile is equally as dangerous if not carried out properly, and certainly isn’t a solution to all the problems outlined here. To work properly agile still requires an overall plan, and plans for each iteration must still be laid down before software development begins. An agile development methodology does ensure that software development is a collaboration effort and shares the risk across both parties more evenly. In other words, the software development team may still hurl themselves down the river, but in this instance the customer is in the boat helping to paddle and bail out water. It’s all about collaboration.
Atlas transitioned the majority of our projects from the waterfall method to the agile methodology back in 2011 and we intend to ensure that where possible we only use agile going forward. Here’s our best tips and tricks that we’ve used to ensure that all of our software projects regardless of size and risk stand the best chance of being delivered on time and on budget:
With or without agile the above tips and tricks have saved us 1000’s of hours of wasted software development time. We hope they can do the same for you.