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.