Card Conversation Confirmation is described by Ron Jeffries as the three critical steps of User Stories. If there are any development teams looking for that magical balance between cycle and ceremony in their processes Card Conversation Confirmation is at the heart of the answer. Add into this Planning Poker and you've got all you need to implement a lean software development team - its a Software Development Lifecycle, in a nutshell. Hopefully this can be read as a journey of self discovery for the team and the individuals that make it up too.

The purpose of this blog (mcLEAN Practically Agile) is to give agile advice to teams who are having a challenge improving their agility. This article is the first in a short series that present a simple easy to implement and easy to maintain Software Development Lifecycle.

Lets make a start by looking at some of the key challenges that software development teams experience across the industry - these are usually related to one of the following (the series will contain appendices to consider each of these in more detail later - please click here to register and receive notifications of updates to the series).

1. Poor definition of requirements - this makes it difficult for the team to get started and stay focused - it also means that completion of the work can be ambiguous and its not clear what testing needs to cover or how it can be carried out independently - this situation often leads to regular changes during development and last minute changes in testing.

2. Poor estimating - or maybe even no real estimates at all - without estimates the team is de-motivated as they will simply be working under pressure to deliver ASAP - under such conditions the whole team will know the project is doomed to failure. Estimates provide a real picture of what is possible with a given team in a given period. One reason why estimates are often skipped in small teams is because the project has been over sold to the customer - and on top of that the team neglects to take responsibility for communicating the risks associated with that.

3. Poor communication - in pressured environments some team members simply keep tight lipped and wait for the train to crash - or develop what they think is required without verifying it and then citing ambiguity as an excuse among the wreckage. When communication does take place - who writes it down? Usually nobody. It is forgotten or when testing comes there is a dispute about what was actually said - emails are resurrected but they contradict each other and were overruled by subsequent unrecorded conversations.

This is a recurring scenario that I've experienced in many development teams - I think its fair to assume that it happens right across the industry - does it sound familiar? Analogy - recently astronomers have discovered new planets circling distant stars as you may well be aware, and they rightly suppose that this is a good indication that most stars are likely to have planets - a theory that's been put forward for many years is now verified by physical observation and statistics. Well I've had a theory for many years that development teams are generally experiencing these kinds of challenges and I reckon I've worked with enough now to have collected the physical evidence to back that up. And in addition to that these teams struggle to mature to a state where they have repeatable or indeed managed processes - no matter how hard they try they remain ad-hoc (later we'll take a quick look at CMMI).

These days most teams will be thinking agile, or iterative rather than waterfall - in my view that's a great starting point. The reasons for rejecting waterfall are usually (a) requirements need to be defined up front and (b) the gated approach doesn't allow for change throughout the project. Time to think a little harder - in scrum you still need the requirements defined up front - you just do that in a different way. Also in waterfall there is something called a change request - which can be used to change requirements at any point during the project - but in agile the change request is less obstructive than in waterfall. The first thing a team needs to do is explore what benefits they are seeking from agile - if the team thinks they are going to get away with not defining requirements then they are off to a bad start.

There are also challenges in taking scrum off the shelf and getting the team to work to its principles and practises - one of the key principles is that "nothing can be added once the sprint has started" - for a development team in ad-hoc this is pretty much impossible. I think these kinds of challenge often lead to teams remaining in their ad-hoc state - occasionally they attempt to climb out of it to make some sense of their world only to get pushed back by their environment's resistance to change. So the challenges to making changes are generally things like:

1. Waterfall demands detailed requirements up front, is overburdened with red tape and takes too long.

2. Agile requires stringent principles such as "no addition of work once the sprint has started".

I am advocating scrum as the ultimate approach - I'm simply recognising that its not entirely practical for every team - probably most teams - to just switch to it in a matter of weeks or even months - it can take years - but there is a path to be followed that leads there with a gradual adoption of new practises and principles. In this article I want to show that Card Conversation Confirmation is a relatively easy transition that can get a team into good shape and provide a substrate for developing into a full scrum team.

In part 2 I'll go into how to get Card Conversation Confirmation up and running - in the meantime you can take a look at the description on Ron Jeffries web site.