XPDay London 2007

Keynote: Embrace Uncertainty – Jeff Patton

Jeff gave a very engaging presentation explaining some of the issues created by producing an incremental process from sprint iterations. He used a number of pop-stars to illustrate the point.
Roger Waters (Pink Floyd) was product owner concentrating on the burn-down wall and how each story (or brick) was been removed from the wall (or not).

Melanie Brown (aka Scary Spice – Spice Girls) was the lead developer asking Roger to, "tell me you want, what you really want". As the iterations started, Roger could see the bricks been removed (the velocity) but also started to see shortcomings in the product. So he asked for those problems to be solved and Mel B obliged by adding those new bricks to wall. However, inevitably, the deadline loomed and the only way to ship on time would be to cut bricks from the wall, something that Roger’s sponsors will be really upset about.

Jeff then introduced us to another Roger (Daltrey) and Pete Townshend (The Who), they are interested in building a road (magic) bus. They have similar problems with cost and deadlines but they know what to do. They’ve got a set of items (stories/bricks) that make up a bus; e.g. steering, sound system, engine, drinks bar, etc. However, that list doesn’t tell it all, e.g what sort of engine should they have? The decided to construct the bus by targeting the must-haves and by only implementing the basics versions of those items.

The model is translated back to Roger and Mel, by partially implementing stories to a point where they are useful it allows resources to be spread across the waiting stories. I.e. you can produce a working product, it might not have the expected bells and whistles the Roger wanted but at least he’s got a product. Importantly it will be released and be able to start realising revenue ASAP.

Jeff summed the process up with Johnny Rotten (Sex Pistols), "I don’t know what I want, but I know how to get it"

I really enjoyed the keynote, and I could have gone home then and felt it was value for money!

Plus quote of the…year, about team work, ‘You have a hole in your side of the boat’

[edit] – other reviews…

http://adamcohenrose.blogspot.com/2007/11/xpday-2007-embrace-uncertainty-jeff.html

http://www.kerrybuckley.com/2007/11/21/xpday-7-jeff-patton-keynote-embrace-uncertainty/

 

Introduction to Agile: The Software Development Paradox – Clarke Ching

The introduction was good and re-enforced a number of points from the keynote. I really enjoyed the point about software engineering following manufacturing rather than product development, see the cake slides. To paraphrase the cake story, if you wanted to mass produce a cake would you create a recipe, create a factory, mass produce the cakes and only then taste them? Of course, not, you’d taste the cake in the product development stages where it’s much cheaper to change. I thought you could also extend the analogy further by introducing quality control in the manufacturing process but hey that probably muddies the point.

The Social Nature of Agile Teams – Elizabeth Whitworth

An interesting study in the side affects of working in a agile team. The study was on the positive affects and they all seemed to solve problems I’m keen to solve; shared knowledge, knowing what is going on (and expected to be done), reduction in "dark room" developers, etc. All good stuff.

Exceptional Ideas: How to get your message through – Lasse Koskela

A bit of odd one this, ironically I’m not sure what this had to do with Agile development. I think the idea was to be able to sell Agile to non-developers, but the concepts can be applied to anything.
Talked about DICEE;
Deep. A great product is deep.
Indulgent. A great product is a luxury.
Complete. A great product is more than a physical thing.
Elegant. A great product has an elegant user interface.
Emotive. A great product incites you to action.

and SUCCESS – so successful I’ve forgotten what it means already!

Choosing the Content of Sprint & Product Owner Backlogs – Tom Tourwe & Olivier Biot

Talked about how to choose the items and were very LEAN like. I didn’t really like this one as I got the distinct feeling that the message was much simpler than they were making it. I also think they seemed to suggest a too lean approach, e.g. they seemed to suggest things like doing a feature and then worrying about performance later. I asked them about that and they quickly said they didn’t mean that but I know a few of us in the audience felt that’s what they saying. I must say that it was good that they shared their experience but just needed to add a couple of extra points to clarify their ideas.

Agile Investment in Software: Who cares how you build it? – Chris Matts

I enjoyed this and Chris is an engaging character. He said it was going to be confrontational but actually I thought his message was exactly what I thought was Agile anyway. Chris shared his experience about using an Agile process to make business decisions about what to build and therefore decreasing the time-to-market of products. One of his key arguments was that no decision should be made without the business agreeing it. E.g. a developer shouldn’t just refactor some code, they should declare the issue and it should become yet another ‘story’ that the business can decided to implement. That was all good stuff but it went a bit downhill when it seemed to offend people’s purist view of what Agile is, what a development team is, the responsibility of IT, etc, etc. That bored me, but the rest was interesting.

Day 2

Keynote: Cheek-to-cheek: why co-located collaboration persists – Yvonne Rogers

An interesting talk about how important it is to be in the same building as your colleagues and the hurdles of some communication devices (e.g. whiteboard, shared monitor, etc) where people can become frustrated waiting for their turn. Unfortunately that’s a 5 min talk drawn out for 60 mins. Not for me this one.

A Technical Story – Alex Vandenberg

A talk about how technical stories muddy the waters and really any useful technical story should be put in terms of a user story. I don’t think this is a surprise but again it re-enforces this sharing of to-do lists with the *whole* team rather than just the developers.

In the non-functional design space no-one can hear you scream – Sallyann Freudenberg

This was a gold-fish bowl workshop about how to take non-functional ‘requirements’ into account. When asked, "does anyone not understand the difference" I stood up. It’s not that I don’t know what they are but I don’t understand how anyone thinks of them as different. To develop a feature without considering things like the performance, how will it be deployed, what kit are we aiming to use, etc, is beyond me. Sure someone has to decided those things and consult with the customer but that’s part and parcel of any development isn’t? I liked and agreed with what some people said but was dismayed at others. Quotes such as, "it’s difficult because it’s not taught in computer education" just annoyed me. Talk about being spoon-fed, especially when the self same people were complaining about the quality of some developers – hmm.

Business is having to change faster to respond to its customers – how can the Agile community help? – David Stoughton

This talk described the need for business to get to market as soon as possible. For me this highlighted again that "Agile" is a concept before it is a software process. The talk also described how customers know more, the power of a brand and other important market points.

Fiat Lux: Testing with the light on – Joan McGallard, George Joseph & Pushpa Sebastian

A good talk about their experiences in creating automated acceptance testing. I did like their ‘active document‘ where the tests were written in English, via HTML, where the values were decorated with classes that were used to automate a test.

The Secret backlog – behind every bug report is a user story – Antony Marcano

Antony discussed how with a bit of creative re-writing a bug report can be turned into a user story. Subtle wording can be used to show where the story came from, e.g. "Instead of <behavior>" would imply a discovered problem. This is quite nice as it increases the visibility of the to-do list and it puts a more positive spin on the issue. It also allows more people to make a decision on whether the issue should be fixed as it is now in the standard iterative processes. He also said that with this you may want to abandon traditional bug tracking systems and go straight to creating the stories. One point that I found very interested was that the tester created an acceptance test for every bug found.