The word du jour in project management ‘agile’ is in stiff competition with the job title ‘Project Manager’ for misuse.
Has anyone come to you and announced they do not have any plans because they are running their project using agile methods? That should be an immediate red flag! It is common for “Agile” to be used as an excuse to not write anything down, agree on project goals, plan or use any project management basics, and “make it up as we go along” – but this is a misuse of the term “Agile”.
In this article, we will attempt to clarify a few misperceptions about using Agile to deliver projects.
Are you Agile or have you just stopped documenting your project?
In 2001 a group of programmers got together to create what became The Agile Manifesto. This (suitably short and concise) statement outlines the Agile principles:
Not going over the top, gold-plating or producing waste is a key element of Agile so it makes sense that the Agile Manifesto is short and punchy, but perhaps the brevity has allowed for misinterpretations to creep in. The most notable is probably that the line
“We have come to value working software over comprehensive documentation”
Has come to mean “Agile projects do not have any documentation” to a lot of people. This is incorrect. The statement is that working software (or product/output) should be valued more than comprehensive documentation, not that there should be no documentation at all.
Different teams, different clients, and different projects have different needs for documentation, including where Agile is used. Agile offers an opportunity to break away from the traditional, document-heavy (and sometimes document-led) ways of managing projects and instead look at a way of letting interactions, collaboration, working product and flexibility drive progress.
Some Agile projects benefit from more documentation. Some traditional projects benefit from less documentation. No one (probably!) benefits from NO documentation.
Perhaps what we should aim for is to use the MVB, or Minimum Viable Bureaucracy – whatever that means for our given project and context.
Are you using Agile because it is right for your project or as an excuse to get out of planning?
To some, it might come as a surprise that it matters when we use Agile methods, i.e what type of project work we apply it to. Not all projects are suitable for being delivered with Agile! In fact, one of the themes coming out of the Agile Principles is to not create waste by doing things “just because”, i.e we should only do things that have a real purpose and that add true value. Therefore, using Agile methods without a good reason is therefore itself un-Agile.
So when should Agile methods be used? In the simplest explanation possible the projects that are suitable for Agile methods are those that involve brand new work where it is impossible, or undesirable to define the entire scope upfront, or where it is important that we get something (like an early version or a component of the whole solution) to the end-user as soon as possible. This is not an excuse for getting out of requirements management and scope definition. If your scope can be defined with reasonable confidence it should be. Agile methods are for those instances when the scope cannot be defined, or when there is so much uncertainty that a scope definition is pointless.
If you have a specific scope that must be delivered ‘just so’ then a more traditional approach (with the relevant documentation and schedules) is more appropriate.
Are you using Agile methods properly or just not planning?
There are a number of different methodologies within the Agile family. What they have in common is that they focus less on detailed documentation and more on collaboration, exploration and adaptation. This often causes a misperception that Agile teams lack discipline, structure and just “make it up as they go along”.
Nothing could be further from the truth! In fact, in order to use Agile methods more planning, structure and discipline are needed than in traditional or “waterfall” projects.
Let me explain…
For Agile in a project context, the most common is Scrum. In Scrum, a dedicated team works together throughout the project. The project is split into chunks of time, typically called “Sprints”. A sprint should be 2-4 weeks long. No more, no less. The reason for this is that 2-4 weeks is enough (warning: if you say you are working in sprints but they are either longer than 4 weeks or have no time limit at all you are in fact not doing sprints, you’re just doing work in stages).
That means that every 2-4 weeks the team starts over:
- They identify what requirements to work on
- They plan how to deliver those requirements
- They do that work
- They close out that piece of work and evaluate how they worked and what they can do better
Each time the cycle starts over the team brings its lessons learned from the previous cycle to ensure they constantly learn and improve.
This means the team plans every 2-4 weeks, and they follow a very specific structure to make sure it works. This is why a team that uses Agile to deliver its projects requires even more discipline than one that uses traditional/ waterfall methods.
Is the team dedicated?
Woah, that seems like a loaded question, doesn’t it? This is not a judgement on your peoples’ work ethic, it is about their ability to focus on the solution and learn together through experimentation, adaption and collaboration.
As stated above Agile methods are best suited to work where the scope is not defined and that is because the true value of Agile is that it brings a structured way to experiment, learn and adapt to gradually uncover what the solution (and scope) should be. As the team works through its sprints and adapts their ways of working according to lessons learned in each sprint they will get better, more efficient and get better at understanding what is true value for the solution. This can only be achieved if the same people work together for a long period of time and therefore you need a dedicated team and not just a collection of professionals that dip in and out of the project.
☐ Is the scope truly undefinable or likely to change significantly?
☐ Are you working in clearly defined sprints?
☐ Are you using the minimum amount of bureaucracy?
☐ Do you plan at the start of each sprint?
☐ Do you review your work at the end of each sprint to ensure you continue learning and improving?
☐ Do you have a dedicated team?