Engineering Playbook

i.e How we code quality software and build our products to last?

Overview

A Frontend Engineer (FE) and a Backend Engineer (BE) are paired to work on the implementation of a single easy product. Since our products usually have far more frontend efforts, the BE is given the task to manage the overall delivery of the product features. Interestingly, in our engineering playbook, the Product Manager (PM) does not play any significant role. This was a lesson/modification that we had to make to achieve robustness in our engineering process.

Prerequisites

The PM details the various features and the user stories along with high fidelity mocks and acceptance criteria prior to the product entering engineering. We have experimented with the PM providing a small set of details, but they all pretty much failed. Here is what the PM’s deliverables provide.

  • Features – This provides clarity in terms of priority of the product features.
  • User Story/Acceptance Criteria – Each feature is explained via User stories and Acceptance Criteria. A typical user story has about 5 acceptance criteria checks. More than 5 is usually a signal to further break the user story. Writing Acceptance Criteria are surprisingly good opportunities to simplify the product feature as it forces the writer to understand what the eventual user would have to go through to accomplish his goal.
  • High fidelity mockup – Planning to manage with low fidelity mockups is a sure shot opportunity to realise engineers need high fidelity mocks. Why? We don’t want the engineers to second guess the visual details. This lesson is something we learnt a bit late.
  • Strangely, the success of the engineering team is really not in their hands. It’s in the PM’s hands. When a PM does a great job in detailing and communicating the product features, the engineering team can easily recover from their mediocrity (if any) but this does not work vice versa.
  •  

Details

  1. We neither do Sprints nor Kanban. We’ve converged on a process that’s a bit of a marriage between the two. We call it Feature Design. We’ve invented (or cooked up) Feature Design as we primarily thought in terms of Product features and how they should be designed. So what exactly is Feature Design? It’s a process of implementing a product feature where priority is given to get the abstract engineering design right. Once this milestone is achieved, the actual implementation becomes a straightforward and sometimes boring work. This is what happens in a Feature Design Cycle.
  2. Day 1 Morning Session
    • 11:00 AM – 1:00 PM – 3 people ( 2 engineers and 1 PM ) meet and the BE leads the overall process. The BE (not the PM) presents the feature to be delivered to the team by going through the Product feature’s use cases and acceptance criteria. The PM is only consulted when there are gaps in the details – these usually end up being minor details. At the end of the presentation, confidence is established between the 3 people that they are aligned on what needs to be accomplished.
    • BE creates a JIRA(or equivalent) Epic and adds the deliverables that need to be delivered by the next day as part of Feature Design. These include the following tasks
      • Backend Modelling – Domain model the feature in question.
      • Behavior specification for backend models. (We follow BDD)
      • Backend API Design – What API endpoints need to be developed?
      • Frontend Component Skeleton – What are the web components that need to be developed or utilized?
      • Mock Server – Develop a mock server with sample responses based on the backend API.
      • Dependencies – Identify the dependencies for the feature deliverable.
      • Market Date – Identify the date the product feature is shipped to production so that external users can use the feature.
      • Product Blessing – Our PMs are technical PMs and so we require the engineering team to get their design approved by the PM.
    • BE creates User Story tickets under the Feature Epic.
  3. Day 1 Afternoon Session – The afternoon session will start with each individual going into their own space and focussing on completing the Feature Design tasks mentioned above.
    • The PM would have received some feedback and will be incorporating those changes in the mockups, user story and acceptance criteria descriptions.
    • The FE will be working on his tasks – Frontend Component Skeleton and syncs with the PM for any minor clarifications.
    • The BE focuses on accomplishing the following tasks in the following order
      • By 3:00 PM – Write down the domain models in a google doc. Get blessing from the PM.
      • By 4:00 PM – Write down the backend APIs in the google doc and get blessings from the PM and FE.
      • By EOD – BE completes the implementation of the mock server using mirage.js and gets confirmation from the FE.
    • Now the FE is no longer dependent on the backend systems to make his progress. If there are any minor changes that need to be made, the FE takes the liberty of making those changes and intimate the BE on Slack.
  4. Day 2 Morning Session – 11:00 AM to 1:00 PM
    • BE works on the behavior specs and gets the PM sign off on the specifications.
    • FE would have figured out the hierarchy of web components and would potentially start implementation since the mock server is available.
  5. Day 2 Afternoon Session – From 2:00 PM
    • BE + FE would add breakdown tasks for each User Story ticket in JIRA.
    • BE + FE give a Market date on the entire feature. The market date is given based on the user story breakdown, the availability of the team and by adding some buffers. But the date is sacred.
  6. From Day 3
    • BE becomes the scrum master for the Product feature and manages the usual sprint rituals such as standups, etc…
    • Everyone is expected to post their updates on slack by EOD. By doing this, way before scrum time, we will know the issues without the actual person conveying in standup.
    • FE and BE use the Frontend development playbook and Backend development playbook respectively to code.

What we love about our Engineering Playbook?

  1. The feature is built before the feature is built – theoretically. By the end of Day 2, the engineers and the PM visualize how the product would be built. Actual building and delivery just becomes operational.
  2. FE does not depend on BE – One of the goals of our playbook is to decouple the FE and BE. By the end of Day 2, both of them have enough clarity and an agreed upon contract to work independently.

Drawbacks of our Engineering Playbook?

Fixed velocity of delivery of a product. – We’ve taken a call to only involve two engineers for a given product. This opinion came from the experience of involving multiple engineers on the same product and this experience led to frequent context switching for the engineers. Instead of parallelizing work within the same product, we parallelize the development of multiple products.

Related Pages

POC Playbook – How we try out new ideas before building products?

Back to Playbooks