Hinweis: Die aktuelle OOP-Konferenz finden Sie hier!
SIGS DATACOM Fachinformationen für IT-Professionals

SOFTWARE MEETS BUSINESS:
Die Konferenz für Software-Architekturen
30. Januar - 03. Februar 2017

Sessionsdetails

Vortrag: Di 8.3
Datum: Di, 31.01.2017
Uhrzeit: 16:15 - 17:15
cart

Quality from the PO perspective – from 6 weeks to one-day release phases

Uhrzeit: 16:15 - 17:15
Vortrag: Di8.3

 

In this talk, I’ll share what I’ve learned about quality, release times and quick feedback from being a product owner. For the last 7 years, I’ve been PO for an open source product. In that time, we’ve moved from painful and non-agile 6-week test phases to sprint (beta) releases every three weeks, with the option of an official release when I want one – with release times of one day. This is a story about techniques, transparency, testing and trust, with the extra spice of dealing with the quality wishes of different stakeholder groups.

Target Audience: Product Owners, Testers, Developers in Agile Teams
Prerequisites: Basics of agile and scrum
Level: Practicing

Extended Abstract
In this talk, I want to share what I’ve learned about quality, release times and quick customer feedback from being a product owner.
For the last 7 years, I’ve been PO for an open source product. In that time, we’ve moved from painful and non-agile 6-week test phases to sprint (beta) releases every three weeks, with the option of an official release when I want one – with release times of one day. This is a story about techniques, transparency, testing and trust, with the extra spice of dealing with the quality wishes of different stakeholder groups.
During the talk, I’ll cover:

  • Introductions: my stakeholders and their quality desires
    -  Specific quality hurdles when working in open source 
    -  Opportunities for feedback that open source projects can benefit from
    -  My aims as a PO for releasing new versions
    -  How it all started: our long and painful (and not particularly effective) release phases
  • How we moved to continuous internal delivery to improve our feedback cycles (continuous integration, daily dog fooding, more automation)
    -  Our attempt at traditional “release candidates” and why I found it too heavyweight
  • Why we could choose to release beta releases, and how this helped our trust and feedback cycles.
    -  This includes a philosophy of “let it go!” – knowing (or even trusting) that nothing too major will make it into the beta release, and that we can release fixes quickly if necessary.
    -  The difference between a beta release and an official release, and how we started using feature branches
  • Our one “0 day” release and the move back to “1 day releases”
  • What’s still to do

Join me on this journey to hear what’s worked, what hasn’t, and what steps can be taken to move towards more frequent releases for a happy PO and customers!