• BDD Stories that are authored outside the team contributes to a hand-off which influences design decisions.
• Because we understand something does not mean that we know how to design it.
• Be aware of when you are analysing and when you are designing.
• Be concrete and abstract late.
• Use the scenarios to close the loop with product owners, stake holders, etc.
• Developers should write BDD stories and scenarios.
• We are less ignorant at the end of the sprint than at the beginning.
• Use code to close the feedback loop for your story.
• A story and it’s scenarios can be a representation of your model, just like a picture, UML, test code, production code.
• Seek out the behavior and express intentions.
• Use the value statement to explore alternative needs.
• Product owners should not write BDD stories
• Recycle stories if there are scenarios that you cannot commit to.
• Keep out the technical jargon.  The moment you get technical, then the story shifts to an implementation.
• Evolve and accept that it is ok to change … your story, your scenario, code, anything.
• Login is not a story

There was a lot more which we all discussed, so feel free to add what you got out of it as a comment for others to grab.

The slide deck which contained the code example is available at http://bit.ly/bhNkvQ.

And lastly, thanks for joining in.  I sincerely appreciate you making the time.

Remember that writing stories is a really difficult thing to learn, because is design is hard.  Persevere.

I think I’m going out on limb here because I will be challenging the value of Product Owners writing stories.  I’m also suggesting that when Product Owners write stories riddled with behavior then developers are disconnected from domain experts and you regress into a waterfall mode of execution fronted by a Scrum Board.  So be prepared to experiment with me and turn up your self-reflection to maximum level because we will challenge many assumptions.

No collaboration, no heroes!

I thoroughly enjoyed Karen Greave’s talk on Agile Testing.  She had just about 100% coverage (pun intended, groan).  Yet, testing is really a pain in the rear.  Testing is execution, and Karen was dead-on right, that automation is the path to follow.  Computers are very good at testing.  A computer does what it is programmed to do, and it can test the way it was programmed to test.  It’s simple: if testing is your constraint, move that constraint away from testing by automating.

Now, you have to deal with the constraint that shifted to the next point: test authoring.  While testing (i.e. execution) is just a passive, laborious effort, test authoring is a very creative, active exercise.  It is actually an exercise in confirming a shared, common understanding.  Kristin Nygard said “To program is to understand” and test authoring is a programming exercise.  That’s why outside-in, behavior driven development style scenarios are actually tests, coded in a human language.  The act of authoring a scenario proves your understanding and the expected working of the software.

This is why I separate test execution (passive) from test authoring (active).  And Karen said that early feedback is good (right again), which is why I author my tests very early.  I’m extreme about this.  I test first.

Automation creates time for collaboration

Lesson to both of us: Think before you wave!

Also, I have to remind myself to not think about waves as email, or tweets or instant messages. It’s just something else! And it has a different spin on the time dimension of communication.

I suspect that Google Wave will force us to be better at the way we communicate, how we express ourselves and the relevance of the content to the conversation.  I can imagine a wave growing over time that describes a story started by a domain expert with feedback from a developer and a nice cadence emerging between them.  It all is in one nice wave, with playback that tells you how you got there in the first place.  I wonder if this will have an influence on effectiveness of remote pairing?

I also have a feeling that if you’re a waterfall type of person, then waves will not have an impact on you.  It’s all about feedback and dealing with the changes, which is at the heart of agility.

Now I just need someone to wave with to try out a slightly modified development flow.

The feedback loop is missing.  They view the stories as a spec that has been handed down.  And they have not made the connection that spec writing is design work that is intended to clearly illustrates concepts in a domain.  It is a form of writing code.  But it’s just that this code is, maybe, non-executable.

Here’s my workflow and how I close the loop.

• write story and scenario
• Sketch a design if needed – helps when pairing to be on the same page.
• Start writing test for scenario
• ooops … test is getting complicated? stuck?
• maybe the domain is not understood enough? Dig deeper, improve scenario, design (as needed) and continue writing test
• or maybe the scenario was badly written? Ignore scenario structure, continue writing test.  Refactor scenario later.  We’re in deep discovery mode here.
• get test to pass
• refactor code
• refactor scenario
• … cycle the red-green-refactor until happy.

Acknowledging when you’re in discovery mode and knowing that you are allowed to refactor requirements is the trick.  Nothing is cast in concrete.  That’s why I like frequent feedback loops with tight turning circles.

No feedback loop, no progress.

BTW, I really don’t like explaining such things as flow-charts and sequences.  You got to find your own style.  It’s not a recipe or rules thing.  The above is something that is about as close to what I do but it changes when the need arises.  That’s also another key feature of being agile – adapt or die in the waterfall.

But I am worried.  In the 45 minute talk, I did 5 minutes with Ruby code and cucumber.  Now so many people want to use cucumber.  Good for cucumber.

I think I should have stressed my point a lot more.

Take-Home #1: Find a way to make the life cycle of requirements part of your workflow.  Should it be a hard dependency?  If the requirements change, then do you want the build to break?  When requirements have a life cycle independent of the code’s life cycle, then you are opening yourself to waterfall-ish problems.

Take-Home #2: Agile in name and process can only take you so far.  You have to live it in your head and in your life.  For me, agile has a very Zen-like characteristic.  You need to live in the moment, absorb the feedback in that moment and adjust your next action in response to all this stimuli.  We are just like an amoeba that reacts to changes in pH.  But the difference is that we are capable of controlling our re-action or subsequent action.  An amoeba is agile by process only.

Take-Home #3: BDD can help you to change your coding and architecture attitude for the better.  It is subtle in its intrusion, but profound in its impact.  The subtley makes it dangerous.  It is not about the clever use of words, it is about the way those words impacts on your code and your resulting architecture.  So find your own cucumber and that does not mean you should go looking for another gherkin.

Perhaps I was not responsible enough.  My actions and words have affected people in a way that I did not intend.

I will also be giving a talk about Agile Requirements.  It’s about behavior driven stories that go beyond traditional, fully dressed used cases.  However, I will focus a lot more about the process and thinking behind this approach as opposed to the code behind the stories.

I always meet very interesting people at SPIN.  Please take 2 hours from your evening and join us for some great geek chat at the Bandwidth Barnyard at 6.30pm on 15 April.

Update. You can get the presentation here.  The size is optimized for iPOD and is quite viewable on your desktop as well.  The tiny bit of ruby code is included in the zip as well.

So, I posed the question “How far away are you from executing your requirements?”. If you are going to go through various steps and stages to get to compilation and then execution, then every step is an opportunity for valuable information being lost in translation. If you can compile your requirements immediately then nothing will be lost.

Each additional step between requirements description and compilation and execution is an opportunity to confuse the user and the developer and everyone in between.  That’s why fully dressed use cases are not so effective as fully dressed behavior driven stories.  And that’s why BDD is very agile and a great asset in DDD and use cases just don’t cut it anymore.

Right now, my favorite tool is Cucumber.  I can execute the requirements and that raises the clarity ranking of my requirements super high.

Then I started thinking about what it takes to coach external DSLs.  I got really scared – parsers, generators, abstract syntax trees.  Those were things that most people wanted to forget about the day after they wrote the exam for that horrible semester course in university.  What makes it worse is that I never did that in university – I did Electronic Engineering and we spent our coding time figuring out how to do Fast Fourier Transforms on digital signals.

But when I look at the progress that is being made in language workbenches to help us create DSLs, then I reckon we should dust off those books and start paying attention again.  Some of these language workbenches still leverage a host language such as Java or C#, but the act of using a structural editor that edits the AST directly is strangely weird.  But, some refactorings are just not a problem anymore.  For example, if you are changing the node on a tree, then all the references to that node are automatically aware of it.  Compare that to a text editor where you need refactoring wizardry in the tools to make sure all references are updated neatly.

I think that language workbenches may be a great tool for coaching DSLs because the things that made your head spin during that lex and yacc week, are made a whole lot simpler.  You can focus on designing the language and walk into ASTs with less fear.  But, be warned — language design is not easy, and you still need to know about ASTs and parsers and generators.  In fact, just write a parser and a generator and it will be a learning experience that goes beyond DSLs.  Better still, do it BDD/TDD style.

The relevancy of language oriented programming is just going to continually increase.  Those previously “irrelevant” courses are important again.  Watch out, the gap just got wider.

• Solving Domain Problems with Aspects has a couple of slides with repeated transitions (courtesy of the export ).  This one has the flying code, as Claudio Perrone calls it!  And it is the presentation that lead to the chat with Ayende Rahien.  He has done something similar in C# here. - 29.1MB @ http://aslamkhan.net/wp-content/uploads/2008/11/SolvingDomainProblemsWithAspects.mov

• Managing Diversity in Agile Teams was inspired by Claudio’s presentation style.  Highly visual with minimal text.  It’s about story telling, movie script style and not about bullet point presentations.  Thanks, Claudio! - 16.6MB @ http://aslamkhan.net/wp-content/uploads/2008/11/ManagingDiversityInAgileTeams.mov

• Bootstrapping your SOA Project has the slides for the workshop that I ran.  It’s a mixture of traditional and visual.  The traditional is used purely for reference / take-home material. - 13.5MB @ http://aslamkhan.net/wp-content/uploads/2008/11/BootstrappingYourSOAProject.mov