Agile core values: Individuals and interactions over processes and tools
The four core value of the agile manifesto are values which I strive to live by, both at home and in my personal life (where it fits, my wife doesn’t care how I write a birthday card, just that I do (although, I suppose that fits too!)). It’s the very core of my job as an agile coach, so I though it was a bit time I wrote a few articles exploring them and what they mean.
I really should have posted this sooner, but, for some reason I haven’t. I think, mostly, because I realised that I needed to get a better understanding of what the values (and principles, but they’ll come later) really mean. While I recognise that being agile is not a destination, but a journey (cheesey, right? But true). I think my understanding of them is now deep enough to write about them, so, without further ado, I present the first in a set of four articles…
Individuals and interactions over processes and tools
I struggle to believe that, in any organisation, there are people that think there is anything that is more valuable than it’s people. If you’re in one of those organisations, then, it’s probably time to look for a new job.
People are the one most important asset in any organisation and the key word here is ‘individuals’, no one wants clones working for them and the more diverse the people you work with are, the more satisfying and fruitful your work life should be. Having an interesting and diverse set of colleagues makes it that much easier to get up and go to work in the morning!
One of the mistakes that I often see made (and, unfortunately, perpetrated by a lot of online and digital scrum tools) is forcing yourself into using a process. It’s interesting to note that the two most popular agile methodologies don’t prescribe any particular process to follow with software development, but people believe that they do. Kanban, for example, is not just a board with a ‘todo’, ‘in progress’ and ‘done’ columns. Each column marks a step in your process. The process you already have. Scrum also doesn’t tell you how to build your sprint backlog, instead, it just says you should have one and is quiet on what you should put on it (with the exception of the sprint burndown, but that isn’t a process, just a tool).
Most companies will already have a process for the way they write software before they begin their journey toward being agile. Sometimes it might be as simple as describe, develop, deploy. Other times it will involve review, QA, regression, analysis etc etc. When you start your agile journey stick with the process you have, don’t make things harder for yourself by changing too much. Introduce the framework of choice and use it to help you see where your problems lie. Then, slowly, organically and by small, incremental changes begin to adapt the process you have into one that allows you to align with the agile principles and create great software (or any other product for that matter).
The point of this is that, really, the process doesn’t matter so much as the people using and creating the process. The tools they use don’t matter as much as the indiviuals working together to create the process and create, or use tools which support their endeavours. Having a process is important, but not as important as the people in your organisation using your process and adapting it to suit their needs in order to attain the principles of being agile. Having tools is important, if they’re the right tools, but not as important as how you use them and what you use them for.
If you’re somebody looking to implement agile in your organisation, or someone trying to make your organisation adhere closer to the agile ideals, then empower your people to improve themselves and their process and then leave them to it.
Hire good people, then get out of their way.
So, that’s the first core value. Next time, working software over comprehensive documentation.