A success rate three times higher! That is why we at 2excel use a mindset known as Agile Methodology developing software or apps. But perhaps the term sounds a bit fluffy, complicated and long-haired? Well, chances are you will think differently after reading this blog.
It is probably no surprise that a word like “waterfall” is often used when discussing the next holiday destination. Surprisingly to most, however, is probably that it is also an integrated part of the vocabulary when talking software development.
Years ago, the Waterfall approach was considered the best when developing software, but due to its shortcomings, the Agile mindset is today often the preferred approach in software development and for good reasons.
Table of Content :
- Let the numbers do the talking
- Flexible forever
- Let’s take a few steps down the ladder of Abstraction
- Hooray and head scratching
- Tear down that wall!
- Paint it blue
Let the numbers do the talking
Compared to the Waterfall approach the Agile Mindset has a significant lower failure rate and a much higher success rate. A Project Success Rate Survey conducted by Ambysoft shows that IT projects conducted with an Agile mindset has a failure rate of 8%, a success rate of 64 %, while 28 % were challenged. Using a Waterfall approach the numbers are 18, 49 and 33.
A CHAOS report from the Standish Group shows a failure rate for Agile/Waterfall respectively of 9/29, a success rate of 42/14 and a challenged rate of 49/57.
A success rate three times as high (42/14) is one reason, why we at 2excel prefer the Agile Approach. Another reason being that we like to be and remain flexible in order to provide the best software possible for our customers.
2excel’s founder and director, Edward (Ted) Deane, explains why he prefers the agile mindset:
– Because the world is not static, neither are our customers’ requests to the software we are developing for them. Unlike the Waterfall approach an Agile mindset encourages continuous development and testing throughout the software development lifecycle of a project making it easy to incorporate changes as they arise. With this approach we are basically building software in pieces. Using the Waterfall approach, the software is only presented to the customer when it is 100% done, Deane says.
Let’s take a few steps down the ladder of Abstraction
All this might seem abstract, complicated, and hard to comprehend, but let’s make it less abstract with an example.
Imagine this scenario. After years of waiting, you are finally having your house built. Your dream house – absolutely perfect for you, your partner and with a nice spacious room for each of your two kids.
The builders have let you know that it will take three months to build the house and you can’t wait to move in. Then something lovely and exciting, but unexpected happens: You and your partner are pregnant.
Hooray and head scratching
Wonderful news, but amid the celebrations, something comes to mind: your dream house has only two rooms for the kids, leaving you one room short when the baby is born! Your dream house needs to be redesigned as you now need three rooms for the children.
And now a question with an obvious answer: Would you rather have to redesign your house two days after the crew starts building the house or a week before the house is ready for you to move into?
Tear down that wall!
Sooner rather than later of course. If the builders have just begun construction, the extra cost should be minimal whereas it can be a very costly affair if you request design changes days before the house is ready. Walls might have to be moved or torn down, architects might have to make new drawings and extra hours mean extra money for the tradies doing the changes.
Using a traditional methodology like Waterfall would equal having the changes made just before moving in. Using a Waterfall-methodology in software development means that the customer describes in as many details as possible what requirements the customer has to the software about to be developed.
A team of software developers then gets together and creates a new software to the customer’s requirements and when the software is all done, they present it to the customer.
Quite often, however, the customer’s requirements would have changed while the programmers developed the software. Having to incorporate changes at this very late stage can be quite expensive as a large part of the software might have to be re-programmed or scrapped.
Paint it blue
Had the programmers used an Agile methodology, the changes would have been made way earlier thus having cost a fraction, if anything at all, as changes are not seen as a problem, quite the opposite. Continuous development and testing are encouraged. Large projects are split up into a vast number of smaller projects that smaller teams are working on simultaneously.
On a regular basis the customer is presented with pieces of functional software having been developed since last meeting. The close and frequent customer contact means that changes in the customer’s requirements can easily and quickly be incorporated in the software.
Just like if you ask a painter to paint all the walls in your house in a blue colour. If the painter does one wall and the asks you whether the blue colour actually is what you were hoping for, the one wall can easily be repainted back to its original colour, if you don’t like it after all. If the painter only asks you after having painted every wall in the house, the blue colour better be what you were hoping for, as the cost of repainting will be significant.
The agile approach is the right choice for you if you expect your customers to request many changes to the software being developed. With the agile approach the software is being developed in many pieces and often presented to the customer making it relatively easy and cheap to incorporate changes to the software. A success rate three times as high as the Waterfall approach speaks for itself.