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. 😉
Share this:
Software is too expensive to build cheaply.... 
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.