Anatomy of a Release Plan, from the newly published book, Beyond Agile.

[From Chapter Nine, Beyond Agile, (beyondagilethebook.com). A book by Jesse Tayler with Alex Cone —a must read for anyone with a stake or interest in the outcome of software production.]

Software is planning, and with Beyond Agile we attempt to reveal the true value and nature of expert planning.

If you have a release, you have a plan. 

Communication regarding this plan can be condensed into its most rudimentary elements. These elements, if made visible and accountable in any form or fashion, can help the project manager optimize individual, team and inter-departmental efficiencies.

Communication is paramount. It is communication that gives others a framework to engage effectively. For instance, visibility of schedule makes it clear to see that requirements are best provided early in the Cycle, during design. Those needing to review a near-final release can see when along the way this will happen. Each individual engineer, tester or stakeholder can distinguish their own part within the process, and plan accordingly.

The Seven Rudimentary Elements of Communication

Beyond Agile highlights the essential activities performed by the most effective teams. These groups all share certain practices of communication and documentation; a continuous process of providing visibility and dissemination. This communication is the very essence of professional software methodology.

Beyond Agile has condensed essential communication to seven rudimentary elements. These seven elements are common to any software construction playbook.

These seven elements are as follows:

1. a central authority to govern approach, a style guide
2. each Cycle has a release plan, give it a memorable name
3. balance and serialize —a documented strategy promoting schedule ownership and visibility
4. release notes discuss what changed from the original plan
5. candidate release docket lists when and why release candidates were rejected
6. post-mortem outlines what went well, and what can be improved
7. a diary of dated log entries or lineage-report contains historic events of merit

Let us review each of these elements in greater detail.

Style guide: even the smallest project group needs to agree upon, and set forth a style guide to establish a shared project-level uniformity. This is almost like a mission statement for coding practice. This guide is always work in progress and typically begins the very first time there are multiple disciplines and engineers working on the same project.

Release plan: is predicated on a memorable and suggestive title or release name, along with a simplified set of instructions describing the release. A well-balanced release has only one or two major Architectural features or fixes, plus a reasonable amount of logical flaws for repair, and of course some amount of time to accomplish it. A release plan lists major visible features for those outside the group and provides some “rules of engagement” directing team members to work within specified bounds (typically limits on technologies and approaches or guidance regarding architecture and design).

Balance and serialize: is a process that serves as a framework and guide to help estimate and visualize time needed for each phase in the software development Cycle. This is a collaborative effort within the team and requires input, advice and shared consent among members. Balance and serialize helps visualize the structure of each Cycle and get everyone to better understand their place within the goals of that schedule. This can take the formality of a Gantt chart or a casual whiteboard drawing of lines and dates. The purpose is to ‘’see’’ the shared agreement of values, and the estimates uniting all efforts.

Release notes: created and catalogued for each release. This document outlines major feature elements and provides a detailed list of items differing from their stated or implied intent. These technical details help communicate and catalog how projections in the plan were later realized.

Release docket: when the time comes to produce a final production release, a release candidate makes its way through various stakeholders of the organization who typically offer a “go, no go” countdown-style response. We record the dates and reasons for any rejections in a release docket. This docket provides invaluable historic data that inform future cycles, and it provides critical visibility. It shows patterns of rejection along with any flaws in design or process that are responsible for those patterns.

Post-mortem: after a release has hit the shelves and is in real world use, it becomes time to regroup and consider what could have been done better. We refer to this as a post-mortem of each release or Cycle, and it is a major chapter of the playbook of continuous improvement for software construction.

Lineage-report: logging significant internal and external events in a software diary or lineage-report can give an overview of your entire software lifecycle. This reference includes external updates such as scheduled operating system updates. This document increases in value the longer it exists, and the more visibly it is maintained.

For each of these seven elements of communication, it is the visibility and authenticity that make them invaluable. Visibility is achieved by regularly updating a standard set of documents people can see and use. Authenticity is achieved with the shared ownership and input from each team and each individual, and by precisely informing stakeholders at each step along the process. 

Software is a plan, make it visible.—

—

Read more about the new trend in software construction methods that is taking over efforts large and small. Beyond Agile is the book that sums up this new spirit and ushers in the awakening of this new era. Take advantage of expert knowledge and make your software teams happier and more productive than you ever imagined was possible.

beyondagilethebook.com