Agile is great. Scrum is OK. Know the difference.

Agile software creation is pretty great. If you don’t think so, it might be because you’ve been introduced to the concept in a confusing way. Or at least that’s what I’ve come to believe based on my day to day discussions with others in the software world.

The problem is that many explanations of the concept fail to distinguish between Agile and Agile-related frameworks (like LeSS, SAFe, Scrum, etc.) and practices (writing user stories, sprints, backlogs). Without a clear picture of the boundaries between these ideas, it’s easy to attribute the flaws of a specific practice to the entire concept of Agile.

The consultancies that are hired for most Agile trainings actually have a vested interest in perpetuating this confusion. When they can conflate their specific frameworks and teachings with the overall concept of Agile, they can lead organizations to depend even more on their costly services.

Some may claim Agile has become so conflated with other concepts om this way that it has lost its value, but I don’t think this is fair. If you can disambiguate the confusion (which I hope to help with), the core concept of Agile remains an extremely valuable tool for thinking about what differentiates highly effective teams.

In reality, the Agile Manifesto consists only of four values and 12 principles. It’s important to note that these values and principles didn’t emerge in a vacuum. They were an encapsulation of what seemed to be working well and a reaction against the bureaucratic, rigid, and hierarchical mindset that characterized Waterfall-style software development in most corporate environments. I won’t elaborate on the problems of Waterfall too much here. For now, just keep in mind that for every value and principle expressed as a part of Agile, Waterfall pretty much falls on the exact opposite end of the spectrum and is usually not effective as a result.

It’s easy to attribute the flaws of a specific practice to the entire concept of Agile.

The Agile Manifesto establishes the following:

Agile values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Agile principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

That’s it. Everything you really need to know about Agile is right there.

The Manifesto isn’t prescriptive about specific practices. It doesn’t tell you precisely what to do, when to do it, how to do it, or what kind of tools to use. Instead, it sets some general guidelines to think about as you figure out what makes sense in your context. If you’re looking to find fault in Agile (which is certainly possible) you should be able to express your thoughts in a way that relates to what’s written above. I think many people, though, will recognize the majority of the content as so immediately intuitive that it almost seems too obvious.

However, just because these ideas are presented simply does not mean they are simple to internalize or to bring into practice. It’s easy to read something like “self-organizing teams” and nod along without fully realizing how radically different that is from workplaces where managers dictate team structure and tell their employees how work should be completed.

Basically, changing culture and mindset is hard. Telling people to follow a predefined set of steps and processes is easy. Project management organizations and consultancies with long histories of selling such processes didn’t immediately evaporate when Agile started to become more popular as a value system. They wanted to continue their established business models, so they doubled down on selling “Agile frameworks.”

The Agile Manifesto doesn’t tell you precisely what to do. Instead, it sets some guidelines to think about as you figure out what makes sense in your context.

Of all of those frameworks, none seem to be as pervasive or widely adopted as Scrum. Scrum technically predates the Agile Manifesto, and Agile was in part inspired by what worked well about frameworks like Scrum. So the good news is that Scrum isn’t completely terrible (unlike SAFe, which I’ve talked about here), and actually is relatively simple. However, I think it definitely does have some problems living up to the values it tries to claim a one-to-one association with.

If you need an introduction to Scrum, you should check out the relatively short Scrum Guide before reading more.

One major difference from Agile is that Scrum actually is prescriptive about what it suggests you do and how you structure your work. The danger of the prescriptive approach is that a team can pick Scrum up and start “doing” it without anyone having changed mindset or values at all. This sort of Scrum-but-not-actually-Agile state of being can be pretty rough, and I think is paradoxically the root of much anti-Agile sentiment. Problems in this sort of environment can manifest in a million different ways including (but not limited to) the following:

• Scrum Masters end up acting like project managers who try to maintain the status quo — controlling instead of supporting the team
• Teams may over-focus on rushing to get work “done” without thinking about the value or quality of that work
• Sprints end up churning out an endless stream of new features without any iteration on what has previously been released
• Teams over-rely on specialization and handoffs without finding ways to parallelize or cross-pollinate skill sets within the team
• Managers enforce process consistency across Scrum teams, limiting the ability of individual teams to self-organize
• Teams are set up without actually having the skill sets they need
• Retrospectives happen, but people give up on surfacing problems because they never see things change

These are all pretty clear examples of Scrum “done wrong,” but they aren’t necessarily an indictment of Scrum itself. What I think is a little fuzzier to identify are places where the framework “done right” seems to conflict with Agile. While Scrum is okay with customization, there’s a point where you end up customizing so much that it doesn’t really look like Scrum at all anymore.

Here I hope to provide some additional data points for consideration as you think about your own practices, based on my personal experience.

Scrum things to (maybe) ditch

• Sometimes we decided to have no dedicated Scrum Master role. Instead, the team can self-manage and rotate Scrum Master responsibilities on a periodic basis. This adds an additional slot for a valuable individual contributor and creates a better sense of ownership over the process within the team. I wouldn’t recommend this for a team that has low Agile literacy or that needs lots of protection from outside interference.
• Occasionally, I’ve worked on teams where we didn’t need a dedicated product owner. Instead, product ownership was distributed within the team. As the designer on the team, I leaned in pretty heavily to fill that gap. If you try this and start having trouble getting consensus, a PO designation may make sense to centralize decision making.
• We ditched most of the concept of sprints and sprint planning. Sprints help teams that are used to year-long cycles release more often, but if you already prefer releasing frequently they aren’t as useful. Mid-sprint change is discouraged with sprints, but Agile is supposed to encourage change! We switched to more of a continuous flow of tasks on a Kanban board. This also made it much easier for me as a designer to slip in smaller UX tweaks as needed.
• We totally ditched the rigor around stories, epics, features, etc., and just tracked things that we needed to do at the level that was most natural. This made tracking simpler and easier to understand and didn’t seem to make us any less organized or customer-centric. If anything, it allowed us to focus more on customer value and less on volume. To be fair, epic/feature/story nomenclature isn’t an official part of the Scrum Guide but is a very common practice.

Scrum things to (maybe) keep

• Regular retrospectives. Day-to-day process improvement is great, but things can go unaddressed without dedicated time for reflection. I’ve shared some of my thoughts on retrospectives here.
• Time-limited daily standups. These help keep everyone on the same page, minimize other meetings, and uncover points where people need to work together.
• Having a team-owned, granular, and regularly refined backlog as the mechanism for prioritizing work. This made it easy to keep track of work and manage shifting priorities elegantly.
• Dedicated cross-functional teams to reduce outside dependencies. This is essential for working without always being in a state of waiting or rushing.

There are definitely more items I could list, but I think this communicates the general thinking behind our decisions about why we continued or abandoned certain things. We didn’t make all these decisions at once. We experimented over time with different roles and processes, changing things along the way based on what seemed to work best for us.

The important thing is just to think consciously about what you are doing and how to do it better. I think concepts like Agile make it easier for us to have those discussions, and if this article provides you with a little more context for solidifying or verbalizing your own thoughts on the matter, I’ll consider it a success.