One of the pillars of our book the Zombie Scrum Survival Guide, and the Scrum framework itself, is “Ship It Fast”. Shipping fast is important because it allows your team to learn what your stakeholders need and reduce the risks of creating the wrong things. While shipping fast doesn’t guarantee success, it is your best survival strategy when faced with complex work.
But for something that seems so obvious, people often have wildly different ideas about what “shipping fast” looks like in practice. A team may believe they’re “shipping fast” because they’re deploying every day to a test environment, but not actually to production. In other cases, teams may feel they’re shipping fast because they’ve delivered a visual design, a test plan, and done some meetings. And what is “fast”, actually? For some organizations, shipping something every month is already fast, for others, that would be extremely slow.
“For something that seems so obvious, people often have wildly different ideas about what “shipping fast” looks like in practice.”
So it’s always important to get clear on when you’re actually “Shipping Fast”, and when you’re doing something that may look like it, but isn’t. Last week, we organized a meetup for The Liberators Network in which we explored this topic together. We also designed a do-it-yourself workshop to help you start a conversation with your team, management, or stakeholders about “shipping fast”, and what benefits it holds when it’s done right.
This blog post describes the flow, structure, and outcome of the workshop. We’ll share the key takeaways and patterns that emerged from the conversations the ±50 participants had. What is the common perception of what “ship it fast” means? What seems to be important? And what are ideas to improve the situation? You’ll find plenty of inspiration in this article!
“Ship it fast” is the third meetup we organize together with 11 other local user groups around the world.
What Does “Ship It Fast” Mean?
“ Ship it fast” sounds nice, but can easily be interpreted in completely different ways. Different interpretations can lead to misunderstanding, confusion, and even self-congratulatory beliefs that aren’t actually deserved.
Maybe a Scrum team goes into a Sprint Review highly enthusiastic because after 3 Sprints they finally released an updated API to the staging environment. They never expected to ship this fast! During the review, the stakeholders express their disappointment. For them, ‘shipping’ always meant a release to production, ‘it’ was a new feature, and ‘fast’ was at least once per Sprint. Now, we don’t want to imply the Scrum team is wrong and the stakeholders are right. We do want to point out, that it’s tricky to assume everyone has the same understanding about ‘ship it fast’.
So, to get everyone’s thinking started, we offered the following invitation:
“What does it look like when your team or organization is shipping fast? Where are you shipping too, what are you shipping, and how fast does it happen?”
For some participants, shipping fast is a highly stressful activity. Mostly caused because they’re not shipping fast and only do massive deployments every month or quarter. If this deployment goes wrong, it immediately causes serious problems. Others, continuously deploy smaller increments of work into production. This makes the whole deployment process much less stressful, gives them valuable feedback from their stakeholders, and provides new ideas for what to work on next.
Many emphasize that teams should focus on getting feedback from real users. People that have an opinion about the product are not automatically important stakeholders. Focus on the people that have a real ‘stake’ in your product. Make sure to get feedback from them. That proves to be quite a challenge for many teams.
For other teams, the customer is the limiting factor for shipping fast. The team wants to ship fast, but the customer can’t absorb/digest a frequent release of new product increments.
Scrum Teams continue adding more details to the product, while the customer only needed a much simpler version.
Why Shipping Fast Matters
In the first part of the workshop, we created a shared understanding of what “ship it fast” means. The next step was to help the group re-discover why shipping fast actually matters. To help them do so, everyone shared a personal story of a time when they were not able to ship fast. The following invitation brought back many painful memories. It did make very clear shipping fast is not a ‘nice to have’ but a crucial strategy to deal with the complexity of product development.
“In small groups, share a story of a time when you worked in a team that wasn’t able to ship fast. What happened? Why wasn’t the team shipping fast? What was lost? How did it impact the team, product, or its stakeholders?”
A clear pattern that emerged from all the stories, is that company guidelines and governance, dependencies with other teams, and comprehensive processes are the reason why they couldn’t ship fast. The organization’s structure and release processes were so complex, shipping fast seemed an impossible endeavor. In many stories ‘fear’ was also an important factor. What if the deployment failed? What if the product was released and a bug was found? What if we would discover the new features weren’t considered valuable for the users?
In all stories, not shipping fast had a huge negative impact on the team’s motivation. The initial excitement for building a new product was completely lost. Due to the lack of feedback from real users, nobody knew if they were on the right track. So the involvement and engagement of team members became increasingly low. The absence of a Done increment also made the Sprint Reviews meaningless. Why should you invite stakeholders if you don’t have anything to show? Because the Sprint Review was often canceled, important feedback was also missing. As a result, teams often wasted lots of time building features that didn’t prove valuable or lacked quality. This caused rework, which damaged the relationship between the stakeholders and the team even further. In short, in many stories, the vicious cycle of not shipping fast resulted in a demotivated team, a low-quality product, and unhappy stakeholders.
Not shipping fast, and only release once every quarter, six months, or year, results in stress, fear, and worries within the team and stakeholders.
What You Can Improve
In the previous step, everyone shared a story of a time they worked in a team that wasn’t able to ship fast. By sharing the causes, consequences, and impact, the group gained a common understanding of why shipping fast matters. In the closing part of the workshop, we focused on how to improve the situation in your current team or organization.
“When you consider the limitations, constraints, and dependencies that have made it hard to ship fast, what should you invest in to avoid making similar mistakes with your team?”
It was promising to see how many great ideas the group had to ship faster with their team. Many ideas are actual experiments we describe in detail in our book, the Zombie Scrum Survival Guide (yes, a shameless but helpful plug).
Ideas for what you can improve are:
- Have a Product Owner that has the mandate to make the decision to release. You don’t want someone that needs to ask the entire chain of command for permission first. If the Product Owner considers the product increment ready for release, (s)he should be able to make the call!
- Remove the separation between “Business” and “IT”. It’s meaningless and only results in more bureaucracy and comprehensive processes. Often the business isn’t even your real stakeholder. So not only remove the distinction between Business and IT but also start searching for the real stakeholder. Someone that really has skin in the game.
- Explain to your management and stakeholders why shipping fast matters. Clarify how it’s a strategy to manage risk, prevent rework, learn faster, deliver value sooner, and improve team morale. When management understands the importance of shipping fast, it also becomes easier to work together and remove impediments.
- Automate integration and deployment. Automation is the primary enabler of shipping fast. Without it, the repetitive manual work that a team must perform for every release becomes a huge barrier. This may lead them to cut corners, especially on the time they spend on manual testing and compromise the integrity of the product.
- Expand your Definition of Done. Instead of considering shipping fast a luxury, make it a principle that is deeply ingrained in your team’s Definition of Done. If it ain’t shipped, it ain’t done!
- Measure lead- and cycle time. Lead time is the time that transpires between when a stakeholder request enters the Product Backlog and when it is fulfilled to that stakeholder through a release. Cycle time is the time that transpires between when work is started on an item and when it is shipped.
- Remove dependencies. Many teams are not able to ship fast because of dependencies with other teams and departments. Make these dependencies transparent, explain how it impacts the team, the organizations, and the stakeholders, and work together to remove them.
- Slice the Product Backlog items. Smaller Product Backlog items make it easier to finish them in one Sprint. The larger items are, the more risk and uncertainty they hide. So work together to slice your Product Backlog items into smaller chunks of work. Check this cheat sheet for strategies on how to do so.
Closing
When faced with complex work, shipping fast is your best survival strategy. During our latest meetup in The Liberators Network, we all shared a personal story about a time when we didn’t ship fast. It brought back painful memories, but also important lessons learned. The least we can do is share these lessons learned with the wider community. Let’s all learn and grow together, and help each other survive the complexity of product development.
PS: if “ship it fast” is an important topic for your team or organization as well, download the free do-it-workshop and give it a try!