There are a lot of people who get caught up in what I call “methodology wars” where they are intent on their position that 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, Kanban, or some other methodology/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.
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. 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
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.
Here’s another example – many people seem to believe that all forms of traditional project management are obsolete and irrelevant and have been totally replaced by Agile. 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 probably will 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.
This kind of thinking 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 the kind of approach I’ve tried to help students develop in all of my online Agile Project Management training courses.