Agile – it’s not about the tools you use

The title says it all, but I thought I’d spend about eight hundred or so words saying more. 😉

I’ve seen a number of people think that “being Agile” is about having a build server, or about using Kanban, or an Agile project management tool. It’s not about unit testing, or pair programming, or continuous delivery, or devops, or any of a hundred other buzzwords. Don’t get me wrong – well performing Agile teams will be using these kind of tools and practices. But that’s not what makes them Agile.

But so what? Does being “Agile” even matter? It’s a label – we could call it something else, like a racoon. Would that change anything? At the end of the day, does being Agile matter?

Yes.

Being Agile is about values. In particular, the values specified in the Agile Manifesto. The very first value mentions tools – they count (and they count a lot), but they don’t matter as much as the individuals and interactions between the individuals. Values are important – the values behind your organisational culture shape it over time. A culture that values process more than people will inevitably seep into a bureaucratic environment. Tip the value towards the people, though, and you move towards a better working environment, one where innovation is appreciated and people are engaged.

To my mind, there are two key practices that a team must be doing in order to have a chance of being Agile:

  • self organising and empowered teams
  • reflective improvement

Why these? Well, Agile teams must be self organising, and they must be empowered to change the way they work. This means they should be able (for example):

  • change their seating arrangements – ideally the furniture layout as well
  • decide for themselves how to track progress internally to the team
  • pair – or not pair – on tasks as they deem fit
  • put up posters in their work area
  • have the authority to decide if their work is acceptable to them.

and many more besides. This doesn’t mean free rein – the larger organisation can impose constraints, but those constraints should be explained, and traced back to a rationale. For example – re-arranging desks may not be possible because the electrical and networking cables can’t be shifted, or a particular technology choice may be vetoed or mandated because of ongoing maintenance issues. But within the bounds of “this only affects us”, the team should have as free a rein as possible. This is all necessary because if you don’t have this freedom, you can’t do reflective improvement.

(A corollary of this is that the team should have at least some discretionary budget and schedule. Not everything the team will want to do is going to be free in dollars, and nothing will be free in time. A team of 10 people will cost an organisation well in excess of a million dollars plus a year, between salaries, hoteling costs, overheads, and so forth. Give the team less than 1% of that – or about $10,000 – and don’t put too many strings on it. Judge them by the results. If they spend the money on iPads and comic books, but deliver well, be happy; the desired result was achieved. As for the schedule – well, Google does 20% time. So does Atlassian. If one day a week seems excessive, try a day a month – that’s 5% time. Or give a week to each person in a rota – team of 10, that’s 10% time)

Self organising empowered teams are nice, but that’s merely a pre-requisite for the important part – reflective improvement. This practice can be summed up in a couple of points:

  • every so often, we stop and look at what we are doing
  • the stuff we think we’re doing well, we keep doing
  • the stuff we are having problems with, we try to improve
  • the things we don’t believe are adding enough value to justify their cost, we try to get rid of – or make cheaper
  • and every time, we look at some way of improving the way we work

If a team practices reflective improvement, and if they are sufficiently empowered to change for themselves, and if they have the right set of values, then the only thing stopping them being Agile and delivering a quality product is their own competency. Fortunately, being Agile isn’t hard – it doesn’t require a team of geniuses, just normal people. But it will make them deliver like a team of geniuses.

Unfortunately, there’s a lot of things that can get in the way. The enemies of Agile are standardisation, micromanagement, bureaucracy, misalignment of responsibility with authority and accountability, risk-adversion, and a conflicting corporate culture. These can be done with the best of intentions, and they can have all sorts of justifiable and laudable reasons, but they can kill Agile dead because they distort the values, reduce empowerment and prevent reflective improvement.

The trick, always, is to find a balance.


Update: Oh, and a hat-tip to Ben Ihle for suggesting the topic. 😉

Advertisements

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 18 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 16 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

1 thought on “Agile – it’s not about the tools you use”

  1. Thanks for the mention 🙂

    It really does comes down to the ability to adapt the process depending on the team, the company, the project and even the iteration. I see being able to adapt as (partly) a function of transparency (i.e. informational openness), and empowerment.

    It’s interesting to map the way companies view ‘agility’ w.r.t. the dreyfus model — quite often many seem to get stuck at the first step, i.e. “rigid adherence to taught rules or plans and no exercise of discretionary judgment”, which is perhaps where thinking along the lines of “We use tool / technique X, therefore we’re agile” comes from.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s