Inter-release scheduling

It takes a special person to lead a start up team. They must enjoy challenges that others may find just too frustrating for words. But it is in this daily 'point - counter point' that the true start up manager thrives. A good example of this theme is what all engineering teams face in the beginning: many high-priority feature requests and a skeleton crew of resources to implement them. Lets call this resource constraint.

Resource constraint is dealt with in many different ways. One way that can be effective is to create a hybrid development model that leverages less expensive off-shore developers to supplement your local team. I plan to talk more about this model in another note, but for now I want to focus on how to make sense of multiple development efforts being run concurrently.

Because a startup is aggressively seeking to become a self-sustainable entity, any sale is treated with the highest level of criticality. So as we methodically move forward, implementing our vision of the perfect software product, we are bombarded with requests from potential sales. To an outsider, the view of the functionality in development may seem disjointed, but we all know that these pieces must be built in quickly to generate sales. On the other hand, we have a team of developers with a variety of skills. You'll see that it really becomes a puzzle of organizing projects based on when the right resource will be available versus architectural priority (i.e. this functionality must be built in to allow that functionality).

I have found one way to achieve a smoothly running team in such an environment is to create inter-release schedules. What I mean by this is schedules that are based on functionality rather than a specific deliverable. First, break the plan up by functional requirement (imagine all of the tasks for Outlook Integration v1 grouped together, then a blank line, and then the tasks for Next Phase of Reporting). Maybe Outlook Integration will be in the next release, but Reporting is not, but having it on the schedule will allow for always making the best use of your resources time. For instance if Dev A completes a task and cannot move onto the next task in that functional area until Dev B completes some supporting tasks, then you can move them onto their part of feature development elsewhere.

I think that you can see that there is a lot more finesse to this than I am able to go into here, but there are a few of you that see the fun. To those readers (that see the fun) I want to say: realize that others see this as a frustrating chore while you see a chess game. Obviously you have to have a well thought out branching scheme in source control. You must know your developers strengths. Also you have to have built a bonded team that respects you and will take direction. Finally you must balance resource reallocation so that it does not become overly tiresome on your team. There is more, but you get the idea.

Cheers,

Brian