Rimu Research

Home

Immediate Storytest Feedback

Coaching/Consulting

Paper and Talks

Background

Contact

Coaching for Agile: Introducing Storytest Driven Development

Here are some examples of coaching/training sessions that I've carried out:

1. Half day on Expressing Business Rules as Storytests

Contents:

  • Introductory talk on expressing business rules. Storytests serve both as requirements and as the means of testing that the requirements have been met.
  • Participants worked in groups of 3 to 5 people on writing storyteller for some simple scenarios that I supplied (or on their own scenarios).  I visited around the groups, answering questions, reviewing progress, making suggestions, etc.
  • Wrap up with feedback on what the participants found and want to explore further

Overview:

  • Story-tests as executable specifications.
  • How to express the business domain with concrete and meaningful examples
  • How to start with a very simple example and develop it
  • Using Fit and FitLibrary tables to express storytests
  • Workflow, calculation and constraint rules.
  • Using storytests for Domain Driven Design

I've carried this out with groups of from 10 to 50 people. I've carried this out with people from a mix of organizations as well as where all the people were from the same organization. I've done this with relative beginners through to international-level agile coaches/consultants.

2. Multi-day Onsite Coaching on Storytests and Executable Specifications

For teams that are already practicing many agile techniques, and are starting on Storytest Driven Development. Here's one example. Contents:

  • Present overview of storytests, Storytest Driven Development (why and how) to the whole team.
  • Coach customer team for 4 days. Chose several stories to work on that are coming up for development. Start with a simple example for the first story. Initially I'll sketch Fit tables on the whiteboard and alter them as we progress. We may start with a simple workflow if the Customers are used to use cases. Then we'll write a second storytest for a variant workflow. Then we'll focus on the underlying business rule and express that as a calculation rule. After we'd tackled a few stories, the Customers will gradually do more of the development of the storytests. I won't formally introduce the details of Fit tables, but will show by example what could be done. I'll also show by example how to use FitNesse.
  • Cover more detail of fixtures, etc to developers.
  • Coach programmers for 5 days. Start with two programmers on one of the storytests. How to write fixtures. How to drive into the code. When to start test driving with unit tests. Driving domain into the code. Resolving differences between current code and storytests. Handling design smells.
  • Ongoing coaching, one day a week for several weeks, to locate issues and to help with those that arise.
  • This can take longer than initially expected because the storytests often expose problems in the way that the software is being developed. Coaching in OO design, TDD, and domain design may be needed as much as coaching in storytest driven development.

    I've carried this out this general approach with several organizations, with groups of from 25 to 60 people.

    Copyright, Rick Mugridge, Rimu Research, 2006 .. 2009.