Update

21 June 2010:  We are pleased to annouce the 21Scrum has been released.   Please visit www.21Scrum.com for more details and to get your copy.

Having been an advocate of SharePoint and Agile development for some time I have always found it disappointing that there has not been a decent solution for managing my Agile Projects in SharePoint.  I initially floated the idea of a scrum tool for SharePoint just under a year ago and have at last managed to dedicate some time in order to make this idea a reality – internally this is called Project Aberdovey. 

Today we announce two things

• Project Aberdovey will be called “21Scrum – Scrum for SharePoint“

21Scrum

21Scrum is a Sandboxed solution that works with all editions of SharePoint 2010 including SharePoint Foundation. 

The solution is made of up 3 key areas

• Sprint Planning
• Burndown Chart
• Story Board

Sprint Planning

All of your backlog items are maintained in a SharePoint list,  you are free to extend the list to add additional metadata and views to make management of the backlog easier.   Planning your sprints is done using the Sprint Planning board where you plan as you would with a white board moving stories between the backlog, current and next sprints.

Sprint Planning

Visibility is central to Scrum projects and the Burndown chart provided gives you a real time view of how you sprint is progressing against the ideal.

Story Board

The story board is what the team uses during the Sprint, ideally this is a big white board in the team room – with distributed teams this is not viable.  The 21Scrum story board provides this white board view and, like the Sprint Planning, allows the team to drag and drop stories as they progress through the stages from Not Started to Done.

Getting Started

A quick guide to getting started with 21Scrum

1) Download the 21Scrum Sandboxed solution – rename the file from .zip to .wsp

2) Navigate to the Solution Gallery in the Site Collection you want to deploy 21Scrum and click upload solution (in the solutions Tab)

3) Upload the 21Scrum solution and activate it

4) Activate the Features

21Scrum is divided into two part

• * Site Collection Feature which has things like the WebPart definitions
• * Site Feature which enables the lists to support the team

This split allows you to have multiple independent Scrum teams working in the same site collection.

At the root site collection activate the Site Collection Feature

And activate the Site level feature in the site that you want to manage your Scrum team

5) The Burndown Chart is provided as a web part,  add this web part to a page.

As you haven’t started doing any work yet your Burndown chart will look like this.   To make testing of the beta easier we have provided another web part.  The “Populate Demo Data” web part will create sample data as if you were half way through a sprint. Simply add this web part to a page and click “Populate Demo Data” and have a play with the Sprint Planning, Story Board and Burndown.

Giving Feedback

Having used a lot of scrum tools and often found them trying to do too many things we have kept 21Scrum very focused,  the ability to be able to get up and running quickly and for the tool to add value and not become an overhead was crucial.   However we may have missed something that you can’t live without!

The beta release of 21Scrum is available to anyone to download and use,  it is not restricted in time-boxed so please feel free to use this on real life projects.

All we ask is that you provide feedback so we can make sure that when we release 21Scrum it is the best Scrum tool available.

If you have a feature request or find a bug please add comments on this page to send an email to andrew@21apps.com

In this article and screen cast we will discuss the idea behind the CI process and focus on the technical tricks that we need to make in order to get this working for a SharePoint 2010 project using Team City and Subversion.

One of the first things that you will want to do for any development project is setup your Continuous Integrationprocess. The value of having a server automatically monitor your source code repository for changes and validating they work is immense

Its worth mentioning that doing Continuous Integration is not something you will want to leave until later in the project.  Waiting means the solution gets bigger and more complex which in turn make the setup more comples.   My recommendation:  Get this configured early, during Sprint 0  (i.e. before you write any real production code) if at all possible.

The basic CI Process

The diagram below shows the normal process that occurs.  

(1) a developer checks in some code changes to the source code repository.

(2) The CI server monitors the source code repository for any changes

When changes are detected the code is retrieved and the automated build is started.  This build will normally include running Unit, Integration and Build Verification tests.

(3) The success or failure of the automated build is reported back to the Team (including the developer).

In some teams breaking the build means the developer has a forfeit of some sort.  The idea is to encourage team work but also to discourage broken builds.

When the build breaks!

A term I read recently, ‘Stop-the-Line’,  is used in Toyota manufacturing process where any problem results in the production line being stopped until the cause of the problem is found, resolved and ideally prevented from re-occurring.    

This should be the same when a build breaks; the whole Team should stop and help get the build working again.  It is not just a problem for the developer who last checked in – the whole team need the process and need the builds to be working.

Setting Up in Sprint 0

The actual process described above is a little into the development cycle, when the build is in place and when the team are working on production code.   Before this can happen there needs to be a process put in place.  I refer to this initial as getting the strawman solution done.

definition: Strawman

In general, a strawman is an object, document, person, or argument that temporarily stands in for and is intended to be “knocked down” by something more substantial.    

source: Whatis.com

The aim is to take some code, which will be replaced hence the Strawman term through the CI process and get the team build notifications working.   You should aim to prove the successful builds but also what happens when the build fails.  Did the team get notified?  and did they react?

The Strawman Exercise

21apps is a small and geographically dispersed team,  we make extensive use of cloud based services for things like source control as they prove to be cost effective and flexible and our strawman  process tends to follow these steps:

1) Create a repository for the project  (Hosted Subversion)

2) Create the strawman project  (Simple ‘hello world’ web part)

3) Create a simple build script  – small steps mean a successful compile is our objective

4) Create a automated build configuration on our CI server – we use Team City

5) Prove the successful and failed builds

In this post we are focusing on step (4) setting up Team City as our CI server. 

To make this easier I have provided a quick video walkthrough on what we have done for the early builds of Project Aberdovey- the process will be very similar for your SharePoint 2010 solutions.

SharePoint 2010 – CI with TeamCity from Andrew Woodward on Vimeo.

Video Spotlights

Key areas that are highlighted in the video that you will enable you to build SharePoint 2010 projects in Team City.

If you are using MSBuild ensure you set the MSBuild version to Microsoft.Net Framework 3.5 and x64 run platform.

Force Team City to use MSBuild 4.0 as this is needed by adding the Environment Variable

Name: MSBuild

Reference Syntax: %env.MSBuild%

Value: %system.DotNetFramework4.0_x86_Path%

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.