What is Agile?

Several years ago, I was given the job of “looking after” Agile for a 10,000 person IT organisation. There were thousands of systems and projects. We knew that a large proportion of projects were Agile because our enterprise architects had sent a questionnaire to the project managers of our most critical 100 projects and one question was:

Is your project Agile? [Yes/No]

Fortunately, I do a lot of work on miscommunication so I suspected numerous problems with asking that question and asking it about projects. I phoned a selection of project managers and asked “You’ve said you’re Agile; what does Agile mean to you?” and here are some of the answers I got:

• We go fast
• We deliver every week
• We work directly with traders and do what they say
• We have a daily meeting  (other questions revealed this was a waterfall project)
• We do Scrum

In other words there were at least five definitions of “Agile”. This didn’t surprise me because I think if you ask five Agile experts what Agile is, you would also get five different answers.

My conclusion was to avoid using the word “Agile” because everyone had a different definition (and educating 10,000 people to have a single definition is not an easy task).

What is Scrum?

In the next pass of the questionnaire I got the question changed to ask:

What method(s) do you use to deliver your project?  [Pick one or more: Waterfall, Scrum, XP, Kanban, Others (please tell us)]

Which wasn’t a perfect question by a long stretch but removed the ambiguous “Agile” word and meant PMs would at least give us a clue about the methods in use and whether they were hybridising them.

As Scrum was overwhelmingly the most popular non-Waterfall method, we then interviewed key people on some Scrum projects to see what they did; I’d loosely categorise the answers as:

• Scrum by the book (give or take)
• Scrum but important bits missing
• Just the Daily Standup
• OMG!

The OMG! category included projects that actively did things that Scrum said not to do: such as the project that had multiple overlapping sprints with people allocated a proportion of their time to different sprints at the same time.

And, as an aside, this isn’t an Agile thing: I interviewed some Waterfall people about their processes and the answers didn’t particularly resemble Waterfall.

My conclusion was to be careful using the word “Scrum” because people had some very different definitions.

Don’t go Agile: Agile transformation the right way

The major conclusion I came to from all this is: Don’t go Agile

And that’s because no-one knows what you mean when you set “go Agile” as an objective for your team or organisation. The same is true (to a slightly lesser extent) of “Implement Scrum”. I have seen a number of “Agile” implementations go horribly wrong because of the ambiguity.

Of course, if your team is small or you have excellent communication, you will work through the ambiguity and potentially create something great. But for larger transformations that’s ineffective and often impossible.

When I coach management teams starting their “Agile” transformation, I start by unpacking what they mean and what they want to achieve. In the process, we lose the word “Agile”.

Asking what Agile means for each manager is a good way to surface the ambiguity and uncover information and conflicting views. But the real meat is in uncovering the business-meaningful objectives and creating a strategy for making incremental progress towards those objectives. This creates a benefits-led transformation.

A benefits-led transformation has a few clear objectives, which will be unique to that transformation. For example, at a programme or project level, you might aim for:

• Number of post-release serious defects
  • Goal: less than 1 per year
  • Current: 100 per year
• Frequency of delivery
  • Goal: monthly
  • Current: 6-monthly
• Stakeholder satisfaction (measured by Net Promoter Score)
  • Goal: +25
  • Current: -50

These are the promises of Agile, but brought to the forefront to be discussed, planned against and tracked to make them happen. And they will be unique for your situation with your managers and stakeholders.

In addition, a good benefits-led transformation has a strategy, making key decisions such as how to engage vendors, staff and other stakeholders; how to balance delivery against transformation; how to develop competency; how the management team will work together to incrementally improve on each of those objectives and how they want to react when things don’t go to plan (which they won’t).

It will have a roadmap, perhaps of practices to introduce, perhaps of infrastructure projects (building continuous integration servers or test environments), that make regular, measurable progress towards the objectives and create a regular stream of successes and accumulating benefits.

And it will have a vision: a motivating, emotion-led view of the end state and what it would be like to get there.

I’ve noticed taking a management team through this process creates a change in mood. Where a team may have started with enthusiasm and excitement, they face the reality of what needs to be done and realise that transformation is hard – difficult discussions, difficult changes, difficult work for them. But they also realise that the benefits are worth it and that this is the real job of a leader and the mood changes to gritty determination.

So what would you like your transformation to be like? Blind enthusiasm for Agile, where no-one understands what that means; or to target clear objectives that matter to you and your business, and face the reality of getting there with gritty determination?

What Next?

• To learn this in-depth, look at our training and our coaching
• To benefit from the approach in your organisation, please Contact Us
• Let us know what you think by commenting below

Credits

Image courtesy of Stuart Miles at FreeDigitalPhotos.net