Shipping to production faster (?)

Earlier this week I facilitated an impromptu “unconference” session at my team’s offsite: Shipping to production faster: can we? should we? how?!?.

Why?

I wanted to discuss this topic because I felt we could be shipping at a quicker cadence and the benefits of processes we could use to ship faster are self-evident and worth the effort:

• reduce complexity: smaller, more manageable chunks of work that are easier to reason about
• iterative: get features in front of users quicker to get early feedback, and adjust based on real-world usage, rather than what we imagine users want
• developer satisfaction: team and engineers see impact quicker rather than waiting a long time for deployment and roll out

Reality

What I realized in facilitating the discussion is that 1) my assumptions about what “shipping to production faster” means are not necessarily correct nor shared across the team and 2) shipping faster as a goal is counter-balanced by some equally, if not more important, goals for the team.¹

Process

For each discussion question, I asked participants to find a place along a wall in the room, with two corners indicating the ends of a spectrum. My questions were:

• what’s your satisfaction with the status quo?
• how important is this topic to you?
• what is your tolerance for risk and production errors?
• are we multi-tasking too much between different projects?

For each question, participants on either side of the spectrum as well as in the middle gave their perspectives. I found it to be a useful way for us to see who stands where on an issue as well as see that in some cases perhaps we are not so far apart.

One interesting take-away for me (perhaps self-evident to others) is that there was overall satisfaction with the status quo and generally a lower level of tolerance for risk and breakages.

Another point that was interesting: when a production error occurs, engineers see the technical side of it, e.g. widget X broke with error Y, this was the number of errors, that is the code that caused the breakage, here’s the patch to fix it, etc. But as our community relations specialist observed: there is a high social cost to these breakages; it requires diplomacy and explanation to justify to a community why we have broken something, and if you do not manage this well or continue to break things often, you eventually lose their trust.

Action items

Towards the end of the session, we split up into groups focused loosely on “engineering”, “design / product / data”, and “team practices” to come up with action items that we could take based on the previous discussion, then voted on these items as a group to further narrow down what we could focus on next. Based on that, it looks like there’s interest to:

• take periodic breaks from new features and address technical debt and maintenance issues
• clarify context by defining impact and effort level for all tasks
• start our day with code reviews and responding to pings in our bug tracker

Summary

While I expected the team to want to push for shipping more, faster, with higher tolerance for risk, we collectively focused on reducing errors, proactively addressing maintenance, and simplifying contexts to tone down multi-tasking.

tl;dr talk to your team so you know how people feel and what matters to them.