Managing Startups: Best Blog Posts by Thomas Eisenmann

Author:Thomas Eisenmann
Language: eng
Format: epub
Tags: BUSINESS & ECONOMICS / Development / Business Development
ISBN: 9781449367862
Publisher: O’Reilly Media
Published: 2013-04-30T16:00:00+00:00

Chapter 37. Continuous Discovery

Marty Cagan

I have written recently about how product teams do product discovery in parallel with product delivery. I have also written about how teams sometimes like to time-box their product discovery work.

What I’d like to write about in this article is an increasing trend I am seeing towards both continuous delivery and continuous discovery.

Continuous Delivery is an increasingly popular notion today. The concept has been talked about by many teams for a few years now, but now there are actually quite a few teams really doing it.

Nearly all product teams today do continuous build. The principle here is that if there are build problems, it is really good to find them sooner rather than later, so typically builds are initiated the moment changes are committed.

Many product teams have taken this principle to the next step and have learned that integration problems are time consuming, and that by integrating early and often (rather than a “phase” before testing), they can significantly speed up their overall throughput by minimizing the time that they are working in isolation.

Similarly, instead of testing everything in a phase at the end of a release cycle (even a 2-week release cycle) and finding all the problems at once, it is much better to run automated regression test suites continuously to find newly introduced issues as soon as possible (which significantly reduces the possible sources of the issue and hence the time to correct).

Quite a few teams now are taking this principle to its logical conclusion and releasing continuously (known as continuous deployment). This means that each logical change (or sometimes groups of changes) are released in small “micro-releases” as soon as they are ready. There are a couple pretty significant benefits to this. The first is that this is the ultimate form of an incremental release strategy which is our key mechanism for gentle deployment – good for our customers and good for us. The second is that detecting and correcting issues in production is much easier when you are just changing one thing, or a small number of things, at a time.

However, everything I’ve described thus far has to do with product delivery. What about product discovery?

I have long argued for exactly the same principle in terms of how we come up with product backlog items. Rather than a “Product Discovery Phase” where we come up with several weeks of validated product backlog items and deliver them to engineering, I encourage teams to do continuous product discovery – where we are constantly identifying, validating and describing new product backlog items. Some discovery work takes a few hours and other things can take longer, but it is an ongoing process of ideation, validation and description.

In the dual-track analogy, the discovery track is continuously generating product backlog items, and the delivery track is continuously building, testing and deploying these items.

With the continuous discovery and delivery trends, many teams are finding that Scrum as a process can be limiting, and that Kanban tends to fit this continuous discovery and delivery model better.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.