Our Blog

where we write about the things we love



SharePoint and Agile: 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 traditional approach, i.e. waterfall style, to the development of our customers' desired end product. While we delivered good solutions to our customers, 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. 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 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 is 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 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.

To read more of Gavin’s blog postings visit http://gavinb.net

Posted by: Gavin Barron, Solution Architect | 17 September 2008

Tags: Agile, SharePoint

Blog archive

Stay up to date with all insights from the Intergen blog