Shallow Agility

At its core, Scrum—the default agile implementation—is a definitional framework. Of course, it is more than that. But definitions are an integral part and are the aspect that most project members in agile organizations are familiar with.

In organizations unfamiliar with agile principles and, in particular, in change-avoiding organizations, implementing Scrum amounts to implementing the definitional scheme provided by the Guide. In these contexts, a project or an organization is said to ‘have adopted agility’ if it introduced ceremonies and artefacts. I call this approach Shallow Agility.

Shallow Agility is good if understood as a starting point, i.e. when you’re aware that at this point, you’re just halfway through implementing Scrum proper. Its drawbacks come with these side effects:

1. Shallow Agility gives a false impression to management and external stakeholders as to the degree of agility that’s been reached.

2. It fosters misunderstanding between project members where some may come to false conclusions about the work culture based on the alleged fact that Scrum is said to have been implemented in a project.

3. It increases the likelihood of barriers of real change.

4. It obscures the benefits of agility, especially among managers.

Ad 1: Introducing agile project management principles in an organization is never an aim itself. Rather, these principles are introduced into organizations for specific reasons, namely, to overcome problems associated with more traditional project management. (After more than 30 years, Scrum as the most popular agile framework can itself be considered establishment. In many organizations outside of regulated industries, it is the default modus operandi. Still, even today it is common practice to describe it as a ‘modern’ approach compared to its ‘traditional’ rivals such as Waterfall.) If you’re misled about how much agility you implemented by adopting the definitional core, you might very easily be also misled about how well you’re tackling the problems that you meant to overcome.

Ad 2: This is particularly relevant in project contexts with high fluctuation. New team members might expect to find an agile culture in an environment that is said to ‘work according to Scrum’. But that might not necessarily be the case in Shallow Agile projects, where the underlying culture could be as traditionalist as before. This might lead to grave misunderstandings as to how things work in that project—ironically, this even includes the ceremonies and artefacts themselves.

Ad 3: If Shallow Agility is not understood as a starting point but rather as an endpoint of an agile transition, it might hinder real change. People might say things like: “What do you want? We are already working according to the book!” The worry here is that if you point out inconsistencies in a given agile implementation, even though that project adopts workbook definitions, you might be some kind of troublemaker, a Scrum Nazi of sorts. In a change-averse environment, people might even use these ‘misunderstandings’ as a communication strategy: Framing an advocate of genuine agile change as an overambitious pedant.

Ad 4: The benefits of agility lie in its ability to overcome the problems associated with its non-agile alternatives. If your business environment doesn’t suffer from these problems, there won’t be any need to adopt agility in the first place. And then you shouldn’t adopt it, even it is in line with the trend. If, on the other hand, Shallow Agility allows you to achieve what you sought to achieve with a project management framework, your organization probably didn’t lack agility. Before implementing a change, first do a proper problem analysis.

Ask yourself why you want to become an agile organization. Be aware of internal barriers. Be as authentic as possible: Rather than implementing Shallow Agility, consider implementing a ‘tamed’ version straightaway (could be custom-made). If Shallow Agility is your starting point for a longer journey, be aware that some parts of, for example, Scrum are atomic. They are either fully implemented or not at all. This concerns increment quality, DOR, DOD, etc. Also, keep in mind the prerequisites of full-scale agility: management support; training; an experienced facilitator; appreciation of agile benefits; etc.