The Mushroom Method:
A Practical, Evolutionary Software Development Process for Small Companies
Contents
Overview
This document describes an agile software development process that I, with help from many of my colleagues, developed over the past several years at a number of different companies. The process has a lot in common with other agile methods, such as eXtreme Programming and Scrum, but it focusses on practical methods that are best suited to small to medium sized groups. Over the years, this method has become known, for better or worse, as the Mushroom Method. The name stems from the shape of the diagram, seen later in this document, describing the concentric release cycles that are at the heart of the method.
Principles Behind the Method
Though the Mushroom Method was developed and honed independently from other agile development methods, the principles that drive its definition and use are basically the same as those espoused by the agile development community. Namely,
-
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
-
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
-
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
-
Business people and developers must work
together daily throughout the project.
-
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
-
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
-
Working software is the primary measure of progress.
-
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
-
Continuous attention to technical excellence
and good design enhances agility.
-
Simplicity--the art of maximizing the amount
of work not done--is essential.
-
The best architectures, requirements, and designs
emerge from self-organizing teams.
-
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Participating Groups - PDQ
Product development activities are carried out by an organization consisting
of three separate but coordinated groups. The Product,
Development , and Quality groups are responsible, respectively, for
defining product releases, designing and developing the software products, and testing and evaluating the quality of the release.
The Product Group consists of representatives from sales,
marketing and technical support, including a Product Manager, and
is responsible for defining the feature sets of each of the product releases
and setting customer expectations regarding features and release dates.
Members of the product team leverage their direct customer contact to help
write requirements documents outlining desired product features and priorities.
Members of this group also participate in weekly bug triage sessions where
reported software defects are tracked, prioritized, and allocated to future
releases. The product group makes the final determination of whether a software build is ready to be released.
The Development Group is responsible for architecting,
designing, and implementing the company's software products. Each
major product release is assigned a Release Manager from this group.
Starting with the requirements documents and working with other developers,
the release manager produces a high level design for the software release,
decomposes the work into tasks and assigns these tasks to other developers.
The release manager also participates in detail design reviews and bug
triage.
The Quality Group subsumes what is typically called
software quality assurance, but its expanded role in this development
process includes evaluating and assessing product usability, code quality,
buildability, performance, functionality, and adherence to schedule. Members
of this group, including a Quality Lead, participate
in design reviews and bug triage and have the final determination of whether
a software build meets its quality goals.
Product Development Cycle
The Mushroom Method is a practical, incremental approach to software development
based loosely on the evolutionary delivery ideas of Dr.
Tom Gilb. Our process encourages us to "deliver early and often,"
thus helping to ensure that we are never very far away from a buildable,
stable system. The product release cycle is actually three concentric
cycles as shown below.
After a product release is defined and architected at a high level, we immediately
begin to execute a sequence of very frequent (every 7-10 days) internal
releases delivering more and more of the desired functionality with each
alpha release. Every 4-6 weeks, the aggregate functionality of the
alpha releases becomes significant enough to warrant a public beta release
including updated docs and a higher level of stability than the internal
releases. Finally, when all desired features have been built and
proven both by internal users and free beta users, and when certain other
quality and completeness criteria have been met, we do a commercial release
(which we call a gamma release here) at which time sales can begin collecting
revenue for the new version of the product.
This evolutionary delivery strategy allows us to do almost continuous
integration testing. In addition, detailed design can be done in
an incremental fashion allowing simultaneous design, implementation, and
testing of different features. This strategy reduces the risks involved
with more traditional models where developers tend to wander and lose focus
during lengthy design and coding phases and the 'end game' of documentation,
packaging, and roll out is played only once, usually under extreme pressure.
The alpha, beta, and gamma release types allow us to progress toward a feature-complete, high-quality production release in a process similar to the annealing process in metallurgy. Each beta and gamma release is the result of multiple, sometimes dozens, of "heating and cooling" cycles where the code is gradually hardened. As in metallurgy, the result is tough, resilient, and relatively free of defects and brittleness. This release annealing aspect is generally not found in other iterative and evolutionary processes like eXtreme Programming (XP) and Scrum.
Release Cycle Entry Conditions
Every release tells a story. Before work can begin designing
and building a product release, several questions must be answered by the
Product and Development Groups with review and input from Quality. The
project artifacts listed in the yellow arrow in the above diagram form
the basis for every commercial product release. These artifacts are
produced by the following tasks.
Task: Determine and Announce Release Charter
Owner: Product Manager
Groups: Product
Result: Charter Document and/or Product Plan
Task: Gather and Prioritize Requirements
Owner: Product Manager
Groups: Product, reviewed by Development and Quality
Result: Requirements Document
Task: Develop System Architecture and HL Design
Owner: Release Manager
Groups: Development, reviewed by Product and Quality
Result: Architecture Document and/or Design Document
Task: Prioritize and Assign Tasks
Owner: Release Manager
Groups: Development, reviewed by Product and Quality
Results: Prioritized Task List
Alpha Cycle
Once a product has been defined, we carve out a small subset of the required functionality that can be built and released quickly to very friendly internal users (usually the Quality group). Since alpha releases are strictly controlled and never released externally (if we're lucky that is), it is reasonable to have less stringent quality goals than with externally visible releases. All employees have access to the Bugbase and are encouraged to report any anomalies or defects discovered during alpha testing.
The most important criteria for alpha releases are that they exhibit
a noticeable increment in functionality over the previous release and that
they occur frequently. Ideally, alpha releases occur every 7-10 days
on average. The first alpha release of a new product development cycle
may take slightly longer than usual while sufficient "critical mass" functionality
is constructed to make a viable release. For example, the first alpha
release might take two months to complete. Just before a public beta
release, the alpha cycle may accelerate so that new features and (more
often) bug fixes can be tested internally before they are publicly released.
In this part of the beta cycle, it is not uncommon for alpha releases to
occur every 1-3 days.
There are a number of ongoing tasks that are carried out throughout
the alpha cycle. This work is typically at the feature or subsystem
level.
Task: Detailed Design
Owner: Developer
Groups: Development
Result: Engineering Note
Task: Coding
Owner: Developer
Groups: Development
Result: Source Code checked into the source repository
Task: Integration
Owner: Developer
Groups: Development
Result: Working development build
Task: Unit Test
Owner: Developer
Groups: Development
Result: Unit tests checked into the source repository
Task: Usability Analysis
Owner: Quality Lead
Groups: Quality, with Product and Development
Result: Usability Test Plan and Observations
Task: Performance Analysis
Owner: Quality Lead
Groups: Quality, with Development
Result: Performance Models and Reports
In order to determine whether a product build can become an alpha release,
a number of tasks must be completed. These exit conditions are called
alpha
gates.
Alpha Gates
Task: Update Engineering Change Document
Owner: Release Manager
Groups: Development
Result: Engineering Change Document
Task: Perform Smoke Test
Owner: Quality Lead
Groups: Quality
Result: Pass/Fail
Task: Perform Regression Test
Owner: Quality Lead
Groups: Quality
Result: Pass/Fail and Bug Reports
Task: Put Installer on Intranet
Owner: Quality Lead
Groups: Quality
Result: Updated Intranet Builds Page
Task: Email Announcement
Owner: Quality Lead
Groups: Quality
Result: Email to staff announcing alpha availability
Task: Source Code Label
Owner: Quality Lead
Groups: Quality
Result: Labeled Source Code Configuration
Beta Cycle
Although frequent alpha releases and formal testing by the Quality Group
are helpful in finding product defects, there are certain kinds of platform
and compatibility bugs that will commonly slip through such procedures.
In order to find and correct these problems, it is necessary to release
early versions of the product to external users so that many different
platform configurations and many different software and hardware combinations
can be tested in real user environments. This is called a Beta
Release.
Note that beta releases, like alpha releases, offer incremental functionality
to users. We do not wait until all the features planned for a product are
implemented before doing reality checks with our users. Ideally,
beta releases occur every 4-6 weeks, with more rapid beta cycles occurring
toward the end of each gamma cycle. Although feature requests and
bug reports are collected from external beta users, the primary purpose
of the beta release is platform and compatibility testing on a large user
population (thousands to tens of thousands of users). Since beta
releases are seen and used outside the company, the quality and stability
expectations are higher than for alpha releases, but not as high as for
gamma releases.
In order to determine whether a given alpha release can become a public
beta release, a number of tasks must be completed. These exit conditions
are called beta gates.
Beta Gates
Task: Resolve/Verify All Known Priority 1 Bugs
Owner: Release Manager
Groups: Development, with Quality and Product
Result: Resolved Bugs in Bugbase
Task: Update Beta Release Notes (from Engineering Change Doc)
Owner: Product Manager
Groups: Product, with input from Development
Result: Beta Release Notes
Task: Update Beta Documentation
Owner: Technical Writer
Groups: Product, review by Development and Quality
Result: User's Guide, Developer's Guide, etc.
Task: Update Public Web Site
Owner: Web Master
Groups: Product
Result: Notice on public site, download page updated
Task: Prepare Beta License
Owner: Product Manager
Groups: Product, with help from legal
Result: Beta License Agreement
Task: Update Test Plan
Owner: Quality Lead
Groups: Quality
Result: Test Plan covering beta features
Gamma Cycle
After all planned and necessary functionality has been built, tested, documented
and proven by numerous alpha and beta releases, an FCS or gamma release
can occur. These are commercial product releases for which revenue
can be collected and, therefore, have the highest of all quality expectations.
Ideally, major gamma releases occur every 3-6 months with maintenance (point)
releases in between where necessary.
In order to determine whether a given beta release can become a commercial
gamma release, a number of tasks must be completed. These exit conditions
are called gamma gates.
Gamma Gates
Task: Resolve/Verify All Known Priority 1 & 2 Bugs
Owner: Release Manager
Groups: Development, with Quality and Product
Result: Resolved Bugs in Bugbase
Task: Update Release Notes
Owner: Product Manager
Groups: Product, with input from Development
Result: Release Notes
Task: Update Product Documentation
Owner: Technical Writer
Groups: Product, review by Development and Quality
Result: User's Guide, Developer's Guide, etc.
Task: Update Public Web Site
Owner: Product Manager
Groups: Product
Result: Notice on public site, download page updated
Task: Prepare Product License
Owner: Product Manager
Groups: Product, with help from legal
Result: License Agreement
Task: Press Release
Owner: Product Manager
Groups: Product
Result: Press Release
Task: Reviewer's Guide
Owner: Product Manager
Groups: Product
Result: Reviewer's Kit
Task: Promotional Material
Owner: Product Manager
Groups: Product
Result: Ads, Marketing material
Task: Source Code Branch
Owner: Release Manager
Groups: Development
Result: Maintenance Copy of Product Source Database
Glossary of Terms
-
Alpha Release
-
An internal release used by employees for testing interim versions of the
products. An internal release is a full installer for all platforms
but usually does not include up-to-date documentation. An alpha release
need not be feature complete.
-
Quality Group
-
The PDQ group responsible for evaluating and assessing product usability,
code quality, buildability, performance, functionality, and adherence to
schedule. More commonly called SQA (Software Quality Assurance).
-
Beta Release
-
A public release distributed via the WWW and used for platform and compatibility
testing across a wide range of installations. Beta releases are just
like commercial Gamma releases including up-to-date documentation, except
they may have known bugs and the included license agreement is different.
A beta release need not be feature complete.
-
Bug Base
-
The web-based defect tracking system and/or the database containing all
reported bugs, past and present, against any product.
-
Bug Triage
-
Regular meetings to review and prioritize bug reports and assign developers
to fix them. Attended by members of all three PDQ groups, usually including
the Product Mgr., Quality Mgr., and Release Mgr. More commonly called
a CCB (Change Control Board) meeting.
-
Build
-
The process of compiling all the source files belonging to a product and
producing the necessary installer artifacts. Builds are numbered
sequentially and occur, on average, once a day (less often at the beginning
of a release cycle, more often toward the end). The Quality group
is responsible for carrying out the builds, although due to the rapid build
frequency, this process is almost completely automated.
-
Charter
-
A brief statement from the Product Group that identifies the "story" of
each new release. This is generally a statement of the business purpose
of the release together with, perhaps, a few of the major features that
will comprise the release.
-
Code Branch
-
A complete copy of the source code repository made immediately after each
gamma release. This branch is used to fix serious bugs discovered
after the release and to produce point releases if necessary.
-
Code Label
-
A labeled configuration in the source code repository that allows reconstruction
of all source files used to produce a given build.
-
Development Group
-
The PDQ group responsible for architecting, designing, and implementing
the company's software products.
-
Engineering Change Document
-
A running list of changes, maintained by the development group, that is
updated before each alpha release. Used by internal testers to determine
what is different in this release and by documentation to guide doc changes.
Also used before a beta release to compile release notes and the readme.
-
Engineering Note
-
A mini-design document, usually concerning one feature or a closely related
set of features, written by the developer responsible for implementing
the feature(s). Engineering notes are written before coding begins
and placed on the intranet where other developers read and critique them
during peer reviews.
-
First Customer Ship or FCS
-
Release of a product for commercial use (sale). Same as gamma release.
-
Gamma Release
-
Release of a product for commercial use (sale). Same as FCS.
-
Gate Criteria
-
Conditions that must be met before a build can be released. Each
cycle, alpha, beta, and gamma, has its own set of gate criteria.
-
Intranet
-
The internal web site used to store all project artifacts, both current
and historical. The intranet site is configuration managed in the
same way as the source code. Access to the intranet is password protected.
In general, only employees, contractors, and advisors of the company have
access to the intranet site.
-
License Agreement
-
A legal document, written and approved by corporate council, that is included
with all public product releases, both beta and gamma. The beta license
includes language intended to protect the company from litigation arising
from defects in the beta code and to limit the impact of unexpected defects.
-
Process Pow-Wow
-
Off site meeting involving all three PDQ groups (and a baseball bat) to
review the software process, identify areas that need improvement, and
suggest alternatives.
-
Product Group
-
The PDQ group that consists of representatives from sales, marketing and
technical support and is responsible for defining the feature sets of each
of the product releases and setting customer expectations regarding future
features and release dates.
-
Product Manager
-
An individual within the Product Group who is responsible for a particular
product or group of products. The product manager owns the requirements
process, attends bug triage meetings, and is responsible for coordinating
release notes and other product roll out activities.
-
Readme
-
A copy of the Release Notes for a product that is included with the product
installer package.
-
Regression Test
-
A collection of test cases for a system including detailed instructions
for how to carry out each test and the expected results. The regression
test for a product is updated incrementally with each alpha release and
must be completely updated to include new and removed features and test
cases before each public beta release. More commonly called a Product
Test Plan.
-
Release Candidate Build
-
A build that is intended to become either an alpha, a beta, or a gamma
release if it passes the necessary gates for that cycle.
-
Release Manager
-
A senior engineer from the Development Group who is responsible for a product
release cycle. Each commercial release of each product is assigned
a release manager who is then responsible for architecting and producing
the high level designs for the release as well as the task list and task
assignments. The release manager also participates in bug triage
meetings and design reviews.
-
Release Notes
-
A document that is compiled from raw Engineering Notes by the product manager.
It contains late breaking and platform specific information about each
public (beta and gamma) release. It may also contain a list of known
issues or defects in the released product (especially for beta releases).
Release notes are accessible via the WWW and are also included with the
product installers where they are generally known as readme files.
-
Source Code Repository
-
This is the source code control and
configuration management tool used by the company. All product artifacts,
including source code, build and install scripts, project documents, etc.
are maintained in a source code repository. It is possible to reconstruct
all builds (including all releases) from the source code repository at any time.
-
Smoke Test
-
A fast and simple test of a product build that is intended to quickly determine
whether it succeeded in producing viable, operational code. A smoke
test is used, in lieu of a full system test, as an alpha gate to determine
whether a build is suitable for internal use. It may also be used
to re-verify a public release candidate after some trivial change such
as a readme edit.
-
Stillborn Build
-
A build that does not pass the Smoke Test and is therefore unsuitable even
for internal testing. This is most often the result of a defect in
the build scripts themselves.
-
Task List
-
A prioritized list of detailed tasks and task assignments for a release.
More commonly called a WBS (Work Breakdown Structure).
Created by: dutton
on: November, 1998
Last modified by: dutton on: February, 2007
Copyright © 1998-2007
by Jim Dutton
All Rights Reserved