Getting Started with Product Delivery

Introduction (Part 1 of 10)

And something for those who are hesitant to make the transition

Vincent Carter

Published in

Straight Scrum

4 min readJun 15, 2021

The Scrum Guide describes a purposefully incomplete lightweight framework that is designed to help with generating value through adaptive solutions for complex problems. The Guide gives you just enough information to get started; however, most organizations and teams need a little more help than what is provided. Where do we start? How do we generate and manage new ideas for our Product? What metrics are important to track in order to measure that value is being delivered? How do we get an initial Product Backlog going? What are the things that we should think about stopping and what are the things that we should start?

This series of quick reads will answer these questions and more by getting to the meat of helping you with some ideas that you can use to get moving with product delivery. If your organization or teams are somewhat hesitant about moving to product-based delivery, pay extra attention to the last section in this article.

This is the first of a ten-part series which includes:

Project-based -vs- Product-based Delivery

Project-based delivery is the process of leading the work of a team to achieve the project goals within given constraints such as scope, time, and budget. Due to the nature of these constraints, any change to one of them will have an impact on the others which usually requires contract negotiation. This approach to delivery also requires you to focus on determining the solution for each of these constraints up-front which is also the point in time that you have the least amount of information. By definition, a project has an ending and with that ending the people involved usually move on to other projects or back to their areas. Any semblance of a team and the synergies that were created on that team cease to exist.

Product-based delivery is a way to organize people for the long-term around something, physical or not, that continues to create value for its users or customers. This approach embraces uncertainty and changes while focusing on getting to the “right” outcome instead of an on-time output. It takes a “learn & adapt as we go” approach to delivering value and it acknowledges that we know the least about what we are delivering at the beginning of an effort. By keeping a team aligned to a Product for the long-term, it paves the way to continuous delivery.

What if Your Organization is Not Ready?

If your organization is hesitant about moving to product-based delivery or maybe there’s a large project that is currently going on and an area doesn’t have the tolerance to slow down in order to go faster, then aligning to a product and adopting a new development framework like Scrum at this time may not be a good approach. If you do not have the right buy-in and support from leadership, my recommendation is to not try to change their beliefs. Forcing any kind of transformational change is ineffective but you do not have to give up either. You may want to meet the organization and teams where they are and instead concentrate on a single metric like Deployment Frequency. In its simplest form, Deployment Frequency is the measure of how frequently a team deploys code to production and by agreeing to slowly improve this single metric, you can help focus your entire organization or an area around a common goal that is inspiring, challenging, and tangible.

Some of the benefits that can come from focusing on increasing Deployment Frequency include:

Work finishes faster and more predictably.
Critical insights into the workflow where teams identify specific areas where code deployment is delayed.
Development issues are quickly resolved or escalated
Fewer integration issues
Production issues are quickly addressed and fixed
Ability to adapt based on new information
Ability to test and quickly learn from new ideas with customers
The risk of un-done work rapidly decreasing

If your organization starts with Deployment Frequency and sees how incremental small improvements can provide tremendous benefits, then maybe they have reached the right mindset and beliefs that are required to make the difficult changes required to move to product-based delivery.

INSTALLMENTS

Introduction with Table of Contents
Next Installment: Getting Started with Product Delivery: Product Vision and Product Strategy (Part 2 of 10)

I am very interested to learn what you think about this topic. My LinkedIn profile is https://www.linkedin.com/in/phooey

GO MAKE A HULLABALOO!!!