Is agile the right approach for your app?

If you're looking to develop an app, you'll probably have heard the word Agile used in articles and on app developer websites. The problem is, this word is often poorly understood, or sold as a set of practices that don't even bring the real benefits.

To help you figure out if agile is worth considering, this post looks at a few areas. What does an agile project look like? How does it affect how your app is developed? How will you have to change how you go about your work? Or your relationship with your board?

Let's take a look at the effects agile will have.

You get started faster, but no specification might throw you

Agile does away with big upfront specifications. This are documents that outline exactly how your app will work. Not having this can be very unnerving for some people, explored below.

Why be less agile?

1. You can see your entire idea illustrated before spending the bigger bucks on developing it
2. You can sleep at night knowing your vision will happen, because the spec says so
3. You'll get a cost and timeline, so you know what you're getting for your money and when

So, NOT doing agile is great, right? Well, it can be. But an agile app development company will help you in different ways.

Why be more agile?

1. You can move faster without all that documentation to write, review and amend
2. You can learn if you're ideas are market-fit in 2-6 weeks, rather than 6-12 months
3. You can save time with face-to-face communication, more efficient than emailing or writing

Organisations that switched to agile did so because, for them, learning is the most important thing. More specifically, the quicker you get feedback from your target audience, the less likely you go down the wrong path. Many apps are under development for 6-12 months, burning tons of budget, only to be poorly received by the market. Agile is about fixing this by removing wasteful practices and getting feedback from stakeholders and customers as quickly as possible.

You'll ship more often, but there is no big plan

With agile, you ship working software more often. This is because the process is broken down into smaller pieces, often called iterations or sprints. These are typically 1-6 weeks long. This can be uncomfortable to some so there are times when being less agile is a good idea.

Why be less agile?

1. You don't have the nerve-wracking experience of showing fledgling ideas to customers
2. You get a polished product at the end, you won't see the "building site" in progress
3. You already have a big plan of what to build, so you can relax knowing it will happen

I'll admit, I struggled to write those benefits because I personally have never seen that work. However, in theory, there is less management overhead and stress. Agile brings different benefits:

Why be more agile?

1. You get customer feedback very fast, so good ideas can be honed into great ideas
2. You are free to set priorities based on what you learn, there is no big plan to mess up
3. You can focus on goals and outcomes, because there is no delivery plan to worry about

You might be thinking that agile is just "winging it" but the last point above is the most important one; goals and outcomes are at the heart of agile and are part of every iteration. Would you rather have a process that is optimised for delivering software, or one that is optimised for delivering software that achieves your goals?

The tools and processes don't matter, but it might feel chaotic

There are only four bullet points in the agile manifesto, and one of them is: Individuals and interactions over processes and tools. This means that it's not that important if you pick Notion or JIRA. Or it's not that important if your processes aren't followed to the letter.

This doesn't work for everyone though, sometimes tools and processes are important:

Why be less agile?

1. You're app developers are building to specification so you don't need highly interactive discussions
2. Your organisation mandates a set of tools, so you cannot just pick what works for the people doing the work
3. You personally believe that, for your project, the tools will have a bigger impact than team dynamics

Agile organisations can still value tools and processes, but it's more likely they will select them because they help facilitate human interaction and actually shipping software.

Why be more agile?

1. You can adapt your process to the skills of the individuals, and you trust the people doing the work to make safe choices
2. You can enable teams to pick tools that make them happy and productive, which causes less resentment
3. You can retrospect on both of these things often, meaning if something isn't working you just fix it rather than follow the rule book

As you can see, the agile approach is going to be more adaptable. One month you might be doing things one way, and the next month the team may have decided it wasn't optimal. This performance tuning may seem chaotic from the outside. You have to be comfortable with change.

For it to work, YOU have to be agile, but you don't know how

This is a big one. Agile only works if you, the business leader, are agile too. There's no point selecting an agile app development company if you can't support the principles outlined in this article. It will fail because agility starts with you, the leader. However, sometimes being non-agile is fine too:

Why be less agile

1. Your board expect to see a specific roadmap delivered, and you can't change that
2. The problems you need to solve do not require innovation or customer feedback
3. Getting a list of things built for a fixed price is more important than adapting to change

Why be more agile

1. Your board expect you to deliver a series of business outcomes or KPIs, not roadmap items
2. Your success depends more on customer growth rather than getting something over the line
3. Your board trusts you to channel their budget in the best way to get the desired outcomes

As you can see, to be agile you need to have trust in two places. Your board need to trust you to manage your budgets responsibly, achieving outcomes that align with the business strategy. And you have to have a high degree of trust in your app development team, because you can't ask them to commit to building to a fixed budget. With agile, the scope and details are unknown by design. Only the desired results are agreed upfront.

Can you do it?

I'd be curious to learn if this has changed your feelings about adopting agile for your app development initiatives. You have to make some fairly big tradeoffs:

• Swap the big upfront specification for figuring things out as you go
• Swap project plans for lots of short iterations with customer feedback
• Swap the annual roadmap for a list of important outcomes
• Swap fixed costs for sensible budget usage; doing whatever moves toward outcomes
• Swap fixed processes for flexible ones that are adapted in the moment
• Swap the mandated tools for allowing team to select what works for the team

This is how a lot of modern companies are achieving great success with their mobile apps and digital product developments. What would you or your organisation have to change in order to make these things possible?