Flowing in the Waves

I just had a quick Google Wave experience with Willem Odendaal and the experience of seeing the other person type was a bit weird for both of us.
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.

Testing is just a laborious pain in the rear

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.

Modeling out Loud Deep Dive

For those of you that attended the Modeling out Loud deep dive at the S.Africa Scrum Gathering today, here are some things that I discussed.  It’s in no particular order, and it only makes sense if you attended the session.

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