Why Agile will never be a project management framework
This is not a Waterfall-versus-Agile discussion:
This post is not about Waterfall-v-Agile. It is much wider than that. Waterfall is a very specific and in fact rarely used form of software development life-cycle, in its pure sense. This post is about the realities and range of projects in business, regardless of how unpalatable those realities may be to some people, and what the business world of real projects is often about.
At its most basic, a genuine project is a unique problem to be solved, within a desired timeframe and within a specific budget. The fact that humans do not find meeting all of these three constraints together easy does not mean that in business we can simply ignore the ones we least like. Being honest, that’s what a lot of the Agile ‘purists’ are trying to do.
Genuine projects do and will always exist. Agile is a product development approach (it is not a method). It is a collection of values and principles about software development. Most importantly, it is a huge mistake to call it or think of it as a project management framework. Also, Agilists frequently label every “non-Agile” approach as Waterfall. This again is a gross over-simplification and misinterpretation of project management frameworks, of which there are many and large numbers of them they have little in common with Waterfall.
Also, if you are making minor incremental changes to existing software or conducting maintenance, that is not a project. It is a software development and maintenance.
Agile contains some great ideas, but sadly there are many who have hijacked Agile to promote their own beliefs about software development, especially their dislike of anything relating to the word ‘management’.
Good practices not unique to Agile
Many Agile purists talk about it as if the following only ever happens in Agile, or were invented by Agile. Neither is true as all the following have been employed on well-run (non-Agile) projects for decades (well before the Manifesto in 2001):
- True cross-functional team working with decision makers embedded in the team.
- Face-to-face communication (on all key issues and questions).
- Daily communication around issues and progress.
- Use of iterations.
- Early and frequent review of deliverables.
All of the above help to minimise re-work and issues on projects and hence speed up the delivery process, while increasing confidence that the deliverables will meet users real needs.
The Agile temptation
Agile vendors draw people in by the promise to deliver products quicker. There are few Executives in the world who are not going to want this. Often this is within the part of the business (Software and Information Systems) that has been notoriously problematic historically (relative to delivery) and can be very expensive with a track-record of exceeding project budgets. Put these factors together, and Agile becomes a very easy sell, almost regardless of the price tag. However, there are some hugely questionable tactics by some leading Agile vendors, as is described below. Whole industries have been born around ‘new’ methods; as you cannot sell a set of values and principles.
When Agile works well
Firstly, there are some excellent results using Agile from people who interpret and implement Agile approaches skillfully and in a highly pragmatic way. They also recognise when they are in a project situation, and combine elements of Agile ways of working for the product development with whatever else is required to manage the whole project. Not in a command-and-control style, but by using effective ways of managing anything outside of the immediate horizon that Agile uses, and outside of the software development itself. And for those who say “anyone in the team will just pick this up and do this” – they are in urgent need of a reality check.
Sadly far too often:
We deal with dozens of different organisations every year and Agile often comes up in discussions. In private, the most common thing we hear is “We moved to Agile; things are worse, not better”.
So let’s look at just some of the reasons why:
- Agile is easy to understand in principle but very hard to do in practice. Much harder than the snake-oil salesmen will admit (or understand). Most of the true benefits of using Agile are not commonly understood and the challenges involved often go unresolved.
- Far too many people confuse Scrum with Agile. When they say they are using Agile, they really mean Scrum. The most common interpretation of Scrum is totally anti the principles and values of Agile.
- Scrum is suited to simple software development where incremental sequential development and deployment is clearly appropriate and teams are independant, but that is far from always possible. Where design is a very large task or complexity is high, the core of Agile may be exactly the opposite of what is needed.
- Getting the real benefits of Agile takes a great deal more than introducing Sprints and Scrum. It takes understanding and commitment from the business and from everyone in the development teams. It will take time to develop an approach that works for you too, and this will have to be adapted when used on multiple projects. Projects by their very nature have unique characteristics and trying to develop a single ‘method’ to deliver them is never going to work. That is not a message many businesses understand or welcome.
- Despite the above, the world is suddenly now full of Agile transformation experts and coaches (many of whom have gained an accreditation after as little as two days of training).
- Agile can make you become very short-sighted, making longer-term planning challenging.
- Technical debt is common and in the medium and long term can be very damaging and costly.
- In many instances, project managers have been dispensed with, leaving a big gap when it comes to managing crucial aspects of delivering projects, such as dealing with stakeholders and any kind of forward planning and more. Also, assuming just anyone can perform this role successfully is a very flawed assumption.
- Projects are always full of dependencies and dependencies are bad in Agile, especially Scrum. This often leads to all sorts of poor decisions inside iterations and can result in a false measure of progress.
- Many Agile methods completely ignore Design, almost as if it does not exist.
- You constantly hear things like: “Agile doesn’t do dates” from the mantra promoted by many purists. To be fair to them, the Agile manifesto talks about quality and releasing software frequently, but is very careful to avoid making any reference at all to “on-time” etc. Some organisations, like Google, don’t have to work to dates. Products are released when they are in a fit shape to do so. Google rarely share any announcements about dates publicly (unlike the old days of Microsoft). But, not every firm has that luxury. There are many times when dates matter and in those circumstances, schedule needs to be a constant and core consideration. The whole topic of schedule is deliberately avoided by most Agilists.
- The applicability of Agile is far less than the Agile salesmen claim.
- Some of the most valuable aspects of Agile can face push-back from developers who have little interest in anything outside of development using statements like “Stand-up meetings are an annoying interruption. We are developers. We write code.”
Also, the key test is not whether Agile is working for the development teams, it is whether Agile is working for those who fund those development teams, i.e. usually their customers (internal or external) and the users of the products being produced.
Too much of the good of Agile is damaged by dogma and questionable tactics:
There are highly professional organisations helping customers use whatever is right for the job at hand – and then there are those who will only ever suggest one approach regardless. They tend to be labeled as zealots. The latter often promote some very unhelpful messages and tactics.
Here are just a few examples:
- Agile is a product development approach and Agile itself is not even a method – it is a set of values and principles. But, it is very hard to sell values and principles – hence the birth of many “Agile” methods.
- If you invent a whole new language to describe things you are already doing and pretend they are new (1), you have the basis of selling something different and you create fear in people as if they don’t know the new language, they feel vulnerable.
- Anything “non-Agile” is automatically smeared as “command and control” or “traditional”. This could not be further from the truth and is either dishonest or born of ignorance.
- In Agile, scope is the biggest variable. On many projects, regardless of product development method, this simply cannot be true.
- In Scrum, only the Product Owner is accountable for the projects’ success – the team is not. Remarkable. Truly remarkable. In Scrum, for example, there is a total refusal to accept accountability around development teams, stating: “transparency creates accountability”. Transparency is a great thing but this statement is utter nonsense. Teams without accountability are of very very limited use. Also, accountability is not command-and-control. Accountability is fundamental to teams being successful and can be generated in many positive ways.
- Failure to accept or even use the words “manager” or “leader”. This is dogma of the most damaging kind.
- Saying Agile can be applied to any project is like saying anyone alive of any age can win any Olympic gold medal at the next games. There are some staggering examples out there. There are some projects where sequential incremental delivery is never going to be possible or applicable. The Manifesto is called “Manifesto for Agile Software Development” for a reason.
- Agile can bring some very clear benefits to the product development element of some projects – but it does not cover everything you have to do and cannot be used in all cases.
- It is not an either/or choice when deciding how best to deliver projects (i.e. whether to have project management or Agile) – we often need both, working together. Agile was never intended to be a project management framework (or method). It does not address large parts of managing projects.
- The world of, or the word “project” are not going to go away, despite this being the desire of some people.
- The elements of project characteristics that many Agile “purists” dislike most of all “e.g. scope, schedule, budget” are realities of doing business and delivering work on behalf of stakeholders and customers. Doing business is not a hobby.
- Believing you are using Agile on some non-software projects is bordering on fantasy at times, or if you really are, there is a great chance it will end badly.
- It is rarely a straight choice between Agile and a more predictive form of delivery and if there is a very clear goal from the outset Agile may even bring more risk than reward.
- It is time for professional associations (such as PMI and APM) to show real leadership around the difference between project management and product development methods.
- Just as one single example: “Planning Poker” – a method of estimating common in Agile – was derived from an estimating method called Delphi which was developed in 1944.
Contact Us Now
Email us today to find out more on how we can help you.