In a recent article on TechRepublic, Ilya Bogorad reminded me how the mere possession of an IT buzzword does not make for good practice. In this instance, the topic of discussion was ITIL, the increasingly popular IT Service Management approach, or a "framework of common sense" for IT service providers, as some analysts point out.

The same cautionary tale is true for Agile, which as a buzzword is currently on the ascendancy, but as a practice has been around for as long as anyone capable of remembering can recall, albeit in different guises: RAD/JAD, Scrum, and DSDM set the scene for what is now roundly known as Agile close to 20 years ago. So why the current hype?

Traditionally, hype is fuelled by a promise of something new or better than before. That's true for Agile methodologies - done correctly, they can deliver successful software projects faster, cheaper, and to a greater degree of quality than traditional lifecycles.

I wanted to see this talk by Guido Schoomheim since Black Pepper has been worked on distributed agile development projects now for a year or so, between sites in the UK and I was interested to hear Xebia experiences. Xebia have a team distributed between their offices in The Netherlands and in India.

Guido started his talk by discussing some interesting statistics regarding the costs of traditional outsourcing. He compared the costs of doing the development locally using a "hyperproductive" agile projects verses standard outsourced waterfall development. In the standard model, when one outsources to a very distant company with a different culture and especially in a different timezone, one has to define exactly what one wants in very detailed specifications which lead directly to a waterfall approach.

His figures suggested that to get the return on investment that one needs for a successful outsourcing project over for example a two year period then the cost of the outsourced team must be about 10% of the alternate local agile team's costs, or even less. However, typically one finds that outsourced teams are about 30% of the cost of local teams. Therefore, he suggested, taking a project that could be done locally with an agile team and cost $2 million, if outsourced to a traditional waterfall team, then that same project would cost around $6 million. Very interesting figures indeed and something that I feel is right and empirically sounds right from my experience of customers who have outsources, however I want to do more research before accepting these figures.

Having laid out some of the well known problems of this traditional approach to distributed teams, especially across continents, he described how his project had addressed them.

This talk was a bit of a surprise. Linda Rising's talk, while thought-provoking, to me didn't really fit an hour's slot in an Agility Organisational Patterns track.

The premise was essentially that we as a society have been taking caffeine since the beginning of the Industrial Age and that life today is different from that of a 19th Century factory worker so we may want to re-evaluate whether the drug caffeine is still useful to us. I'm not really sure how the contents of the talk, which was all about caffeine, fits the title of the talk or the 'agile' track it was in.

She started by highlighting that before the Industrial Revolution, Europeans tended to have beer for breakfast - since water wasn't really safe to drink. However of course that didn't really lend itself to the regimented and time controlled practices required in a factory at the beginning of the Industrial Age. Tea and coffee became popular at about that time, she posited, because it could help us get up with the clock rather than the sun.

The main part of the talk was about the metabolism and concentration of caffeine in the body and discussing some studies that show that while caffeine is good at helping people concentrate on simple and long running tasks (such as those required in a factory), it has no extra benefit in terms of the sorts of tasks that software developers do. In particular she highlighted some of the issues regarding how caffeine effects are based on concentration in the body, and pointed out that drinks often marketed at children can have high levels of caffeine in them: that we "learn" to drink caffeine at an early age where we would be alarmed at giving children other drugs. This was indeed food for thought and I agree with her that perhaps we as a society ought to be re-evaluating how much caffeine we drink.

We have been using agile development methodologies at Black Pepper for a while now and have used Mingle in the past as an online tool for managing stories and iterations.

However, we recently decided on Jira as our feature/bug tracking tool of choice and thought it would be interesting to see if we could use Jira to manage our agile projects rather than have more than one tool.

One of the cornerstones of an agile project is tracking your velocity. This is essentially a measure of how much work you are doing over a period of time. Agile projects are run in iterations, these might be a week, 2 weeks or perhaps a month. The length of the iteration would depend on the project, but 2 week iterations are a good start. Each iteration has a collection of "stories" assigned to it. A story is basically a single feature that has been defined through your analysis of the project before the first iteration. Note that as this is an agile project, you don't have to analyse the project completely up front and have everything mapped out. You just need enough to get you on your way, you will be creating and estimating more stories as you go.

I have recently completed work on my first project using the Agile development approach preferred by Black Pepper. So what you might say - but for a developer that has spent a considerable part of his 20 odd years in the industry firmly believing in a more formal methodology, it came as a bit of a culture shock, although largely an enjoyable one.

It wasn't totally alien however. Having spent the last 5 or 6 years working as a RUP Mentor and instructor, the benefits of an iterative approach were already well understood, but as my time with the project progressed it became clear that there were many misconceptions about the differences between the Agile and RUP approaches to development.

The Rational Unified Process is often thought of as a heavy weight development process, largely due to the apparent level of complexity and the overwhelming number of activities and artefacts described within the commercial product. This is the first misconception; the RUP product is not a development process but a process framework. If RUP is to be used effectively, it must be tailored to the needs of the development environment, the size of the team, the project being undertaken and the requirements of the customer. As the level of process formality reduces, RUP can become more agile, although it will never be as lightweight or as agile as eXtreme Programming. In my opinion, Rational made a huge mistake in the way RUP was originally put together, resulting in a reputation for red tape and complexity. The real problem was the lack of understanding amongst adopters on how to tailor the process effectively. Worse still, any tailoring that is performed is often the addition of new activities and work products that represent corporate standards, without removing any overlapping elements from the base product. This results in wasted effort as development teams produce documentation and other shelf-ware that will never be used or read.

The idea of a continuous integration deployment pipeline has been around for several years and is described in detail by Dave Farley and others in this ThoughtWorks paper. Following my recent experience with Hudson, I thought I'd show how to create a CI pipeline using Hudson instead of Cruise Control.

There are 2 aspects of the CI deployment pipeline that Hudson can most easily help with:

1. Managing binaries
2. Process Gates

The ThoughtWorks paper describes a binary repository as a shared file system where release candidates are stored. A key feature of the process is to promote the compiled binary artefacts through each stage of the pipeline without needing to re-build them. Each time a developer makes a checkin the system builds a new release candidate and stores it in the binary repository ready for subsequent stages to use. Each stage in the pipeline performs a series of tests (acceptance, performance etc.) against the same set of binary artefacts. A consequence of this approach is that the binary artefacts must be configurable for each target environment.

On a recent project we developed a comprehensive set of acceptance tests driven by Selenium RC. The UI acceptance tests were written using JUnit which meant we could easily run them as single tests directly from our IDE. In addition, because our build and deploy processes were driven entirely by ant, it made sence to use an ant task to run the acceptance tests too, and this was where I ran into a annoying little problem with Selenium RC on Linux.

The problem

When tests are executed a browser window will automatically open and close during setup and tear down of each JUnit test. When there are a large set of tests that take more than a few minutes to run, the opening and closing of the browser window can be very distracting!

Agile development processes provide several core disciplines that affect the overall quality of the system under construction. One of the fundamental disciplines in agile development is that of pair programming (“pairing”).