How We Work

I thought readers might enjoy a window into how our development process has evolved. Running the overall development efficiently has always been one of the challenges at OSAF. Our first development manager, Michael Toy, decided he didn't like the commute to S.F. or the open source, non-profit genre as much as he liked another opportunity at a Silicon Valley VC-backed start-up, so he left last October. My experience as a start-up CEO on the one hand and software designer on the other left a gap when it came to development management. However, I was reluctant to bring in an outsider to run development who would sit between me and the staff, so I decided to plunge in hands-on and oversee development, which I did for about six months. I think it was useful and energizing, but it was not meant to be a long-term solution.

Recently I asked my direct reports to help redesign my job. Fortunately, no one wanted me to leave, but they did want me to be more of a leader and less of a hands-on manager. Not unreasonably, they also wanted more authority and autonomy, feeling that would be the fastest path to getting a product out the door, our mutual goal. I concurred. In future postings, I will have more to say about different aspects of this, but for now, I want to focus on development.

Thanks to Lisa Dusseault, we have put in a place a scaffolding for managing development tasks which is working better for us than anything we have done to do date. Thank you, Lisa! When we previously tried to re-purpose Bugzilla to this end, we found that while it worked well as a defect tracking system, it worked poorly for us as a project management tool. We have also been looking at the use of specialized project management tools, but none yet has been so compelling as to cause us to make a switch, though it is possible we will decide to do so at some point.

Our atomic scheduling interval is the milestone, which occurs every two weeks. For each milestone, each working group prepares a plan of what is to be accomplished. See, for example, the application group's plan and results for the 3.18 milestone , now just passed.

Every other Tuesday, I sit with representatives of the development working groups (Ted Leung for the repository, Lisa Dusseault for services, and Katie Capps Parlante for applications) and we review the actual results versus the plan. We apply a fairly strict definition of completeness. An item is done if its code is checked into the tree by milestone deadline; otherwise it is not done. The goal is learn how to make accurate forecasts of what can be accomplished in a two week period. That is, we want to reduce the variance between plan and actual as close to zero as is practical. If we can do this, it means we are in control of the development process, not it in control of us. Milestone releases happen by the clock. Features either make it into the milestone or they don't.

Our "molecular" scheduling interval is the point release. We define the overall goals for a point release at a high level. This is the job of Chao Lam, our Product Manager. For instance, the high-level goal for the 0.4 release, the one we are currently working on, is to be experimentally usable for a few key end-user tasks, and specifically to include the next revision of the basic Chandler user interface; detailed Views of Events, Contacts, Tasks and Notes (and possibly Email); elementary sharing of data with access controls, and basic queries and searching. For details, see the ZeroPointFourPlanning page.

Because we knew the interval between 0.3 and 0.4 was going to be longer than the normal three to four months, we added two "integration points" into the schedule, which are intended to be mini-releases. For details refer to the heading "Draft 0.4A/B Engineering Schedule" half-way down the ZeroPointFourPlanning page.

At the integration points we will see how close we are to our goals and can make decisions about deleting features from the 0.4 release or altering the schedule. While milestones happen by the clock, integration points and the release itself are done when we say they're done. In the ideal case, we never slip a scheduled a release and it has all the planned features as well as some of the "stretch goals". In the real world, a few things will go faster than planned but more things will tend to go slower. However, if we understand how to plan, and we are honest with ourselves in making the schedules, plan and reality will be roughly parallel, not in different universes. That's the goal. Finally, we leave some time at the end, designated at points called "feature freeze" and then "code freeze" to fix bugs and ensure the stability of the release. All pretty standard.

If all goes well, and at this point I am cautiously optimistic, we are on track to deliver a 0.4 release in the fall which meets in main goals. Last week we had the first conversation about goals for its successor, the 0.5 release. There was agreement around the table that at a minimum it needs to be a release we can use internally for the calendar and that anyone else who is a bleeding edge early adopter can do so as well.

In a future posting, I'll write about how we expect to move through a series of point release to a 1.0 product.

Posted by mitch@osafoundation.org at June 20, 2004 01:12 PM