ToolboxI was on a coaching call yesterday. One of the early questions was related to tools. The question was:

What sorts of tools do I recommend for a new team?

I pulled out my standard pitch related to agile tooling. I tried to convey that tools are less important in agile teams. I explained that I typically want to drive collaboration over “following a tool”, particularly for new teams. Then they brought up the dreaded next question:

But what about distributed teams? Are you saying that they don’t need tools either? What if I have team members in India, California, Philadelphia, Zurich, and Singapore? You can’t be serious that these folks need to somehow work on a whiteboard and use cards as their ultimate tool?

And I clearly backed off a bit while trying to explain. No, I’m not saying to use zero tooling or a webcam on a singular whiteboard in Antarctica. But…

I get into this discussion incredibly often in my coaching, in my classes, and virtually whenever I talk about agile teams. It comes up 100% of the time when an organization has distributed agile teams. Of course having tools is necessary within your software development teams. But within newly formed or forming agile teams, I don’t want tooling to be the first focus point. I want solid agile practices, principles, and tactics to be the first focus. And believe it or not, I’ve seen tooling time and again impede teams starting out. 

Don’t get me wrong, it’s not the tools fault. It’s just that we’re so comfortable interacting with tools over interacting with people, that they impede some of the essence points of agility like: craftsmanship, collaboration, quality, swarming, and continuous improvement.

So I wanted to share 10 simple pieces of advice related to your tooling. I hope you find them helpful, I hope they influence your tooling decisions, AND I hope they drive some conversations in the comments of this post.

Tooling Advice

  1. Don’t lead with tools; instead, lead with basic agile principles and as low-fidelity tooling as possible. By low-fidelity I mean: 3×5 cards and sticky notes, whiteboards, swim lane boards, flipcharts, tape, phones, webcams, simple meeting software, conferencing systems, wiki’s, google docs, etc.
  2. Do ensure that whatever tooling you initially leverage, supports full team participation in real-time. It may be klunky from a cohesive tooling perspective, but it must support the teams’ work!
  3. Keep the tooling LEAN. Keep asking yourself; is this the simplest possible tooling solution that meets the team’s current needs? So KISS principle in action; as well as Just Enough and Just-in-Time.
  4. Always try to get as close to Face-to-Face communication as possible. So if you have a choice between a GotoMeeting and IM, opt for the GotoMeeting—or a phone call.
  5. Iterate on your tooling – based on your retrospective feedback and discovery. Don’t be afraid to change / adjust your tooling strategies. In fact, I expect teams to move from simple, low-fidelity tooling to more “advanced” tools as they grow and mature. And don’t be afraid to “throw away” some tools as part of your transition; of course based on the teams’ feedback.
  6. Whatever tooling you decide to use at any given point must…WORK! Make sure that your infrastructure is rock solid – all of the time. If it doesn’t, it’s an impediment and one of your highest priority actions to resolve.
  7. Make sure you have etiquette down – for example, good discipline in muting calls when appropriate, or repeating questions, or asking attendees to speak up, or taking meeting minutes.
  8. Your development infrastructure has to be even more rock solid than your collaborative tooling. Builds, Virtualization, Test Automation, Coverage Analysis, Dashboards, etc. just need to work – locally and remotely. Don’t start “sprinting” if you have a flakey development and test ecosystem!
  9. Let the teams drive the needs based on real impediments, issues, efficiency ideas, and performance improvements. Tooling is not a management exercise; it’s there for the team first and management second. A “strong second”, but second nonetheless.
  10. Don’t EVER blindly “follow the tools”. For example, I did this work because we planned it on Sprint Planning and it was on my To-Do list, so I implemented it. BUT what if the teams’ context changed and this made the task change or no longer relevant. Tools – yes; Collaboration, engagement, asking questions, listening, understanding the Goal – YES!!!

Wrapping Up

Nearly everyone misunderstands my position when I have these conversations. I think I come across as an Agile Dictator or something. And quite often they discount the advice. Please don’t do that. Everything I’ve said aligns with the principles of the agile manifesto and lean principles. I simply want you to put your teams first and tooling second. And I want you to keep things intentionally simple – so tooling lite and collaboration & commitment heavy.  In the end, your distributed teams will operate better and deliver better results.

Now…do we get TFS or VersionOne or Rally or Jira? Let’s buy all 4 and see which one “wins”. Just kidding…

Stay agile my friends,

Bob.