Individuals and Interactions are Important, but so are Processes and Tools
The first statement in the Agile Manifesto values “individuals and interactions over processes and tools”, and it has been the topic of a lot of discussion in the Agile community of late.
Jeff Langr and Tim Ottinger in their article The Only Agile Tools You’ll Ever Need in the September issue of PragPub magazine make the point:
We’re quick to point out that the Agile values and principles do not say “don’t use tools!” They instead say we must emphasize “individuals and interactions” before we consider tools. The two quoted principles remind us that we want team members to work closely, to converse continually, to collaborate.
They go onto address the costs in relation to using tools until finally making the following conclusions:
Our criteria for tools are that they:
- aid the team (hence the emphasis on development and testing tools)
- add no unnecessary burden to the team
- do not substitute for leadership and management
- provide coercive immediacy to aid the team
- are given their rightful place as aids, not drivers
Many organizations have not adopted the self-organizing, team-based aspects of Agile. They still are predictive, top-down organizations. Tools that don’t support this function are hard to sell. However, form follows function. If we continue the same predictive manufacturing model, wrapped in Scrum tools, we as software professionals will have a very hard time rising to the increasing demands of our world for creative, sophisticated, quality products.
Scrum without self-organization and empowerment is a death march, just like waterfall, but an iterative, incremental death march without slack.
Working with Agile ALM should start with values and people as well as concepts behind it. An Agile ALM tool is an ALM tool that fosters an Agile process. An Agile ALM tool must be able to add value to the system and improve the collaboration of the stakeholders.
If we were serious about the Agile slogan, “Individuals and interactions over processes and tools,” projects aimed at non-developers would predominate. As it is, a lot of it seems like a case of programming for programming’s sake.
A lot of developers are introverts, and find it easier to spend time writing code than interacting with people. But if you want to produce something that’s really useful, you need to spend some time getting out from behind the computer, developing other hobbies and interests, and interacting with people. After all, that’s where the ideas for useful software come from in the first place.
TDD, XP, Scrum, Kanban (and the rest) are all processes and tools. All their proponents claim you *have* to follow the process, no matter what. If Agile fails for you, then it is because you are not following the process!
He goes on to say:
Agile is great, and methodologies like Scrum, TDD and XP can be good facilitators for getting from concept to release. But they do not solve the fundamental problem that a bad team fails no matter what process it uses.
… 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 individuals 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.
Ultimately the Agile Manifesto values processes and tools, but values individuals and interactions more. Mike comes to same conclusion:
Hire good people, then get out of their way
Ten years after the Agile Manifesto was written, the debate and discussion continues. Should we value processes and tools more, and if so, should it be at the detriment of individuals and interactions?
It's good to see critique starting
I remember I even wrote a detailed mail to one of our Agile coaches from a well-known scrum coach vendor, asking, why do they enforce some things and why do they discourage inconvenient, yet healthy tools which are useful
It's good to see that after the recent enthusiasm including calling Agile "simply software development" and going to other extremeties, more and more articles are appearing on InfoQ questioning these one-size-shall-fit-all practices.
As for tools, I'm an old guy: I like to create my own tools sometimes, after carefully watching for weeks what's wrong, what could be improved, yet I also believe that the old guys weren't that stupid as we currently see: I prefer use cases over user stories, and I still know why to use strict UML, yet I'd never think of writing a 100-page design documents before implementing. Yet I believe, it can still make sense on a whiteboard or on the pages of a notepad.
One more thing...
What does it really mean by Individuals and interactions
Who makes the software? People.
What do you think happens if you don't treat the team of people with respect, if you don't listen to them, if you don't appreciate and support them? They become unmotivated
What do unmotivated people do? They don't think outside of the box, they don't push themselves to be high performing.
The interactions bit for me is about going back to communication 101. Listen, collaborate, co-locate to get the most out of the team. As per the Allen Curve the method of communication matters, the best being real time and in person.
So we want to focus on happy people who are able to effectively communicate because if they don't then no matter how much of a spectacular process or tool is in place, it won't result in the most optimal result.
Nice article Craig - you had a lot of other people's opinions in there, I have heard you passionately talk about this - what is your take?