How we organize our software development process

According to

, “a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management”.

A good process helps your team be more effective in delivering value to customers by empowering your team to be autonomous (make decisions on their own), collaborative (sum is greater than the parts), and adaptive (ship relevant products that customers need).

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:

1. 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.

2. 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.

3. Then, the scrum master leads the team in discussion on which upcoming epics (aka features) are most urgent and important

4. 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.

5. After everyone is done planning, each person goes around and shares what they are committing to delivering in the upcoming sprint.

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).

• 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.

• 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.

At our current company,

(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

.

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.

Here is how we plan our release cycle:

• We make sure that every epic (aka features) are attributed to a key result or a specific customer use case. That way, we are making sure to deliver as much value to our customers as possible.

• ⁠Each epic is given a deadline ship date that corresponds to when a customer will use it.

• Each epic is broken down into stories (aka tasks), which can be worked on in parallel.

• The order in which stories are worked on is based on the related epic’s deadline and whether or not there are downstream dependent stories

• A story in the same epic with a lower priority means it depends on another story within the same epic to be completed first

• Each person who creates a story during planning will fill in as much detail in the notes to give any future engineer context on why the story exists, the requirements of the story, and any additional knowledge that will be helpful in completing the story.

• When we decide which epic must be shipped for the next release, we change all the stories for that epic to “Not started”; which will then make it appear on our Kanban board.

• Stories are not pre-assigned. When someone has no stories “In progress”, they will take the highest priority story that has “Not started”, move it to “In progress”, and assign it to themselves.

• Each story moves through the following stages on the Kanban board: Not started, In progress, Review (e.g. review pull request), QA (merged into master and need to manually test on staging), Complete (new change is on production).

• Once a story is finished, the DRI (directly responsible individual) moves it to “Review”, creates a pull request on GitHub, and associates it to the story for someone else to review.

• Once the code is reviewed, approved, and merged into the master branch, the DRI moves the story to “QA” where they must now manually test their changes on the staging environment.

• After the new changes are verified on staging, the DRI deploys the code to production and moves the story to “Complete”.

We have stand-ups (daily meetings in Scrum) 4 times a week, skipping the day we have “Mage Force”. Our stand-up meetings are called “Mission Briefings”. Each person goes around and shares what they learned yesterday and what their plan of attack is for crushing their story today. With this format, we maximize learnings (one of our core virtues of “always be leveling up”) instead of simply reporting tasks (which can be done by looking at the Kanban board).

• There is a lot more collaboration at the implementation phase because people are able to work on the same epic together at the same time.

• Working closer together is more fun and exciting, leading to higher team morale and solidarity.

• We ship new features on a daily basis, helping us make customers happier and win more new business.

• Everyone works across multiple codebases and is responsible for many areas of the product. This increases the speed in which we ship new features because everyone is capable of working across the entire tech stack, unblocking themselves if needed.

• We are able to adapt rapidly and change our focus as customer needs change or more urgent features arise unexpectedly.

• Because stories are not pre-assigned, individuals on the team are required to understand multiple code bases and technologies in order to effectively complete stories.

• There is less accountability at the individual level because each person is not committing to being responsible for delivering a set of stories. Instead, the entire team is committing to the work. If something doesn’t get done, who is responsible? We have yet to solve for this.

• Since everyone on the team works together to ship as much customer value as fast as possible, there can be a lack of “ownership” of projects. At Airbnb, engineers were awarded for having ownership of projects and therefore ownership of projects was desired by individuals. The system in place rewarded that desire and behavior.

Structure your software development process to maximize your team’s autonomy (make decisions on their own), collaboration (sum is greater than the parts), and adaptability (ship relevant products that customers need).

A hybrid of Scrum and Kanban, with a few tweaks, works great for Mage at this stage because we are prioritizing speed and focus through deeper collaboration.

As we grow and evolve our process, we need to keep in mind how we deal with individual “ownership” of projects and the increasing need for specialization.