Projects for which Agile Is Inappropriate by Ron Lichty

I encountered agile for the first time in 1999. A decade later, I was not only coaching my own teams in it but also teaching it to friends’ teams. One of the questions I repeatedly heard, in those days, was, “Is agile appropriate for every kind of software project?”

I wracked my brain for some possible kind of software development for which agile wouldn’t be a fit. I didn’t have a good response.

The answer leapt out at me a few years later. It was staring me in the face. I’d been stymied because I was looking for a kind of software. The answer was instead a kind of environment. Micromanaged environments. Agile is not a fit for command-and-control management.

Micromanagement disrupts agile. Micromanagement prevents best teams. Micromanagement prevents learning. Micromanaged teams become order takers.

Agile’s self-organizing teams call for everyone on the team to step up. Micromanagement causes everyone to step back.

For teams to self-organize, they must be nurtured, not thwarted. For most teams, self-organization holds promise to be the most powerful part of agile – and possibly the most fragile. Over the course of two decades introducing agile into my teams and in the past decade parachuting into organizations purportedly already agile, I’ve repeatedly run into organizations signed up for the ceremonies and practices – sprints, standups, planning, points, backlogs, frequent delivery and the rest – without ever embracing the values and mindset behind them. That is, I’ve repeatedly run into organizations that need to let go of “telling” and embrace “teaming.”

Ask any group of product people who’ve been at it for a while to think back to their best team ever and they’ll never describe a team that was micromanaged. Instead, when asked to describe that “best team,” they’ll come up with characteristics like “respect” and “trust” and “shared purpose” and “we had each other’s backs.” They’ll also, in a nanosecond, sign up to be on a team like that again.

In its Aristotle Study of what distinguishes its high-performance teams, Google identified a singular standout defining characteristic, “psychological safety.” The study further described psychological safety as everyone at the table feeling welcome to speak up, each team member speaking about equally, and each feeling listened to. It could be identified visually by “equality in distribution of conversational turn-taking.”

Daniel Pink calls out autonomy as a key to intrinsically motivating people and teams, in his eye-opening best seller Drive: The Surprising Truth about What Motivates Us. “Intrinsically motivated people usually achieve more than their reward-seeking counter-parts,” Pink notes.

Agile gives those of us who are managers the role of “servant leaders.” In its manifesto, agile calls out building projects around motivated individuals, trusting to get the job done, face-to-face conversation, and self-organizing teams – teams that reflect and tune and adjust.

Servant leadership means we managers are not the directors but the facilitators and enablers. We’re looking to create cultures in which teamwork and psychological safety and autonomy thrive – in which everyone in our organizations, right down to the interns, are leaders, each one of us leading from our unique expertise and experience. Make no mistake, few interns are leading software architecture – but our interns likely do have insights from their boilerpot of sometimes edgy schoolwork that’s worth listening to and learning from. (And if they don’t, we probably hired the wrong interns!)

Agile practices are useful. They’re designed to support great teams. Even in the context of micromanagement, agile practices can make a difference – but in micromanaged environments, their benefit is severely limited.

It’s incumbent upon us managers to support agile practices by crafting the culture and the environment for great teams to emerge and thrive – not by telling teams what to do but by setting objectives and boundaries and then turning our focus to nurturing teams to deliver their best.

Only by avoiding telling and by nurturing teaming do we offer our organizations the possibility to deliver their best.

————
This post was originally written for and appears in the book, 97 Things Every Engineering Manager Should Know, edited by Camille Fournier.

Image by Steve Buissinne via Pixabay