1. The Success of Agile
Within the Agile Process and culture, there are many separate versions, from the well-known and widely used Scrum, Kanban, or XP, to lesser-known ones such as Crystal and Lean. The aim of all Agile strategies is to improve the workflow process and focus on efficiency whilst producing a valuable product quickly, often with something to show within a few weeks. This all sounds well and good, and let’s be fair, it has been a successful component of project management for years and is still growing. Fields such as software development and design are especially thankful for the ideas of Agile, but that’s not to say they aren’t popular in other businesses too.
Not only is Agile supposed to be efficient and results-based, but it is also claimed to produce more satisfied clients, be adaptive to change, and even make your employees happier. There is room for collaboration between the stakeholders, including the client and team members benefit from the responsibility and freedom that Agile offers, which results in more productive, effective work and final product.
The 4 main Agile principles are…
- Individuals and interactions over processes and tools
- Working product over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
…but
- Does agile work every time?
- Is it a cure-all solution?
- Does every project benefit from the Agile method?
- Does every team function more effectively when using Agile?
- Is customer collaboration always a good thing?
The answer is clearly no, and Agile is not right all the time for all purposes. So we need to ask ourselves why not.
2. The Principles of Agile Aren’t Always Followed
Agile is quite a powerful methodology, but it isn’t flawless by any means. Typically, there are two main problems: either the plan is not good enough, or the plan is good enough, but the ones who follow it aren’t up to the standards. The outcome is the same in each case – a failure.
Individuals and interactions over processes and tools
It seems strange then that Agile strategies are heavily reliant on workflow processes that are built into the system. Think of the obligatory daily meetings in Scrum, and that is just the most obvious example. And tools? Well, Agile is well-equipped with robust tools. Tools for planning, tools for analyzing, tools for communicating, and collaborating, Agile is awash with tools that are fantastic and well-designed and make life considerably easier. So are we sticking here to the values? You could argue that the tools are secondary to the users of the tools, but in practice, they really do go hand-in-hand.
And individuals? Well, Agile is supposedly centered around teams for a start, but let’s say for the sake of argument that a team is made up of individuals. Agile needs creative, responsible, able independent workers. It wants people to work with minimum input once the task is underway. For some workers, this is an ideal scenario, just what they want to make them feel; special, a key part of the team, valued by the employer. But that’s not the case with others. Not everyone is capable of working by themselves. Some people need direction.
Working product over comprehensive documentation
The Agile principles tell us that success is measured by a working product. But Agile breaks things down into smaller tasks, which are seen as progress. This doesn’t always produce a working product and certainly not a fully operational one.
As for the emphasis on the product over the documentation. This sounds like a winner, but the emphasis in practice is totally one-sided. The product is fully central, and the documentation is non-existent. And how does this work when other team members join without some sort of documentation? Where do they start?
Customer collaboration over contract negotiation
Another principle that sounds great on paper than it is in reality. First of all, it may work perfectly well if clients are aware of what they want and they need someone to execute it on their behalf. In this case, we are talking about a satisfactory product in the making. But very often, what we see in practice is people who have some ideas that aren’t well put, but they want something to be done their own, even though the other party doesn’t have much vision over what exactly is needed. Sadly, customer input often means a change in the plan, which results in more effort, more delays, and more loss of money.
Responding to change over following a plan
One of the biggest advantages of Agile can quickly turn its back on the methodology. Agile is all about flexibility, but that doesn’t mean you can create a mess and go with the flow. It has priorities, and it has processes that should be followed. Since it is not very tight, letting loose of team members might result in some people overworking while others could end up without any workload.
3. Further Reasons
If you can sort out the fundamental issues with Agile, adhere to the philosophy, and plan to get a value-driven, flexible workflow with clear direction – surely then everything will work out. Well, again, it’s not that simple.
Agile Compatibility
Agile isn’t for everybody or every project. For some companies or organizations, Agile isn’t needed at all. This is especially the case when there are known models to follow, and little or no change is likely. Think healthcare or financial industries. They are basically doing the same things over and over again, following strict guidelines. Each step is followed by another, and each is highly detailed and documented. Agile is not for you, this isn’t what Agile is designed for.
Team Doubts
One of the important things when using any Agile strategy is that everybody throws themselves into it and believes in the value. Seeds of doubt in your team, even by just one or two members will reduce the effectiveness of Agile. This could include people who are unwilling to change from a previous model, but also workers who you think won’t work well without strong direction and management and will not rise to the freedom and responsibilities expected.
Here you can either try to convince the participants, by explanation or change the team.
Agile isn’t being used right
Unless agile is being used correctly by all the participants there can very quickly be a breakdown of the whole process. This includes the essential communication between the clients and the team, the manager and the team, and the team member themselves. There must be accessible information for all the parties involved, plenty of feedback, constructive meetings, and allowing the employees the freedom and responsibility without micromanaging.
4. Potential Problems in Agile
Problems with Agile typically fall into certain categories:
Deadline Issues
As Agile breaks the project down into smaller constituent parts it can be difficult to estimate the overall completion time of the full project. The smaller parts are given deadlines and estimated with input from the team doing the task and this is generally reasonably accurate. But then we have the iteration, which adds more time and is difficult to estimate before the review. As feedback and client satisfaction is central this is an unavoidable process. Management should be able to factor in a buffer to mitigate problems but nevertheless, problems occur.
Costs Rise
As deadlines are extended, and more and more changes take place, costs are bound to rise. The client should be aware of this, and it should be an open discussion but a budget is a budget. Agile should produce usable products at earlier stages so perhaps this can offset the overall costs but still a client like to know how much money they need, and cost spiraling inevitably leads to issues.
Documentation
Lack of documentation isn’t necessarily a problem if the project can stand alone. However, because of the focus of Agile on the product over the documentation, it can lead to issues if you have to bring new people in. You might lose team members for a significant time as they have to explain what has already gone on and how.
Scope Creep/ Budget Creep
Agile can adapt to changes, but this means more time. Adding functionality or feature to the project increases the scope and therefore the budget. In most cases, there has to be a balance or at the very least clear communication and negotiation.
Team
The success of Agile very much depends on the abilities of your team and their willingness to take on responsibilities. They have individual as well as team responsibilities, they have a degree of freedom. It often works well for smaller more compact teams where you know each other well and are well aware of specific specialisms and knowledge. With larger-scale projects come larger teams, and with that can come problems.
5. How To Make Agile Work
The first thing to decide is Agile an appropriate philosophy for your type of business. It might be fashionable, and all the rage but it honestly is not suitable for everybody.
If you feel it’s right for you, then you need to go for it, all-in.
Agile will not work if it is half-hearted, it is an all-or-nothing, everybody pulling in the same direction strategy that can crumble easily. Decide to do it, build and inform, even instruct your team, then go all out to make it work.
Summary
Agile is the philosophy on everyone’s lips at the moment. Ok, we get it. We all want to embrace the idea of our business being adaptable and able to cope with challenges thrown up. The world has certainly thrown up some rather unexpected challenges lately. Sowing the seeds that there may be more to come. Agile works incredibly well with the rise of remote work and has a proven record of success for many, many businesses over many, many years. It works especially well with software development but still… it’s not sorcery!
But if you work around the negatives, Agile might turn out to be a pretty successful strategy for your business.