Methodologies that can be used for agile project management
Agile approaches to software and projects are becoming more and popular. People are starting to see that in the battleground of software development, agile is winning. So what are the methodologies that can be used for agile project management? This article will give you a quick overview. And talk about the pros and cons of each. So you can see which one is best for you.
What is agile software development
Agile is a modern approach to software development. It started in the 1990s, and was defined in the Agile Manifesto. This document was written at a gathering in Utah in 2001.
The agile manifesto describes the four values and 12 principles of agile. In summary, agile rejects the big, slow, plan-driven approach that was traditionally used. Those ideas came from project management, which came from civil engineering.
Instead, agile favours working in very small cycles. And repeating (iterating) those cycles over and over. So instead of a single big design phase, then a single big build phase, and test phase etc. Agile instead recommends many small cycles of design, build, test and so on.
Agile cross-functional teams
Instead of big silo or functional specialist teams, agile instead recommends small cross-functional teams. So you have everyone in the team who you need to deliver a working increment.
This reduces dependencies and handoffs. And this cross-functional team includes a “business” person. No more throwing requirements over the wall to developers. They are on the same team!
As the agile manifesto says, “business people and developers must work together daily during the project”.
What is agile project management
Some people have tried using the ideas and principles of agile, in a software project context. The result is often called Agile Project Management.
It was clearly explained in the classic Jim Highsmith book, “Agile Project Management: Creating Innovative Products“. I’d recommend reading that if you want to properly understand these ideas.
The problem with project management
In traditional project management, you try and fix scope. So people know up-front what they are getting. You lock down and plan out the scope at the start. You also set milestone dates. So you are fixing the time too.
If you think about the “Iron Triangle” of Scope, Time and Cost, this only gives you cost as a lever. So if it looks like you aren’t going to get all your scope or aren’t going to deliver on time, you can spend more money to get more done.
The problem with this, is that cost is not always an effective lever.
Remember the infamous “baby” principle of project management? It says “you can’t get nine women to make a baby in one month”. This means that some tasks just can’t be sped up or transformed by throwing more money and people at it.
Also, there is Brooks’ Law. This is named after Fred Brooks who wrote the influential book “The Mythical Man Month” in 1975. Brooks’ Law says “Adding people to a late project makes it later”. You might have seen this for yourself.
Random people get thrown into a team late into a project. Some managers decided to do this to help it get over the line. But it actually just makes this worse. These new people have to be onboarded, trained, equipped and given tasks. They don’t have the skills and domain knowledge of others. So they end up bugging people and asking lots of questions. Their work often isn’t as high quality so there are more bugs and rework.
Now everything gets bogged down and the schedule falls even further behind. So more people get thrown in and things get even worse.
The agile project management approach
The agile approach starts from a very different place. It says that fixing the scope was the big mistake in the first place. This is a bad idea for two reasons.
First, we don’t really know what we want upfront. Especially when it comes to software projects. Software is hard to imagine and can be easily changed. So we are better not defining it in detail upfront. Instead, we should loosely define some goals. And work with a dynamic (changing) backlog of work. Which we update as we go and learn.
Second, fixing scope means we end up in that tough situation above. Where we run out of time and try and squeeze it all in by throwing money at it. Which usually doesn’t work.
If we flex on scope, we can fix time and cost. This gives people more certainty, not less. Since we can promise when it gets done and how much we will spend on it. And see how much scope we get for our spend.
Performing multiple smaller releases instead of one big one makes this even better. Since we can figure out which scope items or features are better value than others. And use those learnings to make better decisions about future scope items.
Methodologies that can be used for agile project management
Here are some methodologies for agile project management. So you can choose the best one for your context.
Scrum
Scrum is not a methodology, but is actually a framework. That might sound like a semantic point, but it is important. A methodology gives you a specific process to follow. It tells you who to have do what work, when to do that part, when to move it to another part.
A framework is a set of principles and abstract rules. It describes the basic skeleton within which a team finds and builds their own process. Scrum is exactly that.
I actually think Scrum is a great framework for an organization moving to agile. It provides good practices like a dynamic backlog, a cross-functional team, and frequent inspect / adapt cycles.
But it is important to note what I mentioned above. It is not really a methodology. If you are looking for detailed steps, you won’t find them in Scrum.
Kanban
Kanban, like Scrum, is more of a framework than a methodology. It is all based on improving the flow of work through a system. Kanban is all about visualizing work, usually into lanes and columns. Then you can identify problems, bottlenecks, and opportunities for improvement. It is a framework for evolutionary change through continuous improvement.
One area where it is different to scrum is that: evolutionary. In Kanban, you start just where you are right now. You don’t change anything. Scrum starts off by making lots of changes.
So Kanban can be an easy set of ideas to add. It is easier to implement without tough change. But you want to overlay it on top of some other framework or methodology. It won’t give you a process out of the box for agile project management.
If you want to learn more about Kanban, start with this great book by David Anderson. it is considered the classic text on the subject. There is also more information at the Lean Kanban University website.
SAFe (Scaled Agile Framework)
Next up is SAFe, which stands for Scaled Agile Framework. Despite what the name says, it is more of a methodology than a framework. It comes with a big complex diagram, lots of complex systems and processes, and fancy names like Release Train Engineer, Big Room Planning, and Operational Value Streams.
SAFe is designed for large organizations that want some pretty solid processes, governance and guardrails. It is especially designed for areas where you have many teams (5, 10 or more) working on one product or platform. So you need to manage many dependencies and complexities.
Personally I am not a huge fan of SAFe. I do not believe it reflects the original intention of agile. Which is to simplify, to remove dependencies (rather than “manage” them), and to empower people. So they can manage their own processes and work. Instead of having it forced on them.
But you might find SAFe useful depending on your context. You can read more about it here. Just beware: it is infamous for being a “certification factory”. SAFe is always changing its core model and demanding people upgrade and certify to the latest version. Which costs a lot of money.
Lean
Lean is more of a philosophy than a methodology. It is very old (it came from Japan in the 1950s), and very influential. Many of the core ideas in Lean (removing waste, reducing WIP / Work In Progress, pull rather than push) are found in agile. Like Scrum though, Lean won’t give you a process or methodology to follow. So you’ll probably need something to help you there.
I do really recommend learning more about Lean, though. Since its ideas are so valuable and influential. The Poppendiecks’ book “Lean Software Development: An Agile Toolkit” is a good start. “High Velocity Edge” is essential reading also.
DSDM
DSDM stands for Dynamic Systems Development Method. It is somewhere between a framework and methodology. While it is fairly general and is intended to be used in or outside of software development, it is also more prescriptive and detailed than Scrum or Lean.
DSDM is well suited for an organization that is struggling to move to agile. Unlike Scrum, it keeps Project Managers (they don’t exist in Scrum). It also doesn’t have an empowered Product Owner in the development team. It has an embedded “Business Ambassador”, who is a proxy for a product owner.
The famous “Snowman diagram” explains team structure in DSDM:
You can read more about DSDM on the Agile Business Consortium website. They are the owners of this agile framework / methodology.
Summary
I hope you found this overview of agile project methodologies helpful! In summary, I would recommend using Kanban principles, overlaid on a framework or methodology such as Scrum or DSDM. I would not recommend SAFe, since it violates many of the values and principles of the agile manifesto. Do you have any further questions or ideas? Let me known in the comments below! I will read and reply to every one.
