AgileFall-ish, or How To Look Agile But Keep Your Waterfall Roots!

So how do we look Agile while maintaining our Waterfall roots? By building a predefined set of features through months of successive Sprints without getting customer feedback.

It’s often said that to be successful as an Agile organization you need to change your mindset. This cannot be repeated too many times. Agile is NOT Waterfall with new words and catch phrases. Unfortunately some companies miss this completely and don’t change their mindset. They simply continue their Waterfall processes in Sprints.

Keep Your Options Open

To be truly Agile you need to keep your options open. You may have a framework of features you want to build. But you won’t really know if customers want those features until they see them. And putting your features in front of customers sooner rather than later is one of the keys to being Agile. This helps you validate real customer needs and redirect as needed.

Gabrielle Benefield speaks about keeping our options open and targeting outcomes instead of output in a presentation given at GOTO 2012 called “Stop Building The Wrong Product Righter, Build The Right Product”. Her discussion leads me to two questions:

Are we using Agile techniques to effectively deliver what the customer wants?
Or are we perpetuating a Waterfall mindset in an Agile setting?

There are two versions of her video presentation. The first is more polished:
“Stop Building The Wrong Product Righter, Build The Right Product”
“Frankenbuilds; if Agile is so good, why are our products so bad?”

Don’t be put off by her early comments. At first it seems she is against Agile and Scrum. But she isn’t. She’s saying that we aren’t getting the full benefit of Agile if our teams limit options and lack customer feedback.

Again, the danger is committing to create a list of features without getting customer feedback along the way. Sometimes our leaders will have a strategy for a list of features and there really is value in creating all of them. But sometimes there is no strategy, it’s just a laundry list.

Don’t commit to a pre-determined list of features (or outcomes) unless we already know (really know) they are the outcomes we want.

Here are the key points I got from the presentation:

  • Outcomes over output
    • On time and on budget are meaningless if you build the wrong thing, at the wrong time, for the wrong people.
    • Output isn’t necessarily a good thing. Outcomes are more important.
    • Stop building the wrong thing ‘righter’.
  • Keep your options open
    • Outcomes are the destinations we want to get to.
    • Options are the potential ways you get there.
    • Target outcomes set a direction, and there are many ways to achieve it.
    • Outcomes break down into multiple options and the options are represented in the product portfolio and roadmap – flexible as opposed to linear.
  • Use experiments to determine direction
    • There are no product requirements, they are product guesses.
    • Set based design – run options concurrently to increase speed to market.
    • Features are not the experience.
    • Target outcomes validate the investment.

References for related topics:
A3 thinking
http://leanconstruction.org/public-docs/TDC-CH40-A3-Thinking.pdf
https://en.wikipedia.org/wiki/A3_problem_solving
Target Outcomes Framework
http://www.gabriellebenefield.com/mobius/how-to-measure-value/
Set based design
http://www.scaledagileframework.com/set-based-design

Here are my full notes from the presentations:

  • On time and on budget are meaningless if you build the wrong thing, at the wrong time, for the wrong people.
  • Output it’s necessarily a good thing. Outcomes are more important.
  • Stop building the wrong thing ‘righter’.
  • Build outcomes over output.
  • Measure value, nothing else matters. – Tom Gilb
  • Possibility – The most features you deliver, the worse the UX gets.
  • First, focus on performance and usability.
  • Target Outcomes Framework
    • Outcomes are the destinations we want to get to.
    • Options are the potential ways you get there.
    • Gather data: it lies (a little) less than people.
    • Become the method actor of UX.
      • Never ask your users what they want.
      • Never ask the developers what they think the users want.
      • “If I had asked people what they wanted, they would have said faster horses” – Henry Ford
      • Get out of your chair and find out what they need.
      • Create empathy, build personas to remind us that real people use our products.
      • Create strategies for getting to the right people at the right time.
    • Data gathering
      • Once you know where you are, figure out where you want to be.
    • Impacting mapping
      • Choose the outcomes by measuring the severity of the problem or size of the opportunity.
      • Optimize for the 20% that’s used the most.
    • Set the target outcomes
      • Make it easy to do the right thing, hard to do the wrong thing.
      • Target outcomes need to be clear and measurable.
      • If you don’t measure how will you know when you get there.
      • Target outcomes set a direction, and there are many ways to achieve it.
      • When you plan based on outputs, you commit to a certain future.
        • “This is what we think we are going to build.” You’re missing the customer input.
      • Stop pretending you can see the future.
        • Once you give a feature a name or document it, it has life and people think you are killing it if you decide not to do it.
    • Create options
      • Keep your options open, be ready to execute rapidly.
      • Responsible moment thinking
        • Make decisions as reversible as possible.
        • Make irreversible decisions as late as possible.
        • Options thinking is about setting up potential ideas and being able to execute on them rapidly.
      • Outcomes and options are fractal, each one leads to another.
        • Outcomes break down into multiple options and the options are represented in the product portfolio and roadmap – flexible as opposed to linear.
    • Simply go and build the right thing
      • How do we know what the right thing is?
        • We don’t know.
      • There are no product requirements, they are product guesses.
        • They are options and experiments we should run, never thinking far in advance.
        • Stop guessing, start testing.
        • Run multiple options fast, make the unknowns known.
          • Get features in front of users early and often.
      • Set based design – run options concurrently to increase speed to market.
      • Seeing is believing, research is too important to leave up to the researchers.
      • Features are not the experience.
        • More features, incrementally adding features, can be the problem.
        • Remove the inessential so the essential can speak.
        • Hit the target with as few bullets (features) as possible.
        • Build the minimal viable, not maximum possible.
      • Measure as you go.
        • Setup automated metrics frameworks.
        • If your metrics lag, your product will lag.
        • Share the data with the entire development team.
        • Why test with 5 people in a room when you can have thousands test real time.
        • Visual progress indicators tell you if you are on track.
        • Target outcomes validate the investment.
    • How do we know we have succeeded?
      • We get to where we are going, the target outcomes.
      • If we are not hitting the target outcomes, adapt.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: