1. We knew someone who had used it before and liked it. 
2. When I took a look at it, it looked really simple to use.
3. The ScrumWorks Basic version was free.  So we can try it out and if we want to can upgrade to ScrumWorks Pro

That was it really.  Not a tough decision.

Our IT installed it and we started using it yesterday.  I used it today and it really is as simple as the demo shows.

The project began in November with a successful kick-off meeting. The project direction, scope, what we were going to achieve, etc. were all agreed upon. The basic idea was to completely re-write the application in C#, using the .NET framework.

We did some preliminary requirements gathering and I made a rough estimate based on the size of the existing application, using the standard tables for project size and estimated effort given in the book “Rapid Development” (awesome book). What I came up with was 18 to 24 months with a 25 man team. This was way more than I’d thought it would be, but then I looked at the fact that the application (a shrink wrapped CRM) had been developed over a period of 15 years and that the more I looked at it, the more functionality I saw, I realized that my estimate was probably not so unreasonable after all.

When the estimate was presented to the client in a phone conference, there was a stunned silence and we listened carefully to hear the sound of a body hitting the floor as he fainted from the shock. We had expected this because we knew he didn’t have the budget for such a large project, so we had an alternate plan ready.

The new plan was to gradually rewrite the existing app, piece by piece, using an iterative approach. This would work with the size of team the client could afford and the client was all for it.

So we decided upon two month iterations and we began to gather the requirements for the first two iterations. The lists we got from the client were way too long and we started trying to cut back but so many requirements were “absolutely needed yesterday” that it got messy.

Then we started getting requests to handle bugs that existing users had that were cutting into our client’s business and causing threats to dump the software. The first month of Iteration one had passed and we’d done very little on it. I had one dev dedicated to it but the other dev and myself were totally tied up with the bug fixing. And more bugs kept getting added with a “Must Fix Yesterday” priority.

So I did an evaluation and came to the conclusion that what we needed was two lists of requirements, one that the client could manipulate to their hearts content and the other that could not be touched because we were working on it. Plus the iterations needed to be really short due to the speed of priority change.

If you are familiar with Scrum, then you’ll recognize what I described as a very simplified description of that methodology.

So, that is why I chose Scrum and luckily the other members of the team, the project manager and finally the client liked the idea too.

I am technical lead on a project that will be transitioning to Scrum and this blog is going to be chronicling that.  I’m writing the blog both for my benefit, because I find that writing up what is going on is helpful to me in learning the new methodology, and for the benefit of others in the software profession who may want to see how a Scrum implementation works or doesn’t.

I’ll be adding more as the project progresses.