Most of the people who have been exposed to the incorrect application of the Agile methodology of project management failed and most probably have a lot of misconceptions about the entire framework, leading to agile project management myths that are just that - myths. In fact, the benefits of agile far outweigh the negatives for many projects, making it a favourite option for project managers around the world.
Or perhaps, people who are just only being introduced to the wonders of the Agile methodology are sceptical of the outcomes as well as the processes involved in it.
For whatever reason, over the past few years, people have come up with the most baffling myths about the Agile methodology of project management. And we have listed down the most popular myths around in this article to set the record straight, once and for all.
As much as we wish this myth were true, it is not. In agile, one can fail just as enormously as one can when using other alternative if not traditional methodologies.
As a matter of fact, because of the transparency and visibility it requires, it is easier for people to fail using the Agile method. However, this is not an excuse to stop thinking.
There is really nothing fundamentally dreamlike about Agile. It simply states that you should “Bring your development team and customer as close together as you can, give them what they need, and then get out of the way.”
If you look around and realise that you do not really have people who like being empowered, getting things done, and taking initiative, that’s a huge problem.
The Agile method just gives your team the permission to work on their best work and be responsible and accountable for the results.
Wherever this idea came from, it is not true. Agile is not at all anti-documentation. But perhaps a more accurate way of saying it would be that Agile does not require documentation for the sake of documentation.
In the world of Agile, documentation is treated just like any other deliverable on the project. And like every other deliverable, the documentation gets sized, estimated, and prioritised just like other user stories.
Perhaps it’s when agile pushes back on documentation and prefers another means of communication is where people get the idea that it is anti-documentation. When in really, the agile method just simply prefers for a team to communicate face-to-face than traditionally relying on written word.
Wherever this myth came from, we are most definitely sure that they have not read a word about the Agile framework and methodology at all, as there is a lot of planning that goes on in any agile project.
For instance, you have your daily planning along with the daily 10-minute standups. Then the bi-weekly planning along with the Sprint meetings, and finally the release planning wherein teams decide what to ship every month or so. With that in mind, it would not be fair at all to say that agile is anti-planning. If anything, it is more of like anti-static planning to be more specific.
This is not true at all. If anything, Agile actually instils strict discipline to deliver the best possible results. It requires its team members to test, get feedback, regularly ship software, constantly change and update the plan, and most importantly, deliver unpleasant news or failures as quickly as possible.
The reality is, Agile is not a simple walk through the park, it is not even for the faint of heart, and it requires a lot of hard work and discipline.
This might be close to the truth, but not a lot as it proclaims. Agile actually comes in two forms of rework. The first is when you have to rework the requirements and the second is when you have to rework the software.
The latter is only reworked when the development team discover a much better way to design the software, and the former is when the customer realises what they want exactly.
However, both need balance, similar to the fact that a business cannot always change their mind, development teams cannot keep redesigning forever. At some point in the project timeline, the team have to ship.
The great thing about Agile is that it actually deals with this problem by empowering both sides through iterating so as long that both work within the project’s means.
All creative works with a deadline faces the same problems and challenges, one way or another. It’s just a matter of doing your best work with the given time and resources you have.
Agile actually works best in architectural projects and something that the architectural industry got really good at was building huge, complex, expensive, and hard to maintain systems during the 1990’s.
So, Agile has pushed back just a little biton this coining the term YAGNI which means You Ain’t Gonna Need It. This is to simply remind teams to continue making things simple until proven otherwise.
But that does not necessarily mean that Agile teams should stop thinking, or that they do not really have any leverage on their previous experiences. It is actually more like an attitude that the best way to build bigger and more complex systems is to keep things simple, and only add the difficult parts as needed.
Scaling is probably one of the most difficult things to do in an organisation. There really is no easy way to coordinate, communicate, and to keep large groups of people to move into the same direction towards a similar cause. But in Agile, instead of finding ways to scale up, it actually looks for ways to scale down.
A scaled down team is so much easier to maintain and manage, plus, structuring it that way can make people work more efficiently and effectively on a project. So,technically, Agile can scale up, but it will be more effective if done the opposite way.
If you're ready to bust these agile myths in your organisation, you need a software built by agile experts for agile teams and their stakeholders. Empower your stakeholders with appropriate information and get down to the nitty gritty with your team in an intuitive digital environment. Start your free trial with Comurce today.