Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

What's Agile? Individuals and Interactions or Processes and Tools?

05.26.2010
| 11072 views |
  • submit to reddit
The Agile Manifesto is one of the most admired and ignored documents around. So many claim to be "Agile", then their actions tell us they are anything but. Which brings us to this series of articles... what is agile?

I always go back to the manifesto. It's not perfect, but it's a really good starting point. What's the first of the four main points?

Individuals and interactions over processes and tools

Step back for a moment and consider how many "agile" companies want to only sell you a tool. How many consultants want to sell you a process? Have you ever wondered how many of the tools or processes actually enhance "individuals and interactions"?

I find, all over the United States, teams that have a tool in place that does the exact opposite. What does a code review tool (designed for remote developers) do to developers in the same room? Are we enhancing interactions or replacing it? When developers in the same room use a tool instead of talking to each other, you've failed this test.

When the feature and issue tracking systems are used exclusively, how do these tools affect your team's interactions? They isolate the team. Plain and simple, if someone would've had to walk over and ask a question (that a technical term for "interact"), but they instead look at a report, is that better or worse? When we can file thousands of bugs and not look anyone in the eye, does that provide a better product?

I've seen teams with several thousands of logged issues. One team measured them in decades. (That's right... decades.) When those same teams are forced to use a simple tool to track their work (like a 3x5 card and a Kanban swimlane), it forces people to talk. They say "Hey, these cards won't all fit on this wall! Where do I put the other 19,000?" And that starts a really good discussion about which features really mater and will fit on the wall.

"Hey, are these the right swimlanes? I think we should have more." "No, less"  Excellent! These interactions get people talking, thinking, and making better decisions.

Many of these tools hide what the Pragmatic Programmers call "Broken Windows". If there are dozens of bugs hidden away in a database, it's pretty easy to add in a few more. If there are thousands, go nuts. Record them. Don't record them. It doesn't matter when they're hiding in so much clutter.

However, when the card wall is visible and everyone can see that several features are blocked, they ask why. Did I slow you down? Who did? Can I help? (That's technical talk for teamwork and interaction.) When the backlog for one week contains 60 items, people talk. When a bug tracker has 6000 items for one week, it's more easily overlooked.

So are you Agile? Are you using Agile Tools? There's nothing wrong with tools, as long we use them properly and place the right value on the right things. One way to phrase it might be to value:

Individuals and interactions over processes and tools

Do your tools streamline the interactions right out of your team's day? Then throw them out. Don't continue throwing good money after bad. Make sure your tools enhance and encourage your team's daily interactions to build the best product possible.
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)