Agile Zone is brought to you in partnership with:

David has enjoyed success using agile and lean techniques at several companies near Washington DC and San Francisco. He joined his first startup in 1999, and helped scale it to a 13 million dollar acquisition in 2006. He now brings entrepreneurial thinking into large organizations so that disruptive innovation can emerge. David is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

Rewind Your Mind

09.04.2011
| 1936 views |
  • submit to reddit
“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:

Build
Measure
Learn

You 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.

References
Published at DZone with permission of David Bland, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: