If you do a quick search of project management frameworks online, you will see that Agile crops up regularly. Therefore, you may be surprised that we are dismissing it as a framework altogether. But, we will explain… A genuine project, in its most stripped back and basic form, consists of three key elements: there is a unique problem that needs to be solved, and it needs to be done so within a specified budget and timeframe. Rather than being a framework or a methodology, Agile is an approach to product development. It is a collection of software development principles and values. Believing that Agile is a project management framework is a big mistake. What’s this got to do with Waterfall? Well, a lot of Agilists tend to use the term Waterfall to describe every other approach that is non-Agile. The waterfall is very specific. In its true form, it’s rarely used. However, the gross over-simplification of the terms has caused a lot of people to misunderstand the project management frameworks that are out there today. The truth is that very few of these methodologies have anything at all in common with Waterfall. While there are some excellent ideas found within Agile, there is no denying that a lot of people have jumped on this term so that they can promote their own software development ideas and beliefs. With that being said, in this post, we are going to delve further into Agile. We will take a look at some good practices that are not unique to Agile, as well as looking at when Agile works well and when it doesn’t. This should give you a better understanding of why Agile is not a project management framework, as it cannot be used in all scenarios and it does not cover everything you need to do.
Good Practices That Are Not Unique to Agile
There are a lot of Agile purists that talk as if certain practices were invented by Agile or only ever happen in Agile. This is not the case. A lot of these principles and practices have been employed on successful, non-Agile projects for years and years. Some examples are as follows:
Frequent and early end-user review of deliverablesUses of early demonstrations, mock-ups, and iterationsDaily communication around current work and issuesUse of simple to develop and updated visualsFace-to-face communication on all key questions and issuesDecision makers embedded into cross-functional teams
All of the practices that have been mentioned above make the delivery process quicker because they help to minimise project issues and the need to re-work extensively.
Why Agile is Tempting and When it Works
The promise for quicker product delivery is what draws people into Agile. Breaking down everything into minute steps, from iPad rental to first draft submission, keeps everything flowing. After all, who is not going to want their products delivered at a quicker pace? Agile is very easy to sell when you consider that this is typically part of the company that tends to be problematic and leads to budget overspends. However, some leading Agile vendor have used questionable tactics. After all, you cannot sell a set of principles or a set of values, and so entire industries have been created around ‘new’ methods. Of course, that is not to say that it is all bad when it comes to Agile. There have been a lot of great results from people that have used Agile. This is when they have used an extremely pragmatic and skilful approach, meaning that Agile has been interpreted and implemented in an effective manner. These individuals are able to identify when they are in a project situation, and so they will merge together different practices and processes with certain Agile elements in order to deliver the best possible results. However, there have also been a lot of cases whereby Agile has been implemented and things have not gone to plan.
Questionable Tactics are Damaging the Good Side of Agile
It is easy to assume that we are simply dismissing everything that Agile stands for and has to offer. However, this is certainly not the case. As mentioned, there are many good elements associated with Agile when it is used properly. Nevertheless, the trouble is that a lot of unhelpful messages and tactics are being used, and this is damaging the good side of Agile. Here are some examples to give you a better understanding…
Saying that Agile can be used on any project is like saying that anyone, no matter their age or physical condition can win a gold medal at the Olympics or lift the next FIFA World Cup. One of the most damaging types of dogma is failue to accept or utilise words like ‘leader’ or ‘manager.’ Scope is the greatest variable in Agile. This cannot be true for many projects, though, no matter what type of product development method is being used. Anything that is not Agile is often simply deemed traditional or command and control. However, it is not this black and white. This comes from a limited understanding of approaches that are not Agile or it comes through Agile champions simply being dishonest about the ‘competing’ methodologies. If a whole new language is invented to describe things that you are already doing, yet you pretend they are new because of the new terms you have created, you are simply selling something that is already out there but you are labelling it as different due to the language used. This is how there has been an entire basis for new revenues, certifications, and such like to be brought about. Agile is an approach to product development. It is not even a method. It is a collection of principles and values. However, the issue is that selling values and principles is incredibly difficult. This is why there has been the creation of a lot of ‘Agile’ methods.
Δ
