Avoid These 4 Agile Traps: Tips For Beginners

Learn the top 4 Agile rookie mistakes to avoid. Based on 10+ years of experience.

Agile is the most efficient way to build innovation

Compared to other approaches, including its direct juxtaposition, Waterfall, Agile allows for minimizing the time spent on formalities and preparing full project documentation (before the project’s actual start, which is a very time consuming and expensive process on its own); and it maximizes the resources spent on actual work.

A simple roadmap is created, with attention given to the core features of the application. Because you develop a clear vision and a product’s spine, so to say, the smaller tasks can be approached with flexibility and can be given a different (changing) priority.

Agile benefits have been widely praised and documented, so you probably know them already. It increases customer’s satisfaction, users’ retention, it allows you to build tangible value with your product, and reduces the risk of failure thanks to quicker iterations and reactions to your industry’s environmental changes.

Quicker iterations mean preparedness for unexpected changes that may arise.

So you pretty much define what to do as you go, instead of planning ahead for months, trying to prepare for things that you can’t really prepare for (crises, above-mentioned market changes, direct competitors updating their value proposition, or pretty much anything else that is impossible to foresee at the beginning of the project).

But… Agile is not a cure-all for all your product development troubles

If you perceive it that way, you might have just fallen into the first trap and common misconceptions built with the hype.

Agile has its values and principles, which, when not followed, can make the product a fiasco, or at least, significantly impede the development process.

At EL Passion, we’ve been working in Agile for 10+ years, and here are my two cents on what to prepare for to avoid the Agile-rookie mistakes, that are just really easy to make for the newcomers, but also very easy to eliminate when you actually know what you’re signing yourself up for.

Trap 1: When the Product Owner doesn’t have the time to be the Product Owner

A Product Owner (PO) is the main decision-maker in the process, responsible for spreading the product vision to the development team, maximizing the value of the features to be developed, prioritizing the backlog items to have a balance between business and end-user benefits.

A bit like a captain of a ship, he/she is commanding, or rather in this case: guiding the crew, so they stay on the right course. It’s pretty obvious that if the captain doesn’t have time to command the ship, things can go terribly wrong.

Yes, self-organized teams can work somewhat independently, but the priorities have to be set and somebody needs to have final say and decide what stays and what goes.

At the foundation of a successful digital product, is a team that understands the vision.

The lack of the PO’s presence in the project comes with a pricey risk. The team has no connection to the product’s vision or the end user’s perspective and may spend time building features that are less important for the client or design them differently from what the client’s imagined them to be.

Both scenarios are, in short, not only a waste of everyone’s time but a very painful waste of the budget.

The solution is, as always, simple in theory and a lot harder to put in practice (especially to people not used to working in Agile environments). The PO has to make sure he/she is able to dedicate approximately 1–2 hours a day for the project (it may be a bit more within the first week of the project’s start).

Trap 2: Not understanding what you’re paying for in Time & Materials contract

There’s a very common misconception that, while working with a software development company, you’re paying for the functionalities that will be delivered. But this is not true in the Agile environment, and commonly following it, a Time & Materials contract.

The core of the Time & Materials contract is that you pay for the time of the hired team, just like you do when hiring people in-house. The functionalities they create are, of course, a tangible result of their work, and you are able to see them in real-time as the work progresses. But still, you’re billed for the hours, not for the end result.

This misconception sometimes leads to serious misunderstandings and in extreme cases, may put the project at risk.

Solution: be aware of what you are really paying for and that in any case you need more time of the team, it will be billable time, even if it means working on the features that have been finished. You can also reserve a small buffer of your budget for the finished tasks for small fixes and improvements. If you have expectations towards any kinds of warranties, be sure to talk with your partner as soon as possible, ideally, before the cooperation starts as it might require a completely different setup.

A Time and Materials contract is actually the most efficient way to measure the progress smoothly.

Trap 3: delaying the release of the application

Continuous delivery lies at the heart of the Agile approach. You want to release your app to the market as soon as possible, even with the limited number of functionalities, even in an imperfect form, so you can have a good foundation to build on, but with the app already out there.

Let’s say your product idea is extensive, and the development of the full scope would take around 10 months. The agile thing to do would be to divide the work into smaller chunks, prioritize the features and release the app sooner rather than later.

Why? With your app already on the market you gain access to real users’ feedback with no user testing sessions necessary and you can navigate the further development based on that feedback. On the business side, you can start building your competitive edge sooner, and, of course, you start to capitalize your investment sooner. One thing to remember:

Software development is not a finished process. Rather, it is a continuous improvement of what’s already been done.

The direct risk of forgetting about the “MVP mindset” is prolonging and delaying the app’s initial release and burning the budget to polish all things to perfection. The reality of working with digital products taught me and reminded me many times that you can’t learn to swim on a cold hard ground. You just need to jump.

Solution? Don’t overcomplicate the already complicated process.

Choose a simple solution and then build on it. Keep the mindset and discipline to release the application as soon as possible, even if it means some compromises. Your software development partner is there to advise you on the best technology, with all pros and cons of further development and expanding it according to your business plan.

As Pamela Zave puts it: “The purpose of software engineering is to control complexity, not to create it.”

Trap 4: Relying on the initial estimation, while significantly changing the scope 🤔

The initial estimation is prepared to give you a rough idea of how much time and money is needed to complete the project.

It’s prepared based on the pre-project-start understanding of the scope of work that needs to be done. At EL Passion, it’s often after a Product Design Workshop. But this scope of work, again, is common to change during the actual development.
New features might be requested, the scope of those originally discussed will be specified or changed, some features will be dropped or reprioritized. All those things affect the time and the budget.

You need to remember that changing the scope can mean two things. Either the end-price and project end date will change, or you will end up having to cross out some of the initial estimation elements before the budget burns out.

The key here is awareness and realization that any changes in the project, quite naturally, affect the overall time of the development and the price.

And the solution: as the project progresses and changes, you should rely less and less on the original estimation — it’s much better to move your mindset to the ongoing projections based on the team velocity and remaining planned work. Whenever you think of a change — talk with your development team, how to approach the needed change, so you’re on the same page when it comes to the effects it brings to the table.

The trap is not Agile itself, but Agile misuse

Agile has revolutionized the way we produce software. It’s been praised and its results documented by the biggest in the business. It works, and it can work wonders also for your product. But only if it’s applied wholeheartedly and consciously, with respect to its values and principles.

The traps I mentioned are common for the so-called Agile newcomers, driven by the hype, but often not informed well enough.

But now that you know them, what’s there to stop you?

Check out also

1. Common Mistakes to Avoid When Developing Your App to see the do's and the don'ts when your developing your app
2. When to Hire An Agency For Your Software Development some questions to ask yourself when you're not sure if IT outsourcing is your way to go