Agile Methods Quick Reference and Selection Guide

When I teach classes or consult, I often am asked about alternatives to Scrum.  This final section provides some guidelines on choosing an Agile method, including factors such as team size, project duration, organizational culture and environment.  First though, a summary of four well-known Agile methods: Scrum, OpenAgile, Extreme Programming and Kanban.

Agile Method: Scrum

Scrum is a tool for new product development (usually software products) in high-performance teams that uses the principles of transparency and “inspect and adapt” – empirical process control.  Scrum focuses on a relatively simple framework of roles, meetings, and artifacts as follows:

Roles:

The Scrum Team Members are individuals who work together to deliver product increments to stakeholders outside the team.  These people are required to self-organize: collectively set goals, create short-term plans, and volunteer for tasks within those plans.

The ScrumMaster is a single person on a Scrum Team who is responsible for ensuring the successful use of the Scrum process, helping the team overcome obstacles, and protecting the team.

The Product Owner is a single person on a Scrum Team who is responsible for ordering (prioritizing and sequencing) the work of the Scrum Team on a long-term basis.  The Product Owner is accountable for ensuring that the highest value product features are ordered first.

Meetings:

The Daily Scrum in which all Scrum team members briefly explain what they have completed in the previous day, what they plan to complete in the next day, and any impediments they have to completing this work.

Sprint Planning in which all Scrum team members collectively select the work for a short-term goal (usually four weeks or less) and create a detailed, task-level plan to accomplish that work.  Sprint Planning represents the start of a Sprint.

Sprint Review in which the Scrum team present their work results from the Sprint to their stakeholders in order to gain feedback on the work and adapt their plan for future Sprints.

The Retrospective in which the Scrum team inspects how they performed their work and makes decisions about adapting how they work in order to become more effective at delivering value and quality to their stakeholders.

Artifacts:

The Potentially Shippable Increment of Product Functionality that the team produces at the end of each Sprint is some set of features and functionality of the product as determined by the ordering done by the Product Owner and the goal setting done by the Scrum Team.

The Product Backlog is a list of all the work to be performed by the team put into order by the Product Owner.  Product Backlog items are usually features or functional in the product and must always be what to build rather than how to build it.

The Sprint Plan (Sprint Backlog) is a collection of tasks, activities and deliverables that the team creates and then acts upon to deliver Product Backlog items in a Sprint.  The team owns the Sprint Plan collectively and the Product Owner is dis-allowed from specifying details in this plan.

The Burndown Chart(s) are simple graphs that show the amount of work remaining (y-axis) charted over time (either for a single Sprint or for a release of the product).

Values:

Scrum asserts 5 values: focus, courage, openness, commitment, and respect.

References on Scrum:

The Scrum Guide: http://www.scrumguides.org/

The Scrum Alliance: http://www.scrumalliance.org/

Scrum.org: http://www.scrum.org/

Wikipedia on Scrum: http://en.wikipedia.org/wiki/Scrum_(development)

Agile Method: Extreme Programming

Extreme Programming is a method for rapidly building high-quality software which focuses on teamwork and software engineering practices all done at an “extreme” level of intensity in a mutually reinforcing manner.

Extreme Programming has a set of rules for each of Planning, Managing, Designing, Coding and Testing software as follows:

Planning

User Stories are created and used for release planning.  Small, frequent releases are scheduled and executed by dividing the project into iterations (usually one or two weeks in duration).  Each iteration also has its own planning session.

Managing

A co-located team working at a sustainable pace have a stand up meeting at the start of every day.  The amount of work completed each iteration is measured as project velocity and used for feedback into the planning processes.  Within the team room, people move around to work with each other and cross-train.

Designing

Designs only address existing functionality and functionality to be added in the current iteration; designing for future functionality is discouraged.  Simple solutions are preferred to complex solutions that all fall within a system metaphor.  Design sessions use CRC cards and “hard” problems are investigated with architectural spikes.  Accommodating new functionality is done with refactoring.

Coding

During coding, the customer is always available to the team.  Test-driven development is used for all production code which also must comply with standards agreed upon by the team.  As well, pair programming is used when writing production code.  Code is integrated often by a single pair at a time on a dedicated integration computer.  All code is owned collectively by every member of the team.

Testing

All code must have fine-grained unit tests and the system must pass all the unit tests in order to be released.  If a defect is found, the team immediately creates a test to demonstrate the bug before fixing it.  Both unit tests and acceptance tests are run frequently with the result being constantly visible to the team.

Values

Extreme Programming is based on five values: Simplicity, Communication, Feedback, Respect and Courage.  Using these values allows a team to change the rules of Extreme Programming to operate in harmony with the environment the team works in.

References on Extreme Programming

Extreme Programming: A Gentle Introduction: http://www.extremeprogramming.org

Wikipedia Article: http://en.wikipedia.org/wiki/Extreme_programming

“Extreme Programming Explained” – Kent Beck

Agile Method: OpenAgile

OpenAgile is an evolution of Scrum that is designed to work for teams and communities beyond just new product development.  OpenAgile has been used in areas as diverse as non-profits, sales management and mining projects, as well as many IT environments.  OpenAgile is “open source” and is maintained by a non-profit organization called The OpenAgile Center for Learning.  OpenAgile has three foundations, a process that has broad similarities to other Agile processes and rather than roles, it has “paths of service” as described below:

Foundations

All the foundations of OpenAgile are required for the proper application of the OpenAgile process.  However, these foundations do not need to be done perfectly before starting a project using OpenAgile.  Instead, the foundations and the ability to use the process develop in a reciprocal fashion over time.

Truthfulness is the first foundation of OpenAgile.  This is not just simple honesty but includes, for example, self knowledge and integrity.  The second foundation is Consultative Decision-Making which is an approach that groups of people can use to come to united decisions about what action to take next.  The third foundation is Systematic Learning which includes a process that is similar to the scientific method but adds a set of values and the allowance for guidance to come from outside the team doing work.

Process

All work is performed by people working in a Cycle (similar to Sprints or Iterations).  Each Cycle starts with an Engagement meeting in which participants reflect, learn and plan.  A list of Value Drivers that is prioritized constitutes a high-level plan for the team that is used to guide the discussions in the Engagement Meeting.  The Engagement Meeting results in a Cycle Plan which is a collection of tasks derived from Value Drivers.  On a regular basis during each Cycle, the team members have a Progress Meeting which also includes reflection, learning and planning but at a finer level of detail.

Paths of Service

In OpenAgile, there is only one formally defined role: the Team Member.  Any Team Member can, as circumstances require, take on any number of Paths of Service within the team.  These include Process Facilitation – focused on helping the team follow the OpenAgile process and apply the foundations, and Growth Facilitation – focused on helping the team deliver value and grow both their own capacity to do so as well as the actual results of the work.  Other Paths of Service include: Mentoring, Tutoring, and being a Catalyst.

The OpenAgile Center for Learning

OpenAgile is owned by The OpenAgile Center for Learning which provides open access to the entire methodology including aspects that are still under development.  These materials are licensed using a Creative Commons license that allows for non-paid duplication and use of the materials with some restrictions on modification.  (Access at http://svn.openagile.com/OpenAgileManuals)

References on OpenAgile:

The OpenAgile home page: http://www.openagile.com/

Main OpenAgile discussion group: http://groups.google.com/groups/OpenAgileChampions

Agile Method: Kanban

Kanban is the simplest of the Agile methods with only three rules, one technique and no roles.  Kanban actually is derived more from lean manufacturing than from software development and as such is more suited to repetitive activities such as maintenance or operations.

Rules

Kanban starts with what you already have.  Any process that you working with is suitable for Kanban.  Start by examining the process carefully and creating a physical, visible representation of the steps of that process and the work that is in those steps.  This is your Kanban board.  For example, if you are using Kanban to manage your portfolio of projects in an IT department then you lay out the steps those project progress through, write the name of each project on a card, and put those cards in the steps.  Keep this up-to-date as the status of the bits of work changes.

The second rule of Kanban is to limit work in progress (WIP).  You may notice that one particular step in your process has many pieces of work in it.  Watch this for a little while and then choose a limit for that step that is lower then the historical minimum number of items in this step.  For example, if you have historically no fewer than ten projects in the feasibility step, then consider setting the limit for that step at eight or seven.  Once a limit has be put in place, don’t move any new work into that step until there is “space”… which can only happen by moving a piece of work out of that step so that the number of pieces is lower than the work-in-progress limit.

The third rule of Kanban is regular experiments to improve your process.  After you have WIP limits in place, work with your team or group to come up with an improvement idea for your process.  Implement the improvement and reflect it in the Kanban board.  Consider changing the WIP limits.

Technique: Cumulative Flow Diagram

A cumulative flow diagram is used to determine if your process experiments are making improvements in your process.  It is a chart with x and y axes.  The x axis is time, usually measured in days or weeks, but it can be whatever time scale is suitable for your process.  The chart has two lines drawn on it based on the cumulative number of items that have arrived in your process and the cumulative number of items that have been completed in your process.  When you first start, the number that have arrived is equal to the number that are represented on your Kanban board and this is marked on the y axis vertically.  The number that have been completed is zero (since you started Kanban).  Every day (or week) update the cumulative numbers for both lines and eventually you will end up with a region between the two lines that represents both your cycle time (horizontal distance between the lines) and your WIP (vertical distance between the lines).  Diverging lines indicate a process that is becoming less efficient, and converging lines represent a process that is becoming more efficient.

References on Kanban:

Wikipedia article: http://en.wikipedia.org/wiki/Kanban_(development)

Choosing an Agile Method

The following are guidelines that can be used to help in the selection process.  In this section, I am only providing information for selecting between Scrum, OpenAgile, Extreme Programming and Kanban.

Problem Complexity:

Most work is done to solve problems.  The complexity of the problem is one of the most important factors in deciding on which Agile method to use.  Simple problems, such as building a widget, are well-defined and have well-defined solutions.  Simple problems are often also repetitive and have aspects which can be easily automated.  Complicated problems, such as building a house in a subdivision, are linear or structured compositions of many small problems.  Complicated problems can be repetitive, but if so, there are often variations in the repetitions making automation more difficult.  Complex problems, such as raising children or creating a new software product, require creativity and innovation, but within fairly well-defined constraints.  Solving complex problems can often be done adequately in an infinite variety of ways, but it is difficult to determine one best way.  Chaotic problems, such as those of the world economy, often seem to have slippery problem definition, difficult to determine constraints, and it is often difficult to distinguish the efficacy of a solution relative to any other.

Simple: Kanban

Complicated: Kanban, OpenAgile, Extreme Programming

Complex: Scrum, OpenAgile, Extreme Programming

Chaotic: Scrum, OpenAgile (but additional efforts to move the problem into the Complex space may be needed).

Size of Independent Work Items (Projects, Product Releases):

Independent work items really means independent problems that need to be solved.  A project is done to (hopefully) solve a problem.  A product is built to solve a problem.  A service is provided to solve a problem.  Different problems, that are independent, usually require separate projects, products or services.  Although any given team can work on multiple problems simultaneously, the Agile methods to support these teams have different fit levels for the size of the problems.  The following size categories are not meant to be exact limits, but rather guidelines with some flexibility.  For example, a Kanban team getting lots of problems in the Small category can still handle the occasional problem in the Medium category.

Small (less than 5 person-days of effort): Kanban, OpenAgile

Medium (from 5 to 125 person-days of effort): OpenAgile, Extreme Programming

Large (from 125 to 5000 person-days of effort): OpenAgile, Scrum

Extra-Large (more than 5000 person-days of effort): Scrum or OpenAgile with scaling practices and Lean applied at the enterprise level

Type of Problem:

These types of problems are more examples than fixed categories.  If you have a problem that doesn’t show up in this list, then see if your problem can be conceptually mapped to something that is in this list.

Scrum: ideal for new product development, IT projects that require software development or complex configuration

Extreme Programming: ideal for systems built on object-oriented platforms

OpenAgile: innovation in a project or operations context, general management that combines project and operational work

Kanban: maintenance, support, or operations

Contra-Indicators:

There are some situations where you definitely shouldn’t use a particular Agile method.  Don’t use these methods if any of these factors are true.

Scrum: team size < 5 people, pure operations work

Extreme Programming: technology platform cannot support automated testing at the micro level nor at the functional level

OpenAgile: team size < 3 people

Kanban: work with no repetitive process aspects

Combinations:

Most of the four methods being compared can work well together under the right circumstances.  Probably the two most important combinations are Scrum combined with Extreme Programming for new product development on object-oriented platforms and OpenAgile combined with Kanban for management with a heavy operational component.  Other combinations are possible as well:

OpenAgile can be used across the enterprise (e.g. in marketing, sales, finance etc.) with product development or IT teams using Scrum.

Kanban can be used for product/project portfolio management with Scrum/OpenAgile/Extreme Programming being used at the product/project level.

Larger organizations commonly have most teams using Scrum as the main Agile method, but with Kanban teams doing support work on legacy systems to prevent small interruptions to the Scrum teams.

Other Agile Methods

There are many dozens of Agile methods.  Many are used in specific applications or specific geographical regions (due to history).  Often there is a book or web site associated with an Agile method, but not always.  Here are a few of the other Agile methods:

• Agile Unified Process (http://en.wikipedia.org/wiki/Agile_Unified_Process) – championed primarily by Scott Ambler. Designed as an instance of the Rational Unified Process.
• Crystal Clear (http://en.wikipedia.org/wiki/Crystal_Clear_(software_development)) – championed primarily by Alistair Cockburn. Based on a great depth of methodology research.
• Dynamic Systems Development Method (http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method)
• Feature Driven Development (http://en.wikipedia.org/wiki/Feature_Driven_Development)
• Lean Software Development (http://en.wikipedia.org/wiki/Lean_software_development)

If you find this useful, please consider contributing with our
“Value for Value” model.