Every Feature Needs a Hypothesis

Share:

In this article, I’ll use a simple, easily accessible example feature to show how a feature hypothesis should evolve and how monitoring results can impact our plan and backlog priorities.

I am going to stick with the “Password Reset” example from the previous article in this “Outcomes versus Outputs” series since resetting one’s own password can be applied to almost any website and application. Continue reading “Every Feature Needs a Hypothesis”

Share:

Outcomes: The Forgotten Test Case

Share:

Outcome versus Output

My very simple definition of the difference between output and outcome is:

  • Output is delivering volume
  • Outcome is delivering value

Theoretically, they could be the same but in practice this is seldom the case.

I can create a lot of ‘stuff’ (i.e. output) but realise very little, or even negative, value for all the time and effort spent producing said ‘stuff’. This article provides two practical examples of what normally happens (we focus only the output), why this is a terrible practice and the problems associated with ignoring the outcomes. Continue reading “Outcomes: The Forgotten Test Case”

Share:

Kohavi’s Law & Harry Potter explain why your experience and intuition suck

Share:

Ron Kohavi was the Technical Fellow and VP of the Analysis & Experimentation team at Microsoft. He had a team of brilliant engineers, data scientists and program managers working under him. Kohavi’s team built Microsoft’s “Experimentation Platform.”  Before the Experimentation Platform was in use, Microsoft teams were delivering well-thought out features, some small, others larger multi-month projects. Output was great – and Microsoft products like Bing, Edge, Exchange, Office, Skype, Windows, and Xbox were benefitting from the exceptional work produced.

Or were they?

Continue reading “Kohavi’s Law & Harry Potter explain why your experience and intuition suck”

Share:

What the Comrades Marathon tells you about Agile Transformations

Share:

I was asked to submit a “Running Mann-style” presentation for the Business Agility Africa conference.  The accepted topic was, “What the Comrades Marathon tells you about Agile Transformations” and ended up being the final of 21 presentations from speakers representing 6 countries.

Before the presentation, several of the 170 delegates asked, “How the hell do you relate Comrades to agile transformations?” After the presentation, they were left in no doubt! The presentation combines stats and stories from the great ultra running event on the planet – and I even managed to work in “The Agile Running Mannifesto!” Continue reading “What the Comrades Marathon tells you about Agile Transformations”

Share:

How George Costanza, Frogger & a Craving For Sushi Help Explain Features & User Stories

Share:

In classes I teach, there is often confusion between what is a feature and what is a user story. This article is a simple analogy (a quest for sushi) that helps to explain:

  • The difference between a feature and user story.
  • How user stories can be broken into incremental chunks.
  • Why George Costanza is not agile.

Continue reading “How George Costanza, Frogger & a Craving For Sushi Help Explain Features & User Stories”

Share:

6 Reasons: From 12 Months to 2 Weeks for Feature Delivery

Share:

This article is a supplementary appendix to the post: The Power of Feature Hypotheses.

Where We Were: 12 Months to Deliver a Small Feature

The graphic below is an example of a feature that previously took 12 months to deliver when we were working waterfall. This was the typical cycle-time for a small feature. Larger features would usually take over two years to flow through the system. With agile, we would now expect this same feature to be complete in a two week sprint. This article provides the six main reasons for the massive cycle-time reduction.

An example of a small feature that took 12 months to deliver in waterfall. In agile this can easily be done in two weeks.

Continue reading “6 Reasons: From 12 Months to 2 Weeks for Feature Delivery”

Share:

Using Hypothesis Statements for Features in Software Development

Share:

This article is an supplementary appendix to the post: The Power of Feature Hypotheses

Experiment-Based Approach

Instead of making up-front decisions based on assumptions and imperfect knowledge we create hypotheses and run a series of experiments to determine whether each hypothesis is true or false. The results determine what we should stop doing, start doing and continue doing. Based on complexity, uncertainty and rapidly changing environments, most software development projects are “research and development” exercises ideally suited to this hypothesis-based approach. Continue reading “Using Hypothesis Statements for Features in Software Development”

Share: