So you have a great idea, something that you really believe will make a difference out there, and now you want to get it built. Getting a business or product from idea to reality can often be a frustrating experience, especially because you have to put large sums of money down early on to just get going. This is why we have adopted the agile development methodology as the best way to build custom web and mobile applications.

At the core of agile development, the main objective is to deliver value (the smallest possible amount) as early as possible to validate that concept before spending large amounts of time and money on it. There are 3 main reasons for this which will now be covered.

Why agile development?

1. Assumptions

It’s very rare for any business to fully understand the problem they are trying to solve and thus many assumptions are made about the extent of the problem, how eager people are willing to have that problem solved and how people want the problem solved.

In the past, all the requirements for a system would be sent out by a product owner (a role we will discuss in a later post) which express all his or her wants. As a fitness enthusiast, I can give an example of what I would want in a home gym.

I would want a barbell with lots of weight plates, a rack to put them on, a pull-up bar, a bench, kettlebells, dumbbells, weighted vests, skipping ropes, gymnastic rings, a squat stand, a jumping box, a rowing machine, an air bike – the list could go on. Now if I were to send this to a gym equipment salesperson, they would probably start booking tickets for an extravagant overseas trip. The reality is, however, that I wouldn’t need all that equipment to start with and buying it bit by bit as I improve my training would make it both more cost-effective and measured. I am assuming I need all that equipment and I would most likely also assume how much I need of each item as well (I’d order 400kg of weight plates when I can only lift 150kg at any one point).

Just like my dream garage gym, assumptions like this are made within any project and although we have to assume some things (to actually get going), we want to try and mitigate the cost and time that it takes to validate each assumption (it would be better and cheaper for me to buy 100kg worth of weight and realise I need a little more rather than buy 400kg worth of weight and lose money or time trying to return some of it).
This is one of the most important aspects of agile development and it’s exactly why we’ve adopted it at Flicker Leap. We want to take ideas that businesses have and implement parts of it as early as possible so that we can start getting in real-world data as soon as possible.

Assumptions will need to be made (especially early on), but you’re going to want to limit how much the assumption will cost you, if it costs at all.

2. Over investing

Over investing in a project is often directly related to incorrect assumptions, although it can also be down to timing and immediate need. Steve Jobs spoke about devices you carry around to play music on way before they ever came about. A lot of people laughed and scoffed at the thought, but years later it became the pioneering product of the Apple we know today.

Just like my weight plate problem, custom development projects run the risk of putting way too much money into something that isn’t ready to be consumed by the end user. We can say this because in the past we have built many a project based on assumptions (we also assumed that it was what the client needed). But they ended with functionality that was never used, which is actually dreadful for a development team who put blood, sweat and sometimes tears into making that functionality work.

The reason why all of our clients have decided to move to agile is that they’re not throwing money at a massive project full of assumptions. They’re investing in something they know will make a difference and getting return almost immediately (getting a return isn’t always the case, but it is more often than not).

3. Massive project timelines

The last reason is that massive scoped projects have both a massive timeline and a massive bill that comes with it. If I got my home gym equipment quote I would quickly realise that I would have to save quite a bit before I could pay for it, which means a whole lot of time wasted. More importantly, if all that equipment wasn’t in stock or had to be made, I would be waiting a very long time until I receive the order and can actually start training. Let me summarise that: I would have to wait until I had the budget and then I would have to wait to receive what I ordered.

This would be the same for any business wanting to get custom development done in the old methodology known as the waterfall approach. A general waterfall-based project would look like this:

• The product owner creates a specification document for the idea.
• They send it to a development company to give them you a quote.
• The development company asks one hundred questions and, if they’re good, they ask for a specification session to clarify as much as possible.
• The development company then sends back an updated specification document with a technical breakdown, a timeline for the project (sometimes split into phases) and a generally large price tag.
• The product owner falls off his/her chair.
• The product owner gets back on his/her chair and contacts the development company to understand why the cost is so high and why they would only see their idea in three months time.
• The development company explains as best they can and offers a discount (ultimately shooting themselves in the foot, which means they’ll probably take shortcuts).
• Finally, everyone agrees and the project commences.
• The product owner pays a large amount of money to get the project going.
• The development company develops according to the specification document, following it religiously to make sure the product owner gets what they paid for (no more and no less).
• The product owner gets anxious as he/she hasn’t seen any sort of return on the money they have put down.
• The development company finally gives the product owner a preview of the application which isn’t completely finished (because they’re building it to the full spec).
• The product owner isn’t completely happy because the design or specific important functionality was saved for the end (even though that is important for the product owner).
• The development company assures the product owner that everything is on track and it will be done before the live launch.
• The product owner starts to realise that some of the implemented functionality isn’t needed and the functionality that is coming later is more important right now.
• The product owner tries to change the priority of features.
• The development company reminds the product owner of the contract they signed.
• The production owner sits back and begrudgingly lets them continue.
• The development company finally shows the “final” product to the product owner.
• The product owner needs changes made because different requirements have come up in the last six months.
• The development company restarts the process leading to the next part of the project with a new specification document.
• Six months later the product owner cannot invest more and cuts his/her losses.

Both parties lose out in that scenario and it doesn’t end up in businesses growing. This is one of the things that agile development tries to solve.

To conclude, we believe that an application’s success is firmly linked to a close relationship between the product owner and the development team. It is also linked to the ability to learn and understand the real world requirements for the application based on continuous feedback. This post is the first in a series on agile development, how it looks and how you can implement it.

Feel free to give us a shout if you would like to explore the idea of working on an agile development project.