So why did we decide to go with Scrum? The simple answer is “constant change.”
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.
