Agile software development – back to first principles

15 May 2007 Agile software development – back to first principles

The Agile Manifesto was released in 2001 with some theatre and not a little revolutionary symbolism. Whilst it was seen by many as being a radical departure from accepted software development “best practise” I remember being somewhat bemused at what all the fuss was about. Rather than being a radical departure, it seemed to describe a lot of what we were already doing.

So were we doing Scrum back in 2001 ? Or XP ? No. Although these methods (and others) had been developing for some years before the release of the manifesto, at that time they didn’t have widespread adoption or even awareness. But – at a time when projects around us were being cancelled, in some cases after years with no progress – we were writing good code, delivering quality systems that the users liked and getting things done. So were we “doing Agile” ?

Here are some of the principles we followed back then:

• Sit the development team together and as close as possible to the business
• Encourage regular informal interaction between the development team and business
• Recruit good people with a passion for what they do and trust them to do it
• Focus on the business benefit, not the technology
• Make sure it works, make Sure it works, make sure it Works

These principles evolved from experience – seeing what worked and what didn’t – and from an innate sense of what is ‘right’ both ethically and in terms of effectiveness. A lot of these could almost be taken directly from the Agile Manifesto and supporting principles which perhaps explains my initial response. So in that sense we were certainly in the spirit of Agile.

But there were a few significant concepts introduced with the Agile Manifesto that were not front of mind for us back then. One of these was “deliver early, deliver often” – an idea so mainstream now that it seems hard to conceive of a time when it wasn’t practised. Yet this more than anything has helped demolish the great dividing wall between technology and business, allowing people from the non-technology world to step into the development process and share control.

Fast Forward to today and what has changed at Shine ?

In some ways nothing at all – we still subscribe to the basic principles we were following in 2001 simply because they’re right and they work. We are still writing good code, delivering quality systems that the users like and getting things done. We’ve chosen not to standardise on a specific Agile methodology yet, but we have heavily borrowed from many and used ideas as appropriate to specific projects. We have used time boxed iterations, test driven development and continuous integration (amongst others) as techniques to help, particularly in order to “deliver early, deliver often”.

It is worth remembering that Agile software development is not XP or Scrum or AUP or any of the other many and varied methodologies. These are expressions and extensions of the underlying principles laid out in the Agile Manifesto. So perhaps Agile software development is more evolution than revolution, defined by a group of like minded people who stood up, looked around and recognised that some of the things people were doing actually made things better.

Or perhaps it is something more.

One of the other new ideas was to “Welcome changing requirements, even late in development”. This puts control of scope squarely back with the business – where it should be – but is arguably the greatest challenge to traditional software development approaches.

But that’s another story in itself so it will have to wait until next time.