Agile is great — Scrum is OK-ish; If you work on software you should really understand 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.
I’ve often been surprised how some people I talk to have a strongly negative reaction to Agile, but then as we continue to talk it becomes clear that they have problems with particular practices — like pushing the team to work unreasonably fast — that are actually in opposition to Agile values.
The problem is that many explanations 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 who 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 expensive consulting services.
Some may claim Agile is so conflated with other concepts in 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 effective teams.
In reality, the Agile Manifesto consists only of 4 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 reaction against the bureaucratic, rigid, and hierarchical mindset that permeated “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 fell on the exact opposite end of the spectrum and was usually not very effective as a result.
The Agile Manifesto establishes the following:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity — the art of maximizing the amount
of work not done — is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
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.
I’d highlight here that the Agile manifesto is not 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 the concepts above. I think most people though, if they have experience working in highly effective teams, 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 for everyone. 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”.
Of all of those frameworks none seem to be as pervasive or widely adopted as Scrum so that’s what I’ll focus on now. Scrum actually 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 (wait until I write about SAFe!), and actually is relatively simple. However, I think it definitely does have some problems living up to the values it tries to claim a 1 to 1 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 an endless stream of new features without any iteration on what has previously been released
· Teams over-rely on specialization and hand-offs 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 agility. While Scrum is OK with customization, there’s a point where you end up customizing so much that it doesn’t really look like Scrum at all anymore. For this next the part I’ll be listing things based solely on my own personal experience. I’m not claiming absolute, universal accuracy, but instead hoping to provide some additional data points for consideration as you think about your own practices.
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 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 yearlong 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 it does seem like things can go unaddressed without dedicated time for reflection. I’ve shared some of my thoughts on retrospectives here.
· Time-limited daily standups. These helped keep everyone on the same page, minimize other meetings, and uncover points where people need to work together.
· The idea of 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 either. We experimented over time with different roles and process, changing things along the way based on what seemed to work best for us.
The important thing is really 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.