I often see a discussion about “What is the best methodology for a Project?” or “What methodology do you like the best?” I don’t think that’s an appropriate way to look at methodologies or frameworks at all. No methodology or framework is inherently “better” than all others and you shouldn’t pick a particular methodology just because you like it better. For example, saying “Agile is better than “Waterfall” is similar to saying “A car is better than a boat”. Each has advantages and disadvantages depending on the environment that you are in.
There are a lot of people who get caught up in what I call “methodology wars” where they are intent on their position that
- “My methodology is better than your methodology” and,
- Whatever methodology they advocate is better at solving any problem you can possibly imagine than any other methodology.
You can see this in the many “agile versus waterfall” discussions and other discussions where SAFe, Scrum, Kanban, or some other methodology or framework is positioned as a “silver bullet” for any problem you might have. They also tend to ignore all other methodologies as obsolete or irrelevant.
What’s the Real Truth?
The truth is that all methodologies and frameworks have strengths and weaknesses depending on the situation and the right approach is to fit the methodology to the situation rather than force-fitting a problem to some pre-defined methodology. Sometimes that may require:
- Customizing a methodology to fit the problem, and/or
- Using a combination of elements from different methodologies. For example, in an Agile environment, it might make sense to use a hybrid approach that blends Agile and traditional, plan-driven project management in the right proportions to fit the situation
Why Is This Difficult?
It’s a lot more difficult to do that, but it can be done – it requires:
- Knowledge of a broader range of methodologies and frameworks,
- Ability to see the strengths and weaknesses of those methodologies objectively, and
- A deeper understanding of the principles behind those methodologies to know how they might be combined to fit a given situation
Why Don’t More People Do This?
Many people are looking for simple, “cookbook” solutions that they can just follow through mechanically with a step-by-step process. For example, there are simple project management approaches that are largely built around following defined checklists and using fill-in-the-blanks document templates. It is a simple, mechanical process that doesn’t require too much intelligence and judgement. Unfortunately, that kind of process isn’t very effective in today’s world.
Here’s an example – I just finished adding some material on “Lean Software Development” to my online training courses on Agile Project Management. Lean is not widely-used as a standalone methodology and it clearly didn’t win the “methodology wars” but the principles behind lean are the foundation for all Agile methodologies including Scrum. If you look at the principles behind lean, they may appear to be at odds with other Agile methodologies:
- Lean heavily emphasizes eliminating waste in a process to improve efficiency, while
- Agile is more heavily-focused on taking a flexible and adaptive approach to meet customer needs and is less concerned about just eliminating waste
If you pursued each of these goals in isolation and to an extreme; they might be in conflict with each other, but if they are blended together in the right proportions to fit a given situation, they can be very complementary rather than competitive.
Examples of Blending Approaches
Agile and Waterfall
Sometimes it may require combining two different methodologies or frameworks that appear to be in conflict with each other. Agile and Waterfall is a perfect example. Many people erroneously assume that
- All forms of traditional project management are obsolete and irrelevant and have been totally replaced by Agile, or
- There is a binary and mutually-exclusive choice between those extremes and there is no way to blend the two approached together
That’s not the case at all. On the surface; if you look at traditional, plan-driven project management and Agile, they may appear to be at odds with each other; and if each approach is pursued in isolation and to an extreme, they could be in conflict but that shouldn’t preclude blending the principles behind the two approaches together in the right proportions to fit a given situation. Here’s an article with more detail on that:
Lean and Agile
There’s a similar relationship between Lean and Agile. If you pursued each of those approaches to the extreme and tried maximize what you would get out of each independently, they would tend to pull you in different directions:
- Lean emphasizes reducing “waste” and Agile emphasizes flexibility and adaptivity to meet customer needs
- Those two approaches are not totally compatible with each other; however, they are not necessarily incompatible either. It just requires some skill to blend them together in the right proportions to fit a given situation
However, “lean thinking” is an inherent component of Agile; and when used in the right proportions, they can beperfectly complementary to each other. Here’s an article with more detail on that:
Scrum and Kanban
Some people compare Scrum and Kanban and will try to argue that Kanban is better than Scrum (or vice-versa). Anyone who tries to make that kind of argument is just biased towards one or the other and doesn’t understand:
- How they are different, and
- Why it would make sense to use one and not the other
They both serve very different purposes and have advantages and disadvantages depending on how they are used. Here’s an article with more detail on that:
When they are used together in the right proportions, they can be very complementary. For example, Kanban is used many times for managing the flow of work within a Scrum sprint and it is very well-suited for that purpose.
We live in a complex world today, where simple, canned, “cookbook” solutions may no longer work effectively and we need to learn to fit the methodology or framework to the nature of the problem rather than force-fitting a problem to some sort of predefined process that may-or-may-not fit. Doing this effectively requires a mode of thinking that is commonly called “Systems thinking” – it requires seeing a problem in a holistic context and understanding the dynamics of the problem at a deeper level rather than mechanically imposing a predefined solution on a given problem. This is exactly the kind of approach I’ve tried to help students develop in all of my online Agile Project Management training courses.
You can find related articles on the topic of “Hybrid Agile Methodology” here:
You will find much more detail on this in my Online Agile Project Management Training.