Scrum is not Agile!

There, I said it! Okay, okay, before you all bring out the pitchforks, please allow me to explain what I mean: Scrum is not the same as Agile, Or Scrum is not the only Agile framework; there are many more Agile frameworks, and one should not use the words Agile and Scrum interchangeably; Or one should not assume Scrum when someone says Agile. That’s all, that’s all I am saying. (Yes, the title is a clickbait!)

Quite often, Agile teams assume Scrum as the de-facto implementation. Or folks think ‘Scrum’ in everyday conversation when discussing software development practices when someone mentions ‘Agile’. Granted that Scrum is probably the most popular agile framework. Some might even say that Scrum brought popularity to Agile methodologies, but is it enough to make the name interchangeable?

Agile Frameworks

There are many Agile frameworks to choose from, applicability of these frameworks varies based on context.

Here is a list of a few of the frameworks:

1. Kanban: It focuses on visualizing the work and ensuring fast response time (just-in-time production).
2. Lean: Lean can be seen as a parallel methodology to agile frameworks. In fact, even Kanban can be seen as a type of Lean methodology; after all, both originated in Toyota. Lean focuses on reducing waste and just-in-time production.
3. XP/eXtreme Programming: Probably the oldest one among the popular agile frameworks to talk specifically about software development practices (many agile frameworks claim to be agnostic of software development). It takes a ‘values, principles, and practices’ approach and focuses on communication, simplicity, feedback, courage, and respect.
4. FDD/Feature Driven Development: Focuses on building the software in a feature-by-feature plan-design-build cycles.
5. Crystal: A group of frameworks that vary based on team size and also includes ways to support huge teams. It focuses on communication and shorter releases.
6. DAD/Disciplined Agile Development: A set of practices and guidelines that can be chosen based on a team’s contextual requirements.
7. DSDM/Dynamic System Development Method: Sought as a replacement/enhancement over RAD, focusing more on business requirements and timely deliveries.
8. Agile Modeling: Although it can be argued as not an independent framework, it poses as a set of values-principles-practices to be coupled with other agile methodologies.
9. RAD/Rapid Application Development: This May or may not be considered an Agile framework, as it was developed as a replacement for the older Waterfall model. It focuses primarily on rapid prototyping and cycles through 4 development phases.

There are plenty more frameworks, by the way. There are various inspirations for creating different frameworks, and they try to tackle different aspects of software development. At the same time, a few even fail to differentiate themselves!

There have been many attempts to scale some of the more successful agile frameworks to span multiple teams. Some even claim to be applicable for large-scale organizations. SAFe, Scrum of Scrums, and LeSS are a few examples. There are conflicting views on the effectiveness of these and such attempts. Personally, I fail to see the value, as they seem to be counterintuitive. For example, I fail to see how any of those frameworks bring the customer closer to the team or facilitate communication.

There is no such thing as Agile

I think we should talk about one more thing concerning Agile; there is no such thing as Agile! In other words, Agile is not a thing. It describes a thing; it is an adjective, not a noun! So there is no Agile with a capital “A” in a traditional sense. And probably, there was not meant to be either; in his talk titled ‘Agile is Dead,’ Dave Thomas famously shared his views on this topic.

The commercialization of the agile methodology, the ‘agilify-anything’ approach driven corporate-level Agile frameworks, the low-effort certification programs, the ceremony-focused rigid practices, and the rampant rise in the incompetent but certified coaches give a false sense of agility to teams and companies. There is nothing wrong with following a framework and practices described in a framework. Still, the team must understand that the point of the framework is not the framework itself but the agility it brings to your delivery practices.