Rhythms as Agile Diagnostics

[article]
Summary:
A healthy agile project has several typical rhythms such as releases, iterations, stand-up meetings, builds kicked off by continuous integration, and the red-green-red test cycle of a developer. These rhythms have healthy ranges (such as a stand up meeting lasting less than 15 minutes) and characteristics (such as that same stand up meeting not containing design discussions). When they fall out of these ranges or do not display the appropriate characteristics, they indicate that something is wrong with the agile process.

A healthy agile project has several typical rhythms such as releases, iterations, stand-up meetings, builds kicked off by continuous integration, and the red-green-red test cycle of a developer. These rhythms have healthy ranges (such as a stand up meeting lasting less than 15 minutes) and characteristics (such as that same stand up meeting not containing design discussions).  When they fall out of these ranges or do not display the appropriate characteristics, they indicate that something is wrong with the agile process.

As a doctor takes a patient's pulse or blood pressure reading to determine if the patient is ill, we take readings of our rhythms to let us know if something is wrong with our agile process. The rhythms, when off, sometimes need to be addressed directly, and in other cases point us towards areas of the process where we need to dig more deeply to find and correct the root cause of the problem.

Before we dig into each rhythm individually let us ask ourselves a question: why are rhythms important to agile methods? Think about it: agile methodologies are all about agility, which is response to change. Before we can even respond to change, we have to know that the change has occurred. How do we know that a change occurred? Feedback. Feedback at all levels of the development cycle. Each one of the rhythms we discuss is a form of feedback. If a rhythm is off then the information that we use to be "agile" is incorrect. When the rhythm is off it is a symptom of a malfunctioning agile process.

In this article, we define and categorize the rhythms of {sidebar id=1} agile processes. Then we will analyze each rhythm separately in order to highlight its valid ranges and characteristics.

The Rythms - An Overview
In true agile tradition, we will start with defining rhythms related to delivering value to the customer. The most basic rhythm that addresses customer value directly is the Release. When the time between releases is larger than one to three months (as it frequently is) then this is usually mitigated by several Customer Review Cycles . These Customer Review Cycles may be as frequent as every development Iteration but many times occur less often. The final cycle that is directly related to customer value is the Story which is the individual piece of functionality that has value to the customer. These three rhythms - Release, Customer Review Cycle, and Story - are directly related to customer value and solving the ‘right problem' (see Figure 1) .

There is another set of rhythms related to delivering the ‘problem right'. These rhythms are driven by the complexity of the problem at hand. Thus they split the problem into manageable pieces. These rhythms should be very familiar to the development team. They are the Iteration, (Daily) Stand-Up meeting, Story Tasks which directly correspond to a cycle of Continuous Integration, and the Red-Green-Red cycle of test-first development .

Release
The release cycle is the most directly related to customer value. It is also the one cycle that is almost always beyond the decision-making scope of the development team. Many release cycles are over a year long (for those of us on agile projects in non-agile organizations), which means that direct feedback about the utility of the product happens very infrequently. Multiple customer review cycles are used to mitigate this issue by giving the team more frequent feedback.

Customer Review Cycle
The customer review cycle is often confused with an iteration in agile methods. XP, for example, with an onsite customer mandates that a customer

Pages

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09