Agile in practice #5 - Does Agile development work for every project?
Is Agile a one-size-fits-all solution? Definitely not. In this article, we will look at pairing Agile with different types of digital products. Does an Agile mindset always lead to success? Are there any industries that are better off with the traditional approach? Read on to find out.
Table of contents
What kind of projects are suitable for the Agile methodology?
There is a popular belief that Agile is best for small projects where the final product is either a website or a mobile app. It’s easy to find examples where that is the case, however, the reality is more complicated than that.
Let’s take Scrum for example - an Agile framework where the team produces workable versions of a product in short iterations. Scrum was successfully implemented in the development of thousands of open source projects, where teams were ten, maybe fifteen people strong, and all the coding and designing could be completed in a matter of weeks.
Today, Scrum and Agile development are top choices for projects where high priority is given to designing great UI and UX - such as for mobile apps and websites (source). Coincidently, they are often small projects built by a handful of people. Does that prove that project size is the only factor that matters?
One of the reasons why Agile works in small projects is that they are prone to changes: whether these are changes in the business goals or in the purpose of the product. Agile was created to respond to rapid changes, regardless of the size of the project (source). After all, large projects can be volatile too - sometimes even more than independent startups. And it’s these kinds of projects, unpredictable and prone to changes, that are most likely to succeed with Agile. But since we live in a VUCA world, almost any project will fall into this category. Are there any examples of when not to use Agile?
When not to use Agile methodology?
There are certain industries that don’t do very well with the increased risk associated with Agile development: finance being one of them. This industry, by its very nature, relies on the predictability of its processes. Any deviation from the norm could lead to a costly mistake.
Another example of a when not to use Agile would be anything that is government-owned. In most countries, projects funded with public money need to go through a government tender and most of them are required to give the total price of building a digital product. With Agile, it’s almost impossible to predict the exact cost of development at an early stage.
And even if an Agile project won the tender, there are still problems with the contract that the partnership would be based on. For example, in Italy, there is a law specifying exactly what to include in public procurement contracts, such as exact cost and all the features that the development team is supposed to deliver. But that’s not how Agile contracts are built and for that reason, they are often misaligned with government projects (source).
There is also a matter of Agile values and principles: if an organization’s values are opposed to at least one of the Agile core values (listed in the Agile Manifesto), they will fail at developing digital products in Agile regardless of what they do. Now that we know when not to use Agile methodology, it’s time to answer even bigger question: why Agile doesn’t always work?
Why is it difficult to apply Agile?
When the Agile Manifesto was first introduced in 2001, it was everything that developers could have hoped for - it released them from the chains of strict requirements that the waterfall model was built around. The strength of the new approach was simple: Agile was a mindset by which product development was organized, not a set of rules or a rigid framework.
But, that doesn’t mean implementing Agile was easy. In fact, many organizations tried and failed, despite their best efforts. Academic literature (source) names a number of factors that contributed to these failures, such as:
- lack of support from management,
- outdated organizational culture: a traditional model is more likely to fail at adapting to Agile,
- considerable size of the organization, as large businesses fail at Agile more often than others.
The reason why is it difficult to apply Agile at large scale projects has nothing to do with the number of employees in organization or their annual revenue. The problem lies in their approach to testing and reviewing, as these processes were left to upper management - people who prefer to work in a rigid structure over a flexible one. If large organizations want to succeed at Agile they need to give their development teams freedom to organize their work and make decisions for themselves. In other words - they need to be allowed to embrace Agile.
The human factor in Agile
The sources used for this article point out that the success of each Agile project wasn’t always evaluated by outside metrics, but by data collected with surveys and interviews (source). Some of the respondents could fall under the category of so-called Agile evangelists - enthusiasts who are committed to spreading the word of the beauty and benefits of an Agile mindset. These people, on occasion, can overestimate Agile’s role in a project’s success.
That is why it’s better to take everything written here with a grain of salt. Despite collecting the data with academic rigor, all the information was presented from the point of view of people involved in Agile projects, such as product owners or scrum masters.
Does Agile work for every project?
Not every organization is well-suited to working and succeeding in Agile. The ones that are often have a flat structure and use flexible management methods. The benefits of the Agile mindset can be best seen in websites and mobile apps - or other type of IT project that put a strong emphasis on delivering a great UX. This, in the end, is what matters most in digital product development - delivering irresistible products.
Share this article:
