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.
We all know that there are Agile “zealots” who insist on rigid adherence to doing Agile/Scrum “by the book” without any deviation. 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. 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 here’s 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
- There’s an analogy to the martial arts that I think fits pretty 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. Check out this article I wrote on “Stages of Mastery in Agile”.
It is based on a model of stages of maturity in martial arts called “Shu-ha-ri”:
The essence of the “Shu-ha-ri” martial arts philosophy is that you should be at a level of proficiency before you start improvising and “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”.