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
Ken Schwaber in his Telling it Like it Is blog questions Microsoft and their understanding of individuals in their implementation of Visual Studio 2011:
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.
Michael Huettermann, author of the recently published book Agile ALM argues that both people and tools are important in a Java.net article:
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.
James McKay has a different perspective, suggesting on his blog that tools are important but good software developers are focussing on their own process rather than focussing on tools for people:
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.
Taking a process angle, Ricki Sickenger argues in a post on his Syntax Meditation blog that Agile itself is a process and a set of tools:
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.
Mike Pearce on his blog takes the team angle further:
… 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?