There is plenty of discussion regarding whether project teams should use a waterfall or agile framework, or even a combination of both. In its purest sense, though, waterfall is rarely used – it is far more likely that projects use an iterative version of the waterfall approach as their project management framework. But, in this post we’d like to touch upon why agile is not actually a project management framework (and never will be).
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 let’s 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 within a specified budget and timeframe.
Rather than being a framework or a methodology, agile is an approach to product development. It started life as a collection of software development principles and values. Believing that agile is a fully-fledged project management framework is a mistake.
What’s this got to do with waterfall? Well, many agile proponents tend to use the term waterfall to describe every other approach that is non-agile.
Waterfall is very specific. In its true form, it’s rarely used. However, the gross over-simplification of the term has caused many people to misunderstand the project management frameworks that are out there today. The truth is that very few of these methodologies have much at all in common with waterfall.
While there are some excellent ideas found within agile, there is no denying that many 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 many agile purists that talk as if certain practices were invented by or only ever happen in an agile environment.
This is not the case. Many 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 deliverables
- Uses of early demonstrations, mock-ups, and iterations
- Daily communication around current work and issues
- Use of simple to develop and updated visuals
- Face-to-face communication on all key questions and issues
- Decision 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 supporting agile. 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 project that tends to be problematic and leads to budget overspends. However, some leading agile vendors 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 great results on projects that have used an agile approach. This is when they have used an extremely pragmatic and skillful approach, meaning that it 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 cases where an agile approach has been used and things have not gone to plan.
Why does agile go wrong so often?
Let’s take a look at why a lot of businesses tend to experience a change for the worse once they have implemented an agile approach…
Agile is hard to put into practice
There is only one place to begin, and this is with the fact that agile is difficult to implement in practice even though it may be a principle that is easy to understand.
Agile requires many changes to current practices and the way in which a business and it’s people work. It can even demand that people within the business change in terms of the role they carry out. It is often deemed a transformation, but there are very high failure rates when it comes to transformational efforts. The scale of change that is needed is underestimated, and considerably so. This is especially the case when it comes to large and complex projects.
Agile ‘experts’ can get accreditation within two days
Another issue is that, despite the fact agile is difficult to implement, becoming an agile ‘expert’ is easy. In fact, the industry is filled with them, and this is because people can get accreditation in as little as two days. It is important, therefore, to recognise the difference between professional PM qualifications and continuously developing project management skills and these minor accreditations when training and developing staff.
A lot of business owners confused Agile and Scrum
Another issue is that far too many people confuse agile and scrum. They believe they are running an agile project but, in fact, they are running a scrum. And, the most common scrum interpretation is actually completely at odds with agile values and principles.
Scrum is more appropriate for projects involving simple software development. This is where incremental sequential development and deployment are evidently the most appropriate and there are independent teams.
The core of agile can be exceptionally challenging to master where the project deliverable incorporates elements other than software or when there is a high level of complexity.
Introducing Scrum and Sprints is not enough if you are to get the real benefits of an agile approach. You need to have a commitment and an understanding – and this relates to everyone in all of your teams involved in a project.
This means that it is going to take time. You need to take the time to put together an approach that is going to be successful for you. Once you have done this, you are then going to have to tweak and adapt your process to suit the different projects you are working on. After all, you can never have a single method that can be used across all projects, as projects have unique characteristics. This is not something all companies welcome or even understand. After all, the thought of having to adapt a process for every project is not exactly enticing.
Agile is only suitable for some projects
Business owners can also make the mistake of assuming that it is an all or nothing decision. However, this is not the case. Agile is only appropriate for a selection of projects; not all of them.
Of course, this brings about more challenges. For teams that are not very familiar with agile, they are going to need a significant amount support when they first get started.
Short-sightedness becomes a problem
Another reason why businesses can often flounder when they introduce agile is that they become short-sighted. This makes it incredibly difficult to plan for long-term change and improvements.
It is also worth considering the fact that project team members often push-back against some of the most valuable aspects of agile. This can be because they do not have much interest in anything outside what they consider their fundamental role. They see frequent stand-up meetings as nothing more than inconveniences or distractions that detract from their “real job”.
Dates do matter for companies and organisations
While there are some companies and organisations that have the luxury of never having to release products or services by a certain deadline date (think Google!), most businesses are not this lucky. While it would be nice to simply be able to release a new product or service whenever it is ready, this is a luxury that most companies are simply not afforded. The truth is that dates matter because or external competitive forces. However, purists will say that they do not have to consider dates because they are working to the agile principles. Statements like this aren’t very helpful when deadlines exist in the real world of business.
Dependencies leads to poor decisions
Another drawback associated with agile is that dependencies are considered as negative factors. However, projects are almost certain to have some types of inter-dependencies. This creates a clear problem. Inside iterations, there are often poor decisions made because of this, and this can result in a false understanding of project progress.
Questionable tactics are damaging the good aspects 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 unhelpful messages and tactics are being used, and this is damaging the good aspects 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 failure to accept or utilise words like ‘leader’ or ‘manager.’
- Scope is the greatest variable in an agile project. This simply is not true for many projects, though, no matter what type of product or service is being developed or what method is being used.
- Anything that is not agile is often simply deemed traditional or command and control. However, projects are not always this black and white. This comes from a limited understanding of approaches that are not agile or it comes through agile champions simply being misleading about the ‘competing’ methodologies.
- If a whole new language is invented to describe things that you are already doing, yet you treat them as new because of the new terms you have created, you are simply re-labelling existing methods.
- Agile is an approach to product development. It is not a method. It is a collection of principles and values. However, the issue is that selling values and principles is difficult. This is why there has been the creation of ‘agile’ methods.
So, there you have it: hopefully, you now have a better understanding of the reasons why agile is not a project management framework, and it never will be. There is no denying that there are clear benefits that are associated with agile. However, it cannot be used in all cases because it does not always cover everything you have to do in order to complete a project in the most effective way.
It is not an either/or choice when you need to decide how to deliver projects. Often, we need to use a number of different principles, bringing them together for full effect. Agile was not intended to be a method or framework for project management. This is because it does not manage elements while dealing with dependencies and integration. Instead, you can use characteristics and different agile beliefs based on the nature of your project.