May 19, 2011

...Learn TDD with Codemanship

Agile Design Workshop - Telling User Stories With Pictures



Hello there. Long time no see.

I've been travelling (like a Wilbury, whatever one of those is) around and about the countryside running training workshops this last week or so, and I thought one course in particular might make an interesting blog post. Though I'm probably wrong about that.

Agile Design is a 2-day workshop for teams where they design and build working software, collaborating on the design while working in pairs on different user stories for the same system - a community DVD library.

The format of the workshop is simple: on the first morning, I give them a crash course in object oriented analysis and design, a bit of Ugly Modeling Language (just enough to be dangerous) and some Acceptance Test-driven Development (you may know it as "BDD" - which stands for "Bacceptance Dtest-driven Development").

Then I hand out some user stories, which I make up on the spot just to keep it interesting for me, and split them off into groups of 2-3 to work on the design for their story. They're instructed to follow a particular object oriented thought process, which is common to pretty much all OOA/D approaches (excluding the ones that don't work.) For each user story, they ask these questions, and answer them using the appropriate modeling tool:

* Who will be using the software, and what will they be using it to do?

* How will the user interact with the system to do it?

* What objects are involved in these interactions?

* What does each object do, and how do these objects interact in telling our story?

They follow this line of questioning for a specific user acceptance test, specified in the popular "Given... when... then" format (because I think it's very important to confuse people by adopting arbitrary fashionable conventions), and their goal is to design and implement the code to pass the test.

Of course, they're all actually working on different slices through the same code - the same classes - and what we end up with is 4-5 groups all working simultaneously on different aspects of the same 5-6 classes. In the normal universe, this would usually lead to what scientists call "a train wreck inside a shitstorm".

In the universe of Agile Design, though, something quite magical tends to happen. By visualising their designs and externalising their thinking for the other groups to see, somehow these groups manage to co-ordinate a single, coherent design. In our community library, there is only DVD Copy class, with only one borrow() method and one return() method, and it all sort of hangs together nicely as one complete system that just so happens to pass all 4-5 acceptance tests.

We don't stop and do the whole design together. Each group is genuinely working in parallel to the others, trying only to pass their acceptance test, and all making progress at the same time.

But the teams do synchronise. Frequently. Throughout the first day, there are huddles and there are teams going over to see what other teams are working on and addressing any overlaps or inconsistencies before going back and adapting their code if required to make it all fit.

They are also strongly encouraged to integrate their code frequently, and to get frequent updates from source control as the code evolves. And, no, they are discouraged from updating their UML diagrams as the implementation diverges from the plan. The ultimate model, the one that's most accurate and up-to-date is the code. The code is the model.

So they do just enough design, then they "prove it with code", Scott Ambler-style. And being able to see what they're working on makes all the difference between a concert and a train wreck.

On the second day, the same groups move on to designing a user interface (yes, we do the UI design last!). Just as it was with the classes in their domain model on day one, they have to identify the common characters they'll all need to tell their UI stories. What does the Library look like? What actions must it support? How will the user invoke those actions? What does a Member look like, etc etc. They collaborate to build a visual language for re-telling their user stories, this time with interactive graphics.

These characters - both in the code and in the UI - are central to the discipline of telling stories together, as a team, that all take place in the same consistent universe of possibilities. In much the same way, if you were to walk into the offices of an animation studio, you may see a thousand artists all working on telling different parts of a story, or different episodes in a series, that all take place in a universe of characters and places, each obeying a consistent set of rules. Which is why you'll often see sketches of the characters displayed prominently on the walls, as well as notes about how these characters behave - the rules that govern these characters across all of the storylines that involve them.

In Agile Design, we work in an iterative and highly collaborative fashion to identify and flesh out the characters in a set of stories that have a happy ending for the customer. We tell the stories and retell them, over and over, evolving the characters and adding more flesh to the bones with each pass until finally we're telling the story in working code, feeding back to the customer at every stage so we can gauge their reaction to each new level of detail.

Every time I run this workshop, the teams suprise me with just how readily they manage to go - in many cases - from having done little or no collaborative design, little or no visual modeling, no acceptance testing, no build automation, no continuous integration, and so on, to doing all of it, and within the space of just 2 days.

This is partly, I suspect, because I've been lucky with the teams involved - smart and passionate developers who are quick learners and, to coin a phrase, "definitely up for it".

But I also think this workshop, among all of my training courses, seems to bring out something extra in the teams who participate. I could be wrong about this, but I think this may be one of the most team-oriented developer workshops out there at the moment.

It's certainly a joy to run, and teams seem to get a kick out of taking part, and do genuinely seem to get a lot out of it. At the very least, it raises some very useful questions within the team about how they currently work, and on every occasion so far, the workshop's have ended with a discussion along the lines of "so, when we get back to the office, we should do this, or this, or that, or the other".

I love my job.




Posted 6 years, 10 months ago on May 19, 2011