Making Global Teams Agile (Part 2): Tools and Documents

This is the second part of our series about what we've learned about Agile over the past 2 years working hard to get to a simple, standard process for making Agile and SCRUM work in almost any team dynamic. As we've said before, our teams focus on making resources that live and work all over the globe behave and feel like one highly effective team.

We know the keys to success are picking an agile methodology (in this case SCRUM) that allows for frequent, short communication (Meetings) and selecting tools (Tools) and documentation templates (Documentation) that ensure all team members and stakeholders communicate consistently and effectively. We'll talk more about commitment to stakeholder / client communication and ensuring a trusted presence in a follow-up article but in this entry we focus on what you need from your tools and the importance of Agile project documentation.

There are many Agile and SCRUM centered tools on the market today, both for use in the cloud and installation in house. Many of these tools are adaptations of traditional ERP system modules from larger companies, others have grown up in the open source community, and still others are lean and focused on just SCRUM. VersionOne, Pivotal Tracker, and JIRA from Atlassian are among some of the most popular and widely used tools on the market and each represents a slightly different class and approach to dealing with Agile projects. Selecting the right tool to track stories, issues, and defects for your team is important, but at the end of the day, using the tool for just the right amount of process is what leads to truly effective and successful teams. Many teams couple the use of one of these tools with a Wiki of some kind and cross linking (using URLs) between the two systems. Wikis make a much better coherent and version aware record of detailed decisions than does a collection of stories or epics (item entries in the agile tracking tool) and accepting the need for a mix of wiki and other documentation is critical to making teams successful.

Priority number one in establishing a tool is to set up a simple process and establish common understanding of the language of the tool across the team. Processes and tools, just like meetings (see part 1), have a tendency to become heavy-weight over time and cut deep into the time available to do actual development work. Striking a balance between effective project tracking and reporting and protecting the 30 hour + work week is crucial no matter which tool you select.

Typically, Agile tools provide ways of doing the following things: describing requirements, prioritizing features and defects, estimating (points and sometimes hours) work, tracking item status and progress, calculating team efficiency over time (velocity), and planning and closing sprints and releases. In the end, all of these tools are just issue tracking tools with various features for grouping items (issues, epics, stories, bugs) into sprints, releases, and then assigning them to team members. Every team member should have access to the tool and all work should go into the tool and get updated regularly as part of the process. Where project tracking requirements begin overshadow work, project managers or SCRUM masters should try to shield the team from anything more than about an hour / week of effort by updating details as part of recurring status meetings or offline after these meetings.

While it is definitely good practice to keep all possible details of story in the tool itself to facilitate work, often linking out to a wiki page or a document (or both) makes maintenance of stories like feature enhancements and bugs for more simple. It's also often much easier to edit and compose complex requirements in this way. The process for driving out details (technical and functional) and reconciling the impact of change is a key missing prescription in the standard SCRUM methodology (and most Agile methodologies) and doing it well means the difference between successful sprints and failed ones. If the team does not achieve the intent of a story in the customer's mind arguing about the content of a story is useless. A story is only truly successful if the client or customer likes what he / she sees and is willing to accept it (at least temporarily) and should be treated as such. Establishing standard templates for capturing and maintaining requirements incrementally as they evolve and integrating these documents with the meeting strategy (meetings should result in documents getting approved or even updated) and tools allows you to always have "just the right amount" of documentation at all times. It also prevents repetition as functional requirements change and evolve (which should be expected).

Selecting the right tool, establishing a shared language, and formalizing some simple templates for integrating documents, wikis, and your tracking tool can radically improve execution and communication on an agile project. Mixed with the periodic execution reviews and testing, these agile documents lower the work of maintaining details in the tool and make details more easily accessible and manageable over time. In the end, three or four document template, a clear wiki page strategy and some standards go a long way toward rounding out the agile process and making your team excellent - no matter where they live and work.