It is critical that whatever change management tool is used allows developers, managers and testers to share the same specifications and modify them easily.

Managing Virtual and Distributed Development Groups in an Outsourced World – Part 2 of 5

In Part 1  of “Who Moved My Team,” we discussed ways to determine if a release will ship on time, along with the pros and cons of managing to milestones or using a task-based or metrics-based approach. Today, we tackle how to manage change.

Part 2 – How Can I Manage Change?

Change in a software project is inevitable. In fact, Agile software methodologies generally embrace change as a desirable part of the development process. But such methodologies (e.g. Scrum, XP, et al.) generally rely on a very high degree of cooperative effort between development, management and the end user.

One company we worked with ended up shutting down their distributed QA team because they couldn’t manage change. Developers would change product specifications on the fly, and the outsourced QA team would log the new “feature” as a bug. Both teams became frustrated with each other, and ultimately, the testers were brought back in house. This company threw away a sizable commitment of time and money because they couldn’t field a change management system that would allow developers and testers to communicate quickly over changes to their specifications.

What Works?

It is unreasonable to expect that in all cases specifications will be executed as originally implemented. Simply saying, “developers may not change the specification,” does not address the problem. Agile is all about embracing change, after all. Therefore, when managing requirements, especially for a remote team, it is critical that whatever change management tool is used allows developers, managers (including both development and product management) and testers to share the same specifications and modify them easily.

In the most aggressive case, this implies a workflow/authorization process that some high-end requirements management (RM) tools provide. However, in the simplest case, a developer must be able to at least easily document the fact that they deviated from the specification, and it must be easy for Testing and Management to observe that fact.

The simplest answer is to implement an electronic version of the storyboard – one that everyone on the team can easily look at, comment on, or change. There are numerous tools that can facilitate this kind of collaboration. Tools that can do this job – to varying degrees of effectiveness – include:

  • Acunote
  • Scrinch
  • AgileZen
  • TinyPM
  • Jira
  •  Trac
  • Mingle
  • VersionOne
  • Rally
  •  xPlanner
  • Pivotal Tracker
  • 21Scrum

There are many, many more to choose from, and I make no attempt to rank them here – I’d get hundreds of emails about how I “missed the best feature of X”, or I just “didn’t get it” when I said Y about Z… It doesn’t matter – search for “agile collaboration tools” and you can find full-featured reviews galore. The point is, there are an abundance of tools that allow close integration between the people gathering and formalizing requirements, writing code, and testing. Find one you like and put it to use.

Key features should include the ability to easily

  • Generate new requirements
  • Change requirements – and easily see who has made what change…
  • Comment on, or ask clarifying questions about, requirements
  • Indicate the state of a requirement
  • Record testing results

But the most important feature is that the tool must easily integrate into your team’s workflow. It must be the repository of record for all project documentation. It doesn’t matter what someone told you on the phone, or even wrote in an email – it is the collaboration tool that holds the definitive set of notes. Therefore, it’s critical that team members have the tool open all the time, whenever they are working. It should be like an email client – always accessible.

Implicit with that is that there should be one such tool. We had a customer who regularly tried to use multiple channels to convey information. On any given day, you might receive a phone call, an email, a text, a ping on Skype, an update in their issue tracking system, or a note in Hipchat. Any one of those media could be used to change a specification, or to re-prioritize tasks. We had to tell the customer that we would only respond to comments posted in the issue tracking system – and actually turned off Skype and chat, and stopped answering the phone.

The point of all of that is: pick one tool and use it as the source of record. Make sure every piece of code written tracks back to something documented in that tool, and document any changes there. Other media can be used to bring someone’s attention to a change to that source, but may notreplace that source as a record of change. Do all of that, and you’re halfway home…

Next Up

We continue the conversation of managing virtual and distributed teams in the Part 3 – How Can I Evaluate My Team’s Performance?