Skip to content.

TalkBMC

Sections
You are here: Home » Blogs » Mike Lunt » Rejuvenating the Software Life Cycle » 2007 » Keeping things together

Keeping things together Keeping things together

Document Actions
What does releasable mean? How can a development team keep the code intact from iteration to iteration?

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.


_____
tags:
Monday, October 29, 2007  |  Permalink |  Comments (2)

What changed in the last year

Posted by Ryan Martens at 2007-10-30 14:16
Mike,
It has been a year since you achieved these levels on your teams on BMC BPM. Where have you been pushing in the last year? How have you matured your ability to "keep things together."

Just curious.
Ryan

Mike Lunt

Subscribe to Van's blog Subscribe to Mike's blog

Bio & Writings

Email Alert: Mike's Blog

Get an email alert when I publish a new blog! Enter your email address:

Rejuvenating the Software Life Cycle
« August 2008 »
Su Mo Tu We Th Fr Sa
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
 

Powered by Plone

This site conforms to the following standards: