Individuals and interactions

If you have ever tried to solve a complex problem, you probably discovered the benefits of working with someone else – whether that person had more experience than you or could just ask questions that challenged your thinking. Compare that to a time when you were handed a checklist and just ticked things off – which produced the better solution?

For simple, repetitive tasks, a checklist is a good way to reproduce a process – when I plan a photo walk, I have a checklist to ensure I remember to make a reservation for lunch, post the details to the website, and add it to the group calendar. I don’t want to forget any of those steps, but it’s the same series of things that I need to do each time – I don’t change that process from one walk to the next.

Fortunately, software development isn’t simple, repetitive work (if it was simple, it wouldn’t be fun!) – there’s always a new challenge to overcome and new business problems to solve. At a very high level, yes you could have a checklist (e.g. check in code, run all tests, update documentation) but it’s so abstract there is little value in it.

This is why the Agile Manifesto says “we have come to value: Individuals and interactions over processes and tools“.

Talking to people – whether they are on your dev team, they’re your customer, or some other technical specialist – is a great way to find creative solutions. Those individuals and interactions are essential – the old saying “two heads are better than one” is so true!

But as I stressed in my What is Agile? post, the manifesto says while there is value in the items on the right, we value the items on the left more – there is value in processes and tools too. How would a dev team survive without an IDE?

Every team works within a number of constraints (e.g. budget, project goals, even health & safety) and sometimes those constraints are expressed as a process (e.g. every code change must be tested by someone other than the developer). Hopefully, the processes are kept relevant and leave teams enough room to exercise creativity wherever possible. Similarly with the tools available to the team: “if all you have is a hammer, everything looks like a nail”, which probably doesn’t result in the best possible product.

Agile organisations need to strike the right balance between governance and creativity … which for some means having to appreciate that development is a creative process, not a production line.