Changing Process While Moving To Shipping Phase

I oftentimes talk about projects existing in three phases: meetings phase (defining the scope), building phase (building it) and shipping phase (converging and flipping the thing on). Transitioning between these phases is always a little chunky for different reasons. Recently I've noticed that I do a set of consistent things when moving between building phase and shipping phase. These generally feel right, so I'm probably codifying them.

The three things you should do when moving into shipping phase on a large project are:

• Make a dashboard that counts the number of tickets required to launch your first user-visible deliverable. While you're in building phase it can be easy to lose sight of exactly how much work is remaining in order to get software into the hands of users. By making a dashboard with all outstanding tickets you can give yourself a very clear velocity + progress tracker on "how far are we from shipping". "Number of tickets closed per week" is a pretty coarse metric, but it's often good enough to set more accurate estimates.
• Setup regular bug-bashes. During building phase it can be easy to build a bunch of pieces but not have confidence that they actually deliver a coherent experience for users. To combat this, I'll setup weekly bug bashes for the whole team to test features end to end. This helps people get a really visceral feel for "where's the system at end-to-end" rather than just "is my feature working". It also encourages you to find rough edges in test setup and rollout which can help smooth out your actual launch.
• Ensure that each part of the system has an end-to-end owner. In building phase it can be easy to think "horizontally" through the system and make sure each component works. Oftentimes as you enter into shipping phase you need to start thinking about the system end-to-end. In this world it can be valuable to start to have people owning complete slices of features if they don't already.
• Write up the actual plan to test and rollout your software. Similar to the bug bashe point, it can often be easy to miss "is it possible to rollout this thing as a single unit". You'll want to write down a rollout plan to ensure this is possible.

Doing these things doesn't always ensure that the process of shipping goes smoothly, but I've found that they generally help. So next time you're entering shipping phase, consider keeping a couple in your back pocket to ensure you launch successfully.

Discussion, links, and tweets

Hey! Thanks for reading! If you like what you read and want more, you can follow me on Twitter.

Tweet Follow @maltzj