Go together like a horse and carriage.

Well, that’s my take anyway. I’ve been involved on a few SharePoint projects now that have taken a tradition approach, i.e. waterfall style, to the development of the customers desired end product. While we did deliver a good solution to the customer I feel that had we taken an agile approach then the end product delivered could have been an absolute killer!

So, why does SharePoint lend itself to an agile approach?

Users don’t get stuff until they see it. This holds true for all software, we’ve all drawn wire-frames and had whiteboard sessions to explain what this new application will look like. Then in the traditional space, the developer disappears into his darkened corner for days/weeks/months returning with something that resembles what was discussed. Oh sure it meets the requirements as they were stated in the requirements docs but does it work for the user? 

Rapid prototyping. When looking at SharePoint for document management or other intranet style usages it is simple to create a rough working model of what the client is after. This helps to ensure that the we can deliver what the client really wants, not just what we think they are asking for.

On the fly tweaks and changes. I was sitting in a demo session the other day with a client who was explaining how they would expect to interact with some data in a particular scenario. Now the views that I had over that calendar list didn’t help them to see what they needed to. Thanks to the ability to create custom views across lists and libraries I was able to whip up and fine tune a custom view. This view will help the users achieve their goals. I know that this view it right as it was essentially built by the user just with me manipulating the tools.

Users can build stuff themselves. Just taking the prototyping another step, users who have had some training can take on some of the prototyping themselves. Admittedly there’s not going to be huge numbers of users that will be able to or want to do this, however those that are this way inclined will love being able to get and involved.

Of course the usual arguments in favour of an agile methodology over a more traditional waterfall approach still hold. I refer you to the Agile Manifesto, Where is the Proof Agile Methods Work and Why Agile Software Development Techniques Work. Sure there are arguments against agile, but it is my firm belief that in the software services industry agile approaches will deliver the customer a solution that fits their needs better and reduce the cost of doing so.