Schedule (2012)


09:00 Registration/Coffee
09:30 Opening Circle
10:15 Session 1
11:15 break
11:30 Session 2
12:30 lunch
13:30 Session 3
14:30 break
14:45 Session 4
15:45 Keynote: Growing Fast Within Government
16:45 To the Pub


09:00 Coffee
09:30 Re-Opening Circle
09:45 Session 5
10:45 break
11:00 Session 6
12:00 lunch
13:00 Session 7
14:00 break
14:15 Session 8
15:15 break
15:30 Closing Circle
16:30 Thanks
16:45 To Bishops Finger Pub (the usual xtc venue)!

Technical Sessions

Chris Parsons BDD Kickstart

Monday 10:15 – 12:30

An introductory practical session teaching people the basics of Cucumber with BDD and how to apply it to their contexts.

It will focus on

  • how to write a great feature
  • how to ensure that your features are maintainable over time, to avoid your tests crashing to a halt and inhibiting your project
  • how to practically apply TDD within the BDD context

The session will end with a practical working through building an example application in Ruby.

Attendees will be working in pairs so at least one of each pair will need a laptop with ruby 1.8.7 or later environment set up. The example app has all the gems locally on a USB stick or they can be grabbed from a github repository

Nat Pryce & Keith Braithwaite Property-Based TDD As If You Really Meant It

Tuesday 13:00 – 15:30

A workshop in which we run Keith Braithwaite’s TDD As If You Really Meant It session using property-based testing tools and reflect on how property-based testing changes the TDD process compared to example-based testing.


When TDD was introduced in the late 1990s, it was in terms of example-based testing tools, such as the xUnit family of frameworks. Since then, powerful property-based testing tools have become widely available. Originating with the QuickCheck library for Haskell, property-based testing tools have now been ported to all major languages (and many minor languages).

These tools have not been adopted by the TDD community. Why is this? Are we TDD practitioners stuck in a late-’90s XP-shaped rut? Do we dismiss anything that was not invented by a Smalltalker? Or are property-based testing tools just not as well suited to the TDD process as example-based tools? How does a property-based testing tool affect the TDD process & the designs that the process drives?

We don’t know. Let’s find out!


Introduce property-based testing tools, the rules of TDD as if you meant it & property-based TDD with QuickCheck or JUnit 4 Theories
First coding period
(Presenters go around encouraging participants to follow the rules of TDD As If You Meant It).
What’s hard? How does it compare to TDD with examples? Anyone got *anywhere*? Share what we’ve learned.
Continue coding
Maybe trying a new approach based on what everyone has shared.
Show and Tell & discussion
  • How do property-based testing tools change TDD?
  • Do some coding styles, languages or problems make it easier to use property-based testing in a TDD style?
  • Does property-based testing push your design in any particular direction?
  • How can we change the exercise to better explore property-based TDD?

Further Reading

Koen Claessen and John Hughes (2000). “QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs.” Proc. Of International Conference on Functional Programming (ICFP), ACM SIGPLAN.

QuickCheck for various programming languages

The Practice of Theories: Adding “For-all” Statements to “There-Exists” Tests (David Saff, Marat Boshernitsan) Submitted to IEEE Software, Special Issue on Test-Driven Development.

Experience Reports

The Strangler Pipeline by Steve Smith

How to Continuously Delivery greenfield and legacy applications “en masse”

What would you like to learn?
If other people can relate to the technical and people challenges associated with scaling Continuous Delivery

What do you want to share with others?
A warts-and-all experience report, largely copy and pasted from a previous 30 minute presentation at Sky Horizons 2012 ( and my perpetually-in-draft Strangler Pipeline series at

Cost of Delay by Joshua Arnold

Why and how to use “Cost of Delay” better to understand the value and urgency of the features you could be developing – and using that understanding to make better decisions.

What we’ve learned from using this across a $100m p.a. portfolio for a Fortune 500 company.

Intended audience: Anyone involved in making decisions in the software development lifecycle.

Lean and the Enterprise: Maersk Line’s journey by Ozlem Yuce

Learn about the journey that the world’s largest shipping company, Maersk Line, have taken so far in testing, implementing and learning about Lean-Agile across the whole organisation.

Maersk Line operates the world’s largest container shipping fleet, with 325 offices in 125 countries, with a turnover of $26 billion per year. Maersk Line IT has over 20 development teams spread around the world with a mix of onshore/offshore and thin outsourcing.

The Wrath of Waterfall: Historical view of how we worked
First Contact: A giant project (X-Leap) – what we learned. what worked, what didn’t
The Search for Agility: LPD – piloting eight Lean Product Development practices
The Final Frontier: The Enterprise! Agility at scale (rolling out across the organisation, scaling and centralising key components)
Next Generation: LPD 2.0 (what we’re doing now, where we’re heading)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s