You know more than you think you know, just as you know less than you want to know.
As I wrote last Friday, you just can’t know everything at the beginning of a project. A lot of times, you can’t even know things at the end either! That’s one way of looking at the whole “Agile” concept–simply realizing that your knowledge is limited and therefore letting go of a lot of things that you can’t control correctly anyway.
So what kind of manager works best with an Agile team?
It’s not about the manager
I’m going to back that up and ask why an organization–one that’s big enough to have anything like a “senior management” corps–would want to pursue Agile software development in the first place.
Well, let’s look at this guy.
What do we know about the Pointy-Haired Boss, from years of reading “Dilbert”? He’s clueless, arrogant, and intellectually lazy. You just know instinctively that his idea of “Agile” isn’t going to work. But this is how a lot of shops do it.
I really do hear it a lot: “We tried agile but it didn’t work.” Even the way one says this is passive. Something was out there, we tried it, it failed. Let’s rephrase that:
- “We picked some specific Agile practices and didn’t get the results we wanted or expected.”
- “We brought in an Agile consultant, but it just cost a lot of money and nothing really improved.”
- “The guy who’s always talking about pair programming, we let him do it, but nobody else is interested.”
Here’s the thing. Agile isn’t about the work. It’s about you. That’s why, when someone asks what Agile methodologies I use specifically, I try to deflect the question. Pairing is important, but it’s more important that you’re happy to be corrected a couple dozen times a day. Test-driven development is useful, but it’s more useful to imagine a hundred ways something can go wrong. Stand-up meetings can be effective, but the trust in your colleagues that frees you to do your own thing makes them really effective.
I can’t find this anecdote anywhere online, but I heard this thing once about the difference between American and German forces in World War II. The story goes–and it doesn’t really matter if it’s true because it’s illustrative–that the U.S. had a huge logistical advantage because so many of our young men were used to fixing their own cars at home, as well as working with minimal supervision on farms and in small shops. When a Jeep broke down at a bad time, a Yank would hack up a quick repair, something good enough to get through the battle or to the next town. The Germans, so the anecdote went, were more likely to await orders (and fail to accomplish the mission) because they were all about top-down management.
The difference is not just the informality, it’s the mental and emotional ability to connect with what needs to get done as opposed to what you’ve been told to do. That’s part of the principle of self-organizing teams.
But it kind of is about the manager
So far this sounds pretty good to management. Yay, self-organizing teams! Yay, workers who take initiative! Yay, higher-order skills! Time for golf!
But you have to ask yourself, is your corporate culture one that rewards following orders? Or rewards the solving of difficult problems?
If you’re in an order-following culture, and someone up there decides you are to “do Agile,” I’m pretty sure you’ll end up in the “it didn’t work” category. Even if you’re in more of a problem-solving culture, there are surprises and snags that will test your commitment to all that self-directional foofah.
It’s not a product you can buy…
…or really a method you can adopt. To wear out a cliché, Agile is really an attitude or a mindset. And I’m afraid it has to start at the top.
I don’t know if there’s a one-word name for it, but there has to be an attitude in middle-to-senior management that they don’t know everything, that some things aren’t amenable to control, that surprise is something that should be expected. You have to trust your teams, even when they don’t deliver the results you expect. You have to imagine more than one possible outcome. You have to accept correction of your first impressions, gracefully and with ease.
Oh, wait, I know the word. It’s “humility.” Sucessful Agile efforts begin with a culture of humility.
Now the scary part
Trust means you have to give up Control. A lot of it.
Imagination means you will have less Certainty.
Correction means you have to acknowledge that you never had Perfection to begin with.
It’s easy to laugh at the Pointy-Haired Boss, but the organizations that do well with Agile software development–or any other kind of Agile work for that matter–are the ones that can cope with losing Control, Certainty, and the assurance of Perfection. That’s a lot harder.