BT

Individuals and Interactions are Important, but so are Processes and Tools

by Craig Smith on Oct 07, 2011 |

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?
 

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

It's good to see critique starting by Adam Nemeth

In recent months, I went crazy after I've seen a company falling by taking Agile and Scrum literally and seriously. It was nothing but processes and tools. Every time I saw an article on infoq, I was the first one to respond, that Agile is not the Holy Way and shouldn't be adopted in an enterprise culture, in an enterprise way.

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... by Craig Smith

Almost on queue at publication, Alistair Cockburn posted this interpretation of the Agile Manifesto on his blog: alistair.cockburn.us/Individuals+and+interactio...

What does it really mean by Individuals and interactions by Renee Troughton

I like to think of that manifesto line as such:

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?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT