Who is really responsible for Delivery? In an Agile organization the answer is 'everyone'. The Product Owner, however, is the first line of success in fulfilling the first Agile principle, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” They define valuable for both the customer and the business with the Product Backlog, ensure ongoing value through vigilant grooming and validate value through feedback integration. The Product Owner is also responsible for ‘early and continuous delivery.'
Yes! It’s true. Early and continuous delivery is just as much the Product Owner’s responsibility as valuable software is for the Agile Development Team. While the Team creates the best solutions and benefits from User Stories (defined value), the Product Owner must consider early and continuous delivery while prioritizing and refining the Product Backlog. Owning delivery starts at the beginning of the planning cycle when the Product Owner translates input into backlog items. In short, the refined Product Backlog reflects your ability to satisfy your customer.
Business value = (What you need x When you need it) + Flexibility to change
This Business Value equation is supported by the principle of early and continuous delivery. Early delivery provides flexibility to change which helps refine the ‘What you need’ component. Continuous delivery gives customers frequent opportunities for feedback, which helps refine both the ‘What you need’ and ‘When you need it’ components.
Many Product Owners default to prioritizing the Product Backlog solely on the business importance of a piece of software without considering the value of early delivery and early customer feedback. These are Agile Principles that produce value, and when de-prioritized, carry risks.
Product Owners who consider early and continuous delivery, and the feedback loop it creates, build business value and reduce delivery risks. Refining the backlog without considering early and continuous delivery in the size, scope and priority of backlog items, severely limits several agile advantages and carries some specific risks:
- Lack of Stakeholder Confidence
Stakeholder confidence is key in striking the agile bargain of team autonomy for valuable delivery. They pay for and are accountable for your success. Unless you are in a mature agile organization you will likely need to provide some proofs along with your evangelism to get them comfortable with team autonomy. Early and continuous delivery is a strong advantage in showing results. When stakeholders come to expect early delivery of working software, they have less reason to Command and Control the team and more reason to believe that the later iterations of the product will be more valuable than even the initial product vision allowed for.
- Stressed Communication
With a new feature or a critical change, user communication, training, and support make the software stick. Immature communication plans/channels risk botching user adoption. Early release, however, generates early communication and iterates with the software, until communication is right sized. Releasing early also gives you the chance to align the right marketers and communications specialists to the target customer.
- Stale Software
When the delivery cycle is stacked without considering early delivery features may not be as relevant when they make it to the customer. For example, the ability to process credit card payments is released after a long delivery cycle but is eclipsed by the need for Apple Pay integration, the primary payment mechanism for your recent expansion into the eGamer market segment. Credit payments provide some value but not the best and most relevant value to the intended new customer. Or, a white labeled database option for customer microsites is eclipsed by a new Google Sites module, already adopted by half your customer base. Prioritizing your backlog for early and continuous delivery allows you to respond to your market and changing business conditions.
- Complex Implementation and Re-Work
Implementation can be complex and carry its own quality risks. Delivering more frequently stimulates good and automated implementation practices. Delivering a large, complex feature, carries integration risk as well as implementation acrobatics, especially if it touches two or more systems. Re-Work is similar. The more complex the feature, the deeper the customer feedback, the heavier the re-work burden. Architectural re-work is the most expensive. Releasing early and often tightens the user feedback loop and affects change earlier.
Early and Continuous Delivery starts with Backlog Refinement
Early and continuous delivery builds stakeholder confidence, develops valuable customer communication strategy, relevant software and mitigates implementation risk and re-work. By stressing early and continuous delivery in backlog refinement, the Product Owner creates a powerful value package. The Product Owner owns delivery.