#2782

When Tools Take Over Your Team Room

There were some good comments on my Tooling is a Third Order Effect post a few weeks ago. Tools and how they effect a team’s software development activities is particularly importance when you consider distributed teams because they often adapt their processes quite significantly and make heavy use of tools to compensate for their distribution. That combined with a thread here within the Microsoft agile community got me thinking about a mental model for (agile) process adaption and tooling.

When you think about it most tools are really a concrete instance of a process. Software Factories are a great example of tooling to support and augment a software development activity. So how do all the processes that make up your team’s software development activity fit together?

By the book

We all have to start somewhere. In most cases teams start with a process out-of-the-box or by-the-book. They may hire consultants or coaches to get them started but most teams start by trying something without significant alterations.

You may not do this for very long. Quite quickly you’ll find things that don’t work for your team, especially on a distributed team. There may also be business requirements which force you to adapt your process right from the start. This requires care as effectively you’ve skipped the inspect part of the inspect and adapt cycle.

In fact one of the biggest failure modes I’ve seen with new Scrum adoptions is teams who read the book and—because it seems so simple—change a bunch of things right from the start without understanding the potential impact of those changes. Typical examples include dropping daily standup meetings or lengthening their sprints.

Adaptation

The next step is to adapt the process. How soon you start doing this largely depends upon your team and their prior experience with whatever process they’re using. Agile processes are designed to be adapted over time. They use an empirical process control mechanism. In other words you inspect and adapt the process frequently. Agile teams have frequent opportunities to reflect on their progress and adapt it. Other types of process may be less amenable to adaptation but will probably be adapted none the less.

Pretty soon the team is using some the aspects of the process from “the book”, some adapted book practices and even some additional process that they adopted from elsewhere or are required to do as part of some business requirement; for example to support compliance with SOX or a company wide policy related to how and when software is deployed.

This is something that’s never done. Over time the red and blue circles may overlap less as the team further refines its process and optimizes it to its individual requirements. The process keeps adapting until the project ends and the team goes on to do something new.

Tools

What happens when we add tools? Most tools—especially software based tools—come with their own process, either explicit or implicit. Typically tools try and implement some “book” process. Some do this well, some less well. They may also be customizable to support some of the process adaptations your team or company uses. Examples of this might include the ability to produce custom charts or reports or adapt workflows to better reflect what people actually do.

Many agile teams use sticky notes and a whiteboard for a lot of process management. This has several advantages. It’s very easy to create your tool—the board and notes—to align with your process and the adaptations your made to it. It’s also very easy to change it as you make further refinements and adapt your process over time.

Considering tools is particularly relevant to distributed teams because they tend to have to use more of them to compensate for being distributed. This doesn’t just include software tools—like Visual Studio Team System—it also includes other tools which a collocated team wouldn’t use as much—like a conference phone for running daily stand up meetings.

A tools/process mismatch

What happens when tools are mismatched to the process?

The highlighted red area in the bottom right of the Venn diagram represents changes made to your process solely to support the tools. This might mean the team has to think about it’s velocity in a different way because the tool only supports burndown charts not cumulative flow diagrams. It might mean work has to be done in a fundamentally different way to accommodate the tool. For example if your source code control system only supports file locking not version merging then the team will have to account for this as they break down the work and create tasks!

My contention is that this is invariably a bad thing.

In some cases the tool may bring something new that the team likes. In which case this falls into the blue-green and red-green intersections on the diagram. In other cases the tool supplies something which the team cannot live without and they are prepared to pay a tax—in the form of some additional tool specific process—in order to get it. In other words the tool adds to the blue-green and red-green intersections but also adds to the red highlighted area (the tax).

As discussed above the team’s process is constantly being adapted so the tool’s ability to adapt is also critical if the red area isn’t going to grow over time.

I’ll be covering this model as part of my talk on distributed agile next week at Agile 2009.