Driving an Agile project team

Most of you have a picture of how Agile methodology works. This article will shed light on how Agile teams work, and what roles make up an Agile team.

Agile projects are driven by quality, and quality means different things to different people. At a recent project management conference, I heard a great quote: “After a project is finished, the money and time has gone, all that’s left is the quality.” This succinctly conveys why we need to make sure we have a good understanding of what quality is required of the product.

Rather than waiting until the ‘customer testing’ phase of a project, we agree with the customer at the very start of the project how quality is defined and what quality is required.

Throughout the project, we ensure we meet the required level of quality. Because we are measuring progress throughout the duration of developing a product that has business value, we include the quality measures as part of the completion criteria, or definition of done. This gives us the opportunity to continuously review the impact of the agreed quality on the speed and cost of development, and the information we need to discuss any trade-offs that may be required.

As a result of this emphasis on quality on Agile projects, many techniques and supporting tools have been developed to ensure quality is being built in from the start, for example, continuous integration, automated testing, and Test Driven Development.

Tools in Agile projects

Rather than producing detailed requirement documents, Agile teams often make use of User Stories, which are pointers for a conversation. These are deliberately small pieces of work, ideally no more than a few days work in duration, so the requirement doesn’t need to be accompanied by detailed documentation. The team needs to collaborate to gain a shared understanding of the requirement.

This doesn’t necessarily mean that there will be no documentation of what has been discussed. If there is value in the documentation being produced, then the work to produce it will be prioritised appropriately. But if there is little value seen in the documentation, then producing it will be seen as a waste and it’s likely to either get ‘prioritised’ to the bottom of the work pile, or ditched altogether.

Often, documenting how the product actually works through the creation of automated test scripts or user guides is normally seen as having greater value than documenting the requirements.

The most common tools you will see on an Agile project are index cards, sticky notes and whiteboards. Face-to-face conversation is the most effective form of collaboration, and the use of these tools promotes this form of conversation. Posting the results of these conversations in the team area for all to see creates a high level of visibility for the project. These are commonly referred to as Story Walls and Information Radiators or Big Visible Charts (BVCs).

There are sometimes challenges in managing this information, such as when the teams are geographically distributed, or the governance process requires an electronic version of the information. While the preference is to have co-located teams and governance processes that makes use of these BVCs—rather than produce periodic project reports etc—this isn’t always practical or immediately achievable. As a result, there are various electronic tools available to support remote teams and stakeholders, and these can also be used to generate the information required by broader stakeholders such as the executive or the steering committee.

The roles on an Agile team

Product owner

A pivotal role in Agile projects is that of the product owner, who alone is responsible for clarifying requirements and setting priorities for the project team. The product owner will often make use of a team of experts to advise him/her in this role.

The product owner is normally a representative from the business, appointed by the project sponsor. They should have a thorough understanding of the business problem that the project is to solve. This person needs to be available to the project team on a daily basis, ideally co-located with the team.

Team members

The team should have all of the skills required to complete the work they have committed to, as represented by the User Stories. Team members should be available full-time to the project team, and co-located. The ability of the team to deliver business value is likely to be impacted if any of these things are absent.