Engineering Blog

Why do you want to be Agile?

I’m going to assume that you are part of an organization. Probably someone that is part of, or interacts with, an IT department. And that you are at least mildly interested in Agile – anywhere from ‘Hey, I heard about this Agile thing. Can it help us?’ to ‘We’re an Agile shop. Bring it!’ So, consider for a moment: why do you want to be Agile? Precisely, what benefit(s) are you expecting, beyond hanging with the cool people?

There’s a million reasons why you might want to try it. If you’ve read the Agile manifesto recently, the phrase ‘better ways to develop software’ might be compelling to you. Anecdotes from other development teams describing quality of life improvements might be attractive. Or you might have overheard a coach’s spiel asserting a 5000% improvement in productivity.

I’ve made some bold assumptions about who you are. Now, I ask you to imagine that I’m a Boss. I’m the guy that, when you’ve made up your mind that you’d like to adopt Agile practices, you need to convince to go along with you. How do you answer the question ‘Why Agile?’ for me?

So. I’m the Boss. You come to me with a proposal for organizational change; you want to create or change working agreements between departments. A soft argument about developing software ‘better’ is not going to convince me that I need to approve all these changes and accept the risks and costs of transforming my department.

The way to convince me is to identify pain points in the organization. Are we consistently taking longer than expected? Are we releasing defects into production? Are our customers complaining that we’re not delivering what they need? Once you’ve identified the pain point, figure out a way to quantify it. If you can propose to me ‘If we make this change, it will reduce the pain. This is the time frame in which we should see an impact, and this is how we measure progress.’ you have a basis for an experiment – a proposed course of action, an expected outcome, and a quantifiable & objective measure of success.

When a change is structured as an experiment, there is a framework for managing the risk of change. When will I get my improvement? How will I observe progress? How will I decide if it’s worth it, or I need to call it off? Can the information we gather be used to drive other experiments, or provide valuable business intelligence? Being able to answer these questions makes me – one of the Bosses – much more likely to accept your proposal.

The next challenge, of course, is how to provide good metrics that aren’t bullshit. They need to be quantifiable; they need to be objective; and they need to have a high enough resolution to be useful (e.g. annual reports are probably not frequent enough to inform decisions). The better the metrics, the more I can use them to inform my decisions. And since the metrics allow me to quantify how great those management decisions are, I have a stake in the transformation.

Agile methodologies (Scrum, Extreme, Kanban, etc) provide a good foundation for measuring pain. I personally like Kanban; it has a very high resolution for metrics gathering. But, whatever methodology you use – Agile or not – the ability to provide good metrics are invaluable when justifying organizational change. So understand where the Boss hurts before you’re asked ‘Why Agile?’  If you explain how Agile can help them feel better, you’re more likely to get buy-in; and then maybe YOU can be one of the cool people!

And now, a shameless plea for feedback: What metrics have you used? Which have been effective, which are useless, and which are bad? Comment below, and we can talk more about what makes a good metric.