Read this on medium.com via ideas.riverglide.com.

Imagine you’d never seen an orange or an apple before. Then, imagine you read a few articles showing an image of a shiny, red fruit, saying – “This is an orange, it will help you with your vitamin C deficiency”. It’s a similar shape to the foods you’ve eaten for other vitamin deficiencies so still fits your model. You proceed to eat lots of this red, shiny, crunchy, refreshing fruit and you teach your colleagues the same. Now they’re eating “oranges”…

“You keep using that word, I do not think it means what you think it means.”

After some time, your vitamin C deficiency still hasn’t improved. So everyone says “down with oranges, they don’t work”—including the some of the authors who’s articles you’d read. The problem was that you were eating apples, not oranges. But it’s too late, you, your colleagues, some authors of the articles you read—now have a disdain for anything labelled ‘oranges’.

This sounds ridiculous, but only because you know the difference between oranges and apples. Yet, it reflects the same kind of wide-spread misconception that has fuelled the growing disdain I’ve seen towards the Connextra Template—As a…I want to…So that…

Summary (TL;DR):

• Some believe User Stories are analogous to product features & that they should state business benefit – this is a fundamental misunderstanding;
• User Stories are about what the user will be able to do/achieve (not actions or features they’ll do it with);
• The Connextra template (As a / I want to / So that) helps us start valuable conversations about: who the user is, what they want to do and why;
• Some tried to ‘improve’ the Connextra template to capture features and business benefit (software requirements). These ‘improvements’ spread far and wide, propagating the ‘feature’ misconception of user stories;
• It’s not too late to make the paradigm shift away from writing ‘software requirements’ to truly understand user stories as ‘the story the user wants to be able to tell’;
• Truly understand the User Story paradigm and you realise that the Connextra template is as useful as ever.

The root of the misconceptions

Think of a User Story as a short-story that a user will be able to tell about what they want to do and why they want to do it. It’s not the feature the product will have or the actions they’ll perform, it’s what the user will be able to do – as in achieve. One story may actually mean subtle or significant changes to multiple features, involving several actions.

“Stories aren’t a different way to write requirements, they’re a different way to work”  -Jeff Patton

User stories are a paradigm shift, a different way of working. Jeff Patton explains this superbly in slides 1-50 of his User Story Mapping slides (I highly recommend you flip through them). Jeff highlights that “Stories aren’t a different way to write requirements, they’re a different way to work”.

 
The misunderstanding that User Stories are just a different way to write old-style software requirements has contributed to continuous deterioration in how the Connextra template is communicated across the industry—changing User Stories into product features (or user action within a feature). Product features and actions within them generally describe the product (not the problem)… again, like old-school requirements.

“A further problem with requirements lists is that the items on the lists describe the behavior of the software, not the behavior or goals of the user” –Mike Cohn, User Stories Applied (2004) Addison Wesley

Unfortunately, the problem wasn’t with the Connextra template, it was with widespread misinterpretation of it. This misinterpretation propagated so far and wide, that many teams now experience the problems caused by slicing work into product features (problems that User Stories are designed to solve). And now people are saying—“User Stories are broken!” and “the Connextra Story Template doesn’t work”. Clearly, comparing apples and oranges, much like in the opening story.

How did this happen?

The Connextra template highlights the who, the what and the why from the user’s perspective:

As a <someone>
I want to <do something>
So that <some result or benefit>

This helps us start the right conversation; exploring the short story a user could tell about something they’ll be able to do – hence the term ‘User Story’. The “As a…” helps us start empathising with the user. The “I want to…” gets us thinking about what they want to do (not how). The “So that…” get us closer to their motivation – why they’d want to do this.

Unfortunately, many people mistook User Stories to be just a different way to write requirements—which they’d always expressed as features & functionality. In their efforts to help colleagues and peers understand user stories in the same way, several people began sharing this template:

As a [role]
I want [feature]
So that [benefit]

Many teams found that whole features were too big to implement in a short enough window, so we also saw a variation on this where the interactions within the feature were described:

As a [role]
I want to [action]
So that [outcome]

Others sticking with the larger feature model, asked about ‘benefit’ part – what’s that for? Is it the benefit to the user? If it’s about the user, then where do we ‘document’ the business benefit? The question of ‘value’ and ‘business benefit’ was seen to be missing so we started to see:

As a [role]
I want [feature]
So that [business benefit]

People didn’t always know what the specific business benefit of a feature was so they started writing “As a… I want ” and left the “So that…” part out. So, a different format was put forward to encourage thinking about the business benefit and we ended up with a catch-all for feature or action—“functionality”—plus the business benefit as the opener (which became a confusion between what the business wanted and what the user wanted):

In order to <achieve some value>
as a <type of user>
I want <some functionality>

Whether it was the intent or not, I believe that these variations made it easier for teams to think they were working with User Stories when in fact they were simply capturing product-features and business-benefits like old-style software “requirements” – only dressed in a User Story like template.

The opportunity

User stories are about the user – hence the name. It’s a way of working, not a way of writing requirements. This is an area we all need to get better at explaining.

What we write on the User Story card (or electronic equivalent) using the original Connextra template helps us start the right conversation about users’ needs, slicing by value to the user. Starting the right conversation to slice by business value is a different problem.

The original Connextra template works just fine for User Stories that tell a story about the user. The template wasn’t trying to fix the mindset of slicing-by-feature. Books like User Stories Applied were there for that. The misconceptions began when people assimilated User Stories through their feature-biased filters and tried to ‘fix’ it – rather than question their own understanding.

This left many teams with “features dressed as stories” caused by a fundamental, yet common, misunderstanding. Who knows, I may have once shared in that misunderstanding myself. Now, we have an opportunity to change this by learning more truths about User Stories so that we can all benefit from increased agility.

Have you been working with features dressed as stories? If so, and you want that to change, here’s a place to start.

 

Antony/Andy would know how to make what I’m doing better/easier right now, if only they were here!

Maybe all you really need is 30 minutes to an hour pairing or just talking, not a whole day of our time. Maybe all you need is a few emails back and forth between us. Rest assured, we’re here and we’re happy to help, on anything including:

• For product and technology teams:
  • Thinner slicing of your Minimal Viable Products (MVP)
  • Effective user stories, Feature Injection & agile business analysis
  • Effective Cucumber scenarios
  • Communicative, narrative code
• For coaches, managers and leaders:
  • Values & building a culture of innovation
  • Enabling more adaptive teams
  • Challenges of culture and process change
  • Facilitating effective workshops: story-sizing/planning/retrospectives

All sessions are strictly confidential and we’re more than happy to sign a mutual non-disclosure agreement if required. If you aren’t sure if either of us can help, why not get in touch and let’s see. If we can’t, it won’t cost you anything…

Individuals: Pay what you think it was worth

Maybe you need to talk about a challenge you’re facing with your team, colleague or management. Perhaps you have some nightmarish Cucumber scenarios that are making your head hurt. Perhaps you just need someone independent to bounce ideas off.

We’ll have a conversation on Skype, Google Hangouts, Facetime or just on the phone. At the end of the time, all you do is:

• Tell us what you thought it was worth and
• Pay only what you are comfortable paying

Money is relative to both your personal income and your responsibilities. You know what they are and we trust you to make a fair exchange of value. All we ask, when you pay whatever amount you’re comfortable with, is to tell us what you thought the session was worth.

You may work in a company that trusts & values your judgement, allowing you to expense personal development activities. This model equally applies, but when that isn’t an option…

Companies: Pay what you think it will be worth

Many large, established companies find it hard to work in the above way. You may not feel you have the freedom to work in the above way (in which case we really should talk). Your manager may want to sign it off and your finance team may want to have a purchase order in place for a fixed amount before you talk to us. So, if you want let’s talk a bit about the challenge and what a new way forward in addressing that challenge is worth. We’ll agree a price and we’ll go from there.

After a chat, you might find that you have a lot more freedom than you think and we can help you make things easier. For more information, get in touch with an email or a call to +44 845 056 9606. We’re happy to help.

A user story is a “short descriptions of functionality–told from the perspective of a user–that are valuable to either a user of the software or the customer of the software”[1]. You may first encounter stories in this form:

As a microblogger,
I want to find out as soon as others mention me,
So that I can choose to respond while topics are current.

One common misunderstanding of user stories might result in the above example looking more like this…

As a microblogger,
I want a notifications screen showing my mentions,
So that I can find out as soon as others interact with me.

The problem here is thinking of user stories in terms of what the user will have, rather than what they’ll be able to do. This can cause avoidable dependencies that limit your flexibility, reduce your speed to market and limit your ability to change direction based on market feedback.

These dependencies can be dramatically reduced if our user stories steer the conversation towards what the user will be able to do. Let’s explore why…

What the user will have (features)…
Let’s imagine we envision a house (which will be made of lego in this exercise). What stories would you write for your lego house? Here are some of the typical stories people write:

• As a cook,
  I want a kitchen,
  so that I can prepare food.
• As a parent,
  I want a master bedroom,
  so that I can sleep comfortably with my partner.
• As a car-owner,
  I want a garage,
  so that I can park my car off the street.

Have a think about what’s involved in delivering these stories with a lego house, building our final vision of the kitchen, the bedroom, the garage. If our vision is to have the master bedroom on the top floor, then we can’t have a place to sleep until we’ve built the ground floor. To build our garage ‘iteratively’ we will focus on building the walls first, then put the roof on. Essentially, the architecture drives the order of implementation, not what is of greatest value to us.

The problem here is that these stories are encouraging us to fixate on specific solutions to each problem. Ideally, we want the story to be about what the user will be able to do (i.e. sleep comfortably together), not what they’ll have (a bedroom).

In these examples, as is often the case, the problem we’re trying to solve is there, just in the ‘so that’ part. Getting everyone to share in an understanding of the problem(s) we want solved helps us prioritise based on business value…

What the user will be able to do (capabilities)…
Now, imagine if we had stories like this:

• As a cook,
  I want to prepare hot food for the family,
  so that we can safely enjoy various fresh foods.
• As a parent,
  I want to sleep comfortably with my partner,
  so that we can keep each other warm.
• As a car-owner,
  I want to park somewhere safe,
  so that I can keep my insurance premiums low.

Have a think about the different ways we could initially solve these problems (from camping cookers, a mattress on the floor and a driveway to park the car). We can meet all of these needs rapidly without having to achieve the final vision but make it possible to layer on more and more refinement to each one evolving to the solution and enabling us to discover the solution we really need.

when what we want is “a thing” then what we are describing is not a user story – it is a feature.

Features (“I want a…”) vs. Capabilities (“I want to…”) 

Relatively recently, while running my user stories course (with Lego) to delegates at a well known company, one delegate pointed out a difference between the ‘template’ for the two story styles above. They observed that in the case of stories that are really “Features” the format tended to be “I want a…” whereas for stories that were “Capabilities” the format tended to be “I want to…”. Some found ways around this by saying “I want to have a…”.

Interestingly, the original ‘Conextra Template‘ indeed followed “I want to…” and all of Mike Cohn’s examples in his book “User Stories Applied” are indeed capabilities (although sometimes in his explanations he does refer to stories as describing a feature, his examples are generally capabilities).

In short, when what we want is “a thing” then what we are describing is not a user story – it is a feature.

(This short section was added on: 22nd May 2015)

Flexibility & Adaptability…

Each of these stories may be broken down even further. Let’s look at the garage and all the needs a garage might meet

• As a car-owner,
  I want to park my car off the street,
  so that I can reduce my insurance premiums
• As a car-owner,
  I want to shelter my car from the rain,
  so that I don’t have to wash it as often.
• As a car-owner,
  I want to hide my car from onlookers,
  so that opportunists don’t think of stealing or vandalising it.
• As a car-owner,
  I want to hinder thieves from driving my car away,
  so that I get the lowest insurance premiums.
• As a car-owner,
  I want to securely store my tools near the car,
  so that it’s easier to do basic maintenance.
• …and so on.

Now think of the different ways we could meet those needs with our lego house?

Most of these stories are largely independent of each other and can be delivered in almost any order. This allows us to prioritise the stories based on value rather than the architecture of the final vision.

We’ll realise our first piece of value very quickly and continuously gain more and more value until eventually we’ll have a whole garage (if that’s what we really need). If this was something that makes us money, it would mean we’d be generating revenue sooner. Revenue would grow continuously as we continuously grow our product.

It also means we can change direction at any time, for example if we were to start getting feedback taking the garage more in the direction of a workshop with space for a car rather than just a simple garage.

In the real world
I recently helped a client interview people who had from three to five years “experience” with user stories. During the interview I pulled out some index cards and pens. I described a simple product (which was surprisingly similar to early incarnations of Twitter) and invited them to help us write some user stories for our backlog.

What each of them wrote was, essentially, a functional specification, split like use-cases into several cards, except using the above “As a… I want… So that…” template. They explained each story in terms of the screens in the user-journey such as Registration, Login, View Profile, Follow Other Users, Post a Status Update, View Status-Updates and so on. The real issue here isn’t in the name of the story, it’s in what the stories represented in their minds…

I asked them to help us prioritise them based on value. “Registration is most valuable because without it we can’t do anything else”–one interviewee explained. This means that it would not be possible to obtain any feedback about the main value proposition of the product until a number of user stories are complete. Each candidate explained the stories as dependent steps in a journey that, essentially, had to be built in the same sequence as the journey [4].

The main value proposition is sharing updates with people and seeing what others are saying. A simple screen-name (like in a chat room) will do  initially. Registration and login are largely about hindering others from pretending to be me. Could there be simpler ways of achieving this at first?

Like I said, I’m not suggesting that any of the story titles that each candidate came up with are invalid, just that they thought of them in terms of the expected solution (what the user will have), not understanding the real problem (what valuable thing the user will be able to do).

In Closing…
With tractable mediums like lego or code (with the right engineering practices around it), we are able to evolve our product to meet each user-need in turn.  This is facilitated by thinking of our user stories in terms of the outcome (e.g. shelter from the rain) rather than one possible output (e.g. a roof and four pillars). Ultimately, this way of thinking is one of the key upstream enablers to realising value early & often and brings more opportunity to rapidly adapt to feedback by dramatically reducing dependencies.
——————————-
Experience this for yourself: If you would like me to run this as a hands-on workshop with your team(s), let me know. We’ll explore how user stories work in practice, not only by writing the stories, but understanding the conversation and means of confirmation [3] that complete the practice of user-stories. I can also wrap this in a simulation of Scrum and/or Kanban so that teams can experience how user stories work in practice. I make it accessible to all team members using lego as a metaphor for software, demonstrating the principles described above. We then explore how to apply this to your products, writing some stories or reviewing and refining your existing stories to take what we learn into the real world.

Acknowledgements:
The Lego House exercise that I run has been created by combining my experience with a number of other exercises, including the “XP Lego Game” and Rachel Davies‘ Household Stories exercise.

Footnotes:

[1] “Advantages of User Stories for Requirements” by Mike Cohn (See also his book, “User Stories Applied”)
[2] Typical user story format: http://guide.agilealliance.org/guide/rolefeature.html
[3] There is a lot more to user stories than this three line statement. The simplest explanation is that this is just the ‘Card’ in the three C’s of User Stories: http://guide.agilealliance.org/guide/threecs.html
[4] A key characteristic of user stories is there are few dependencies, if any, between them and each is valuable. This is explained by the mnemonic INVEST: http://guide.agilealliance.org/guide/invest.html

Scenario: Upgrade my SomeService subscription from Basic to Pro.
Given I am on the Basic plan
When I upgrade to the Pro plan
Then I see a message confirming the upgrade
And I see that I am now on the Pro plan
And I receive a personal thank you by email
And SomeService keeps a record of when the upgrade happened
And SomeService keeps a record of payment

There’s a feature I rarely see used, the ability to use bullets (with asterisks ‘*’). I’ve found that using this among steps with Given/When/Then can remove some of the clutter, making the scenario easier on the eye…

Scenario: Upgrade my SomeService subscription from Basic to Pro.
Given I am on the Basic plan
When I upgrade to the Pro plan
Then I see a message confirming the upgrade, and:
* I see that I am now on the Pro plan
* I receive a personal thank you by email
* SomeService keeps a record of when the upgrade happened
* SomeService keeps a record of payment

What I don’t like about this, however, is how the ‘Then’ step appears in a different context to the bullets and seems less important. To make sure that all the steps are seen as equally important, I can do this:

Scenario: Upgrade my SomeService subscription from Basic to Pro.
Given I am on the Basic plan
When I upgrade to the Pro plan
Then the following occurs:
* I see a message confirming the upgrade
* I see that I am now on the Pro plan
* I receive a personal thank you by email
* SomeService keeps a record of when the upgrade happened
* SomeService keeps a record of payment

Note how I’ve put in a “Then” step that segues from the “When” to the actual expectations.
A ‘Segue Step’ doesn’t have to do anything, other than transition the reader from the previous steps to a list of expectations:

Then /^the following occurs:$/ do #nothing
#just segue to the next step
end

Another way of using a Segue Step could be like this:

Then I should:
* See a message confirming the upgrade
* See that I am now on the Pro plan
* Receive a personal thank you by email
And SomeService should:
* Keep a record of when the upgrade happened
* Keep a record of payment

Asterisks can replace the opening keyword of any type of step, but using them in this way for Given or When steps could be a scenario-smell, suggesting that the scenario has too much detail or those steps are at the wrong level of abstraction. Using asterisks and Segue Steps are most appropriate in “Then” statements with two or more “And” lines.

After doing this, reading scenarios without asterisks and ‘Segue Steps’ now feels like the “And Then” scene from “Dude, Where’s my Car”…And then? I hope you find it useful to write better scenarios too… And then? And then? And theeeeeeeeeeeeen! And thenandthenandthen!

Special thanks to Andy Palmer for reviewing this blog post and helping me say it with fewer words.

‘Internet radio‘ has come a long way since it first began. Long gone are the days where you have to seek out an online station that streamed a preselected playlist with mostly music that you like, or several stations for those with more eclectic taste. Instead, services like Pandora.com and Last.fm create a personalised radio station that matches the user’s own personal taste.

These personalised internet-radio stations are far more sophisticated than just specifying what genres and styles you like. When they first started you didn’t do that at all. When last.fm first started you provided an example of a song that you like. Software analysed the song finding common aspects of the music’s ‘DNA’ – including genre, tempo, how melodic it is and countless other sound characteristics in their database. From this they create a user-specific internet radio station that matches the users taste. As you listen, you give them feedback saying which songs you love and which ones you hate. Your future play-lists are refined with each piece of feedback you provide. This feedback is in itself more examples of songs that do and don’t match your taste. As a result you’d find yourself listening to songs you’d not have otherwise discovered.

That is Specification by Example! The product (in the above, your personal playlist) evolves by inferring the desired rules and characteristics from concrete examples.

And, as several have been saying for years… Test Driven Development is just that – Specification by Example – applied to software development. Instead of examples of songs, we provide examples of what we’d like the product, or part thereof, to do. These examples take the form of tests. It so happens that the evolution of the software product is performed by humans, unlike the internet playlist evolved by a machine.

Go-karting is where most of the current Formula One racing drivers first learned the basics of race-craft. Antony Marcano, a former kart racer himself, recounts a father-and-son racing experience that helps him explain what goes wrong for many organizations that adopt Scrum as their first attempt to “go agile.”

In this article I explained how novice drivers try to go as fast as possible rather than trying to master the racing line:

At the open practice session my son and I attended, novice drivers seemed to approach their first lap as if it really were as easy as experienced drivers make it look. They floored the throttle and flew down the straight only to crash—painfully and expensively—into the barrier at the first hairpin turn.

I went on to liken this to how many teams adopt agile…

Organizations starting their transition to agile methods with Scrum are much like the novice drivers trying to go fullthrottle before learning how to take the corners. Before being able to truly bend and change their software with speed and ease, they fly into short iterations and frequent incremental product delivery—crashing painfully into the barrier of hard-to-change software.

It was my son’s first experience in a go-kart. We started by driving slowly with him following me to learn the racing line. We gradually went faster and faster. Soon, we were the quickest drivers on the track.

Since then, he has gone on to advance further and further in his racing. Back then, we were in slow, 35mph go karts. This year he started racing for a team in race-tuned karts (see photo). The driver-coach in the team watched him driving on his first few attempts in his new high-performance machine (70+ mph, super-car acceleration). While he was reasonably quick, he wasn’t smooth.

His coach told him “slow down”. His coach said “whatever speed you can do while still driving on the ideal racing line is the speed you should be going”. My son went out again. Initially slower than he was before, his speed progressively built… we watched his lap-times improve dramatically.

Yet again, we relearned this lesson: slow is smooth–smooth is fast.

For some reason, I see teams who are novices in agile development make the same mistake, however, not always feeling like they have a choice. Kanban might make it easier to start from where you are and gradually improve but it’s ok if you’ve decided to start with Scrum. When starting with Scrum, start slow, focus on doing fewer things well first then progressively improve. On a course I gave recently, one of the attendees said “but how do you get management and marketing to back-off enough to allow us to slow down?”

My answer: avoid going faster than you can. But if you feel compelled to go faster, make it a business decision. Help them understand that there is a risk that whatever time you save now will cost you more in the future. Help them understand all the effort you’ll spend repairing the damage that going too fast will cause. Pretty soon you’ll be spending so much time fixing problems and struggling to adapt hard-to-change code that there will be little capacity left to add new features. Essentially, incurring a  “Technical Debt” .

As a general rule, I always try to start something new, slow and steady. I only go as fast as I know I can while predictably and sustainably delivering. I’m mindful of business pressures but experience has shown me that by focusing on “making things right” we can deliver smoothly, build trust and progressively become faster.

—————–

[1] You can read the original article here: Putting the Kart before the Horse? – published in Better Software Magazine, 2009

My son’s story is continued here: http://damanimarcano.com

Is updated here: https://www.facebook.com/DKMRacing

And here: https://twitter.com/DKMRacing

And here (updated 03-02-2014)…

UPDATE [11-12-2013]: Damani Marcano finished his first ever season 3rd in the Hoddesdon Kart Club Championship Junior Rotax Formula at Rye House, the track that started Lewis Hamilton’s career. This achievement is significant since, as a novice license holder, Damani had to spend the first half of the season starting every heat from the back of the grid. Find out what happens next season by following his story on Twitter and/or Facebook. Who knows, by adding to his ‘likes’ / ‘followers’ you may become a part of his story by helping him become more attractive to a potential sponsor.

…we’ve heard a number of leaders in the Agile community promoting the idea that you should focus on doing the right thing – discovering what customers really want and need – rather than focusing on building and deploying working software

David disagrees because…

“doing things right” creates the circumstances to enable deferred commitment. Deferred commitment enables better predictability and faster delivery and a virtuous cycle ensues. Deferred commitment forces hard selection decisions and creates a focus on how selection is done. Combined with the limited WIP of a kanban system, deferred commitment raises awareness of the scarce resource of engineering capability. This is turn focuses attention on how to best utilize that scarce resource by “doing the right thing.”

There is another reason why focusing on “doing things right” is a good idea. One of the very principles behind many agile/lean approaches is iteration, allowing us to make the wrong thing so we can see it is wrong and more rapidly figure out how to make it right. The ability to do that quickly in an easy to evolve product is a significant aspect of agile approaches. “Doing things right”, as David points out, is the path to making this rapid evolution viable.

One way this is relevant is when we give the customer what they say they want so that they can then see what they really need. The ability to iterate quickly and predictably, as David clarifies, builds trust and leads to getting the right thing faster.

So, I entirely agree with David, however, I would phrase it in a slightly different way. To me, there is a distinction between “doing things” and “making things”.

David is talking more about what I would describe as  “making the right things” vs. “making things right”. I think of “doing” as a layer below this. Where “making things” is more what we do and “doing things” is more how we do it.

doing the right things -> doing things right -> making things right -> making the right things

For example, using TDD might be “doing the right thing” but maybe the practitioner isn’t very experienced in it and is not using many of the techniques that give them the most benefit for the effort they put in. While they might be effective, by “doing the right thing” (TDD in this case), they are not as efficient at it because they’re not yet “doing TDD right”.

So, if you ever hear me talk of “doing the right things” before “doing things right” then it’s because of this distinction in my mind between “doing” and “making”.

Start with “making things right” and you’ll get better at “making the right things”.

To improve at “making things right”…

Start with “doing the right things” and you’ll get better at “doing things right“.

—————————

Footnote :

Barry Boehm is the first thinker who I saw use the phrase…”Building the right thing” vs. “Building things right” in his 1981 book Software Engineering Economics. I use the term “making” because it’s a more general term that has fewer implications on “how” we create a product. This is partly because developing software products with agility doesn’t feel like “building” to me.

To me, modern (agile) software development feels more like pottery. But, instead of ‘throwing clay’ we throw our consciousness, in the form of electrons flowing over silicon, onto a spinning wheel of user-story implementation cycles.

We evolve our understanding of what our customer wants with each conversation. We reflect that understanding by evolving the product’s shape as we touch the outer surface with each new automated acceptance test (or example scenario). We evolve its structure as we touch the inner surface with each new unit test (or unit specification). We keep it supple as we moisten it with each refactoring. Our customer looks on, gives us feedback and we start the next revolution of the software development wheel. Never letting the product dry and harden; keeping it flexible, malleable, soft(ware).

There is nothing that feels like construction here. I never feel like I’m “building” something. Much more like I’m evolving my understanding, evolving the product, evolving my understanding again and so on.

For these reasons l am not comfortable with referring to this process as “building”. I’m also not comfortable calling it “throwing” (as in pottery).

I am very comfortable calling it “development”. I use the word “develop” in terms of its literal meaning:

“to bring into being or activity; generate; evolve.”
–dictionary.com

From the first thought of a new idea, through each conversation along the way, to each revolution of the software development wheel, I develop products.

I don’t “build”.

I create. I make. I shape. I evolve.

—————————
Footnote: I’m not aware of anyone drawing this analogy before. If you have heard or read someone explain it in this way before now, please let me know.

Enabling Serendipity

For example, Google’s 20% time, where employees can spend 20% of their time working on anything they like, has resulted in numerous “happy accidents” where pet projects have matured into fully fledged revenue enhancing products, such as gmail.

Charles Leadbeater talks of the “we think” phenomenon, where innovation occurs simply by people having access to products that give them flexibility in how they use them. This philosophy taps into the free thinking collective consciousness of the social web. The birth of Twitter is the perfect example. Hash tags, “@” mentions, retweets are all customer innovations that were subsequently added to the Twitter experience we know and love today. It’s highly likely that “@” mentions were a significant factor in boosting user engagement and hashtags are now one of Twitter’s revenue sources.

Countless more examples exist but how is this achieved and what does this have to do with serendipity?

Adrian Cockroft of Netflix explains that you can’t force innovation, you have to get out of the way of innovation. This applies to what we enable people to do with products, such as the Twitter story, as much as what people do with their 20% (or more) time.

Facilitating Serendipity

It’s not just the organisation that needs to embrace serendipity, the working environment does too. In “Designs for Working” Malcolm Gladwell highlights:

“Who, after all, has a direct interest in creating diverse, vital spaces that foster creativity and serendipity? Employers do.”

He uses Greenwich Village, where opportunities for people to meet by happenstance are rife,  as a model for the ideal work environment. Many of his ideas can be found in the forward thinking companies, I’ve already mentioned, that are breaking all the rules and being so successful as a result.

Much innovation in what we produce or even how we produce it may never have happened if they had required a typical business case or if the working environment was more like a factory-line or made up of closed offices.

The Serendipity Economy

Daniel Rasmus, the person who coined the phrase “the serendipity economy”, captures the problem with your traditional business case so well when he says:

“If the only economics you have to work with come from the industrial age, then everything looks like a factory.”

Rasmus highlights, in “Welcome to the Serendipity Economy”, the benefits of knowledge, ideas, experimentation are not immediate or predictable within a specific time-frame or quantifiable with traditional measures of productivity or returns on investment. He highlights the importance of serendipity in innovation and the power of social networking in accelerating the process.

I was talking with one client the other day about their budget approvals process. It was so heavyweight that several increments of the product could have been developed with the money spent on documenting theoretical feasibility and commercial viability.

Exploiting Serendipity

Instead, companies would be better off adopting a lean start-up model for new projects. Ensure that employees have social networking tools at their disposal. Share the ideas. Create a simple sign up page that’s sent out to employees or even the general public. Get feedback. Provide “seed-funding” to the projects that inspire the most passionate responses. Get the first few features built. See how hard or easy it is. If it works out, you’ll have empirical data to base future estimates on and you’ll have the beginnings of the product (maybe something releasable).

All this can be done with less than many large companies would have spent on writing business cases with hypothesised technical-feasibility and unproven commercial-viability. Yes, some ideas will flop, but that experience could be the very thing that inspires your biggest success.

Google, Twitter, Netflix and more show us that investing in serendipity (and talent) is key to the modern organisation’s success. It will take a leap of faith that many feel they cannot afford to take in these difficult economic times. But, to survive and thrive in the future, you have to ask if it’s a leap you can afford to not take.

It runs completely heedlessly on PhantomJS but still behaves (mostly) like a typical webkit browser. By avoiding the overhead of actually rendering the page in a GUI it can run standard Selenium tests noticeably faster and on a headless build server too.

This is especially beneficial if you want to use continuous testing IDE plugins like Infinitest or JUnitMax or simply to encourage developers to run end-to-end tests more frequently.

GhostDriver is written on top of PhantomJS, a headless WebKit browser which uses QtWebKit.

It’s already 35%-50% faster than ChromeDriver despite the fact that QtWebKit has the standard WebKit Javascript engine. QtWebKit is moving to the V8 JS engine (as used in Chrome) which means it’s only going to get faster…

It’s still work in progress and hasn’t implemented the entire Selenium wire protocol yet but it’s certainly one to watch.

Presentation at SeleniumConf 2012: http://www.youtube.com/watch?v=wqxkKIC2HDY

Find it on GitHub: https://github.com/detro/ghostdriver/

Implemented by: Ivan De Marino