Release Date

Finally, a date is set. Motivation is difficult if you feel you're putting your work into a black hole, paddling up stream, etc. That's true of any project under any methodology. Release date problems come in two forms: Setting an overly aggressive/arbitrarily early date, or failing to set a shipment date at all. We were in the latter category. Most projects I've worked fall into the former, however. But it's not quite that simple.

The optimal release date for a project is not so much a line as a large, grey band, fading from red (too early) to black (too late). As you approach any given date, the likelyhood of that date being the correct date becomes more focused. A wise project manager will defer giving dates as long as possible, and give them with great qualification. The doesn't help the business owner who needs predictability for sales and training. This is all old news, so far.

Our real question at this moment is "How is Agility helping me set and ship on my release date?". Well, for us it is allowing us to view how many features are done (ready to go with product) and how many features are outstanding. We can limit the variability in our estimates because we constrain future estimates to what remains, no some ambiguous shot in the dark. So we have set an arbitrary ship date. With our project backlog we can see most importantly what is not going to be ready by date X. Knowing that, we are able to work with the business owner to determine if this is acceptable functionality, or a date needs to be pushed.

In our specific case we have not been able to fully integrate QA, so we are requiring a trailing QA cycle (as under SDLC) to finalize the product for this realease.

Staffing Issues

Two staffing adjustments have occurred: our best developer (other than myself) has moved on to join the Empire, and our ineffectual test resource has been pushed out. Best wishes to the former, good riddance to the later.

Now how has agility helped helped us cope with these changes? First our dev guy. Since we are using an iterative approach, the bulk of his previous tasks/responsibilites are in a state of completion and required little hand-off. Additionally, the iterative approach didn't have him pre-committed to longer term projects and goals, leaving little to hand off. The only knowledge transfer was for current-cycle work and what little historical information might be gleaned. Since we're practising continuous integration, there is no fear that code he was working on would be lost - it's already integrated in the product, source control and build automation scripts.

On the test guy, we're actually better off. Not that he was a bad guy, just unable to function in a "pull" environment. By that I mean he required someone to tell him what to do at every stage (push tasks down). Agility is a pull environment requiring all parties to understand what needs to be done at a high level and take appropriate steps to insure they are able to complete the tasks they committed to. Not very friendly to junior people, which is where pairing comes in. He was not junior, tho, so that is no excuse. At the end of the day it is now clear that we have no test resource currently - and visibility is always good.