Over a million developers have joined DZone.

Lean Startups: Thinking in reverse, yet leaning forward

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

“A good engineer thinks in reverse and asks himself about the stylistic consequences of the components and systems he proposes” – Helmut Jan

This advice is not limited to engineers. It also applies to many of us who want to produce software that actually matters to people.

Thinking in reverse, yet leaning forward can yield innovative results. This can be especially helpful when you feel as though you’ve become stagnant in your day to day activities.

Applied to Lean Startup

As the Lean Startup movement continues to gain momentum, one has to be careful not to blindly speed through the Build -> Measure -> Learn loops.

As Eric Ries stated in his Mixergy interview, even though you act in:


rewindYou need to first think it through in reverse:

What do I need to learn?
What do I need to measure to learn?
What do I need to build to measure to learn?

It may sound awkward, but the subtle shift in thinking really blew my mind when I first realized how it would affect building out minimum viable products.

Applied to User Stories

Mixing things up can also help you inspire innovation when writing User Stories. I was first introduced to this by Lyssa Adkins a few years ago.

Instead of following the standard User Story format of:

As a user,
I want feature,
so that benefit

You can work in reverse from the end to the beginning:

So that benefit,
I want feature,
as a user

This forces you to think about the benefit first, and then trace it back to what feature would provide that benefit. You can then trace the benefit back to the user.

This subtle shift in the way you approach writing User Stories can profoundly affect how you think about your features. It may help you realize that a benefit or feature you initially thought was useful does not have any user demand.

Applied to Behavior Driven Development

Another method of applying this technique is with regards to Behavior Driven Development.

Instead of following the gherkin approach of:

Given context,
When event,
Then outcome

You can work in reverse from the end to the beginning:

Then outcome,
When event,
Given context

Doing so will help you think about the desired outcome, to the event that triggers the desired outcome, to the context that surrounds the event that triggers the desired outcome.

There are other applications of this reversal of thinking, but you should get the idea in the above examples. Try them out when you feel as though something just isn’t working and you need to shake things up.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Published at DZone with permission of David Bland, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}