Release Cadence
Large, distributed teams rarely collaborate on a single stream of work. Complex programs are typically decomposed into multiple parallel projects (see Figure 1).  While it helps make rapid progress, decomposition isn't always consistent and often leads to significant inefficiencies and reconciliation {sidebar id=1} problems.

The solution is to have teams deliver in rhythm of consistent cycles:

• At the outer-most level is a program or the entire delivery; this is decomposed into a collection of loosely coupled parallel projects.
• A project is a collection of functionality that is delivered in a series of time-boxes called releases; a project will span multiple releases.
• Each release is time-boxed and will typically last between 6 to 10 weeks.  A release is decomposed into several iterations.
• An iteration is the smallest time-box, fixed at 1 or 2 weeks.  During an iteration, each team analyzes, develops and tests a set of functionality.

Code delivered at the conclusion of each time-box at each level must be "complete," meaning it can be built locally (that is, a build supporting the work just for that team), passes local QA, can be built in the "master build" spanning all teams, and passes all unit and integration tests.

Figure 1: Release Cycle

Crucially, teams deliver to a fixed schedule, only allowing variance in the volume of functionality delivered.  Teams may not vary the time box to get an ‘extra' feature in a release.  Features, even those planned for a particular release, may slip to a subsequent release but completed code is always released at the planned times.  As a result, delay is minimized whilst integrity is maximized:

• Features postponed will typically be top priority for the next release window (the next 6 to 10 weeks out.)
• Feature pile-on is implicitly resisted.
• Production-quality code is ready at frequent, scheduled release dates available for more rigorous regression testing and, ultimately, production.

Projects converge only if there is disciplined execution to best practices: holistic integrity is ensured by disciplined execution to development best practices, such as test driven design and continuous integration. It is especially important that teams continuously reconcile their work to a "global integration" so that the master build across all teams always maintains integrity.  This allows distributed, parallel teams to work in confidence rather than hope for the best during an opaque "integration phase." 

Cadence eliminates the wasted effort and delays introduced by the scramble and pile-on that typically occur when preparing a production release, due to:

• Tangible intermediate deliverables subjected to production-level demands for quality within a release cycle, providing integrity in what is built.
• Transparency of work as status is reported at the end of each iteration, release, project and program (more about this in the next section); and
• A reduction of "hidden tasks" which are not tracked (such as build and incremental QA) and therefore not allocated time budgets; this reduces waste, uncertainty and risk.

Transparency
To be transparent, distributed operations require fact-based progress reporting, not someone's opinion or "feeling" of status. Fact-based transparency scales from a foundation of granular requirements that are completely encapsulated.  A statement of work, called a "story," is a description of functionality that is testable and has business value.  It expresses requirements in a simple and portable statement that a team can deliver from analysis through QA, and it can be estimated, measured and tracked.

A common, consistent and complete statement of work provides a framework for teams to communicate what they have done, are doing and have yet to do within an iteration, project or program.  Tracking progress is not burdensome as people need only indicate status of a story when there is action (e.g., it is taken, completed, suspended, etc.)  As a result, stories allow precise reporting of exactly what people are doing.  They also scale to provide uniform, unambiguous status and forecasting across the program.

Activity, then, is effortlessly monitored.  Status is summarized and rolled-up to project, program and even departmental levels in an overall "delivery dashboard."  Slippage and impact is immediately exposed to all stakeholders, enabling rapid reprioritization and reallocation of effort across an interconnected set of functionality.

Communications
If they're to be effective, cadence and transparency require a consistent communication structure.  Delivery cadence and transparency are reinforced by a set of focused, recurring events that engender communications and trust in distributed teams.

The core event within each project, the daily "stand-up," is where all team members discuss what they've done, what they're working on, and what blockers they face.  Unlike authoritarian "status meetings" that present a plan, the stand-up brings into focus what's actually happening.  Co-located or distributed teams can signal to all participants immediately where a hotspot is developing, or where there is redundant or useless work about to take place.  This meeting scales up to support a distributed program: project managers, architects and development leads can connect in regular stand-ups across all projects of a program to discuss what their respective teams are doing. 

Stand-ups are supplemented by planning and retrospective meetings executed with the start/stop of each iteration, release, project and program.  At planning meetings, stories are allocated, forecasted and selected for execution, whereas retrospectives are used to call out lessons learned (what worked, what didn't, and what needs to change) from the time-box just concluded. 

For distributed teams, communications do not come for free: role duplication, exchange of people and infrastructure such as videoconferencing and virtual desktops are all important to overcome communication barriers.  These are well documented elsewhere, but it is important to note that these are most effective when reinforced by focused, consistent structures.

These communication events occur with the rhythm of delivery defined by the release cycle. They are especially important for distributed teams to achieve shared vision and minimize wasted effort.

Achieving This State
This is not just a plan for greenfield development: existing teams can adopt these practices.  Start by setting the longest time-box, for example, require a release every 90 days.  Jumpstart transparency by collecting existing requirements into expressions of a common unit of work and define new requirements as proper stories.  Iterative delivery cadence can be introduced with lightweight progress reporting of stories delivered on a schedule.  Clearly, this transformation won't happen in zero time: there may be extant technical challenges (e.g., decoupling and componentization) and there must be relentless adherence to best practices.  However, even the most ad-hoc development groups can increase their consistency through disciplined execution.

Conclusion
An agile approach to managing distributed development provides consistency and predictability over the life of development.  For IT, this creates credibility with the business, reduces risk, and contains slippage and delay.  It also builds functional and technical integrity into the software produced, reduces waste and maximizes the efforts of the team toward producing the software.  And, it brings business and IT into alignment by giving a common language with which to communicate the state of delivery - good or bad - to all stakeholders.  When fully implemented, using an agile approach to managing distributed development provides operational flexibility in even the most complex delivery programs.

Comments (0)

Write comment

Show/hide comment form