The FitNesse Narratives project that I've been working on along with Andy Palmer, has reached a major milestone - our first story is functionally complete. We're finishing off some refactoring and need to automate the build but once those things are in place our 'Iteration 0' Story will be done.

I thought that you'd like a preview of the NarrativeFixture, the star of this story, so you can start to see where we are going. You'll be able to get your hands on it and use it yourself soon enough.

Yes, that's right... I'm giving a public course in Agile Testing (or Agile QA as some might call it) on Thursday 9th July in London with Rachel Davies and in association with SkillsMatter.

We cover everything from Agile fundamentals through to Acceptance Test Driven Development and Behaviour Driven Development.

I frequently encounter people who tell me of risk management courses that they've been on and tell me of four (straight from Wikipedia) strategies for addressing a risk::

• Avoidance (eliminate)
• Reduction (mitigate)
• Transfer (outsource or insure)
• Retention (accept and budget)

I'm no risk management expert, but I've certainly got plenty of experience in it. I am a lover of language and words and immediately notice one small problem with this model - the use of the word "Mitigate".

"Mitigate" is a commonly misunderstood word. Many use it as a synonym for "reduce" but it actually has a special meaning:

to make something less harmful, unpleasant or bad -Cambridge Dictionary

It's been a while since I wrote it... but it's finally in print.

Putting the Kart before the Horse?

A former go-kart racer recounts a racing experience that helps him explain what goes wrong for many organizations adopting Scrum as a first attempt to “go agile.”

I'd written a blog post about this topic in early January. Reflection on my son's karting experiences gave me two useful metaphors to get the point across. Actually many points... including this one:

Some have given me feedback that it's not that easy to find out how to contact me... or how to pass information about me onto other people. To address this feedback, I've put together antonymarcano.com.

Enjoy.

If you've been following pairwith.us then you may have heard us mention the the pomodoro technique.

If you're a mac user (as I now am) and use the pomodoro technique (or want to try it) you may find this timer dashboard widget useful, that with some minor tweaking looks like this:

I spotted a tweet by Mark Needham referring to a blog post by Brad Wilson coining the phrase "Design by Example".

I like the Design by Example (DbE) name. It's nice. It rolls off the tounge, more so than BDD in my opinion. But it misses out on the "development" (in the literal sense of the word) in the way that phrases ending in "-Driven Development" don't. It does better emphasise the initial purpose of TDD/BDD/DbE - i.e. design. Although design is the initial purpose, the automated tests or 'executable design specification' provide you with the safety to refactor, as Brad himself says.

In a previous post I introduced a project I'd started with my friend Andy Palmer.

We simply wanted to have a way of journalling our efforts on a new opensource project (don't try and download what's on the public repository - we're treating that as a spike and will be making the latest code available once our first story is complete). We decided that the best way to journal our efforts would be by recording a video of our development sessions.