You know more than you think you know, just as you know less than you want to know.
—Oscar Wilde

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.

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.”

Refocus

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.

You totally want to read more about this, and you will, if you get onto my eZine mailing list. You get a complete mailing about once a month, with articles and links and special offers that help you do your job, as well a quick note every week or so with something funny or interesting. Do you need more stress? No? Then this is for you.

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.

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.

20 Comments

Great post Mark. It is very true that Agile is more about people rather than tools and processes. I find it sad that somehow companies got away from the human side of things. I think it started long ago, and now we are seeing a shift back to it, as people are tired of being treated like untrusted resources. That means for many the move to Agile is a paradigm shift. I feel though that companies need to implement Agile philosophies to continue to be successful into the future. Ultimately, those that don’t will see a massive exodus of their top talent.

I really agree wholeheartedly that it’s not about the agile techniques you use. It’s really about the mindset.

In our three people team for example, we do way less unit testing as my brain tells me to do. But we’re fine with it as we really imagine those hundred ways things might go wrong during development. On the other hand I’ve seen tons of useless unit tests lurking teams into false security. What is worse?

I’ve built and lead two Agile teams now and found it relatively easy to motivate and nurture a culture of excellence within the development teams.

By far the harder job on both occasions (tech-startup with no initial revenue and established UK travel operator with £200m annual online revenue) was managing upwards in terms of expectations and management reporting, not to mention deadlines!

I’m generally surprised at the very low number of non-technical people (and that includes some IT managers) who take the time to try and understand more about development methodologies or processes that might be employed within their company, even though technology might well be a cornerstone of their business.

After all, it seems to me the best developers are the ones that take the time to understand and question their business environment.

@Robert, I agree. Agile is simply treating your team members as if they were real people who are intelligent and can figure things out if you let them.

@Andrew, Yeah, have you noticed that your knowing “the MBA stuff” gets you a pat on the head, but the Suit People don’t have any patience for the really important parts of the IT practice?

You’ve also prompted something else here: Agile means you very likely will not quite get exactly what you had in mind at the beginning. That sounds like a loss, but only (cue the Imagination theme) if you compare it to the fantasy of a perfectly controlled project that is flawlessly executed. At its best, Agile delivers not what you wanted but the best you can get.

Understanding that what you wanted isn’t real–it’s only in your mind–is part of that whole Humility thing.

Ah! @Matthias, yes indeed–Humility can make you Agile, with some guidance, but Agile processes can’t create Humility. Start at the beginning.

Good point about the unit testing. It’s certainly nice to have everything you know about the code in the tests, and that’s a wonderful goal, but the next best thing is to have the knowledge somewhere. And the questioning: “What could go wrong? What could we have missed?”

> Test-driven development is useful, but it’s more useful to imagine a hundred
> ways something can go wrong.

I absolutely agree with you … furthermore, if you deeply understand and use TDD, your “code quality” and testability will be higher and stronger even if you’re not writing tests at all. I’ve noticed that, switching from a new project to a legacy one. In the first I have my tests assemblies with Nunit and cruise control. In the second, absolutely nothing. Yes…you feel like a wire-walker but without the security net 100 feets under. But my code style is still the same…it’s like I’m writing tests in my mind…

The question I grapple with often is “How do I bootstrap an agile team?” Agility expects (assumes?) that a team shares a common value system. So the real question I ponder is “How do we create a shared value system?” I think the answer may well be in “humility”. And perhaps an unwavering dedication and belief system.

I try to bring the philosphy of Ubuntu into teams. Ubuntu is simple: people are people through (other) people. That is how Mandela transformed a nation, and how Ghandi changed the minds of the British Empire. The common behavior of these two men is “humility”.

I think we agree, Lorenzo. It’s great if you do the actual unit tests in code and approach your coding with “tests in mind” of course. It all makes the code better!

Aslam, that’s a very interesting philosophical approach. There is definitely such a thing as Agile values, although like a lot of value systems (and unlike others!) Agile doesn’t purport to explain everything about life. 🙂 I’ve done Agile work with people from many backgrounds who have very different value systems outside of our work environment… but still, I agree, Agile requires a kind of thoughtfulness that the very structured methodologies don’t.

That’s what I meant when I said, “Agile is about you.” It is a way of thinking and feeling that goes beyond the procedures.

This is a load of philosophical, agenda-based crap. The only one thing I’ve found you cannot do without is feedback. If you do not get feedback on your work you can never be done. If you are never done, you never get paid.

[…] development approaches might not work for you. Update: Irionically, I stumbled via Infoq about the one essential agile ingrediment which says all about it much nicer than I ever could have done, only that Mark Schumann shows the […]

Great article! This is truly spot-on and is extremely important insights if you’re going to pull off the Scrum methodology.

I wish everybody – especially in management – at every company tried to understand this…

I particularly liked this part:

“… 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.”

[…] The one essential Agile ingredient – "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." As true for agile development as it is for social engagement strategies… […]

Thank you for your comment, “Bull.” I think we agree on everything except the “crap” part, because feedback only works if you’re truly willing to accept it. It’s still incredibly important to listen and observe… with (ta-da!) humility.

If new information is to penetrate, management has to know they do not already know everything.

Kristofer, you’re too kind. I’m rethinking that last sentence you quoted, “You have to trust your teams, even when they don’t deliver the results you expect.” Hmmmm. At what point do you stop trusting? I mean, there are bad developers out there, or good developers organized in really bad ways. I don’t have an instant answer for that, even though it’s the type of thing I’m sometimes called upon to help decide. So thank you for reminding me of that.

So many times I’ve heard managers brag about their ‘Agile’ approach or team, and it turns out to be exactly like the Dilbert cartoon shown.

It’s been very disheartening to watch the term ‘Agile’ degrade over the last 3 or 4 years, from something that had substance and represented a welcome departure from the brain-dead corporate beancounter mindset, to become another code-word for unrealistic deadlines and a total disregard for all the hard lessons of the last few decades as the practice of software has evolved.

[…] 5 November 2009 Agile is a hot word in software development and there are many articles written about Agile, or not so Agile, software development. Most articles focus on the methodology but Mark W. Schumann has written an interesting blog post that looks at what is required for success with Agile development. One of the interesting points is that Agile is really an attitude or a mindset. He explains this in the article here, found here. […]

and you hit the nail right on the head, I sometimes fallen prey to introducing teams to the practices instead of taking a step back and explaining the objectives, a empowered, responsible and accountable team

[…] The situation calls for someone who is “aggressive without being arrogant” and “can handle pressure” while “getting stuff done.” And I thought hey, maybe this project isn’t necessarily right for me for some other reasons… but she did catch the spirit of what I talked about a couple weeks ago. […]