Is Anyone Doing Agile Correctly?

Maybe not, and that’s okay.

Have you heard of “Agile” software development? If you work in technology, you probably have, or soon will. Agile is a process for defining, developing, and iterating on software. Developers love it, hate it, and/or love to hate it. In many cases, that’s because no one seems to get it right within an organization.

Agile comes from the Agile Manifesto, a document written by high profile software engineers who sought to better define the objectives and optimal processes for building software. But today, Agile is defined by the organizations that use it. Some organizations pay for Agile trainings, and even hire Agile-specific roles like “Scrum Master”.

TL;DR — This is Basically Agile

  1. Daily standup meetings (<15 minutes, purpose: state whether you are blocked on a task)
  2. Work is allocated in biweekly sprints, with ticketed stories assigned a score based on their work estimate
  3. Work not assigned to a sprint is added to a backlog, which is groomed near the end of every sprint in preparation for the next sprint

My Experience with Agile

Drawing on my experience in my last 6 organizations, 3 of them incorporated some form of Agile-ness (Agility?) into their project planning. In other words, they invested time into Agile training, then adapted the system for their own purposes. Among software developers, this is a bit of a recurring joke. Despite Agile practices being quite specific, their implementations are often lax. The implication is that “Agile” is a buzzword used to recruit engineers or justify existing processes. Here are the 3 most commons deviations I’ve witnessed:

  1. Standup meetings turn into status updates and product discussions. The meetings go over the allotted time and become bloat. The name “standup” is meant to prevent this (there’s an incentive to go quickly if everyone has to stand for the whole thing).
  2. Work estimates aren’t taken seriously, or are taken too seriously. Work estimates are important for allocating tasks to the right people at the right time. They should not be used as deadlines. This approach will naturally lead to stress, and overestimating in the future.
  3. Stories are written too vaguely. The most important component of a story is its definition of complete. Is it finishing feature development? Passing tests? Reviewed? Merged? Deployed? The worst mistake is writing a story to a vague spec and having someone redo their work due to miscommunication.

My Experience without Agile

It’s true that most organizations don’t follow the strictest processes, but what’s the alternative? In my experience, nothing. My 3 previous organizations that did not using Agile instead resorted to ad hoc assignments. This only worked when teams were sufficiently small for everyone to maintain a working knowledge of most tasks. Even then, it was cumbersome. As these organizations grew, they inevitably suffered from all the same problems as Agile organizations, and then some.

Despite this inefficiency, we would often joke about the brokenness of Agile. The joke was on us, because we weren’t doing any better.

The Lesson? Don’t Take it Too Seriously

For all that I’ve seen go wrong with Agile, I’ve also seen teams refine it to better suit their own needs. For example, a remote or distributed team can’t always rely on standups for relieving blockers. Some teams may better benefit from 1-on-1 meetings, group sync-ups, or message-driven communication as a supplement, or even a replacement.

Does it still make sense to call a team “Agile” if it doesn’t strictly adhere to very specific guidelines? I think it does. A shared terminology is important, especially for hiring and onboarding. Even non-strict Agile teams tend to have a meaningful organizational advantage. As with anything, the human component of work is what’s most important, and humans don’t always resonate with strict processes. There’s a tradeoff between flexibility and rigidity, and that tradeoff ought to be evaluated constantly.

The ability to adapt quickly is, after all, the definition of agility.

If you’ve enjoyed this article and want to read more, please consider signing up for a paid medium membership through my commissioned referral link below. This adds no extra charge to you, and is the best way to support my writing. Thanks!

Matthew Cannalte

Matthew Cannalte

Software Engineer | Armchair Philosopher