G Forces, Release Cadence and Feedback Cycles


When I saw the G Forces presentation by Kent Beck at the Lean Kanban Central Europe conference  had an insights that wasn’t that clear to me before.

For those who don’t know the G Forces presentation: it is all about shortening release cycles from months to weeks to days to hours to minutes.

What became clear to me: The release cadence is not the real point. It is all about feedback. You have to be able to incorporate feedback according to your release cadence. Releasing every day doesn’t help too much if you need a month to collect feedback and react on it.

Perhaps we should reflect that with our metrics. What about Feedback Cycle Time and Feedback Coefficient as new metrics for teams?

Feedback Cycle Time would be the time you need from the release of feature A until you are able to release feature B that incorporates the learnings from feature A? For example: You release feature A to production on 1st of february 2012. Then you collect data from the production usage of B for 1 week. You discuss the findings for one week and take another week to redefine some of the features in the backlog. And then you need 3 weeks for implementation, test and release of feature B that incorporates the learning. In this scenario your Feedback Cycle Time would be 6 weeks.

The Feedback Coefficient would be Number of Features for which feedback was collected / Number of Released Features. For the Feedback Coefficient it doesn’t matter if the feedback was positive or not. The only important thing is the learning. When we are honest most teams today achieve a Feedback Coefficient of zero or very near to zero. The optimum would be 1.

I think both metrics would focus on a weak spot in many teams: The teams try to maximize throughput and minimize lead time but don’t really care about feedback from the market.

5 Kommentare

  1. A practical implementation of where you want to go is simply Eric Ries Kanban board, which binds the whole company and thus the developers to gathering feedback before going further:

    Backlog | In Progress | Built | Validated

    Cheers

    Markus

  2. Yves sagt:

    Yes. And that’s why the Lean Startup movement says that it is all about validated learning. The last column on your Board has to be ‚validated‘ and not ‚done‘ because it stresses the fact that releasing a feature has now value and therefore # of releases has none.

  3. stefanroock sagt:

    Roman Pichler also has suggestion for a board design in his talk „Customer Discovery with Kanban“: http://www.slideshare.net/romanpichler/customer-discovery-with-kanban (slide 17ff). I like that very much since it not only visualizes the work but also the aggregated learning.

  4. Johannes Link sagt:

    I agree and would like to stress that collecting money is a very clear way of collecting feedback.

  5. Hi Johannes,

    in some cases it’s true, in some it’s just a tempting vanity metric or the amount of money in the beginning simply not measurable. Then you don’t have a statement.

    The examples of the power of cohort metrics etc. given in Ercs‘ book for getting more detailed validation are compelling and go much further than ‚just money‘ 😉

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s