Quality and Innovation

Agile is everywhere. Sprints are everywhere. Freshly trained Scrum practitioners and established devotees in the guise of Scrum Masters beat the drum of backlog grooming sessions and planning poker and demos and retros. 

They are very busy, and provide the blissful illusion of progress.

(Full disclosure: I am a Sprint Grinch, and my heart will not grow three sizes, or even one… on any day. I do support Alistair’s Heart of Agile, because I think he’s as pained about where the industry has gone as I am. Probably more.)

Despite the mirage of progress, the people on the front lines doing the engineering work feel little relief from the ill logic and misplaced pressure of the pointy haired bosses. The managers aren’t getting the deliverables faster (like they convinced themselves they would). There are tons of charts and graphs that tell us how we’re doing (like burndowns) but now the CFO is using them to whip our horses just a little bit harder, trying to get them to go faster. They’re not going fast enough. (Spoiler: They will never go fast enough.)

And isn’t that what Agile is supposed to do… speed things up? NO!

Once upon a time, we used to build software like we built skyscrapers: plan every single task, put in on a Gantt chart, and make sure there are approval gates between every phase of work: elicit requirements, design the systems, write code, test it, deploy it, maintain it.

But a couple of big, bad things tended to happen over and over: 

• By the time we got to “test and deploy” we’d discover that the thing we built was not what the users and stakeholders actually needed. (“But it’s exactly what you asked for in the requirements,” we’d say, “and you approved it at multiple decision points.” “Sure,” they would say, “but we learned a lot in the meantime, and things are different now. You just built us what we thought we needed six months ago.”)
• The software developers would build something that the operations team, responsible for standing it up and maintaining it, wouldn’t be able to support at the intended service levels. (“You can’t expect us to maintain this,” they’d say. “It’s fragile.”)

Agile practices emerged more than two decades ago when engineers said… hold it, there’s got to be a better way. If we work collaboratively with our users and stakeholders, learning together, figuring out how to realize value together… then we’ll produce something that real people are able to get value from much faster. We need control over our process, and we need you to be actively engaged, business people. We can eliminate all these handoffs, and replace them with shared accountability.

The two solutions were: 

• Agile: We said “let’s take a more collaborative approach to development, and get the users and stakeholders together with the engineers, so they can all learn and co-create together until they’ve produced the next nugget of value.” 
• DevOps: Instead of two groups siloed from each other, let’s automate the handoff and make it seamless, and give the developers tools that will alert them when they’ve got to fix more stuff. If tests automatically run before the code is merged into production, we’ll always know that we’re deploying stuff that runs. (I’m pretty sure everyone agreed this was a good idea.)

Agile is a great aspiration. But how often have you ever seen the users and stakeholders sharing space, sharing accountability, sharing the process of creating value? Not often. They still coordinate through user stories, and tickets, and handoffs, and PRs. 

Agile speeds up value delivery, but not necessarily software delivery. Having daily stand-ups and burndown charts and JIRA tickets won’t make people code faster. But it will make managers think they should be coding faster, and that’s where the poison will settle in and grow.

Bottom line, my position statement is:

1. Any (minimalist) process is better than no process.
2. Agility is an essential goal, but Scrum and certified Agile practitioners are less likely to get you there.
3. Go back to first principles: plan an iteration, co-create value, see where it got you and reassess your ability to reach your goal, then adjust. Keep experimenting.

Would I ever use Scrum? Sure, under specific conditions:

• There’s something we have to build, and we’ve never built it before.
• The road ahead is unknown.
• We have access to collaborators who can help us see what’s needed.
• We agree to intentional checkpoints where we can see how far we got, and whether we can still get to the place we’d originally intended.
• We iterate, and iterate, until we agree we’ve incrementally added enough total value nuggets to move to the next project.
• There are no well-meaning-but-not-helpful engineering managers or business managers hovering over the development team with bated breath, waiting to beat us with burndowns. The dev team can manage itself.

Agility is a laudable – and essential – goal. But only in rare cases do I believe Agile and Scrum will get you there.