Agile App Development
What is agile app development?
Most people feel (non-coders) that you give a list of specs or “statement of work” to a developer, get quotes, develop the app, and then you part ways with a perfect app. This is NOT how it works. Agile development was developed with 12 core principles that focus on iterative development, not the “waterfall” approach most non-coders assume is the industry standard way (and only way) to get an app developed.
Iteration takes planning
Iterating means you will be developing code early and deploying it often. You can see that Gartner said agile development is essential for mobile application development, or you can notice the number of updates to your favorite apps as proof of agile being core to all apps out there today that are popular. This helps everyone save time, and effort, money.
The backlog is a priority list in its simplest terms. You have all the items that you would ever want, importantly they must be “irreducible” which takes communication between technical members of the team as well as input from the non-technical people in the organization to make sure the items are as small as they can be. This leads to the ability to score each item (we use hours in Mercury) and much less chance to have miscommunication when development is happening. With less distractions, code gets written more quickly and open communication allows them to complete in a much shorter time than other types of development teams. For example, our average sprint time is 1 week compared to industry standard outsourcing of development taking 3-6 months and costing much more.
Iterating means always sprinting
The reason agile development is so successful is not just time and money based, it is quality. The way agile development allows only the most important items to reach the top of the backlog and hence get developed, you are always adding feedback, bugs, and other items in order to keep the cycle moving and app improving. If you look at your phone or other device, you will notice apps update pretty quickly. This is because they have reached the end of a sprint, they’ve done their QA and tested it with users (this can vary in operation), and now they need to fix the app to keep users’ attention, fix bugs that have been reported, or any other reason they felt it was important to develop those items in that sprint.
Keeping on this tight cycle of planning, development, testing, release & feedback and repeating it often will end up compounding in value over time for you and your users. As you get more great feedback and see users using the app, you can quickly spin up tests and push updates that enhance their experience, leading to people being more likely to share the app, spend their valuable time on it, and ultimately a place in the app you can monetize to make it a viable extension (or entire base of) your business.
Coding is expensive, on top of the developers and all those sub-disciplines (such as backend vs front end), but also you need other experts and positions and that experience comes with a cost. There are the just so many voices to be heard, a system was needed to stop the dreaded scope-creep (when little tweaks to the requirements create an unworkable solution). The backlog was designed for this reason and to be the backbone of the project’s movement through sprints, never being “done”.
Agile development was developed in order to make the process of development less error prone and brings more value to the end-user. This method requires meetings to be performed and other rituals that always have the app in development. So, if you’re thinking you can get an app developed and not be always in development, prepare to have a nightmare of a time and quite possibly (maybe probably) failing. Instead, the more economical and safe route is to develop using agile principles and only get true value producing updates to development and bring users what they want much more quickly and reliably.