I’ve worked in places where the word fragile was used to describe Agile, which was often followed by a smile or a laugh, despite no one using the term fragile having any solid experience with XP, Kanban or Scrum. When there was no direction for the project, requirements were not clear, or when things were going wrong, Agile was humorously blamed – “we’re running Agile!”, even though the project was running using a Waterfall methodology, with all its steering committees, business working groups, daily, weekly and monthly reporting, massive Gantt charts that regularly brought Microsoft Project to its knees, risk registers, and long long days.
I’ve worked in both types of projects and organisations throughout my career, and I have seen that in an Agile organisation, Waterfall is often inaccurately disparaged, and in Waterfall organisations, the word Agile is used mockingly.
I thought it would be a good idea to look at what I think are the pros and cons of Agile, starting with the cons.
Cons of Using Agile
Lack of Upfront Analysis
This is a big issue to address, and in my opinion really helps to define what sort of project methodology should be used for the project. Some projects need some upfront analysis, and sometimes the skills of business analysts, system architects, security architects, plus the expertise and acumen of business experts set the necessary groundwork for successful projects. A good example of this are regulatory and compliance projects, where it is clear what the minimum project outcomes need to be (regulations will often include this, although interpretation may be required by analysts), so a period of upfront requirements definition should be completed prior to code being written, SOPs (standard operating procedures) updated, communications send to impacted parties or training started. The actual execution of these activities might suit an interactive approach, however.
Lack of Documentation
This is both a pro and a con, but it really depends on the project and context. The Agile Manifesto doesn’t actually specify that there should be no documentation, only that working software is favoured over comprehensive documentation. But that doesn’t mean documentation should be valued, or written, or maintained. The team and their stakeholders should produce documentation where it is valuable to do so, and should never do it just to ‘tick a box’. But taking the misguided view that because you’re using Agile you don’t have to write documentation is really detrimental, and can have long lasting negative effects on the organisation.
Unrealistic Expectations of Management
I’ve seen this first hand, and it is a weird phenomenon – this idea that because you’re using Agile you’ll magically go faster within a couple of sprints (in the case of Scrum) – the stakeholders exact words were “They’ve have three sprints, make them go faster!”. The expectations of management, quite often caused by the demands made by upper management, or misguided opinions formed from some snippet or anecdote they heard from someone somewhere, are that if you use Agile you can deliver faster. This isn’t the case, and in fact the very fact that a particular expectation exists in the organisation is probably a good indicator that no project methodology will make any team go faster. Agile is supposed to empower teams to do their best work, and to work at a pace that is sustainable for the team. But it takes time to build a team that performs well, and you need the right environment for the team to work in.
“They’ve have three sprints, make them go faster!”.
Agile Frameworks are Open to Interpretation
Many of the agile frameworks are open to interpretation and are not prescriptive at all. This leads to a great variety of implementations, with varying degrees of success. This lack of prescriptiveness is part of the beauty of the Scrum Guide, for example – it specifies some things, but leaves a lot of the implementation specifics to the organisation or team so that they can find what works best for them. But this can lead to inconsistencies and confusion between teams on some key aspects, for example at Spotify, where teams were free to choose the communications paths that suited them, but across the organisation it was hard to know which way to communicate across teams.
This need for interpretation also creates another problem – you first need to make the mental shift to understand the why before you can implement the how. This shift needs to be made across all levels of the organisation as well, otherwise you encounter issues like unrealistic expectations that I talked about before.
Empowered Teams Can Become Directionless
One of the powerful aspects of Agile is empowering teams, but it is also counterproductive to tell teams that they are empowered, and expect them to understand what means, and for them to run themselves. Teams of people have a way of organising themselves and getting the work done (or imploding!), but it is a big ask to expect them to do this and to get their work done. A team really needs a good leader or leaders to be able to understand what this truly means, and how they can benefit from it. A team though can be reassured that while they can make decisions about the way they work, the tools they use and the way they solve problems, someone like the scrum master and product owner (or other leader) has a longer term vision for the team and the product they are working on.
Agile in particular requires a mindset shift to see how the same “certainty” can be achieved in a different way – don’t look to charts and reports and milestones, look to the product itself.
Agile Doesn’t Suit All Types of Projects
This is true, it doesn’t. But there is no one-size-fits-all when it comes to project methodologies. The limitations of waterfall project methodologies are well documented, and some of the criticism aimed at Agile seemed to be that it doesn’t fix everything!
But it seems that a lot of the frustration leveled at Agile is reality directed at management, and poor management at that. Despite all the available information and statistics on how to treat your staff, poor management is still prevalent and making a bad name for Agile. You just need to read some of the comments here to understand this. One comment stands out for me in the discussion: “Agile is great when it’s limited to Developers” – wasn’t that the point all along, to put developers in the driver’s seat, and get their leaders to support them in their journey of producing the product? Despite what some managers might think, a manager doesn’t create the product, the developers do.
Pros of Using Agile
Accepting The Reality of Product Development
Agile accepts that estimates can often be wrong, that delays are likely to occur, and that priorities can change. Agile also accepts that while stakeholders and users often think they know what they want, they might not always be right. Agile mitigates these issues by ensuring the items in the backlog with the higher business value are worked on first, the idea being that if you deliver those, and then the project runs out of budget or time, or get cancelled, then the some or most of the envisioned value is delivered. Contrast this with waterfall projects, where typically none of the value is delivered until later in the project’s life. If the project ends, the value might not be delivered at all.
Inspect and Adapt
This is not specific to Agile, in fact any project methodology can include practices where the team members inspect they way they work and agree on ways to improve, or experiment with new practices. Kanban, Scrum, and other frameworks all include this as a practice. The frequent examination now only improves the way the team works, it makes the team feel included in decisions that impact them, and the team also buy into their work practices and processes. Often in waterfall, a review happens after the project ends, when it is too late to make changes in the project. The lessons might be applied to the next project, but why wait that long?
Regular Software Delivery
Agile, especially Scrum is designed to regular deliver incremental improvements or additions to the functionality (or features) of the product. Scrum makes this prominent in the Scrum Guide – each iteration (sprint) should deliver a usable increment of the product at the end of each sprint.
This regular, timeboxed, incremental delivery means that changes can potentially (and I stress the potentially part!) be made at the end of each sprint, so if business priorities change, or a feature needs to be adjusted, then the team working on the product is able to make those changes in a shorter time. Contrast this with a classic waterfall approach where requirements are specified upfront, signed-off, and any changes coming afterwards go through a change request and approval process before they are made. Typically waterfall delivery takes a long time to incorporate changes into a product, if at all.
Another advantage of this approach is removing the reliance on larger deployments – smaller, more frequent deployments tend to be have a higher success rate, and a faster rollback time in the event of deployment failures – the evidence for this is in the literature on DevOps.
Stakeholder Engagement
One of the key elements of the success or failure of a project or a product is how closely the stakeholders are brought into the development. The larger the distance, the higher the chance of failure – because the less stakeholders are engaged the more likely the product being built will not be suitable for their needs. Scrum manages this through the role of the product owner, who represents the stakeholders, and through the sprint review, where stakeholders can see the completed product increment first hand and provide feedback. This feedback can then potentially be included in the next product increment at the end of the next sprint.
Agile in general manages this through transparency of the progress of the team. For example through the Kanban board which should be placed in a location that is prominent for the team’s visibility, but also for the stakeholders, so they can visually see the team’s progress, and also blockers. This transparency in both the positive (progress) and negative (blockers) creates more meaningful conversations with stakeholders, and hopefully the stakeholders can help remove blockers and impediments. One of the big issues I have seen with projects is when surprises arise – a project is reported to be on track, and then all of a sudden it is delayed – this delays and issues were always there, but hidden from stakeholders until it was too late. If the project team were more transparent, the stakeholders would have been aware of the issues earlier and would probably have helped out by removing impediments, finding the required knowledge, or managed the product priorities.
Don’t look to the milestones and drive the team to meet it, set up the team for success and they will drive themselves to the milestone.
Flow
One of the great strengths is the focus on flow – focussing on setting up the conditions for the team to be able to do what they do best. One way to look at it is to study what the typical waterfall methodologies focus on vs the popular Agile frameworks. Waterfall focusses on deliveries and milestones, and actively tracking progress against them, to make the product or achieve the goals of the project. Agile focuses on trying to give the team the skills, resources and conditions so that they are able to work to their best ability – and by doing this they will meet the milestones, and make the product or achieve the goals of the project in a more sustainable and flexible way.
This shift in mindset can be different, especially in businesses where predictability, or the appearance of predictability, is important. Waterfall methodologies, with all the tracking and reporting, gives this appearance – someone can read the project status report and see how the actual progress compares to the planned progress. However in Agile, especially in Scrum, the same person can simply look at the product itself to see the progress, and attend one of the Scrum Reviews to see the latest features added.
Conclusion
As in many cases it is not an either-or situation, it is the mindset or the way you look at things. Agile in particular requires a mindset shift to see how the same “certainty” can be achieved in a different way – don’t look to charts and reports and milestones, look to the product itself. Don’t look to the milestones and drive the team to meet it, set up the team for success and they will drive themselves to the milestone.
A note on the words Agile and Waterfall: There are a lot of different agile frameworks, so to use the word Agile as though it is a methodology is more than a bit misleading – and yet in the article I have. What I have in my mind when I say Agile in this article, I am thinking of the different frameworks available. But there is a big difference between the frameworks – take Scrum and Kanban for example. And similarly for Waterfall – when i refer to Waterfall I am actually thinking of PMP and Prince2.
