Agile release planning, Agile narratives

The Amarinda Consulting newsletter.

You are receiving this newsletter because we received a subscription request from your email address - honest! If you think this is an error or you don’t want to receive CuttingEdge any more please check the bottom of this newsletter for removal instructions. Your email address is only used for sending out CuttingEdge and will not be passed on to third parties.

Continuous integration and release planning

I seem to have acquired a reputation for being the continuous integration troubleshooter.

I’m starting to think continuous integration is the second “forgotten practice” from the first XP book (remember “system metaphor”?). Sure, everyone talks about it and everyone’s doing it, but a lot of places I’ve seen aren’t really getting it right. And why is that? I think because those two innocuous words sweep a considerable number of issues under the carpet.

What’s this continuous integration thing anyway?

Too often, continuous integration is mentioned in the same breath as CruiseControl. (Google it if you don’t believe me). Let’s set aside the fact that CC is a pig to configure and keep running compared to simpler and more effective tools like Build-O-Matic. The real issue is the idea that you can automate continuous integration. Don’t get me wrong; you can automate many things–compiling and packaging, your tests, deployment, some documentation–but in general you can’t automate all the process discipline that goes around it. Those two little words are really saying everything about how you deal with software artifacts on the project. They are saying an awful lot, because in the Agile world-view those software artifacts basically are your project.

A team can self-organize its way to a continuous integration process and toolset that works, but how much information is really out there on the practice of continuous integration? I’m talking to a client at the moment about release management. They can’t see where it fits into the Agile canon, and want me to do a mapping for them. I was initially a bit puzzled by this. I wanted to say, well, it’s right here, and point to continuous integration. But then I took my agile hat off and started seeing it from their perspective. I had to admit there’s not much in the way of coherent explanations of what continuous integration actually is and how you go about doing it.

34 signs continuous integration isn’t working

I’m not the only one feeling the pain at the moment. Lindsay McEwan, with whom I co-presented at XPDay 2006 has also had some recent experience of environments with dysfunctional continuous integration. When we started putting the session together we realized we had a bit of a problem. Let’s call it the CruiseControl effect. How do you explain what the session is about when it’s about not being about CruiseControl?!

So we tried to write down a few of the things that might resonate with a broad audience:

  • Developer “done” means something very different from user “done”.
  • You’re sometimes surprised that code ended up on branch X (which is in production and supposed to be locked down) and, strangely, it doesn’t seem to be in your new release candidate.
  • It takes forever to make a release.

and so on.

Lindsay and I took turns noting stuff down. Later I wrote up and slightly expanded our list and published it. We had 34 things that indicate you haven’t really got continuous integration right. That’s a lot of things, until you consider the idea that “continuous integration” is a code name for practically your whole software lifecycle.

I wrote the book on continuous integration… well, part of it…

Years ago I started writing a book, one chapter of which was on continuous integration. The book never made it to the publisher: my co-author Ivan Moore and I had just too different writing styles to make it work. Plus we felt like our book was already a “me too” effort, eclipsed by earlier and better offerings. With the benefit of hindsight and the surfacing of implicit knowledge that comes from having to explain stuff over and over, I have to admit that we were probably wrong to stop so soon. Continuous integration is not a solved problem.

By the way, if you’re interested you can read the draft at http://amarinda.com/articles/Continuous_integration. There are so many more things that chapter needed to say, but it’s a start.

Agile Narratives

Agile Narratives is a project to collect and make freely available personal stories about software development (Despite the name, we’re just as interested in stories which attack agile development or have nothing to do with it). We’ve already collected over 20 stories, which you can read online at the Agile Narratives website. The database is indexed so it is possible to find stories by topic. The most important topics are shown on the site’s topic browser.

Some examples of the ways you can use Agile Narratives:

  • build a case study to support change within your organization;
  • research possible consequences of an action before taking it;
  • discover emerging new techniques and practices;
  • chart the uptake of agile software development;
  • discover new organizational patterns;
  • learn from the mistakes and successes of others.

All the stories in the database are indexed according to a number of criteria by the people who submitted them. Some examples are: whether the story is about success, what kind of organization it is about, etc. Alternatively, you can search using keywords.

You can use Agile Narratives online at agilenarratives.org.

News

  • I attended the grandly-named first international conference on postmodern programming two weeks ago. Postmodern programming is a movement that tries to recognize and accept the realities of software development in the 21st century while questioning the validity of received wisdom about how we should be doing it. Thought provoking.

  • The XPDay 2006 conference is over. This year we had an exceptionally strong programme which contributed to another sold out conference. You can find some personal reflections on the conference at duncanpierce.org.

  • Rachel Davies will be joining me to run a workshop on cognitive bias in decision-making at SPA 2007, March 25-28 2007, Homerton College, Cambridge, UK. We’ll be unpicking why irrational environments occur and what can be done to make them more rational.

  • Rachel Davies, Giovanni Asproni and I will be presenting an introduction and experience workshop on the Scrum methodology at ACCU 2007, April 11-14 2007, Paramount Oxford Hotel, Oxford, UK.

About CuttingEdge

CuttingEdge is the newsletter of Amarinda Consulting, copyright Duncan Pierce 2006. Permission is granted to pass on copies of this newsletter to interested parties.

If you have received a copy of this newsletter and would like to subscribe, please send an email to CuttingEdge-request@amarinda.com with subject “subscribe”.

You will not receive more than one email each month. Your email address will only be used for sending out CuttingEdge and will not be passed on to third parties.

If you would like to stop receiving CuttingEdge please send an email to CuttingEdge-request@amarinda.com with subject “unsubscribe”.