Earlier this year, I started writing on the limitations of Scrum as a result of articles I had come across. In my first article, I was critical of the individuals (largely Scrum Masters) responsible for guiding Scrum adoption in organizations. In my second article, I took a look at the system (and those who create them – leaders and managers) and wondered aloud as to whether the organizational constructs actually supported Scrum being effectively leveraged in our organizations.
It is possible, readers came away from my first two postings with the impression I believe nothing is wrong with Scrum – it’s perfect – and dubbed me a Scrum zealot of some sort. Well in case you did, maybe this last post will leave you with a different impression. Maybe.
Scrum is defined as: a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. This definition would seem to imply that as long as a team is in the business of delivering products, Scrum should be a fit. Is it really as simple as that?
I rarely hear productive dialogue around the scenarios when and where Scrum (the process framework itself) isn’t a good fit for a team developing products, so I’ll attempt to start some dialogue here. In my opinion, for Scrum to be a fit, the holistic nature of the work the team is doing needs to be in alignment. When could the nature of the work not be a fit? I’m going to attempt to identify these situations via the lens of the VUCA framework. VUCA stands for volatility, uncertainty, complexity and ambiguity.
Volatility refers to how much change is occurring. In the context of Scrum, I see this as how does the rate of change impact how we plan. Let’s consider Team A that gets to their Sprint Review and identify they did not deliver what they had planned because they had to deal with new work that emerged during the Sprint (not because they planned poorly which many teams do!). Or maybe every Sprint there is a discussion around canceling the Sprint because the Sprint Goals keep changing due to emerging market factors. Maybe emergency customer requests or defects have to be addressed in order to keep major accounts. The nature of their work is so volatile, they cannot plan any further out than maybe a day or two. In this case, Scrum may not be an appropriate fit.
Uncertainty is focused on the degree of predictability we have. Scrum works well for handling unpredictability around what will satisfy the customer because the framework requires customer engagement throughout the process. On the other hand, Scrum expects certainty around what the team will be working on in any given Sprint and the goals they have. If we cannot arrive at a level of certainty around what exactly we will be working on in a Sprint (maybe due to volatility), Scrum may not be a fit.
Conversely, if there is little uncertainty about what needs to be delivered such that (for example) customer engagement has little impact on delivering a work product that meets the desired goals or if the team just needs to plow through a laundry list of items and ordering (or prioritization) is not particularly important or if potentially releasable increments are not needed during the duration of development, then Scrum may not be valuable as a framework for delivering products.
Agile frameworks and methods are designed to deal with the complexity involved in the development and delivery of products. But what if your work is not complex? What if it’s simple or complicated? While complicated work is difficult/hard, we know the steps we need to take and the “end is largely known from the beginning”. Simple work is like complicated work except we don’t have the ‘difficulty’ property present. In either case (with simple or complicated work), the amount of discovery that occurs while we are doing the work is minimal and hence the benefits of Scrum itself is probably minimal. If we don’t need to inspect and adapt, then the events Scrum provides for this are probably overhead.
Ambiguity has been described as the presence of “unknown unknowns”. It seems to me “unknown unknowns” are always present except in the simplest of endeavors. The question we need to answer is this: how much of our work is characterized by ‘unknown unknowns’? It’s my personal opinion that Agile (and hence its frameworks like Scrum) work best in situations where the work has a balance of ‘known knowns’, ‘known unknowns’ and ‘unknown unknowns’. When ‘unknown unknowns’ is the predominant characteristic of the work, there may be better frameworks for managing such work.
So yes, it’s quite possible, that the nature of a team’s work may be such that the Scrum framework is not the best framework for managing the work. We can only come to this conclusion when we take the time to objectively profile our work. Objectivity is key here and worthy of another post.
It’s at this juncture I need to remind us that Scrum (and Agile by extension) are not THE goal. Your organization has business goals that are extremely important. Your team has hopefully been asked to own making a contribution towards these goals. Agile (and its frameworks and methods) may enable you achieve those goals in a manner that is fulfilling and rewarding and yet it is important that we continuously assess, with a critical eye, the frameworks and methods we have chosen and make sure they remain a fit.
I find many teams and organizations give up on Scrum because it makes them uncomfortable as it shines a light on both team and organizational dysfunctions, NOT because the nature of their work is not a fit. To make matters worse, they then distort Scrum by redefining it to meet how they would like to work. When we give up on Scrum or any other frameworks for the wrong reasons, we have placed a self-imposed cap on what we could have accomplished. Our new approach doesn’t really solve our problems; it just introduces a brand new set. Isn’t that a crying shame?
I hope these three articles on Scrum provide you with thinking tools that help you choose ways to work that are both fulfilling and extremely effective.