Making Global Teams Agile (part 3): Great Agile Documentation

As a follow up to the continuing conversation about making globally distributed teams work in agile fashion, we focus this article on what it really takes to make requirements documentation work. The most important step in getting this right is to recognize "this isn't your father's requirements document anymore" (although that might be his car commercial tag line) and that "requirements" are more than just a few words in a story. What all great agile requirements documents have in common is that they are short, to the point, focus on the visual, incorporate functional and technical guidance in one place, and they are expected to be iterative.

In part 2 we discussed using agile tracking tools like JIRA, VersionOne, and Pivotal Tracker along with a wiki to capture requirements. Wikis are great for requirements from one perspective because they are easy to author, quick to edit, and track versions over time (which is invaluable) in understanding change. Every day that goes by on an agile project, people have questions about how and what to develop to meet the needs of the customer. Capturing those answers as you go and making sure that where the customer and technical leads expect consistency, there is clear guidance the team can always get to means the difference between success and failure. Surprisingly little effort (as a start) just putting together a simple wiki page for each area of your project and keeping it up to date incrementally makes an enormous difference and saves tons of time and mistakes.

While Wikis do a great job of tracking change over time and they are more consolidated (often) than your stories (sometimes you'll see 20 or more stories for one functional area of your project) they have 2 major shortcomings: they still spread work out in many places and they are not disconnected. Sometimes, it is just plain easier to use a real document or tool to share details. Case tools like VP-UML and Poseidon (I site these for their platform independence) are great for sharing technical intent across a distributed team and the ability to share documents like database diagrams, class diagrams, and sequence diagrams (these are some of the most useful visualizations for communicating technical direction) can save hours or even days of re-work. Throwing implementation guidelines, a handful of visualizations, and requirements together for the shared standards and a couple functional areas of the project into a single, portable word document (as an example) can also be extremely helpful for allowing developers to work disconnected and stay on target. Whichever document types your team uses, they should be treated just like code and should be checked in and shared via your source code repository (probably GIT or SVN these days) or at the very least uploaded to the wiki in an appropriate location. Again, these documents are works in progress and their content may get moved onto or pulled from the wiki as appropriate to the needs of the team.

Focusing on the visual in these documents is another important way you can set the team up to succeed. Basic wire-frames or designs of interfaces are the first place to start. From there, descriptions of data in the form of an annotated ERD diagram and a basic class and package diagram ensure that the team understands what is expected for delivery, what information is involved, and how the technical lead and team agree the basic structure should be implemented. For projects using scripting languages like Ruby and PHP, you can still use component diagrams to communicate this. What is great to realize is that a project with 100 functional features probably only requires 10 - 12 of these pictures in place for the team to infer how everything should work, and you can build these in just a couple of hours / week and save hours and hours of miscues and confusion in every sprint. If you're skeptical, try doing a search through your inbox for one of your story names and see how many e-mails got traded over the course of a single sprint and then try spending the time on docs and repeat the exercise.

Back in the days of Waterfall and the Rational Unified Process (RUP) the software architecture community pushed a very formal methodology for doing analysis and design that often led (and still does sometimes today) to 2 or 3 separate and specific documents for a project. These documents became rigid and required layers of change management to alter and a repeat of the entire waterfall process. Agile documents still benefit from structure, but it is far better to merge scope, functional requirements, and technical guidance into one iterative document (or at least one per area). The skills of a great analyst, architect, development lead are still incredibly valuable and applicable to agile or SCRUM projects, but now they work as a team to produce the exact amount of guidance needed at any given time. The easier this information is to access and have at the developer's fingertips, the better, and the clearer the authoritative source of the latest ideas are, the less time the team wastes in confusion and re-work. It shouldn't be un-common to see a 4 page document that shows 2 use cases, some functional requirements, a wireframe, a class diagram, and a database diagram mixed together. You'll find lots of this content and concepts are re-usable from story to story and function to function and if you commit to iterating you produce great guidance that keeps the team moving as one to get the job done with minimal week to week effort.

As we said, this is not your father's documentation but a few hours / week spent doing this out ahead of the project team can double your team's velocity and effectiveness easily. The trick is right-sizing and simplifying the documentation to your team's needs, establishing templates and patterns that make producing and reading these documents easy, keeping the documents in some kind of version management system and easily accessible to everyone (online and offline), and accepting the iterative nature of the documents and the process. The goals are to save time and create shared vision to improve execution. In the end, team synergy and communication accounts for more than half of the team's effectiveness and a great documentation process can make it look easy.

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.

Making Global Teams Agile: Meeting Strategies

For the past 2 years, we've been working hard to get to a simple, standard process for making Agile and SCRUM work in almost any team dynamic. Specifically, our teams focus on making resources that live and work all over the globe behave and feel like one highly effective team without undue overhead.

The keys to success in building an effective team, in our experience, are picking an agile methodology (in this case SCRUM) that allows for frequent communication in short, structured ways (Meetings) and selecting tools (Tools) and templates (Documentation) that ensure all team members and stakeholders communicate consistently and effectively with minimal wasted time and effort. A real commitment to stakeholder / client communication and interpretation and ensuring a trusted presence (real or virtual) with the customer is often crucial as well. In this article we focus on what it takes to really establish a great meeting strategy.

A great meeting strategy is the first place to start in getting a project off the ground. Standard SCRUM calls for several types of standard meetings, including: Sprint Planning, Backlog Grooming, Sprint Demonstrations, and Sprint Retrospectives. These regular meetings allow the team to understand what the customer wants to see next, demonstrate progress, refine requirements and requests, and improve the general process. Mixed with the daily SCRUM (the daily status meeting that gets the team all talking and working together constantly), just establishing these meetings on a consistent schedule and setting up ground rules and agendas is possibly the most important property of an effective, reliable project team.

Of course simply establishing some meetings and agendas is not enough to make a project or even a meeting strategy successful. Every meeting has to have a clear purpose, ground rules, and a known agenda that remains consistent over time. You also have to place meetings at the right time of day (beginning and end of day meetings work a lot better than mid-day meetings because they interrupt less work) and keep them as short and effective as possible with manageable goals. A Backlog grooming meeting should happen once every sprint (we find 2 week sprints are the most effective) and should have the goal of refining and prioritizing just enough requirements to cover the next 2 sprints in about 60 - 90 minutes. Daily SCRUM meetings should last less than 30 minutes and should allow every team member to speak quickly just to identify progress on specific work and raise (but not discuss in detail) any concerns, problems, or open questions. The last few minutes of every meeting must be reserved to discuss follow-up actions and next steps to set expectations for the next meeting or for progressing work. The goal of any meeting strategy should be to reserve as much time for the team to do what they need to complete work and demonstrate it every sprint while ensuring plenty of opportunity to reserve time for frequent course correction from the customer, client, and project leaders between sprints, milestones, and releases.

Finally, establishing regular channels of communication within the project team for standard activities like testing, design reviews, code reviews, and commitments is just as important as the standard SCRUM meetings themselves. Sprints (particularly short ones) move too fast to assume critical activities will happen without this planning. If you are relying on a development lead or architect to ensure quality (we recommend this highly if you care about maintaining feature velocity and controlling defects) he or she should have 2 - 3 scheduled, structured times to intervene and review work every sprint and teams should get used to presenting their work in this way. Once again perfection is not the goal, but intervention is not perfection - just exceedingly better than chaos. Likewise, testing should commence and become the focus of each sprint at a standard, scheduled time and features should be frozen, and some time for test review should be reserved as well.

In the end an effective meeting strategy dictates how much effective working time left to a team to really develop features and functions and establishes the culture and communication of the team. Done correctly, it allows a team to learn to work together and respect each others contributions and ensures that everyone pulls together to get the job done. Balancing communication with efficiency is always a challenge, but if you can reserve at least 30 hours of a 40 hour week (ideally more) for actually getting work done, the project will almost certainly be on the best possible track. From here, making the project team great is more about other things that we'll talk about in a later article.