Before Scrum rose to prominence, eXtreme Programming (XP) was most practiced Agile methodology. ThoughtWorks’ Agile beginnings were with that exclusively, and ten years ago none of the enterprise consulting companies cared about Agile at all. Scrum took over when more players started promoting “Agile” as it had stronger and clearer management. The ‘iSupply’ project at ThoughtWorks’ client BP back 2002/3, was fully XP. Well, it had some team-led experimental changes, that were later detailed in an ‘Agile 2004’ presentation originally at http://agile2004.agilealliance.org/files/XR3-3.pdf that’s been taken down. That presentation talked of ‘My Supply’, but the project name was iSupply in reality, and luckily Tim Mackinnon keeps a copy of the same PDF at his site - phew!

Technologies

The technologies we used were Microsoft .Net 1.1, WinForms, and Neo a persistence technology written by our tech lead Erik Dörnenburg (now one of a few directors globally, in ThoughtWorks consulting hierarchy). BP had experimented with a web version of iSupply before ThoughtWorks was asked to lead this attempt, and one thing we realized was that it needed to run:

1. Online and occasionally offline
2. Over connections with inconsistent speed
3. With changes as a set, rather than as a series record writes in one transaction

That’s why Erik made Neo, and the BP encouraged us to open-source it from the outset. It is not so much used today, as Microsoft persistence technologies have expanded beyond the simple ‘data-binding’ that was available then (maybe in part inspired by Neo).

WinForms 1.1 itself was hard to develop for an an Agile way. ThoughtWorkers want to write tests for everything, and WinForms back then hardly lent itself to good testability, leading us to try MVP style separations. Visual Studio was not as evolved as Intellij IDEA back then, and even with an early beta of JetBrains’ ReSharper, it was hard to be fast with. At least we were used to faster. We also used an early version of NMock to aid a clean evolution of the code base, and FIT for functional testing.

We coded, as far as we could, classes that fitted the Constructor Injection idiom. We experimentally put in PicoContainer.net for formal Dependency Injection, but took it out again a day later as a single “God class” was able to do the right component composition elegantly without the help of a container.

Born from the realizations mentioned earlier, we had a bunch of non-functional requirements (NFRs). Erik, like all good architects, knew which NFRs should be dealt with sooner, and which could be delayed to later iterations, and how to explain everything to stakeholders adequately.

Iteration and Story size

The application’s domain was a hard one too: product stock level forecasting at a monthly and (a milestone later) daily basis per SKU. Because of that, we needed two kick-ass business analysts to embrace the XP ThoughtWorks insisted on, and feed us stories on a just in time basis. Samantha Lloyd aided by Alex (?) were BP staff and threw themselves into the methodology, working according to the INVEST principle. James Davison (now ITV’s Head of Delivery in the UK) was our awesome Project Manager, and with Erik, Sam and Alex prepared the next iteration a couple of days before it kicked off.

Our iterations were one week long. Project leads attempted to reduce the mandatory meetings schedule as much as possible. XP has fewer, and shorter, meetings in the calendar than Scrum by design.

Estimation in a “Planning Game” was tough for us, as there was often wide disagreement on how long a story would take to do. I’m getting to the point of the blog entry here - our average story size was 1.25 days, and that nearly always matched our estimates too according to James. At least what was estimated for a week was more or less what was achieved, and that was despite the developer disagreements. With a story size like that, you could expect one week iterations to work for you, and they did.

We did finger throws rather than using playing cards. Each finger was an “ideal day” (not abstract points). You’d bend the knuckle of your index finger for 1/2 a day. Jim Arnold (a Brit now over in the US like me) threw that for nearly every story. Similarly Mike Royle (now General Manager of ThoughtWorks “TOLA” region) and Brent Cryder (now CTO of the Dillard’s chain in the US) would throw that small quite often. Clearly, they had a strong view about how quickly stories could be completed.

And that was the takeaway - small stories, even with older technologies, and a tough app/domain:

average story size: 1.25 days including QA

Daily workflow

Aside from Test Driven Development coding and QA ….

Morning Stand-up (10-15 mins)

Stand-up was of the quick variety. What you were doing yesterday, and what you expect to be doing today. James would chastise those not engaged in the conversation, or were repeating what they’d said the day before.

Story sign-up (5-10 mins following Standup)

When Yesterday’s Story is not Complete…

One of the dev pair would rotate out, and someone else in. If the same story were to stretch into another day, the longer serving of the pair would rotate out. That happened without exception.

For New Stories…

You and your new pair, would take something from the board (refer the Agile 2004 PDF link at the top), clarify anything that needed to be clarified then go find a pairing-workstation to code it. You’d do what Scrum calls tasking with your pair at the workstation in most cases just as you were about to start coding.

Tech huddle (15 mins)

There also would be a short, impromptu, tech huddle if needed. It didn’t always happen.

The dev team

Mike, Jim, Erik and I are still in TW ten years later.

Now ex of ThoughtWorks:

• Ivan Moore & Tim McKinnon (esteemed friends from the extreme Tuesday club in London before they joined ThoughtWorks)
• Mike Roberts (in New York now)
• James Webster (in Australia now)
• Brent (as mentioned).

BP’s developer

• Julian Sominka - still at that client (but further up the chain now).