Monday, January 25, 2010

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

Wednesday, January 6, 2010

The Fast & The Furious: Process

The enjoyment that I have found in effecting turn-arounds in both operational and development environments comes from bringing order to chaos.  I think it is fun to take charge of something that is broken and fix it.   It's about the love of putting things in order (or is it the "need" to put things in order?).  This usually takes the form of establishing new and efficient processes, documenting them and then training personnel in their use.  There is a lot of work that goes into the last sentence (things I didn't even hint at), but as I said it can be a lot of fun and extremely rewarding. 

Working a start-up company can present some of the same challenges and opportunities for "fun", but there are also some key differences.  With no established procedures to work with, there is a clean slate  on which to make your informed sensible decisions.  There are no bad habits to break or mysteries to be solved, it is all about understanding the goals of this new venture and then customizing a successful template that you feel best suits the situation at hand.  So again we find "establishing new and efficient processes, documenting them and then training personnel on their use". 

One difference in crafting a turn-around at an established company and manning a start-up is the post implementation of your plan.  For a turn-around the win is not only to bring the environment to a pre-defined level of achievement, but to implement a continuous improvement plan based on metrics.  The procedures that were put into place need to be made up of measurable tasks  which provide the metrics necessary for ongoing improvement.  This is the hard part - the constant monitoring of the machine and then making the minute adjustments that increase efficiency.  In a start-up this task is 100 times more difficult.

The best laid plans of mice and men, right?  The ground is never too firm at a start-up, there are just too many variables.  What I call "infrastructure processes" are established, providing the stability necessary for the team to move forward.  Over time however factors such as the economy, new technology, governmental policy, and input from investors will have an effect on a company's goals and therefore the processes.  This effect is amplified for a start-up.  Flexibility must be king if the organization is to adapt.  This is a different kind of fun. 

In a start-up the ground may quake beneath your feet much more frequently and with more volatility.  It may not be enough to make minute changes - the whole play book can suddenly be called into question.  In conceiving an initial plan, the leader's job is to not only assess the new venture's goals and vision but to then weigh the risk factors that may adversely effect their efforts.  For instance, what is the probability that a key governmental policy that is critical to the business will change?  With this decision analysis having been done, the best plan for the organization can be established.  However, a prudent leader will then staff the new enterprise with energetic and flexible personnel that can weather the exciting and challenging tasks in this fast and furious environment.

~Brian
http://brianleblanc.net