Agile Sharepoint development by 21apps and Andrew Woodward MVP

The numbers are in and I think this small sample really gives a good view as to the way people are approaching their SharePoint development projects.

Numbers taken from a one week poll asking people which build servers they used on their SharePoint projects.

It’s very clear from this that people are in one of 3 camps of almost identical size

• Those using Team Foundation Server
• Those that user another non Microsoft tool
• Those that don’t do anything

Team Foundation Server

Installing and using, or developing against Microsoft SharePoint Server requires a fairly big commitment to the Microsoft technology stack, so the domination of Team Foundation Server is probably to be expected.

• If your a big corporate user of SharePoint you most likely have a deal that includes TFS licenses
• You have likely committed to Microsoft as the platform of choice across the board
• If your a Microsoft Partner delivering products and solutions you will have a big investment in Microsoft licenses, and also a duty to adopt the MS recommended path
• TFS is a good solution,  and it’s getting better in 2010

Non Microsoft Tools

I was surprised by the mix of Non Microsoft tools,  having looked at what you get for free and the costs for licensing beyond that I would have expected Team City to have a bigger following.  Perhaps the reason for not being higher is jetBrains being thought of a Java based?

I bundled CruiseControl and Cruise together,  in hindsight I should have split them as they are totally different products.   I will make the assumption that most are using CruiseControl as this was really one of the first decent automated build tools to target the .Net platform.  People have got to know it an have scripted automation for their non SharePoint projects already.

Final Builder I have always liked the look of;  I really do find the whole raw XML editing that we have to do in any build automation a bit like developing against SharePoint,  it’s ok but the tools really should be better than this.   Final Builder has a great product, but the cost per user is perhaps the barrier here.

Other

Some people had build servers but didn’t use it for SharePoint – would really count those as None.

Others listed the source repository (SVN) or scripting language (msbuild, nant) so I assume that the build is done manually using batch files rather than via a dedicated build server.

Also someone listed Hudson,  something I had personally never heard of, but will bundle with the Non Microsoft Tools.

None, we don’t have a build server

This was probably the biggest surprise to me,  and perhaps not the way you might think.  I was actually surprised that only 35% of people indicated that they did not have any form of build server for their SharePoint projects.  

Based on my years of doing consultancy gigs I found that the majority of companies that I went into to do work didn’t have anything even close to an automated build server.  Heck some don’t even have source control for the code!

So I can take a couple of things from this

• People who don’t were too embarrassed to answer
• SharePoint development has moved on significantly and most teams now have proper build servers
• The readers of my blog are not representative of the wider SharePoint user base

Conclusion

There are still a lot of SharePoint teams out there that have yet to get the benefit from automating their builds,  who will undoubtedly be spending many hours manually putting things together the night before Go-Live.  

For these people, and those moving into SharePoint for the first time, there is a need to provide more information on why investing time in getting your automated build in from the start can make huge savings over the life of a project.  Providing walkthroughs on how to do this and some of the challenges you will encounter along the way.

Based on the feedback I could look at doing TFS first,  but I know that for teams with nothing setup yet this is going to be a big stumbling block.  Trying to convince you boss to roll out Team Foundation Server just so you can automate your SharePoint build is not an easy argument to have.   I will instead look at the options allowing you to get up and running quickly and more importantly without needing to get budget for licenses. 

I will start with Cruise,  and I will be dog fooding this for real on Project Aberdovey.  

Thanks to everyone who took the time to vote,  I would love to hear your own take on what the numbers mean to you and your experience with automating builds in SharePoint.

UPDATE:  Project Aberdovey is now live and called 21SCRUM

Download a trial from www.21scrum.com

Being an advocate of SharePoint as an application platform I looked long and hard for a decent implementation of a Scrum and have always been found wanting.  I have seen simple examples where any power user could set things up but found the lack of any Burndown charts meant you lost probably the most important part of Scrum – the visibility.

I have found that VersionOne is one of the best products on the market, although it has a lot of options which tends to put off new teams.

For those that use Team Foundation Server your probably going to head towards the Scrum for Team System developed by Conchango.  I’ve not used this in anger so am unable to comment on how well it works however this solution is not really a SharePoint specific solution as it requires you to make the commitment to using Team Foundation Server.

Bil Simser did a good post on scrum tools,  although its nearly 3 years old still has some good links.   Again however the tools are not specifically SharePoint.

Why the SharePoint Obsession?

SharePoint is the collaboration tool of choice, companies have deployed it and it is being used with varying degrees of success.  People have become familiar with the how to add items to a list, how to upload documents into a document library and for the more advanced how to build engaging dashboards.

What is the biggest thing you get from adopting scrum?  ‘Visibility’

What do you need to encourage to make Scrum work?  ‘Collaboration’

SharePoint is the natural platform choice on which to build a Scrum tool.

Introducing Project Aberdovey

As with all good development teams I think it is right that your development project should have a name,  and in keeping with some big companies in the Seattle area 21apps uses place names.   Aberdovey, or as it’s spelt in Welsh Aberdyfi, has probably one of the best beaches in the UK and is located 50 miles west of the office.

Put simply, Project Aberdovey is a Scrum tool for SharePoint.

There are a few aims for the project:

1. Produce a fantastic Scrum tool built on SharePoint
2. Develop the solution using agile techniques including TDD
3. Dogfood the solution as soon as possible – what better way to develop the right solution
4. Open development – I want to give feedback on the challenges but also welcome your input

I will be looking for ways to give people visibility,  I am looking at codeplex as an option but welcome any suggestions.