There's a recent thread on the Scrum list about how an executive or highly-placed manager could get Agile going. I've been one of those guys, and I know a bit about Agile, and here's how I'd proceed. First, focus management attention on cyclic delivery of running tested software. Second, provide the resources to learn how to do that.

D... If You Do, D... If You Don't.

I believe, and it’s pretty well accepted in Agile circles, that you can’t impose Agile practices or methods from above with much chance of anything good happening. People don’t understand, don’t know what to do, and will resist doing what they are told. The results will be mixed at best.

So what if you’re an executive or highly-placed manager, and you’ve become interested in getting the benefits that you’ve heard about, read about, or perhaps even seen, in an agile situation? Do you have to sell into your own organization in hopes of getting a groundswell going?

I’d like to suggest that the right starting point is to focus the managers, projects, and teams that report to you on results, not on approaches. Let them choose the approaches, with some assistance in considering and learning about the options.

OK ... Then What Results Do We Want?

A while back I was interviewing an executive from a large utility, and I asked him what his customers wanted. He replied “They want it free, now, and perfect.” We had a good laugh over that, but of course, that is exactly what they want. It’s what we all want. We want our software cheaper, sooner, and with fewer defects.

Now, the executive in question has a means in mind: Agile software development. He may have some buzzword favorite in mind, perhaps Scrum or XP. I’d suggest that he should set the specifics aside, and ask for what all the Agile methods purport to deliver.

OK ... Then What Do We Ask For?

Let’s iterate a bit. Here’s my top-level suggestion:

  1. Running Tested Software Let's make it clear to our reports what we will honor, and what we won't. Most even semi-competent managers are pretty good at giving the boss what he wants. That's how they survive. Therefore let's require our direct reports to focus their monthly status reports and other communications on concrete demonstration that real, deployable software, passing customer-specified tests, has been produced each month. Let's accept no other form of "progress" as being particularly interesting. You're working on the requirements for Project X? Boring. You've got someone figuring out architecture for Project Y? Boring. The guys are designing Project Z? Boring. What have you done for me lately? Who has built something that their customer will certify is part of what they want? That's interesting. Who has shipped something to their customer and the customer is using it? That's very interesting. Note: I would not expect to have to create new incentive programs, do intensive metrics, anything like that. I would simply make it clear to my reports, every time we met, that the only thing that matters is the production of running, tested software, every month. See A Metric Leading to Agility, for a bit more discussion on how this works.
  2. Coaching and Training. Arrange contracts with leading lights in all levels of Agile software development. People who can come in and present to management and teams about what's possible, what's going on in the business. People who can come in at the dirt level and teach teams how to test, how to refactor, how to plan and track, how to do all the down and dirty techniques that really have to be done to execute an Agile approach safely. Make those leading lights available for training and coaching to any manager at any level who wants them to come in. Those lights aren't there to code or do work, only to enable the team members to learn how to do what I'm asking, namely to show me running, tested software every month.

At this level of detail, for most organizations I’ve worked with, this is all it would take.

If that’s what I care about as an executive, that’s what most of my managers will learn to provide. Some may not learn, and I’m sure those will find rewarding careers elsewhere. But that won’t be very many of them, because with the clear requirement to focus on delivery of provably desirable stuff, and the resources to learn how to do it, folks in the organization will step up to the task.

Managers … and everyone in the organization .. are typically pretty responsive to clearly-set objective that can be met. They’re typically pretty responsive to what their manager really wants, especially if they have the resources to accomplish what is asked. We’re talking here about

  • Clear Objectives: We value running tested software meeting our customers' needs, and
  • Real Support: We'll provide training and coaching, free of budgetary impact, for anyone who needs it.

Frankly, my experience says that any competent upper-level manager or executive can take these starting ideas, and by sticking to them and using his normal everyday management skills, bring his organization into the 21st century.

Ask for what you want; provide the necessary resources. Leadership 101; Management 101.

Is It Really That Simple?

Well, no, and yes. Nothing is really that simple. After we set these objectives, we’ll need to stick to them, explain them, help people figure out how to meet them, and maybe even occasionally kick some butt. Management is never simple.

And yet, it’s a lot simpler than one might think, approaching things from other angles. We don’t need to define how things will be done, or set up complicated incentive schemes and such. Generally speaking, managers who understand their objectives and who have the resources to accomplish them, will do a pretty good job of accomplishing them. With those few who do not accomplish their objectives, we already have means of dealing.

I’m expecting this article to generate some questions, and when it does, I’ll extend it or supplement it to deal with those questions. But if you’re an executive wanting to go Agile, I suggest that this article describes a decent place to start. For further information, write or call.