Don’t fall for Faux-gile

I remember the first time it happened to me. I’d been working on my first Agile team 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 one of the developers. 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-gile.

It was far from the last time I had this experience. Now that Agile has proven its business value, it’s gone mainstream, embraced everywhere from start-ups to the federal government. But popularity comes at a price. Too often organizations want to say they’re doing agile more than they actually want to do it. 

To make matters worse, Faux-gile can sneak up on you, and you don’t always realize your team has fallen into bad habits. But if you know what to look for, there are clear signs to spot. 

The face of Faux-gile

Here are the top three signs of Faux-gile: 

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 project progresses, and you accumulate more benchmarks, your estimates usually become more precise.

If you find yourself consistently underestimating effort, it may be a sign that your stories are too large. In that case, try breaking them down into smaller components. 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.

Poorly defining your stories 

Stories are the heart of the Agile process and the source of many common Agile mistakes.

One of these is describing what happens in a story without clearly defining its business value. Delivering business value is the whole point of Agile. If you aren’t doing that, the rest of Agile is nothing more than meaningless ceremony.

I’ve often seen this happen when team members rely on prior experience rather than thinking through the business needs of their new project. Suppose you’ve designed a timesheet app for a company that distinguishes between sick leave and PTO. 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-gile, 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-gile 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.