Inside Out
Notes on seeking wisdom and crafting software

How we work

ℹ️ The text describes the principles, processes, and reflections of a new feature crew at work. The team focuses on guarding customer's interest, quality over shipping, smaller changes, unblocking others, data-driven decision making, experimentation, bi-weekly sprints, no standups, velocity as a metric, great engineering as an individual metric, planning and estimation processes, area path for fundamentals work, story points system, and scope simplification.

I had an opportunity to kick-off a new feature crew at work. This appeared to be the perfect time to reflect a bit on my learnings working across teams. We came up with a set of principles and processes for the new crew.

Sole objective is to grow this team into a self organizing and sustaining crew. From a charter aspect, this crew owns the core service primitives and experimental innovations.

In the spirit of learning, here’s the baseline for principles/processes reproduced verbatim (few org identifiable elements redacted).

Principles

  1. Our foremost priority is guarding customer’s interest. Fundamentals are at the core of the service and they affect how all application level experiences are perceived by the customer. We are the champs of non-functional quality aspects for the service (e.g. cost, reliability, latency etc.)

    • Quality is more important than shipping since a small mistake in core layer brings down the service or several features.
    • Smaller changes and experiments are preferred over big bangs.

  2. Our second priority is to unblock others. It includes participating in code, design reviews and hold the quality bar.

  3. We are extremely data driven and candid about asking for data to help decision making. At the same time, we understand the limitations of data and are not afraid to dive into unknowns.

  4. We embark on features only after defining the possible impact. Embrace experimentation to gather evidence on approaches.

Processes

  1. We run in bi-weekly sprints. Planning and retro are on last Fridays of the sprint.

  2. Planning/retro is the only meeting for the team. We don’t do standups.

  3. Your pull requests and collaborations are status updates. No additional work is expected to update Tasks or Backlog items.

  4. How we get better?

    • As a team, our single most important metric is velocity (= # of storypoints/sprint) Side note: velocity is a function of clarity of thought/vision
    • When in doubt, we simplify scope and ship early (= embrace experiments)
    • As individuals, our most important metric is great engineering (= code quality, design, decision making, agility and rigor)
    • Sprintly retro is the time we reflect on these and continuously make ourselves better

  5. How we plan?

    • Area path for the Fundamentals work =
    • New asks come in as Backlog Items or Bugs into this area path
    • We triage incoming items only during the Friday planning event. No hard interrupts
    • Priority of an item is purely based on the impact it generates (or a measure of IcMs/issues from past)

  6. How we estimate?

    • We use story points as a fake currency for complexity of a backlog item
    • 1 story point = amount of time taken to understand, code and test activity
    • Story points come in fibonacci sequence: 1, 2, 3, 5
    • Backlog items with > 5 points are broken into smaller items during planning
    • Planning is a team game - we use a variant of Planning Poker for estimation

Reflections

There are a few aspects which may appear contradictory. E.g. quality over shipping implies slow movement and decision paralysis; yet scope simplification and ship early is part of the process. Key distinction here is that often decision paralysis occurs when changes are widespread (= risk). Scope simplification forces us to isolate the risk to a few affected areas.

Second, holy cow, how can you recommend no standups? Allow me to puzzle you little a bit more :) I think standups are marketed to unblock people and keep everyone appraised of progress. Doesn’t pull requests and collaborations over email/chat also do the same? When the size of a team is small, why waste everyone’s flow by asking them to come to a room and say the things that are already known in the system?

I’m a huge fan of collaborative planning. It ensures everyone in the team has a stake on shipping the task. We all help each other stand up to the commitments and ship beautiful code.

Story points remain limited to 5 to also force us simplify and discourage big bangs.