The Joy of Shipping

This post was first published in The Evolving Analyst, a collection of writing on business analysis compiled by Marcus Udokang and Emal Bariali. Marcus and I discuss The Joy of Shipping on his podcast, The Inquisitive Analyst, which you can watch on YouTube.

Epigraph

“At Microsoft, there was no peer pressure to do anything except work and ship on time. If you did, you got a Ship-it Award. Easy. Black and White.” - Douglas Coupland, from his novel Microserfs

I can remember, as a teenager, seeing a Microsoft “Ship-It” award sitting on a bookshelf in my aunt’s home office - which was recognition for her contribution to shipping an early version of Microsoft Mail on time. I didn’t know then that getting product into customer hands would become a fixture of what I do.

What is shipping product?

For me, this has been delivering software, over the web, to financial institutions or their customers. I imagine the practices for this type of work differs from the work of building physical widgets or other types of projects, but I’m sure the “Joy of Shipping” is similar. I get a great deal of satisfaction from seeing my work have an impact, and this can’t be realized until it is put into the hands of users.

Shipping software is not the end, it’s just a new beginning. Once the software has shipped, there are operational activities: maintenance, fixes, and support. Finally, there’s a sunset: decommissioning the software, a significant project of its own, often a migration to a new and shiny replacement, and the cycle begins anew.

For most of my career, my role has been focussed on the shipping activity: get a set of functionality available to users on a timeline, while balancing other activities in the same code base, using the same resources. A timeline has been set, typically embedded in a contract with another external party. Failing to meet that timeline can result in lost revenue, penalties, or loss of reputation, which will impact the ability to attract future business.

I love working on these kinds of projects, as they force pragmatic decisions, and stretch my analysis muscles:

• What is possible?
• How can we solve this with the resources available?
• What is the best way to play this hand of cards I have been dealt?

How to play your best possible hand

Here is your hand: you have set resources, third party audits to satisfy, inefficiencies you need to tackle, dependencies to keep current, multiple stakeholders to satisfy, a roadmap to progress. How do you ship a release of your product?

Align priorities

It is important to align all stakeholders as best as possible. Of primary importance is allocating resources. Ensure that the leadership team understands where resources are being allocated, and bring visibility to work that might be hidden, like platform currency. There is almost always more work that the organization wants to get done than resources available, and difficult decisions need to be made to decide what gets done. Risks may be taken - perhaps a dependency upgrade will be deferred to past its end of life, with a developer allocated to work on a new feature instead. It is important that these risks are informed risks.

It’s also important to align priorities when planning work on a common code base. Having two teams work on two features when they are working on different parts of the codebase is fairly straightforward. For example, it’s probably acceptable to have one team working on updating the customer onboarding flow and another team updating the administrative interface. However, having one team working on upsell/downsell functionality and another team changing the payment processor used for billing could be challenging, as the former will need a stable interface for pre-authorizing payments and partial refunds.

As you plan your product road map, work with someone familiar with your codebase to minimize conflicts. If there is one team working on a time-driven deliverable, ensure other teams are aware that they should not be merging in potentially breaking code - explore options like “feature flags” which developers can leverage to deactivate incomplete functionality, allowing the time-driven deliverables to ship without blocking the development of other features.

Communicate context

When working with the project team, I always ensure that in addition to providing requirements and defining the work, I always provide context, and I ensure that everyone understands why we’re doing the work. Understanding context gives meaning to the work that might not be apparent in the requirements.

A developer might not have visibility to how customers use the product, or the costs of the services consumed by the product. What might seem like boring rework and a waste of time might be a part of a larger strategic goal, or result in a significant cost savings. Developers might question why they would spend two weeks reworking a push data feed into an on-demand data pull. It already works. Why spend the effort? Sharing that it is expected to save the organization a million dollars illustrates how it supports the company’s goals and gives the work meaning. Everyone works better when we see purpose in what we do.

A second reason for providing context is that an individual contributor is often the subject matter expert of the subsystem. If the contributor understands the “why”, with underlying knowledge, the contributor may be able to provide a better solution to the problem the business is trying to solve.

Communicate milestones

Ensure everyone on the team is aware of the target ship dates and the milestones required to meet the dates. These dates should be visible to everyone, easily accessible, regularly communicated on stand-ups, and printed on the walls of shared workspaces.

Ship often

It is easier to deliver small blocks of work often, than large blocks of work infrequently.

• It is easier to assess the impact of small changes.
• It is easier to test small changes.

Delivering smaller releases often leads to better release processes through practice and process improvement. Teams should strive toward automating deployments, to the point where one click gets the code you want to deploy to a target environment. Automated processes are much less error prone, save so much time problem solving missing or forgotten steps, and keep test environments consistent and closer to production.

When not to ship?

There are times when the gap between expectations and what is possible is so vast that no amount of cleverness, last minute insight, or quick post-release fixes can address. A go/no-go call is scheduled. Information is shared between stakeholders. A picture is painted, but it’s often incomplete, and a judgement call must be made. We must balance the potential consequences of proceeding with something imperfect against the penalties of missing a ship date.

With experience, I am better at making these decisions. At the beginning of my career, I made “go” calls to meet a project date with a goal of meeting the set expectation, only to realize, from the negative feedback on the second business day, that there are more important expectations than meeting a target date. I have become more conservative over time.

Consider shipping something imperfect when:

• Rolling back is well understood
• Gaps can be addressed with alternate processes (such as additional support, documentation, and short term manual processes)
• Defects can be addressed quickly
• Making an attempt to ship will fill knowledge gaps helpful in a future delivery attempt
• It makes sense to deliver partial functionality, and follow up with the balance later

Consider delaying shipment when:

• The target date was arbitrary, with limited negative consequence
• Rolling back is not possible, high impact, or poorly understood
• The product supports a business function, and a flaw would impact its ability to deliver its services
• A flaw could result in significant additional work, further delaying delivery
• A flaw could result in refunds, expensive penalties, unmet SLAs, or legal action

When making these considerations, it is important to note that a flaw can be more than a coding defect. System slowness or a lengthy new process flow delivered to a business function could prevent service levels from being met.

Ship-it!

Align resources and your road map with leadership priorities. Ensure everyone on the team knows upcoming milestones and speak to the “why” behind “what” is being built. Lean toward shipping something good now, over something better later, and get your product shipped!

* The Ship-It image above was enhanced by Gemini. The traditionally edited original is: Microsoft-ShipItAward.jpg