f3yourmind

A team that I am coaching has settled on using BDD stories and scenarios for describing their requirements and specifications.  They’ve also chosen cucumber as their acceptance testing tool.  All well and good, but they are making very slow progress and seem to be really struggling with the change in workstyle.  I think I’ve spotted the reason for this.

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.

Peter Hundermark has a nice summary of the talk on Agility at Scale that Scott Ambler did in Cape Town a few weeks ago.  And Scott had the courtesy of straightening out some thoughts on Peter’s blog as well.

Padding End Dates. End dates exist because of our immense desire for closure.  We cannot tolerate the thought of not knowing when something comes to an end.  So we would rather stick in a fake end date than no end date.  Are you prepared to stick an end date on your life, just so that you can create a finite sense for someone else?

Optimizing the whole. For me “whole” means everything, your workflow, your thinking, your architecture, your code, your communication, … everything.  But just drop into the code bit for a moment.  The reason TDD works is because it gives you feedback quicker.  It is not about the red-green-refactor process alone.  You have to be agile in your code and design too.  And linear problem solving results in linear code styles and mindless red-green-refactor results is not agile unless you are 100% immersed in the moment of exploration and discovery.  Overall, I think optimizing the whole, getting rid of wastage, lean, etc is all about finding the right balance – at that point in time, in that context.

BDUF. How much of upfront design is big design up front?  It depends on the context and the principles on which your software development is based and also who is affected by the software that is produced.  I like the phrase “little too much design up front” and “little too little design up front” which I picked up in this post by Kent Beck. (Please don’t acronymize that!).  That particular post was simple and extremely profound view, for me at least.

Just when I thought that I am making progress, I feel like a noob again.

Amazing! I just read Scott Hanselman’s blog post on finding geek balance outside of the geek world.  I started commenting on his blog, but realised I was blogging on his blog.  Here’s my own lumber-yard, geek-balance experience.

Just before Christmas, Fiona and I decided to have a deck built in the back yard.  I tossed the contractor’s quote out and decided to build it myself.  Why?  Same reason as Scott and I also specifically wanted to try my own personal Zen and the Art of Deck Building.  Fiona was naturally skeptical but indulged my mid-life crisis moment.

A much simpler design

An apprentice in a world craftsmen. DIY shops are intimidating.  I was an apprentice in world of journeymen and craftsmen.  I eventually found a benevolent craftsman who was humble enough to help me without judging me.  His ideas helped me simplify my design considerably and, more importantly, gave me some confidence.

Really listening to feedback. My paper design was a BDUF .  The moment I placed the wood on the ground, Fiona suddenly changed the location of the deck.  Short tale:  I am still building – new requirements still emerge from my main user.  Early on, I resisted every change with enormous annoyance which resulted in huge arguments.  Then I realised that the needs were real and the new requirements came from seeing how the deck looked with each step of construction.  I had an abstract BDUF and Fiona was taking in real feedback -  being agile!  And I was being rigid!

Living in the moment. I tried hard to live in the moment.  When I was digging a hole, I dug the best hole ever, deep, straight and true, until I hit a concrete block in the way.  Then my beautiful hole was a mess and I was angry at this block and tried to get past the block and continue digging my hole.  Zen moment – the task had changed.  I focused on the concrete block. Chipped away one tiny piece at a time, eventually it fractured and I could continue digging my beautiful hole.  I was focusing on the future, not the present and that screwed up my productivity.

Conflicts in collaboration. So I tried to live in the moment with everything from that point onwards.  When I was cutting wood – I cut wood and tried to get the best cut ever – to find beauty in the cut.  The one day my son, Khaleel, helped out and I got annoyed that he was messing up – it was not as beautiful as I wanted it.  After calming down and living a moment of fatherly guilt, I let him help me dig another hole and I just let him … to live in his moment.  He loved the texture, smell, etc of the sand and dirt.  I imposed my own hang-ups of not wanting to get really dirty.  I realised that he was more into having fun and I was messing up his fun – until I decided to live in the moment with him – by his values.

First release into production

Finding the balance. Building the deck has been one of the nicest non-geek experiences in recent times.  It made me think differently, behave differently, regard people differently and maybe, one day, it will quietly help me build software better.  I think the trick is to find a place where you will always be the traveler in a world of benevolent journeymen.  And when you can’t find that world, then just be a benevolent journeyman in world of travelers.