Agile 2006 – my highlights

Over the last couple of days, I’ve spent some time collecting my ideas and thoughts following Agile 2006. Spending the time to reflect has really helped to tie up the loose ends that were hanging around in my head, at least the ones from last week. I’m glad I took the good advice to stay away from email, well as much as possible, because for the first time in a while I’ve really got into “the zone” and it’s been incredibly productive. So here’s a brief summary of my highlights, and for a summary of all of the sessions I went to, check out the Agile 2006 page.

I went to so many worthwhile sessions, it’s hard to pick my favourite, but three in particular really stand out:

Ron Jeffries and Chet Henderson’s Planning Game – this session is great for two reasons: firstly, it’s fun and entertaining, and secondly, the lessons just reveal themselves through the game: to the most value from an agile project , you need to have clear estimates for the stories, you need to know your velocity, and the business needs to assign a clear value to the stories. Armed with this information, you can get almost all of the project value in the early iterations. Combine this with small, frequent releases, and then you start to see the real value of being agile and iterative. Ron and Chet have performed this session a lot, and it shows. It really is a performance, the banter and role playing were fantastic, especially in the Management role. If you haven’t done this, and you get a chance to, do it.

Programmers are from Mars, Customers are from Venus – Angela Martin and Robert Biddle – this was a highlight for me because it had some really practical, relevant guidance on splitting up the role of the customer into nine separate roles with specific different responsibilities – including acceptance tester, UI designer, negotiator, diplomat, and technical writer. They also suggested techniques such as having programmers play customer apprentice to improve interaction, and having a customer counselor for those times when you just need to vent. The powerpoint is really simple and clear, and it was good to attend a session that really focussed on and sympathised with the customer, rather than the team. I don’t play the role of customer, but it did give me a much deeper understanding of why it isn’t always as easy as you think.

The Test-Driven Development Pairing Game – Peter Provost, Mitch Lacey, Brad Wilson – this was the one session I refused to miss, and I’m glad I went, even though I had to leave Diana Larson and Esther Derby’s session on retrospectives, which I was also really enjoying. Brad and Peter have a great energy and humour, and they’ve created their own way to productively get the better of each other. Anything that makes writing unit tests fun for developers is pretty impressive, and their solution to write a single test and then pass the keyboard so that the other person makes it pass seems to go some way towards doing that. They somehow demonstrated something that combines two fairly complex practices in a really simple, easy to understand way, and entertained a group of people while simultaneously writing clean code. That’s pretty impressive. I’m just hoping that when I demonstrate it back home, it will seem as easy.

The biggest highlight of all was just meeting and talking to so many people who were doing agile – people who were still experimenting, who were learning from the same mistakes I am, and people who’d done it over and over and could share their experiences, or had the patience to listen to mine and offer advice. Over the next few weeks I hope I can share some more of my own experiences as I try and put some of these things into action!


Agile 2006: Agile/Evolutionary Database Techniques – Scott Ambler

Monday 16:15-17:00


Database design and refactoring can be done in an agile and evolutionary way.


Data is only one of the many important aspects of software development, and rarely a primary one. Agile is developed from the “object” community, and sometimes suffers from a blind spot with regard to database development.

Databases can be built incrementally, with an evolutionary approach within the agile model. At the start of the project, spend around ten or fifteen minutes with the business owner to define the database structure at a high level – at this stage, attributes and behaviors are not discussed.

Having a small amount of upfront modeling is useful to avoid major changes later – but it is not necessary to do the amount of upfront modeling advocated by traditionalists.

The database is then built iteratively, evolving in the same way as the objects, with just enough tables and attributes at each stage to support the system. Visual Team Studio for Data Professionals supports this approach for database engineers.

Often expectations of the data community are low, we don’t expect them to be able to do “trivial” things, such as adding a field to a production database. But databases can be refactored while retaining both behavioural and informational semantics – in other words, without messing up the data.

Databases are generally tightly coupled to applications. Refactoring a production database, for example changing a field name, therefore affects a lot of applications. However, it can be done by creating a new field with a new name, using triggers to ensure it is kept up to date, and using a short transition period to allow developers to update all of the applications that will be affected. The “scaffolding code” is then removed.

Coupling is the main enemy of database refactoring – if this can be reduced, refactoring databases becomes more straightforward.

Recommended further reading
Agile Model Driven Development:

Agile 2006 – Demonstrating Responsibility: the Mindset of an Agile Leader – Christopher Avery

Monday 13:30-15:00


Responsibility is a skill that can be self-taught by becoming aware of the responsibility process, and refusing to operate from any of the stages below taking responsibility ourselves.


Being accountable is not the same as being responsible. Accountability, or being held to account, is external – determined through a management hierarchy. Responsibility is internal, having the ability to respond, a sense of ownership of the issue.

We know what responsibility means – so how is it that so many responsible people do highly irresponsible things? Many experts and books say we should take 100% responsibility – but few explain how.

People are more able than they realize to solve problems simply by responding to them in a different way. Responsibility is not a character trait – it’s a skill, which can be taught directly. The responsibility process goes through six stages or steps.

No personal learning occurs at the bottom levels of the responsibility process, until we start taking responsibility. The key is to become aware of the responsibility process, to develop an awareness of how we are reacting to problems, and refuse to operate from any of the lower stages.

It is a challenge to adopt – subconsciously we will resist it, and it can result in exposure that is humbling and politically unsafe. It doesn’t work as a management tool – it can only be self applied, and as a leadership tool, should be suggested after the problem – not during.

Key points

  • Become aware of where I am in the responsibility process and “refuse to operate from any of the lower stages”.
  • Can be used as a tool for a Scrum team to learn to become self-managed and take responsibility.

Recommended further reading

The Declaration of Interdependence – Six Principles to Benefit You and Your Agile Organization – Alistair Cockburn, Better Software Magazine, June 2006

The powerpoint contains further notes and explanations.

Agile 2006: Refactoring Games – Alan Harriman, Joshua Kerievsky

Monday 11:00-12:30


There are many different types of code smells, refactorings, and quality criteria. The goal of this session was to use games to learn several techniques related to refactoring.


All of the games are played with a card deck produced by Industrial Logic, containing green Quality cards, yellow Code Smell cards, and blue Refactoring cards. The deck is fairly extensive – some examples are included below. Each card also contains an explanation of the quality, smell, or refactoring.

Overall, this was a decent, eye opening session that introduced a number of concepts in an interesting way. I do intend to try these with my team and report back on their success!

Game 1 – Rating the value of different types of refactoring using Refactoring War
This game reminded me of Top Trumps. Players have a set of cards of refactoring types, turn over the top card, and rate each one. The player whose card scores the highest keeps all of the cards.

The cards are scored on two criteria: frequency of use and design impact. The team works together to assign a score between 1 and 5 for each criteria and then add them together.

The “war” occurs when the team thinks that two or more cards are of equal highest value. In this case, players holding these cards flip over a new card on top and repeat the exercise.

The objective is simply to get teams discussing the different types of refactoring, get more familiar with the techniques and start to recognize when they can be applied. Without more background in refactoring, the game feels strange the first time it’s played, but over time it would probably be a useful exercise to keep teams thinking about the code that they’re writing and learn to recognize smells and apply refactoring techniques.

Game 2 – Identifying relevant refactorings in Refactoring Hunt
Players study several smelly code snippets and evaluate which of the refactoring cards could be applied to clean up the code. Each card can be applied to one piece of code or set aside if it doesn’t apply to any. Once all of the cards have been assigned, the team reviews the suggested solution.

The objective of the game is to help the team start to recognize how to apply refactorings. There was a lot of disagreement over whether the suggested solution was right, which wasn’t as constructive as it could have been. A better variation might have been to suggest that there;s no “right” solution, but simply let teams compare and discuss their own.

Game 3 – Relating code smells to qualities in Qualitaire
The team lay out the large green quality cards, then decide for each code smell card: “Which quality would be the best fix for code that suffers from this Smell?” Again, once the game is complete, the team reviews the suggested solution.

The objective of this game is to familiarize the team with code qualities, and identify the smells that prevent good quality code. As in Refactoring Hunt, the discussions were the most valuable part of the game, and having a suggested solution caused more disagreement than good discussion.

Example cards
Qualities: highly cohesive, loosely coupled, no duplication, simple, testable.
Refactoring: Substitute algorithm, unify interfaces, change reference to value.
Smells: Oddball solution, duplicated code, long parameter list, long method, feature envy.

Key points to apply

  • The team can learn to refactor in a structured way by familiarization with common code smells, qualities, and specific refactoring techniques.
  • The refactoring games are a great way of introducing this information to the team.
  • The games would have most value from focusing on discussion of solutions, rather than steering the team towards one right solution.

A particularly productive business trip

Last Thursday, after working until midnight on Wednesday, I arrived at our office in London at 8.30am for a breakfast “meeting”. OK, it was just a breakfast gossip really, but still. It was 8.30am and I was TIRED.

At about 12.30pm, I left in a taxi to Paddington station to catch the Heathrow Express. My flight to Seattle was due to leave at 15.05, so while I had enough time to get to the airport, I had very little time to spare.

I made the 12.50 Heathrow Express. Perfect. I sat down, opened my bag and looked for my laptop. Oh **** … yes, I had happily walked out of the office leaving it sat in the docking station on my desk.

At this point, there was enough time to have somebody at the office bring the laptop to Paddington, just about. However, after three unsuccessful attempts to reach my manager, I got on the train and decided to sort it out when I got to Seattle.

I didn’t feel bad for too long, because at check in, I was unexpectedly upgraded to business class, so for the first time I enjoyed the BA flat bed for nine hours and had my airline meal served on a china plate :)

I have to give my co-workers huge kudos here. Not only did they manage to sort me out a loaner laptop by the time I arrived, they also went to great lengths not to make me feel too bad, although the jokes since have been pretty funny. I’ll spare you the references to hair colour, but as Ryan pointed out “it makes for a particularly productive business trip, I always say”.

So after two nights in Seattle, during which time I’ve caught up with my colleagues in our Bellevue headquarters, I’m off to Minneapolis today to go to Agile 2006. I’m really looking forward to it, especially since thanks to Tobias Mayer my blog seems to have a few new readers who I’m looking forward to meeting at the conference.

Minneapolis, here I come …

It’s taken me a while to organise, but I’m finally on my way to Agile 2006

I’ve heard mixed opinions on the conference – from the complete evangelist to “too much powerpoint but great networking”. Well, I’m not that averse to powerpoint, I’m definitely not averse to social events, and while I’m still pretty much an agile novice, I already know some of the main areas of difficulty in our organization so it seems like a perfect time to go and network with the experts. I’m also excited that Minneapolis hosts America’s largest indoor water park.

Having left it a bit late to book, I managed to get the last seat on my flight out. Since I’m combining this with a trip to our offices in Seattle, it took me a good hour or so yesterday morning to activate my new credit card and use it to arrange two round trip flights, one conference ticket, accommodation in Minneapolis and Seattle, and car rental for a week in Seattle (I’m hoping the conference hotel really is only four blocks from mine …) Thank God for the Internet, or it might have taken a lot longer … and more importantly, I couldn’t have done it in my pyjamas!

I then wandered over to Oxford Street and spent the afternoon clothes shopping in the sales (I did change out of pyjamas for that). I need new clothes for the conference, right?

See ya there!