One of them relates to tooling and distributed agile teams. It seems as if everyone is searching for a “Silver Bullet” tool that will magically make agile work incredibly well for his or her distributed teams. Far too often the question relates to a specific tool, for example, “Bob, should we use Rally or VersionOne for our teams”? Tell us which one to select.

I usually use this as an entry point for a larger and broader discussion. That is – are tools the number one concern in initiating a new set of distributed agile teams? The usual answer is yes. In fact, it’s often the case that tooling is the first thing that organizations focus on when they’re transitioning to agile and I think that’s the wrong approach.

I’d much rather they focus on teams, organizational training, and getting a healthy, low-fidelity start than immediately trying to buy their agile implementation.

So, what’s wrong with tools?

The short answer is nothing.

Have you even been dumped by a girl or boy friend and the reason was – “It’s not you…it’s me”? Well, it’s the same answer with Agile Lifecycle Management (ALM) tooling. It’s not the tools – it’s us.

Many of us are looking for tools to help us solve really complex problems. We put the tooling before the teaming or the people. If you understand the underpinnings of agility, you realize that view is backwards. Tools never solve your hard problems…people do.

Let me illustrate my point with a story

I joined a company a few years ago as an Agile Coach and Scrum Master. They were quite new to agile. They had installed Rally’s agile tool and asked Rally to come in for a bit of training and coaching. So, they did just that – installed the tool, got things started, and went away. The organization at this point was on their own in their agile journey.

Not necessarily bad and they had done a nice job of what they’d been contracted to provide.

I joined about 3 months later. As the “Scrum Master” I also inherited administration responsibilities for Rally. I’d used it at several previous jobs/clients, so I was fairly familiar with the tool. But I’d never been the sole administrator and was looking forward to gaining more detailed knowledge.

Around my 4-5^th day on the job, one of the developers (Mike) came up to me really anxious about something. He said – “Bob, I need a Rally trigger configured right away to remind me to talk to Sally whenever I work on a backend stories of this specific type. Sally is expert in that area, and I feel her review and approval would be a good thing to get”.

Not knowing any better, I could only agree. But when I looked to the right of Mike, I noticed a nametag on the seating space right next to him. It read – Sally Smith.

I asked Mike – “is this the Sally you want the tool to tell you to collaborate with”? I mean Mike; she’s sitting right beside you.

Mike said – “Yes”!

You see, the entire organization blindly followed the to-do and working list produced by the tooling. Beyond collaborating at the daily standup for 15 minutes, there was simply no other collaboration…unless Rally reinforced it. I’m exaggerating a little bit, but not by much.

Guess what I did? So did I give Mike his “collaboration nudge”? No.

Instead, I pulled the plug on Rally. I felt that the team wasn’t mature enough to leverage the tool AND demonstrate the collaborative behaviors of solid agile teams. So I decided to ���retire it” for a while and go back to very low fidelity tools like whiteboards, flipcharts, and post-it notes.

I told the team that we would turn Rally back on after they had gained more experience and maturity in their agile journey. That in other words, they had to EARN the tools.

Maturity matters

I think the moral of my story is that tools in and of themselves are not bad. But, I truly believe agility is best learned with:

• The simplest possible tooling, paper and electronic, that can support your agile needs;
• Tools that don’t get in the way of team collaboration, but rather reinforce and enhance it;
• Tools that the team influences based on their needs and NOT driven by management reporting/tracking needs.

The focus on new teams should be on face-to-face collaboration. And yes, even if the team is distributed in some fashion.

Now this recommendation is for new teams. As teams mature, they can expand or change their usage of reliance on tooling. But they’re doing it from a position of experience rather than as a start-up silver bullet.

Finally, a Commitment to Agile Principles

This is another conversation I often have in conferences. I often get challenged that agile doesn’t work in distributed team contexts. That if team members are 12 time zones apart, it is virtually impossible to collaborate.

I try to remind them that this is a choice teams make. If the teams are committed to agile principles, then they will find a way to support the collaboration and teamwork aspects of agile even if it’s inconvenient because of the time or any other obstacles.

For example, they need to commit to the daily stand-up as a communications and collaboration synch-point as a team. That they’re not doing it to “be agile”, but they’re doing it because they’ve made a collaborative commitment to their team and to a new way of working. Even when it’s challenging because of time zones!

I also encourage them to get creative in how they collaborate. For example, rotating meeting times so that everyone gets a fair chance to get up early and using simple webcams so that they simulate face-to-face conversations. I’m always surprised at the solutions that teams come, to ease the challenges, when they commit to the principles.

Wrapping Up

Is implementing agile in distributed contexts harder than with co-located teams? YES!

Are tools incredibly useful in distributed team contexts? YES!

But don’t let the fact that your distributed OR the tools you use move you away from operating solid, fundamental principles within your agile teams. And occasionally “dust off” a Post-it Note or two.

Stay agile my friends,

Bob.