I am asked this question at least once a week, and I’ve heard all kinds of arguments and disbeliefs in the theory of making every iteration “releasable”.  As one of the fundamental tenants of a good Agile practice and the antithesis of most Waterfall projects, the ability to keep the software in a customer-shippable format is a key measure into how “agile” a team really is.  It seems odd to me that it’s almost been a year since my last blog entry on this, and it’s still a nagging issue which we still struggle with from time to time.

So, what are the acceptance criteria for staying releasable?  Here’s a recent definition we have starting using on a daily and/or iteration basis:

• The software builds and can be installed in its current state.  (a daily requirement)
• No severity 1 or 2 defects exist.  If regression defects are found, they must be prioritized over new user stories in iteration planning.  (an iteration requirement)
• Shipping to a customer is 1 (2 max) hardening iterations away.  (an iteration requirement)

As mentioned previously, there are a variety of ways to address “the big feature at the core of code base”.  Beyond trying to break the feature down as much as possible, some methods include hiding the new functionality and using configuration to enable/disable the new functionality.  A more extreme way to solve this problem is to create a branch of the software that can be tested in some form or fashion.  This part of the software would be merged back into the main development path once it has proven its merit.  (While possible, this last approach is the least desired, due to the integration risk introduced later than normal.) 

Regardless, the actual implementation is often less important than the discussions related to mitigating the risk associated with destabilizing the existing functionality.  Having the releasability criteria often triggers conversations within the Agile teams on how to address trouble areas instead of dumping weeks of code into the product hoping for a miracle in the end.

I recently recorded a podcast on Agile at BMC and made some predictions on where Agile is headed.

Here's the link: Mike's Agile Podcast.

As many of us have discovered, coordinating three or more Agile teams is a lot of work, especially when the teams are scattered around the globe.  I “borrowed” the title of this post from Cohn’s book ' Agile Estimating and Planning', where he mentions the pains of coordinating large projects and suggests some ideas on how to deal with this situation.  For the Performance Manager group, a key item is our intense system of communication that never sleeps (literally, in some cases). 

Two of our most popular methods of communication are well known in the Scrum community, even though they serve additional purposes with our multi-cross-continent-time-zone setup.  First and foremost, daily Scrum of Scum (SOS) meetings occur with leads/leaders from every team, and these meetings occur early in morning (US time), so they are friendly for participants in India, Israel, etc.  During these meetings, all of the teams get a chance to hear what’s going on across the teams and determine whether roadblocks exist within another team that may cause a problem for other teams.  An important aspect to keeping these meetings short and productive is focusing on what’s being done or on blocking items affecting other teams.

A second important method of communication is our iteration demos, which occur every two weeks during non-hardening iterations.  Again, these are done at globally friendly times, and all of the teams get to see what the others have done.  This provides a sanity check for consistency and allows each team to accept critiques on the work from the past two weeks.  Since these meetings are recorded (via Live Meeting), the support teams and others can always use these meetings as on-going training for the new release well in advance of it being made available to customers. 

In all cases, the communication methods are setup to create total transparency and prevent passive-aggressive behaviors.  As transparency increases, the teams become more comfortable with being open and potentially “exposed”.  The main goal is to make small course corrections instead of having big rework items, but the process never gets put on cruise control because the fleet can quickly run aground.

From my experiences, backlogs are important to the Agile process for a variety of reasons, but the most important purpose is to provide a common medium for what the team should be focused on and in what order.  A backlog should reflect customer value, since the backlog has been derived from the customer (in theory).  Often, side projects and corporate initiatives skirt the backlog, creating contradictions in focus.  In Agile Estimating and Planning, Cohn describes several problems that occur when focus is compromised.  First, when team members are forced into a multitasking situation, productivity falls as switching amongst tasks becomes a burden.  In addition, the ability to prioritize is quickly lost when initiatives run parallel to the backlog.

One solution we often debate is to push these parallel objectives into the backlog and prioritize them with everything else.  The difficult thing about doing this is rationalizing the customer value in these side projects; however, the exercise alone will be well worth the effort.  The team may determine to that the side projects do not result in something real to the customer and/or increased revenue, and they may ultimately lower the priority.  In other cases, the benefits of implementing an initiative may be realized by discussing the customer impact and subsequently estimating the cost.  In either case, when these items are listed as “overhead” and left out of the backlog, there is a greater chance the team’s productivity will be lower in both real and perceived terms.  The hit to real productivity occurs due to a lack of focus; however, the perceived productivity will be lower because the list of items accomplished will be much shorter since the overhead items were never listed in the first place.

Many software companies talk about underpinning layers of software that allow various products to be built with the idea that interoperability and integration will just happen. These layers of software are called "infrastructure" in many environments. Without software infrastructures, many products are often forced to recreate the same functionality over and over, such as logging in to a system. Unfortunately, there are often many "infrastructures" which hurts the original intention of creating the base layer in the first place.

To minimize this, companies must first consider another layer, and this could be characterized as the cultural infrastructure. The cultural infrastructure is similar to getting everyone to do the wave at a baseball game. Each person can be individually shown how to standup, throw two arms in the air, and sit down; however, if the group as a whole isn't in sync, there is no wave. Setting the cultural infrastructure is often difficult because employees in a company are rarely sitting shoulder to shoulder within site distance of each other.

Setting the cultural infrastructure can be remedied (no pun intended) by first aligning goals and second, coordinating expectations. One way to do this with an Agile method is to use matching iterations and release cadences. With this model, people are thinking about the releases and planning at the same time. Adjustments needed by one team are domino-ed into the iterations of another team, and most importantly, the goal is the same for everyone at the same time.