I recently participated in a discussion on LinkedIn that was initiated by someone who suggested several possible roles for a Business Analyst in Agile/Scrum that didn’t seem consistent with Agile principles at all. I believe that modifying and extending Agile and Scrum may be necessary to fit the situation, but it has to be done intelligently and I think it takes some skill to figure out what makes sense and what doesn’t.
Finding the Right Level of Customization
This can be difficult to find the right compromise between:
- Rigid Adherence to Agile and Scrum, and
- Simply “winging it” and using completely adhoc, unproven processes
Rigid Adherence to Doing Agile and Scrum
We all know that there are Agile “zealots” who insist on rigid adherence to doing Agile/Scrum “by the book” without any deviation. That often results in a mechanical approach of doing Agile “by the book” rather than adapting it to fit a given situation
Adhoc, Unproven Processes
On the other hand, there are people who “wing it” and treat Agile/Scrum practices like a “cafeteria menu” where you can pick and choose the principles and practices you want to adopt and which ones to ignore
What’s the Right Approach?
Neither one of those approaches makes sense in my opinion but there’s a lot of “gray area” between those extremes. So, how do you determine what makes sense and what doesn’t make sense? I don’t think there’s a clear answer to that question but there are some guidelines that I think are useful. There’s a big difference between:
- Taking a proven framework like Scrum and modifying it and extending it in a way that is consistent with Agile principles and practices, and
- Just starting from scratch ignoring Scrum and all other Agile methodologies, principles, and practices and attempting to put together some kind of ad-hoc approach
In many cases, if it is done correctly; it may not really require modification of the Agile/Scrum framework at all because the framework, itself, is intended to be flexible and adaptive and it can fit a wide range of situations without significant modifications. In fact, that is why Scrum is called a “framework” and not a “methodology”. It’s mostly a matter of using the framework intelligently rather than doing it rigidly and mechanically.
An Analogy to the Martial Arts
I think that there’s a lot we can learn from the martial arts. There’s an analogy to the martial arts that I think fits pretty very well:
- There are a variety of different kinds of martial arts but they all have some similarity and they all require some level of knowledge, proficiency, and discipline in how they’re practiced to be good at it
- You don’t just go out and start doing martial arts without any training and experience to know how to do it.
Levels of Mastery in Agile
Check out this article I wrote on “Levels of Mastery in Agile”:
It is based on a model of stages of maturity in martial arts called “Shu-ha-ri” which is described here:
The essence of the “Shu-ha-ri” martial arts philosophy is that you should be at a level of proficiency before you start improvising. A basic principle is that “improvisation without knowledge and proficiency is just amateurism“. I think that is also very applicable to Agile. It takes a considerable amount of skill to figure out how to modify and extend Scrum and other Agile methodologies to fit a given situation.
The key message is that people shouldn’t underestimate the level of skill it takes to modify and extend an Agile/Scrum approach to fit a given situation. That’s a key advantage of some predefined frameworks like SAFe but, on the other hand, even with some of the predefined frameworks, it takes some skill to adapt an Agile approach to fit a business and there is no “silver bullet”.
You can find related articles on the topic of “Choosing the Right Approach” here:
You will find much more detail on this in my Online Agile Project Management Training.