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

Development Metrics? Try DevEx by Ron Lichty

If you read my post on never, ever, ever, letting story points or velocity be used as a performance metric, you are likely aware of my skepticism around software developer and development metrics. In that post, I called out Jerry Muller’s thin book, The Tyranny of Metrics, for capturing the inane insistence on metrics to “measure" developer productivity. Muller quotes Andrew Natsios in defining an increasingly problematic, increasingly common human condition that Natsios labeled “Obsessive Measurement Disorder: an intellectual dysfunction rooted in the notion that counting everything… will produce better policy choices and improved management.” Muller devoted his book to debunking that belief.

You also likely know my appreciation for work by Nicole Forsgren and others - their book Accelerate, and their DORA studies, which focused not on attempting development and developer metrics, but rather on leveraging very tangible delivery metrics.

(Worth watching: good talk by Emily Nakashima on leveraging DORA for KPIs.)

More recently Forsgren and co-coauthors delivered SPACE: actually looking at developer productivity.

Now Forsgren with yet another set of coauthors has looked into Developer Experience - DevEx - not just tools, but human factors such as having clear goals for projects and feeling psychologically safe on a team. DevEx has been shown to have a substantial impact not only on developers' performance and productivity, but also on their satisfaction and engagement, and on employee retention. And how do we measure DevEx?

Complete with real-world examples.


Image by Lukas Bieri via Pixabay