Why Using an Agile Methodology in Mobile App Development is Not Scary

 Published On February 01, 2015

This article was written for Hatching Lab. All rights reserved.

Although agile seems to be a natural fit for mobile app development, a lot of people who are new to this field always get scared by the idea of not following the traditional “documentation - design - development - testing - fixing - releasing” process, which is called the waterfall methodology. Instead, a common practice of agile methodology is working on “time-box” based phrases called “sprints”, which is typically 1 to 3 weeks, and the team will be planning a sprint ahead while working on the delivery of a list of items, which is usually based on the business value provided by customer or the experience of the team. I have my product spec ready but you’re not having a whole schedule of the release of the final product? I just want a small app done in a month and you’re going to wasting time by delivering too many releases? Wow that just sounds scary!

The waterfall methodology is there for a long time, and it does seem to be natural for software development since making schedule and doing things in a certain order seems to make sense basically for everything. But more importantly, software development was mainly something that’s involved with hundred of managers and developers working on something that costs years to develop (remember the famous “The Mythical Man-Month”?), and waterfall is always easier for the managers to make themselves to believe they are staying in control. Is it necessarily true? Just remember that large projects like ObamaCare HealthCare.gov still failed in year 2013.

Now we have mobile apps. It is common to see a famous app come from a team that is less than 10 people and gets done within 3 months, and if you’re planning to build an app as well, the waterfall methodology may seem to be a safe approach since it makes you to feel like you’ll be staying in control, too. But eventually, all you want is the right app to be done within the budget, right?

There are lot of theories to read about agile if you search the internet. Besides of those, here are the facts based on our experience in the apps we built.

Estimated time has nothing to do with agile or waterfall.

Estimating time is always hard in software development, and it has nothing to do with the methodology you’re going with. The traditional task based schedule seems to be more acceptable since it can be used well in a lot of other fields, but building an app is not like building a house, since the nature of building an app is creative work. Instead it’s more like drawing or composing. This makes time estimation kind of tricky:

  • How fast people work on creative works can vary, so it’s hard to set a certain standard, like how many icons should be drawn or how many lines of code should be written in a day.
  • The quality of creative works is hard to evaluate. It is not possible to state something like “the UI should look at least 8/10”.
  • The purpose of the app is to please the users, i.e. higher conversion, lower drops etc. and it’s not the same as to please the customer.

As a result, estimating time has nothing to do with the methodology the team is using. Waterfall wastes some time in making tasks and schedules and can’t help improving the quality of the app, while agile takes more time in making releases so it’s hard to compare which one costs more time. In our experience, agile seems to take more because we always want to do validation after a sprint to make things in the right direction, but it is going to save time eventually. For example, if we spot some steps in register process dramatically result high drop rate, we’ll be able to refine the process (be it our fault or provided by the customer) before we spend more design and development resource in it.

Things are not always going according to the plan.

Just take a look at the predictions economists made and you’ll see how hard it’s to predict human behaviour. It may sound weird, but the more experienced you’re, the less confident you’ll be to say that you can always come up with the best approach. Instead, experience helps you find the best approach in the minimal effort, until one day you’d be so experienced that you can instantly point out where the next billion dollar business is like Steve Jobs. Before that, you’ll need to perform testing and with the waterfall methodology it is impossible to do so, because you wouldn’t be able to have anything to test before the function testing begins, and by then all the design and development hours will be spent already.

This is bad especially for the people who come with a pretty detailed product spec. Normally they are so confident not because the idea is very validated, but due to the time they have dedicated in. They are so familiar with the idea and believe it is going to work, and refuse to make any chances until they finally have the beta version and started testing with external testers. Although it’s hard, after seen the actual feedback from real life users, they will have to admit that the app needs rework and new expense will be generated.

Again, if we’re not sure about some foundational design of an app, by using the agile approach it will be easier for us to test in an early stage and point the problem to the customer. Even it’s proven that the design is actually fine, we don’t really waste any time since what we did was simply implemented it earlier. Stay close with the team. —

When we are comparing between waterfall and agile, please keep it in mind that agile came long after waterfall and the main idea of the agile methodology is to solve some problems software development always has, and one of them is how to get the customer work closely with the development team. It may be a pro or a con depending on different situations, but for mobile development, we always found it to be necessary to work closely with customers.

Good business analysis helps customer to get the picture of how to form a mobile app based business, and the mobile app market itself never remains static. People are always get inspired by the new apps coming out, and by using the agile methodology, customer will be able to have the flexibility to prioritise things in a more dynamic way.

Even in a case that everything sticks to the original plan, agile is still helpful because things will be visualised in a much earlier stage. Wireframing tools help this too, but they are not as good as interactive demos since the latter is closer to the final product. It helps both way: customers gain a better vision of what’s going on, and misunderstanding from developers can be spotted in a very early stage. It may seem to be scary to change a lot of things around in an early stage of the development, but it is much better than dealing with a final product that doesn’t work.

We can avoid the downsides of agile.

Like everything in this world, the agile methodology is not perfect, although it’s a really good thing on paper. In practice, some problems are spotted by us and other people too, and it’s very important for us and our customers to overcome these.

  • Agile emphasises how important changes are in development, but emphasising this too much may lead to poor quality of the overall system design. Although agile itself doesn’t encourage understanding the whole system in an early stage, we need to always keep a good system design in mind and build the foundation of the app (both client and server side) based on our experience.
  • Again, welcome changes doesn’t mean changing the same thing back and forth meaninglessly. We’d separate positive changes with correcting mistakes, and when the “correcting mistakes” changes that results extended estimated time/sprints have to be made, we always analyse them and try to find out the best way to avoid similar mistakes both in the future of the current project and in future projects.
  • Agile emphasises the importance of working with customers, but in real life customers may be scared by the early demo of the apps, or asking for change too much which leads to too many more sprints. Generally we need to balance the work done and the time spent, and by adapting the agile methodology it’s important to share our experience with customers, too.
  • Agile doesn’t magically improve how good you actually good, but it does help us to show all our potential value. Instead of just building and delivering the app and system, we care more about making the app actually works. So even for the customers who wants to follow the traditional waterfall pattern, we can still take some advantage of agile in the wireframe - design - development phase and provide better results.
  • On LinkedIn.com, “agile” and “agile development” are 10+ times more than “waterfall” and “waterfall development”.
  • Example: Spotify - “Going Agile allows Spotify to be faster, better, and cheaper than industry Goliaths like Google, Amazon, and Apple”

Read More

About more explanations of how the agile methodology is better, please read “12 Advantages of Agile Software Development” here.

Tags: Agile HatchingLab.com


comments powered by Disqus