How we organize our software development process
By: Tommy Dangerous
Tags: Startup, Product Development, Development, Engineering, Teamwork

At OnMyBlock (our previous startup) and at Airbnb, we used Scrum (with a few tweaks) as our software development process.

Every 2 weeks, our team would get together to review all the work that was done in the previous sprint (a time-boxed window usually 2–4 weeks long) and then plan for the upcoming sprint. This meeting is typically called sprint review and sprint planning.

Here is how we conducted the sprint review and planning:

Before the meeting, the scrum master (a single person responsible for project managing the stories during a sprint) would ping everyone to make sure they updated all their stories (aka tasks) in our project management software. At the start of the meeting, each person goes around and shares what they shipped, what work they couldn’t finish, and explain why they couldn’t accomplish the unfinished work. Then, the scrum master leads the team in discussion on which upcoming epics (aka features) are most urgent and important Everyone independently plans what they will deliver by the end of the next sprint, choosing from a list of prioritized epics. Each person is allotted a fixed number of story points. If you are allotted 13 story points (we used Fibonacci numbers to scale our story points), you can only commit to stories that have a total sum of 13 story points. Story points are values assigned to a story (aka tasks) that attempt to provide a sense of how difficult it will be to accomplish that story. After everyone is done planning, each person goes around and shares what they are committing to delivering in the upcoming sprint.

Sprint schedule

There are usually “stand-ups” in Scrum, which are short daily meetings for the team to update each other. Our team felt daily stand-ups were too frequent and unproductive so we cut it down to 3 per week except we have 2 per week on the weeks where we have sprint review and planning. Our stand-ups follow the typical agenda where each person goes around and shares what they did yesterday, what they are working on today, and if they have any blockers to their current story (aka task).

Pros of how we did Scrum

Engineers had more ownership of the features they were responsible for and this resulted in better performance reviews because we were assessed on which projects we led and delivered end-to-end.

There was clear accountability because if someone commits to work that they didn’t finish, they would be responsible for explaining why they couldn’t finish it by the deadline.

Less knowledge was required to accomplish tasks because an engineer can fill up their sprint with tasks that were related to their area of expertise; such as backend, frontend, data, ML, different services, specific languages, etc.

Cons of how we did Scrum

Estimating the difficulty of stories was rarely accurate, which led to frequent over estimating and underestimating of the work.

When we pre-assign ourselves stories, we typically chose stories that belonged to an epic we were responsible for. Many of us ended up working in silos, which decreased collaboration during the implementation phase of projects (we had a lot of collaboration during the design phase).

Entire features shipped slower because the concentration of effort was spread out across multiple epics at once.

It was difficult for our team to quickly adapt and change course mid sprint since we planned 2 weeks in advance.

The process today

At our current company, Mage (AI application development tool), we use a hybrid of Scrum and Kanban with a few tweaks. The tool we use to manage this is called Airtable.

Once a week, we hold a meeting called “Mage Force” where we review all the features we shipped last week and then prioritize the features we need to deliver in the upcoming release. Before we start the meeting, we hold a trust activity where the goal is to build trust amongst ourselves and to build each other up (one of our core virtues of “give people power-ups”). In contrast to having a 2 week sprint, we have 1 week release cycles where we ship as much product as possible that our customers need.

Magic

Here is how we plan our release cycle: