Agile heresies – or paths we need?

Don’t get me wrong, I think the agile-scrum-kanban thing used by most software companies is great. I’m no stranger to singing its praises!

My take on agile is the same as Churchill’s on democracy: it’s not perfect, but the other systems we tried were even worse.

That said, a love of agile can go too far. There’s a famous story from when Eisenhower was president of Columbia University about the groundskeeper complaining to him that students kept trampling the grass on a diagonal shortcut across a quad, to which he replied, “They’re telling us where we need to put a path.”

With that in mind, here are four agile heresies that are really ways in which the people are telling us where we need to put a path.

Heresy 1: Rolling over stories to the next sprint

In theory: All stories committed to a sprint are finished in that sprint.

In practice: Anywhere from 10% to 50% of the stories aren’t finished and roll over to the next sprint.

Why it matters: It leads to absurd accounting conundrums. For example: “Should we reduce the points for the rollover stories by the amount of work we did this sprint?”

Typical guru advice: “Next time, break the stories into smaller pieces!”

Why this doesn’t work: Most people really do try their best to break epics into “sprintable” stories! But sometimes, you have to actually start doing a task in order to learn how it can be further subdivided.

How people cope: Spikes can help by setting aside a sprint just for researching a task, after which better, more “sprintable” stories can be made.

Eyes on the prize: The point of making software isn’t to have a predictable team velocity, it’s to make software. The key is setting expectations correctly — including giving updates on slippages as soon as they arise. Sprint velocities help with this, but aren’t a goal unto themselves.

Heresy 2: Stories for a single resource

In theory: Every story must involve multiple roles to collaborate: UX, engineering, QA, dev ops, etc.

In practice: Some stories do that, but many stories only require a single person, often a shared resource: e.g. a tech writer, a UX designer, a dev ops person, etc.

Why it matters: Anyone who creates such stories is committing agile heresy! Heresy, I tell you!

Typical guru advice: “A story that involves a single resource is too small. It should be a subtask under some other story instead.”

Why this doesn’t work: Stories are also supposed to finish in a single sprint, remember? But shared resources may not be available until the next sprint, or the sprint after that. There’s also something very silly about having, say, an engineer and a tech writer estimate a combined story, when their work is very, very different. And finally, people tend to not like subtasks anyway, as they make the project board harder to read with clutter.

How people cope: Well… they make separate stories for different resources! Sometimes they link them together with dependencies (“Story 1 is blocked by Story 2”).

Eyes on the prize: Ultimately, the stories in an epic are a checklist of what needs to be done to deliver that epic. If certain items are assigned to specific individuals rather than lumped together with other people’s assignments into combined stories, that can actually make it easier to track progress on the epic.

Heresy 3: Estimating with hours

In theory: Human are bad at estimating tasks in hours, but better at giving relative estimates in fuzzier units known as points. So all you need are points, not hours.

In practice: Unfortunately, the spacetime continuum moves in hours, not points.

Why it matters: Not accounting for hours is a big part of why stories roll over from sprint to sprint (see above).

Typical guru advice: “When you first start agile, you may want to break stories into subtasks with hours. But as you establish a team velocity, you won’t need to do that anymore.”

Why this doesn’t work: Some teams default to the same point estimates: every story, seemingly, is a 5 or 8 on the Fibonacci scale, even though they don’t all take the same amount of time.

Other issues with points:

1) No one ever knows if points are meant to be convertible back to hours anyway, or are just some abstract description of complexity. Or both.

2) Points alone are harder, if not impossible, to relate to people’s time off and/or other commitments. Especially since points are supposed to be a capacity measure for the team, not the individual.

How people cope: It’s admittedly easier to estimate in points instead of hours. Stories will end up rolling to the next sprint as a result. But this may or may not be a big deal (see heresy #1 above).

Eyes on the prize: If you really do need to meet specific deadlines that can’t slip, you should — and totally can — plan people’s capacity and tasks with actual hours. Points are good for stories, to give a rough feel on how big the effort is. Then, once you commit to a particular story, carving it into subtasks with hours will give you a clearer view into your timelines.

Heresy 4: Skipping retros and demos

In theory: You need to have a demo and a retro at the end of every sprint.

In practice: Retros get canceled for lack of interest from the team who feel they have better things to do, like actual work. And business stakeholders don’t attend demos, because too often they consist of engineers showing off reams of code, rather than discussing something a salesperson cares about.

Why it matters: Without demos, code can get released that business stakeholders aren’t on board with. And without the introspection of retros, if a team’s process is broken, they may never fix it.

Typical guru advice: “Have the presenters tailor their demos to a lay audience! And make sure you really do implement all the improvements suggested at a retro, or else the team won’t take the retros seriously.”

Why this doesn’t work: Retros really do often devolve into high-fives and/or venting. The systemic problems identified are often out of the team’s ability to solve, so bringing them up every two weeks in a public forum can be bad for morale.

As for demos, public speaking is not in everyone’s toolkit. Even when it is, it can be a lot of work to make a good presentation — will that go into sprint planning?

Finally, not everyone builds GUIs that can be easily demo’ed. (Here, agile betrays its origins in the world of website development.) If business stakeholders just want database queries to run 10x faster, and it’s going to take 3 months to get to that goal, what is there to show them every 2 weeks? Be real here. Execs and sellers just want to know that an infrastructure goal was achieved, not how it was achieved, or (even worse) how we got to being 35% of the way to the goal.

How people cope: Remember those cartoons from Spotify? And how they dropped the agile ceremonies they didn’t get value from?

Eyes on the prize: Introspection is important. Quarterly demos and retros tend to work better: there’s more to show and discuss after three months than after only ten business days.

In the end, even the professional gurus will tell you agile is not a rigid code to be adhered to no matter the cost. It’s a framework, whose concepts should be treated as guidelines. And as we discover new paths across the quad, we should take them.

Now, what could be more agile than that?