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