Agile methodologies have recently been getting something of a bad name, it's not unwarranted but it is unfortunate. The problem isn't actually the process, an agile process will work very well - if the infrastructure supporting it is capable of of being agile as well. By supporting infrastructure for a process here I don't mean servers and software I mean the people and the organisational foundations. The organisation trying to use an agile process must it's self be agile, quick to react to change. Agile processes that work have one thing in common, they encourage features to be released early and released often.

A pretty basic overview of our process goes something like this:

Big Bag of Features

Our projects and releases go through a number of stages, the first we call The Big Bag of Features. When a project is really just an idea, it's something we might want to build and we basically rough out some ideas and start to grow them into all sorts of crazy future versions, we talk about all the features we'll need to achieve them and how we'll go about it.

Minimum Stable Feature-set

From the BBoF we usually end up with at least one, more often than not a number of possible outcomes and development paths. By talking through all of the options, all the features and all the future versions we'd like to be able to build leads us naturally to something we can build; a vision for a product.

Citrus is a good example of this practice, we're at the stage where we've decided the vision for the project, have a big bag of features we'd like to implement and are now in the process of creating our MSF

From the vision we decide what we need to make a product work; less is definitely more at this stage. We normally take each feature we've decided would be nice to have and try to think about who would use it and why. If we can't come up with a compelling argument for most of our users using it, we normally chuck it back into the bag to worry about later. We refer to the result as theMinimum Stable Feature-set (MSF) or Minimum Launch Feature Set.The bare minimum we need to launch a working product.

The MSF becomes the next iteration, and once it's set we don't alter it. Nothing is added or taken away. On the surface this might seem either silly or a bit high and mighty, but we can do it because we put the work in ahead of time. We've discussed how we envision the product being used and we make sure we've covered all the bases. New great ideas just aren't important enough to include, no matter how good they are. We leave them for another iteration and another day.

These ideas can be politically disastrous in some organisations, it's downright heresy to tell the boss, or the sales director or a colleague what amounts to: their newest great idea just isn't good enough. It's important for an organisation to have focus though, this is where the MSF and short iterations come into their own. Releasing early and often means that you're quickly on to the next round of updates and those great ideas can be looked at objectively alongside anything else in the Big Bag of Features.

Getting started

Finally we start coding the interfaces first, then backend to meet our MSF. In the case of a new project partial interim releases are made for testing. We try to work out an entire area of the project first then release that to our testing audience for feedback. As the iterations contiune towards release we add all the features from our MSF.

Updates

When it comes to updating projects we throw away the Big Bag of Features and start all over again.You heard it right, throw them away, gone. A long time ago I learned that feature lists just cause trouble. You can't help but schedule them, the schedules are very loose and they're never met but still promises are made based on them. In the end they start to read more like a list of failures, things your application doesn't do. More importantly, things your application will more than likely never do. So we throw them away and start again with a new Big Bag of Features, the most important features will bubble to the top of your memory anyway and will end up right back in this new BBoF.

For an update our MSF is usually a single feature, or small feature set if they work best that way. The aim is to keep the releases small and concise, targeting one area of functionality. This doesn't mean that we don't set milestones or visions for the future development of the product, we normally make a milestone accomplish some greater goal or vision for the product. But we try not to roll a list of disparate fixes to various parts of the application into a single release, we break them up into many smaller releases.

Rinse and Repeat

We continue in this way for the life of the project releasing features to users early and often so bugs are spotted quicker and we never go too far down a dead end, creating something users won't use. It's during this stage that we really work hard to measure how an application is being used, or not used so we can focus our energy only on the most important parts. We never try to be everything to everyone, we're not afraid to disappoint some people or to just say no. We want our application to be great at what it does, not mediocre at everything.