<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=266211600481844&amp;ev=PageView&amp;noscript=1">

Bikeshedding, The Waterfall Industrial Complex, and the Force of Nature That is Sinking Your Team's Agility

Feb 15, 2017 Custom Application Development Jon Fazzaro

Bikeshedding, The Waterfall Industrial Complex, and the Force of Nature That is Sinking Your Team's Agility

Agile is dead.

So we have been told. But who killed it? What was the motive? Was it Frank from infrastructure in the break room with the red stapler? And how in the Cockburn does one kill an adjective?

I have a theory, but a part of you is not going to like it.

Great Scott

To set this up properly (and also to knowingly elicit an eye-roll from the less patient among you), let's jump back in time, about a hundred years.

It is the height of the Industrial Age, and Henry Ford has just perfected his assembly line. A collection of humans, none of whom individually know how to craft an automobile from end to end, are working together to do just that once every 93 minutes. It is an unheard of feat of production that puts a quality vehicle within reach for any Joe Bagadonuts, at $260 a pop.

So, how did Ford pull this off? Taylorism. As in Frederick Taylor, one of the great pulsating minds of Capitalism, who has probably put a notion or two about work in your head, too. Maybe without you knowing it.

"The man in the planning room, whose specialty is planning ahead, invariably finds that the work can be done more economically by subdivision of the labour; each act of each mechanic, for example, should be preceded by various preparatory acts done by other men."

—Frederick Taylor, Scientific Management (1911)

The key to Ford's automotive attainment (and subsequently the explosive productivity of the twentieth century economy itself) was this subdivision of labor–taking the skilled job of a craftsman, and breaking it down until it was more the domain of the aforementioned Mr. Bagadonuts. Everybody wins; Joe gets a job, and Henry & co. gets Joe's cheap, replaceable labor. The more Joes that Ford could add, the faster the line would go, linearly.

So, naturally, around the mid-century mark, when software became a thing that people wanted to make together, we applied this same state-of-the-art thinking to the problem. If we could manage to break down the work of developing software into its component jobs, we wouldn't have to find individuals who were skilled in doing all of them. Or, for that matter, pay them what that sort of nerd would be worth.

We didn't get far down this road before another Fred famously recognized that the whole subdivision thing didn't hold water when it came to scaling the work of software.

"When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic."

—Fred Brooks, The Mythical Man Month (1975)

Not that it stopped us from trying for a several more decades.

So, then, what's the deal with software?

It's in the doing of the work that we discover the work we need to do.

This slightly more modern gem from Woody Zuill succinctly captures the essence of Knowledge Work.

Software is knowledge work. No matter how meticulously we plan it out ahead of time, much of our plan will be wrong. This was not the case when the job was to build a car dozens of times in a day. The linear scaling of productivity is dependent not only on the subdivision of the job, but also on its predictability. And knowledge work, by definition, is not predictable.

The key to successfully engaging knowledge work is not to plan for every permutation up front as with factory work, but instead to optimize for feedback, learning, and your team's ability to react.

Or, as I like to call it, agility.

Meet the old boss, same as the new boss

Agile Software Development has officially been a thing for a decade and a half, and it was brewing for a long time before that. It makes things so much better that some of us simply cannot shut up about it. And it has confounded some of us so completely that we are calling for its head on a platter.

Why is this so hard? Why do we even have names for things like Death March Agile, Scrummerfall, and (Poppendieck help us) Deployment Sprints? Why, in the age of information and ideas that flow like milk and honey, do we persist in the folly of applying factory thinking to knowledge work?

Meet your lizard brain.

The amygdala is the fundamental stump of brain that we share with smaller animals. Like, for example, lizards.

It is not the part of you that has thoughts, the part that you imagine to be you. It does not reason. Whether you notice it or not, it is in charge, and its one job is to keep you alive long enough to make more things just like you, with lizard brains that are in charge of them.

And it loves this whole Taylorist thing you're doing.

Agility requires that we think creatively. It calls for us to talk through uncomfortable topics and seek out unanswered questions. It asks that we become vulnerable to each other, learn new things, and challenge the boundaries of what it is to do our job on the way to making software.

But what ends up coming easy to us instead is to clock in, follow a spec written and signed off upon by other people, and clock out. And if that spec happens to be wrong, not only is it not our fault, but we reserve the right to groan ineffectually about the shortcomings of the people who wrote it.

Humans are pack animals. We survive by sticking together. And the lizard brain's primary means of keeping our genetic code in the stack is to keep us from endangering our status in the tribe.

That means dampening our creativity, because creativity risks rejection. It means sticking to the plan, and it means letting sleeping dogs lie. It means putting up resistance to learning a new way to do something. It means not touching the boundaries of our job with a thirty-nine-and-a-half foot pole.

Our lizard brain really just wants us to sit down, shut up, and keep typing out code. And the mindset looming over us from the previous century that has been shaping our thinking about work for our entire lives is right there to gently cup and protect it.

Better play it SAFe®

Ironically, Agile frameworks themselves can provide a haven for just this sort of broken thinking.

After all, if we can spend time bikeshedding about why our sprints should be three weeks long instead of two, we won't have to talk about why the feature that we're in the middle of implementing isn't even a good fit for the product.

When we attempt to implement something like Scrum without letting it change us, we end up with loads of new meetings and procedures in which we measure how well Joey B. is following the spec, and ask if he can maybe trim a little more off his estimates. Meanwhile, marketing gets to broadcast how Agile we are, while we sit back and wait for some of that twice the work and half the time we've heard so much about to roll in.

Of course, when twenty pounds of user story does not, in fact, fit into a five-pound backlog, and JB takes a hike with the only true understanding of our code base trapped in his considerable noggin, we declare Agile to be a bag of ivory tower monkeyshines that just doesn't work in the real world.

Agile is dead! Long live agility.

Good Agile is real. We've been doing it for years over here. It's how emotionally whole people develop software.

But making this happen takes work. Assuring your inner lizard that you're not going to be fired/eaten just for putting up a Kanban board is easier said than done, as is letting go of the mental model of work that we were trained for since elementary school.

It's still a small price to pay for being able to trust that we're building the right thing, and to know that we're trusted to build the thing right.

Still don't agree? Let us know why in the comments.

 

4 Things Every Successful Scrum & DevOps Team Understands About Knowledge Work 

 

Here are some other popular posts on similar themes:

Why the Most Successful Leaders Resist Their Instincts when Managing Agile Development Teams

The 3 Core Principles that Make up the Agile and DevOps Gold Standard

Test-Driven Development and the Importance of Clean Code in Scrum Projects: Tech Club Podcast

Posted in: custom software

Topics: Custom Application Development Web Development custom software Scrum Agile

Comments