I remember the first time it happened to me. I’d been an agile developer for less than a year. We were having our morning stand-up, and something felt off. The room was oddly crowded. The scrum master was having a heated discussion with a developer. Everyone else was sitting heads-down on their laptops, paying no attention.
Minutes passed. A creeping suspicion grew into certainty. This wasn’t the agile I’d read about. This wasn’t the Agile Manifesto in action. This wasn’t agile at all. It was faux agile.
With everyone from start-ups to the federal government jumping on to the agile bandwagon, there is plenty of room for variety.
Faux agile, on the other hand, is deadly, invasive, and pretty easy to spot.
The face of faux agile
Here are the top three signs of faux agile:
Stand-up failure: This is what I experienced in that crowded room. It usually happens when PMs are under the gun and anxious about looming deadlines. What should be a quick, 15-minute update—just enough to move the project forward—gets hijacked into lengthy discussions and negotiations.
A project manager who needs to drill down with a team member should talk separately with that person. A stand-up shouldn’t last 45 minutes and hold the entire team hostage.
If you can’t meet one-on-one, at least involve only the people you need. You’ve heard the story about the chicken who tells the pig they should open a ham and eggs restaurant? (“No thanks,” says the pig, “I’d be committed, you’d only be involved.”) At a stand-up, you only want pigs—leave the chickens out of it.
Estimating time, not points: It’s easy to understand why teams fall into the bad habit of estimating effort by time instead of story points. After all, you’ve been trying to estimate time since birth: When will you finish your homework? How long to clean out the garage?
The problem is, humans are notoriously terrible at estimating the time to will take to complete a task, especially a complex or unfamiliar one. Story points are a more reliable approach because you only need to gauge relative effort: Is today’s task bigger, smaller or about the same as the one you did yesterday?
Better yet, you only get better over time. In early sprints, there may be some variation in estimation. But as the team establishes velocity and accumulates benchmarks, story points become more standardized. That means you can better estimate and prioritize stories, delivering more business value.
Hint: if you’re struggling to estimate story points, your stories may be too large. Break them down. For example, if your story is about a user completing a complex form, split it into its constituent parts: the progress bar, the drop-down menu and so forth—each with its own bit of business value.
Stories without value: Stories are both the heart of the Agile process and the source of its most common mistakes.If you describe what happens in a story without also defining its business value, you’ve missed the point. Delivering business value is why Agile was created—without it, you just have a bunch of meaningless ceremonies.
It can happen when team members get a bit lazy and make assumptions. Say you’re designing a timesheet for a business client. You define a user story to track sick leave and another to track vacation days. But if that business lumps all paid time off in one category, you’ve just introduced unnecessary complexity, time and cost without adding a drop of value.
Other common story definition blunders that are a recipe for mistakes, re-work and delay:
- Stories that aren’t reviewed by the team
- Failure to define acceptance criteria or critical dependencies
- A lack of technical criteria (especially important where those criteria may not be obvious to the user—for example, is the information in that drop-down box standard text, or dynamically generated from the back end?)
- Omitting essential documentation links. Making team members hunt for details slows them down and increases the risk of conflicting information
An agile sanity check
Despite my war on faux agile, I’m not trying to claim some kind of holy agile superiority. Agile doesn’t have to be one-size-fits-all, and shouldn’t be. There is a middle ground I call “pragmatic agile.” It simply means compromising where it makes sense.
For example, imagine the product owner comes to you mid-sprint and says, “The business absolutely has to get this user story into the next release, ASAP.” An agile purist might tell her to jump in the lake; everyone knows you’re not supposed to change your development priorities mid-sprint.
But those of us who inhabit the real world understand that change happens. As pragmatic agilists, we’d estimate the effort required to build the new story and let the product owner decide what equivalent amount of work will be postponed in order to fit the new story in.
Pragmatic agile gives you a lot of room to bend—the trick is not bending so far that you actually break the process.
For me, there are only three non-negotiable principles:
- Definition of Ready: Treat a story as ready only when its business value and acceptance criteria have been properly defined, and the business, QA, and dev teams agree on the value a story is delivering.
- Definition of Done: A story is done only when it’s fully unit-tested, deployed in a QA environment, validated by QA as meeting acceptance criteria, and—critically—accepted by the business.
- Respect the Retrospective: You can’t enforce continuous learning and improvement without a retrospective to keep you honest. Retrospectives are critical to determining what you did well, so you can do more of those things, and what you didn’t do well, so you can stop those practices or improve them.
Keeping it real
There’s no need to take a dogmatic approach—that’s a recipe for failure in any field. But if you want to deliver real business value, there are a few corners you can’t cut.
The good news is faux agile is easy to spot. If your project has gone off track, know that many teams have been where you are and successfully found their way back. Be vigilant, be pragmatic and agile will follow.