The Background
As many of you know I'm working on a new project, shortBet, which is an MMO credibility engine (still working out exactly what that means, but it sure does sound cool). With my partner on the project, Jamie, we've gradually shaped many of the architecture and design choices.
The project has been moving forward quite nicely in the current nascent stages. One of the conclusions we both agreed upon without much discussion was use of agile development methods. These methods have served us well in our day jobs so it seemed natural to put them to work for us on the construction of shortBet.
The Issue
Writing actual application code is imminent.
Well the time has come, and I'm sitting down as the customer to put in some stories for the first iteration. We've found an excellent (but closed source) free resource, Community Edition of the Rally Software Development. The Community Edition has essentially every feature any small team would need to implement planning with agile methods. However, before I go down the path of using Rally planning, I wanted to think aloud about the matter.
I'm coming to some stark realizations about the limitations of agile methods in our circumstances as this project moves forward. First off, let me stipulate that I think agile methods are great. I think planning software tools are essential for these methods. I think that Rally is very suitable planning software tool. However, I'm concerned that agile methods - specifically the planning methods - will fail us because:
- we don't have a genuine customer
- we don't have a genuine project manager
- we don't have genuine quality control testers
- we have an ultra small team of developers (and part-timers at that!)
- there is no genuine external pressure of time
- there is no genuine external pressure of money
Will the both of us switching customer, project manager, developer, investor and tester hats be feasible to pull off implementing the agile methods? The agile methods, in my mind, are about bringing these sorts of genuine people in a process cohesively, managing each roles' inherit point of view on a project's successful progression. Using the agile methods to artificially distill these roles out of a small (part-time) team doesn't seem philosophically sound.
Agile methods for planning do have a certain amount of bureaucratic overhead that though valuable and essential for the sanity of most development projects, may prove to be too costly to the limited resources involved in the project. What I fear is putting time towards making the agile methods work as if they were the ends and not the means.
The Alternatives
What I want to do, when I finally actually sit down to write the stories is just this:
- Write a sentence or two on what feature I want to see
- Assign it to a one of us
I don't really care what order the stories get done at this point and for the foreseeable future. I specifically don't care about estimates at this time. With our herky-jerky schedules, estimates no matter how accurate really have no meaning when the available pool of developer time to throw at stories is forever unknown.
Also, while the story is being worked by the developer, I want the planning software to be a centralized and historical place to document
- what aspects of the Entity Framework and MVC were used and modified to fulfill the story, or
- why the story will not be done, or
- reassigning to another developer
The question I'm flat out asking myself right now is this: Is the Google Code Issues interface a suitable alternative for a small part-time team than the full blown Rally planning interface for our team's needs? It's a limited interface, but is that limited nature a good thing?
