An Executive’s Justification for Agile

I was recently working with teams at a client as they transitioned from a traditional project management mentality to one of Agile. C-Suite Executives originally felt comfortable with traditional project management because dates and scope were communicated and they could “abstract” the day-to-day details of that project away, allowing focus on the strategic concerns of business. Delegation is a common tactic of successful managers and is how much of the corporate world gets large initiatives complete.

Often many middle managers struggle going from high performing doers to strategic generalists (Watkins, 2012). The managers that aren’t able to delegate and move up, struggle in their position. So many successful executives work this way – get the details onto the plate of someone else. There are a few problems though, as we know today:

  1. Can the executive trust the date and scope that your project managers are giving you?
  2. Are the executives asking the people underneath them to work very differently from the way they would like to work (delegation of details)?

Many have addressed the first question on trusting date and scope, so I won’t discuss in depth here. But you can certainly look at the success statistics of waterfall projects here and here and come away with a conclusion that, on the whole, bigger projects struggle with waterfall methodologies.

Addressing question #2 is where I’d like to go in this post: Are you asking the people underneath you to work very differently from how you’d like to work?

There are at least two roles that will suffer in this model:

  • From the executive’s perspective, they like to have the details happen elsewhere, but what happens in traditional project management projects is that someone builds a project plan, and then everyone works to that project plan. Team members might be updating their % complete on every task, and that rolls up to total project % complete. In many cases, the project manager manages an all-inclusive project plan, from low level tasks to strategic milestones. That person must be aware of both the details and the high level: a challenge. Compared with Agile or Scrum projects, the team commits to building features and functionality; how they do that is their business. Notice the difference?
  • From a “resource manager’s” perspective, that person is asked often to time slice their individuals and think each and every time how people fit best together to get the job(s) done. I once spoke with a customer that had just moved over to Agile and as a resource manager, he asked the question “Now what? I don’t know what to do with myself.” He was literally busy shuffling people around, but all that stopped when his teams moved to Agile. The shift to a more strategic approach has led to career success.

Let me propose that you think about an Agile transformation or some Agile adoption in your organization as just applying good business/management sense, in the following ways:

  • Delegate the “HOW” to the team itself. Stop having your managers up the chain so involved in the implementation details of your software delivery. This should come naturally to inherent natural managers.
  • Delegate the “WHAT” to someone – preferably a product owner. This is usually a challenge for executives. A project is usually a WHAT and a WHEN, because software is fungible (i.e., it can be divided up nearly infinitely different ways). This fungibility means – you can have a high level WHAT you hold others to account for, but let them make tradeoffs on the details. Normally, your project is not a failure if they did not get that least most important feature.

Now that we hopefully agree that Agile makes good management sense, it’s important to discuss how to get there. You should consider hiring an Agile consultant to assess your specific situations and provide a detailed change management plan. You should also challenge your immediate subordinates to think about “delegation” and work towards that end. Even if you do not adopt (or, implement) a full Agile environment, you will get better results and a more engaged organization, which is a ‘win’ from every angle.