Imposition and Dark Agile

Are Imposition and Dark Agile both bad? Yes. Are they the same thing? No.

Let’s explore the ideas underpinning this screed that I tweeted last week:

So I’ve been thinking about the #Agile Indu$trial Complex 😀 as um discussed at length by @DanielMezick and others, and chatting with @chethendrickson, and I have a few thoughts and questions to share.

Imagine, if you will, that you’re a somewhat ranking manager in a rather large company. You become aware of #Agile, through reading in Forbes or drinking with your fellow mucky-mucks, and you come to see that amid the hype, there seems to be some good happening.

Obviously, you need some of this. Looking around the organization, you see that most everywhere there’s product-ish development going on, you need this.

What are you to do?

Well, you /could/ hold a plebiscite and ask all the workers what to do. You can’t really do this, because if you did, they’d mostly die of shock, and the ones that lived would know for certain that you were just fucking with them.

You could try an experiment or two, maybe finding teams that wanted to do something, and have them experiment for a year or two, then assess the results, and after some period of time … do what?

You could a) then pick a method or b) keep letting teams do whatever they wanted. The latter, much as I think it would be a good idea, runs deeply counter to What We Do Here at XYZ Corp.

Our job here at XYZ is to manage.

Or you could, with some amount of due diligence, decide what framework to use: Scrum looks good but small. SAFe looks like a big company thing. LeSS looks small but good, but you’ve never heard of it.

If you’re big enough, your due diligence might involve a Large Consulting Company, a McKinsey or Deloitte or some such. If you’re smaller, maybe you pick it up on the street.

No matter how you base the decision, you’re going to make it. That’s how things work at XYZ.

(Side topic to revisit: unless you pick Kanban (which you likely won’t), you probably have to make organizational changes to put your method in place. This requires management decisions.)

You can even make a decent case that the organization should use the same approach all over. This would make training easier, provide common terminology, and such.

However it goes, you decide, because that’s your job.

So, imagine that you say, “OK, all the teams are gonna do Method B”. Is this harmful? Frankly, I don’t think so. Management’s job is to set the direction. The question is what happens next.

Suppose what happens next is Certified B-Master training for everyone. Is that bad? I don’t see how.

Is it bad to bring in coaches? I’d say not inherently bad, but that it might depend on what the coaches say and do.

So where’s the evil #Agile Indu$trial Complex in all this? Serious question. What’s missing from this story that looks like the evil AIC?

Show me. Lead me.

Now my schtick, of course is Dark Agile. Where is that? Dark Agile is in what happens next. We can and should talk about that.

But right now, the question is, what have I missed in my story that missed out the heavy imposition by the #Agile Indu$trial Complex?

Well, the conversation goes on and on. You can find it in my threads and replies if you wish. It has gone on and on for days since I started this, and one thing stands out: Dan is always the same, damning some unnamed “Agile Leadership” or the catchy “Agile Indu$trial Complex” for not coming out and repudiating what he sees, apparently, as the only problem in “Agile”, which is that everyone is imposing Agile on everyone, and the evil money-grubbing AIC isn’t shouting from the rooftops about it.

It happens that I am strongly opposed to most forms of “Imposition”. I hate being told what to do. I always like to know what to do, and I don’t always have to lead my own parade. But I like to follow a leader, not be driven before some tyrant who’s just here to hear the lamentations of my women. What’s perhaps odd is that in my half-century of doing this stuff, I have had exactly zero tyrants inflicted on me.¹

Probably I’ve had an incredible run of luck, but nonetheless, since there are probably a dozen employees per manager, it’s just simple math that the manager is off your case most of the time, even if they are trying to be a tyrant. More to the point, except for the truly stupid ones, management mostly realizes that they don’t really know how to do a damn thing, so they mostly rely on the workers to do the work.

They can, of course, be jerks about it, put pressure on people, be rude, and so on. But that’s quite different from “imposing Agile” on people.

The people at the top of the organization have, in my view, the right to decide that the organization is going to go Agile. In most companies by far, management is there to decide things and get them done. We might prefer a more democratic or holocratic organization, but the hierarchical one is most common and it’s likely to be around for a long time. And their job is to decide stuff and then apply the organization’s resources to get it done.

I’ve written elsewhere about how I’d impose Agile if I were an executive, and I freely grant that I would in fact insist on the organization becoming Agile. And, as always, I mean that in the sense of the Agile Manifesto.

So, in some simplistic sense, even I, the good and kind Glinda of Oz er Ron Jeffries, would “impose” Agile. I suppose I’d even be clear that “Agile” was what I was looking for. But I’d do the imposition by setting goals and defining outcomes, mostly around, of course, my personal hobby horse, running tested software. . Then I’d back up those goals with strong support for training and coaching as needed and desired by my various teams.

Is this Mezick-Imposition?
I don’t think so.

Is this the kind of evil authoritarian imposition that Dan is talking about? Well, frankly, I don’t think so. Does the kind he’s talking about exist? I think it does. Is it common, and does it reach all the way down from the executive floors to the workers building software down in the code mines? Frankly, I’m very doubtful of that. Why? Because first of all, executives don’t show up in the code mines very often, and there are many layers of management in between. And most of all, because that kind of authoritarian behavior doesn’t work very well, so in a successful company it’s not likely to be the prevalent mode of operation.

Surely there are exceptions, companies that run entirely on people shouting orders downward. I’ve never actually encountered one, but again maybe I’ve just been incredibly lucky in my half-century of doing software.

Somewhere in the Imposition Threads, as they’ll go down in history, Dan suggested that Dark Agile, my personal vendetta of the moment, was due to Imposition. Frankly, I don’t think so. My esteemed colleague Chet and I just talked about it, for the zillionth time, and we think the primary cause of Dark Agile is pressure, and the secondary cause is ignorance of how to do Agile Software Development.

Is pressure imposition?
Not Dan’s kind, certainly.

Now Dan could argue, and probably will, that pressure is imposition, and I’ll argue back that it isn’t the kind of imposition he’s actually talking about, which is the top down declaration in no uncertain terms that All You Bastards Are Going To Do Agile Now Or Your Heads Will Roll.

The pressure we see is pressure to get more features done. It comes at the beginning of the planning period, in the form of “stretch goals” or cajoling to just take on a couple more stories. It comes in the middle of the period, in the form of pointed questions about why things are taking so long. And it comes at the end, when no one shows up for the reviews, and when the issues that are raised in the retrospectives aren’t dealt with, or maybe the retrospectives aren’t even done because we don’t have time.

The ignorance we see is a secondary effect of the pressure, combined with an unpreparedness or unwillingness to invest in the team. Developers do not automatically know how to produce running tested software every two weeks. They have to learn, which means they need training and coaching. That training and coaching, today, is time consuming and expensive, and very few organizations provide it. Very few organizations even give developers time to search it out on their own.

These, in my somewhat experienced view, are the causes of Dark Agile. They are not the same as Imposition and they are not even applied by the same people Dan is talking about.

There are many forces acting,
not just one!

Since the problems with Agile are not all in Imposition (though imposition in many forms is surely undesirable), and they are not all in Pressure or even Ignorance, we must conclude something like this:

There are many forces acting to make it difficult for any person, or any organization, to become Agile. It will not do to focus on only one.

Different people will focus on different concerns. While it certainly makes sense to call out to others to join one’s own particular bandwagon², it’s not so good to act as though all those who are following another path are stupid, venal, or evil.

There’s a lot of work to be done. Let’s try to support it getting done, not undermine it.