Sad Agile Groups Are Sad in Acquainted Methods

There’s a well-known Leo Tolstoy line in “Anna Karenina“: “All completely happy households are alike; every sad household is sad in its personal means.” (рус. “Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.”) Sad Agile groups like to imagine the similar factor: that their dysfunction is distinctive or particular. It not often is.

In actuality, most struggling groups fall right into a small variety of very predictable traps.

Earlier than assuming your workforce is getting the promised advantages of Agile methodologies, i.e., higher outcomes and happier groups, it’s price checking for some extraordinarily frequent anti-patterns. Lots of them look productive on the floor. Most of them use Agile vocabulary. And most of them quietly undermine what Agile is meant to obtain.

To know why these patterns present up so typically, it helps to begin with a fast take a look at the place Agile got here from.

Waterfall vs. Agile

Waterfall is an older product improvement methodology constructed round a linear, sequential course of. Necessities are outlined upfront, designs are finalised, engineering builds, QA checks, and solely then does the product ship. Every part palms work off to the subsequent, and suggestions from actual customers usually arrives very late… if it arrives in any respect.

This method can really feel reassuring to organisations as a result of it guarantees predictability and management. Sadly, it additionally assumes that we are able to totally perceive the downside before we begin constructing an answer, which is not often true.

Agile emerged as a response to these limitations. As a substitute of treating improvement as a sequence of hand-offs, Agile is meant to be adaptive and collaborative. Cross-functional groups work collectively to resolve consumer issues, studying via small experiments, common suggestions, and steady iteration.

The objective os Agile isn’t pace for its personal sake. It’s about studying shortly and constructing the proper factor.

Many groups declare to be Agile. Far fewer really behave that means.

AgileFall: Waterfall in Agile clothes

AgileFall is an unholy hybrid of Agile and Waterfall. It often occurs when senior management nonetheless needs the consolation of a top-down method, approving options and plans upfront, but additionally needs the advantages they imagine Agile groups ship, equivalent to quicker supply.

On the floor, AgileFall seems to be busy and iterative. Product iterates on necessities paperwork. Design explores and experiments. Engineering tries completely different approaches before settling on an implementation.

The issue is that each one of this iteration occurs independently.

Every part nonetheless happens in sequence. Work is nonetheless thrown over the wall. Every group is pressured to work with selections made with out their involvement, quite than collaborating as a single workforce to resolve well-understood consumer issues.

AgileFall is nonetheless a Waterfall; it merely applies Agile rules inside particular person silos as a substitute of throughout the complete workforce.

You’ll know you’re working in AgileFall if there’s loads of experimentation, however little to no actual collaboration between product, design, and engineering. That’s no Agile. It’s only a slower Waterfall.

Design as a service organisation

In Agile groups, design is not an add-on. It’s a core a part of how work will get performed.

When design is handled as an external service, one thing groups “name in” once they want screens or mock-ups, the high quality of the work nearly all the time suffers. Agile groups are cross-functional by nature. Product, engineering, design, analysis, and anybody else concerned in making selections must be working collectively as one workforce.

Groups with embedded designers and researchers have a tendency to be extra genuinely Agile. Designersdevelop a deeper understanding of the product and its customers, and so they’re in a position to affect problem-solving a lot earlier in the course of.

This doesn’t imply designers can’t have a design supervisor, a profession framework, or common boards with different designers to focus on wider initiatives. These issues typically work very nicely. The hazard seems when design is handled like an external useful resource quite than an actual workforce member, i.e., introduced in late and excluded from shaping the work from the begin.

Characteristic factories

Agile groups that focus solely on transport options, with out ever revisiting or enhancing them, are typically referred to as function factories.

These groups do all the “proper” issues on paper. They run stand-ups. They monitor velocity. They transfer work throughout the board. However as soon as a process is marked as Executed, it is not often questioned once more. Iteration stops at supply.

Suggestions, when it exists, not often ends in change. Options pile up with out anybody stepping again to ask how they match collectively, whether or not they’re fixing the underlying downside, or whether or not the consumer expertise is really enhancing.

Caring about velocity doesn’t robotically make a workforce a function manufacturing unit. Measuring tempo might be helpful; it could spotlight when one thing has gone unsuitable. The issue arises when velocity turns into the solely factor that issues.

Agile groups ought to care about how shortly they will study and reply to consumer wants. Generally constructing the proper factor takes slightly longer upfront than constructing the unsuitable factor. Nevertheless it nearly all the time saves time in the future by avoiding limitless rework.

Full chaos

An absence of inflexible roadmaps does not imply a scarcity of route.

Whereas many Agile groups keep away from committing to detailed plans months upfront, they need to nonetheless have the option to clarify what they’re working on now, what downside they’re making an attempt to resolve, and the way they’ll know once they’ve solved it.

Groups in full chaos bounce from one request to one other, typically pushed by whichever buyer or stakeholder requested most lately. Work is steadily deserted midway via as priorities change with out warning. Folks do not know what’s coming subsequent, or whether or not the work they’re doing will ever ship.

This is not flexibility. It’s exhausting.

There’s an vital distinction between refusing to over-commit and having no shared understanding in any respect. Groups that rigidly comply with roadmaps can simply turn out to be function factories. Groups with no backlog or route typically fall into chaos. So long as a workforce understands the downside it’s tackling and what success seems to be like, it could experiment and pivot with out being consistently derailed.

Feeding the beast

Feeding the beast occurs when groups anticipate designers and researchers to function at the similar tempo as engineering, i.e., consistently producing new designs so improvement by no means has to decelerate. The end result is predictable: burnout, shallow considering, and little or no significant iteration.

Designers and researchers rush from function to function, whereas engineers complain if designs aren’t “completed”. Usually, engineering refuses to start work with out a full set of ultimate designs, turning the course of into yet one more variation of AgileFall. Older options are not often revisited, and studying stalls.

Satirically, in accordance to Laura Klein, this anti-pattern is typically one in every of the best to repair.

When groups make investments time in refactoring and enhancing their codebases, engineering beneficial properties respiratory room. Designers and researchers achieve time for discovery and experimentation. Cleaner methods are simpler and safer to work with, which frequently permits groups to transfer quicker general once they do focus on transport new user-facing options.

The frequent thread

All of those anti-patterns share one thing vital: they mistake exercise for agility.

Agile isn’t about rituals, pace, or iteration. It’s about collaboration and constantly aligning what you construct with actual consumer wants.

In case your workforce feels sad, caught, or busy with out making progress, odds are you’re not alone, and also you’re most likely not damaged in some distinctive means. You may simply be caught in a really acquainted lure.

Additional studying:

1. Agile Design, Laura Klein.
2. 6 Insights to Achieve Agile UX Excellence, Laura Klein.
3. How to Succeed as a Designer on Agile Teams: Embrace Imperfection, Laura Klein.

The article initially appeared on Substack.
Featured picture courtesy: Anton.