Executing in Software Startups
Delivering convincing results with constrained resources is a challenge. I have used a mix of different methodologies and techniques like Scrum and Kanban and it looks like the general setup works for others as well. Below, I have used Asana to illustrate the approach.
Given you have prepared a roadmap, highlighting important deadlines and priorities, you should have all the necessary prerequisites in place. For a startup, a week is a fairly long timeframe for iterations, and a lot can change while enough can be delivered. Choosing a week for iteration length with a small team of up to 12 people is a good default. Given a capable team, retrospectives and demos can be easily done monthly.
Planning a week is a joint effort and for a successful weekly meeting, everyone should mark the last week tasks either as done or move uncompleted tasks to the new week before prioritization happens. The tasks are initially prioritized by the product owner while others make recommendations. As the team matures and gets engaged, the prioritization becomes a bit more of a team effort than a one man show.
For prioritization there are essentially four buckets of tasks: Upcoming Week, the Week After, General Backlog and Icebox. The weekly buckets do what the title says, the General Backlog is for all the tasks that need to be delivered at some point in time. The Icebox serves the purpose of cleaning up the Backlog from items that will not get the attention of the team anytime soon.
Usually there is also a need for projects to deliver something specific. The tasks in projects get assigned also to the correct bucket so that the product owner and project owner can both keep track of the progress. In this approach, projects exist mainly for monitoring purposes.
During backlog grooming the product owner chooses the most important tasks from the buckets and assigns to the most likely team member for fulfilling them successfully. Estimation of the task is done by the assignee and occasionally reassignment is necessary. In estimation, introduce a rule that any task with larger estimate than 8h should be broken down into subtasks.
During a weekly meeting everyone summarizes what was done and gives an overview of the plans. The others give feedback on estimates, priorities and dependencies. These can usually be resolved during the meeting. 5–10min per person is realistic with good preparation.
Bugfixes and minor changes happen. These are aggregated into larger tasks that get allocated a time budget for the week. The team is also responsible for tracking operational changes in tasks so that the past remains a correct reflection of what was done. This will be useful when doing throughput analysis and roadmap planning.
Architecture design spikes, timeboxed open-ended research follow essentially the same approach as described above. As the time runs up, what was learned is listed either as new tasks or summarized into the existing task. Many companies have found that oscillating between the new and improvements between iterations is a good practice.
This general approach can be tweaked to suit you particular purpose, but should serve as a good baseline for building a high-performing team in your company. The approach should take about 5–7% of your team’s time once you have settled with the details.
