Most “agile methodologies” are checklists of practices with little or no discussion of the reasons why those practices are recommended. Instead, they offer a neat to-do list and a promise: if you check off all these checkboxes, you’ll be Agileing Correctly.
Some of these package deals are even peddled by famous software folks. Who are we to question? As a result, teams end up committing to a set of practices without thinking about the underlying motivations. This leads to a lot of conversations that are essentially:
Q: “Why are we doing this?”
A: “Because it’s part of scrum.”
That’s unsatisfying and breeds frustration.
In the real world, nobody wants to “do kanban.” They do want to be part of a high-functioning team writing great software. These agile package deals promise that.
The trouble with adopting a list of practices to increase team function is that a team is is a group of individual people in a context. A given set of practices may work great with one team and horribly on another — even if the second team is the same developers working on a similar project.
When practices are unhelpful, you can change your team to better support the practices, or change the practices to better support the team. In today’s hiring climate, the former borders on irresponsible. The latter is hard to do right, especially when all you know is the practice and not its underlying motivation.
It is critically important to know the reason behind a practice. Without that, you don’t know how to adjust when (not if!) the “stock” practice doesn’t quite work for you.
Here’s an example of how that works.
Standup
It’s on the checklist of nearly every agile methodology. Standup is where everyone meets quickly at the beginning of the day, before starting work, to talk about what they did yesterday, what they’re doing today, and any issues they’re facing.
But what if most of your team is in San Francisco and then you hire a few folks in New York? The “stock” version of standup won’t work for you anymore, because there’s no time that is everyone’s “beginning of the day” anymore.
There are lots of ways you could adjust the standup practice at this point:
1. Let the NY folks work for 3 hours before standup
2. Make the SF folks start work at 6am (ha ha!)
3. Do two separate standups in separate time zones
4. Everyone just checks in on Slack in the morning before they start work
…and many more.
Which way should you go? How should you adjust the practice such that its essence is retained? Without an understanding of the reason for the practice, you have no guidance. People vary in their underlying reasons, as well. These differences are usually unstated and lead to a lot of process arguments.
The real reason for standup is to make sure that everyone starts their work with the maximum possible information about what is happening around them. When people have more context about the work other folks on the team are doing, they themselves do higher-quality work.
The tricks here are twofold:
- People need to get the right information (i.e., helpful to their project, without dilution from unrelated info).
- You want them to get that information when it can have the biggest impact (i.e., at the beginning of the day).
Let’s see how our various options for modifying standup support (or undermine) this motivation.
Option 1 — hold standup at 9am Pacific and have the NY people work for three hours before that — is a non-starter, because we want people to get this information before they start work instead of 3 hours in.
Option 2 — hold standup at 6am Pacific — would achieve the goals of standup, but probably conflicts with the schedule flexibility that most companies want to support. Very few people can start working at 6am; even fewer people want to. Forcing the NY team to hold SF hours doesn’t work for approximately the same reason.
Option 3 — separate standups in the different timezones — is another big old NOPE as long as the folks in different timezones need context on each other’s work. Note, however, that if you can separate their work enough that information from the other team is distracting instead of helpful, this option might work.
Option 4 — put an update in Slack before working — won’t work either, because folks need access to everyone else’s updates before they start working, not just at random times throughout the morning.
What else could we do?
Is there an option that supports schedule flexibility and also supports the underlying motivations of standup?
An option we didn’t originally consider is to make the information available to the NY folks, without requiring SF to be awake early. Each person or pair in SF could record a quick video at the end of the day about what they did. (Or put a few sentences in Slack.) The next day, before starting work, the NY folks can catch up on what the SF folks did via those updates. Then do normal standup at 9am SF time, with everyone, to process questions & blockers.
Evolve or Die
You will have to evolve the stock set of agile practices for each team, and even on the same team over time. Many teams don’t, though, and as a result, folks get really frustrated because agile seems pointless. I’ve even seen outright hostility towards practices that, if tweaked slightly, would start delivering the originally-promised benefits.
Agile isn’t a checklist. Say it with me:
Agile isn’t a checklist.
Agile is a set of philosophies focused on maximizing relevant information. These philosophies lead, in many cases, to a similar set of practices. But all practices must evolve over time.
When they don’t, when they get disconnected from their grounding philosophies, they become make-work and start appealing only to the unthoughtful folks who want a set of rules to enforce. And believe me, you do not want to attract those people to your projects.
Talk about the motivations AND the practices.
We could avoid a lot of the frustration people have with agile if we focused more on the reasons for the practices. Any time you’re discussing a practice, ask out loud: what are our goals with this practice? Why do we do it? What benefit does it give us? What benefit could it give us?
As developers we often get down in the weeds and focus a lot on the code we’re writing. But building great software is as much about people as it is about code. We have explicit standards for our code; our processes are essentially our standards for communication.
Make sure all your standards are serving the right purpose, and you can do amazing things together.
