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!


Forming, Storming, Norming, Performing

During Agile 2006, one of the presenters (unfortunately I forget who!) mentioned the “forming-storming-norming-performing (adjourning)” model of team development. I recently found a good powerpoint by Glen Alleman on this subject that describes the stages and their characteristics. Since a number of people were interested at the conference, I thought it would be useful to post the link here.

Glen Alleman – Forming-Storming-Norming-Performing

As Agile 2006 draws to a close …

With my brain creaking from information overload, I made my way to my final session of Agile 2006 this afternoon to see Peter Provost and Brad Wilson with Mitch Lacey in an energetic demo of their pairing game, known as the Test Driven Development Pairing Game – at least it is until they can stop their keyboard wars for long enough to get creative with names.

What a way to end a great week – and restore my energy ready for the party tonight :) I knew by lunch on Wednesday that what I’d take away from the conference already surpassed what I’d hoped. It’s been so much fun to be a geek for a week in the middle of hundreds of others who really care about agile, who don’t look at me like I’m crazy, and have an instant response to all of my unanswerable questions.

I came here armed with a big range of questions and I’ve been persistant and often downright annoying in my quest to find answers. Luckily and thanks not only to the presenters but also my new found friends who were willing to talk about agile over a breakfast, burritos, or beer, I feel like I’m going back armed with not just answers, but a lot of new tools to make an overall plan to guide our team’s future with agile.

My plan is to write up as much as I can from the conference and post it here, starting with a summary of my highlights early next week … but in between the massive amount of reading I also plan to try and do, it may not happen as soon as I’d like! Watch this space :)

Now it’s about time to get ready for the banquet …

Agile 2006 – A Detailed Rundown

For all but two of the sessions I attended at Agile 2006, I created a brief write up which is published here. Since most of the sessions had PowerPoint presentations supplied on paper and the CD, I’ve tried to avoid rewriting the content, and just summarized the main points and my own additional notes and views.

The “points to apply” represent what I took away from each session. In some cases where the main points were things I already knew, these are the extra insights or reminders that I’d forgotten.

The other sessions I attended were:

Enterprise development with Scrum – Ken Schwaber: I happen to know somebody else was taking excellent notes through this presentation, so I’m going to wait on those
Faciliating Agile Retrospectives – Diana Larson and Esther Derby: I’m currently reading the book, so planning to make a post after I’ve completed it. Also, I left half way through to go to the Test Driven Development Pairing Game demonstration.

Agile 2006: The Test-Driven Development Pairing Game – Peter Provost, Mitch Lacey, Brad Wilson

Thursday 15:30 – 17:00


A new twist on pair programming that combines test driven development, or test driven design, with pair programming to create a game.


This was the only session of the entire conference that I had decided in advance there was no way I was going to miss. I’d heard about the technique and was really interested to find out more so that I could take it home. I wasn’t disappointed – Peter and Brad have so much energy and passion, and their constant banter made the session really entertaining.

It was a live demonstration, and the application they chose to demonstrate it (building a simple bank account object with unit tests) worked really well – I intend to use the same idea to demonstrate back to my team.

There are three legs to the development “stool”:

  • Test driven design
  • Real time code review
  • Refactoring

Developers want to get the most out of their time, and traditional pair programming can be boring for the navigator. The driver is the tactician and the observer should be the strategist, but in practice they are often thinking about email, lunch, or what they’re going to do next.

TDD evolves the design of the system. In TDD, a test is written before writing the code, then just enough code is written to pass the test, then the design is improved: write – run – refactor.

Refactoring improves the design without changing the functionality. If more tests are necessary, then it’s not refactoring.

In the TDD Pairing Game, the keyboard is passed at every step, which means it goes back and forth very rapidly – each step should not take more than 3-4 minutes. The pair negotiate over disagreements, so it ends up being a process of negotiation. The test writing drives the design.

  • Step 1 – write a test that compiles, but doesn’t pass. Pass the keyboard.
  • Step 2 – write enough code to make the test go green. Pass the keyboard
  • Step 3 – either write another test, or go back and do one refactoring.

The rules of the game are simple:

  • If the test light is red, the next step must be to make it go green.
  • If the test light is green, choose whether to write a successful test, a failing test, do a refactoring, or stop and think strategically about the system design – use the whiteboard to diagram it, etc.
  • If the system doesn’t compile, the keyboard can’t be passed.
  • Don’t write too much code. Throw exceptions if things are not yet implemented. You’ll be surprised where it leads you if you don’t write too much code.
  • One test at a time to evolve the game.
  • No email, no phones with email, no IM.
  • It’s recommended that developers should check in as much as possible – at every green light, if it’s cheap enough. Source control is a big giant undo button.

Tests have three separate code “paragraphs”: arrange, act, assert. Set up and teardown are considered evil – factory methods can be used instead. Whether we unit test edge cases or not, is a design question.

Ideas for new tests are kept in comments in a list, which evolves as you start coding. If a test gets too big, comment it out, then go back and refactor.

Recommended further reading

Avoid Setup and Teardown –

Agile 2006: Programmers are from Mars, Customers are from Venus – Angela Martin and Robert Biddle

Wednesday 13:30-17:00

Being an XP customer is a lot of work, but this can be separated into roles and split among multiple people. There are also practices that can be used to make the customer’s life easier.

Of the entire conference, this was probably the session that gave me the most practical tools to take back to my team, and in the most straightforward way.

It’s a lot of work being a customer in an Agile project. Rather than heroic programmers, we’ve moved towards needing a heroic customer – there’s a lot to do and it can be exhausting. Many customers need to be available to the programmers to answer questions when they are needed, but still have to fit in their other work. However, most customers agree that the reward of having working software every iteration does make it worthwhile, so how can we redress the balance?

The customer role can be divided into nine sub-roles to form a customer team. One person can take on more than one role, or they can be taken on by different people.

Geek Interpreter
This person helps the customer to understand the programmers. This is probably not a full time job.

Technical Liaison
Almost no software development project is new, so there is a need to integrate with existing organization technical infrastructures. This role takes the responsibility for making sure that the integration happens in a sensible way. It may or may not be a full time job, depending on the business.

Political Adviser
This person helps the customer to get agreement from others in the organization. It’s always an unofficial role, to help the customer get through organization politics.

Acceptance Tester
This person works to support the customer and define acceptance tests.

UI Designer
This person designs how the system looks to the end user, which creates requirements for the system itself.

Technical Writer
This person creates the documents required for the end users of the system.

This person supports the customer in the organization, talks to the people who “matter” and report back.

This person completes the administrative work necessary to support the customer.

This is the traditional customer role. This person must be flexible, agile, and decisive; able to work at the big picture and detailed levels. The Negotiator is the point of contact for developer questions, although would likely field these to the acceptance tester.

There are also several practices that can be used to support agile customers:

  • Programmer on-site – to help programmers understand the users better.
  • Customer apprentice – to help programmers understand the customers better.
  • Programmer holiday – allow the team to spend a week or an iteration focused on technical debt, refactoring, or spikes – while the customer has time to catch up.
  • Story standards – common templates for the stories.
  • Show and tell – to show the sponsors the return on their investment.
  • Look before you leap – create a business case for the features, and use release planning.
  • Be prepared for the “three month crisis” in long term projects, when they realize “their eyes were bigger than their stomachs”
  • Plan for this and be upfront when things slip
  • Customer pairing – divided geographically, or by functional line
  • Customer counselor – to allow venting, and to coach the customer

Agile 2006: From User Story to User Interface: Collaboratively Designing and Testing User Interface – Jeff Patton

Wednesday 09:00-12:30


The user interface can be designed from the user story by following a process to define the UI tools to be included, then creating paper prototypes to test the usability, without focusing on the visual design.Â


The user interface consists of five layers:

  • Strategy – why is the software being built? What’s the usage context? What are the business goals?
  • Scope – tasks for the page
  • Structure, skeleton, and surface – this is where the user interface and prototyping takes place.
  • Understanding the task-centric scope defines the page structure. Tasks should be defined at the role level – i.e. a person engaged in an activity, e.g. shelf stacker. Create personas to represent people the product would serve – this allows focus on specific people in the design. Consider their skills and aptitudes.

When modeling tasks, consider the goal level:

  • Cloud – on going, business level goals, e.g. communication
  • Kite – long term goals, e.g. manage email
  • Sea – tasks that could be accomplished in one setting, e.g. send an email
  • Fish – sub tasks that stitch together to form a task, e.g. enter “to” address
  • Clam – sub tasks that form larger sub-tasks, e.g. look up an email address

Stories should start from sea level – at this level, if a user accomplishes the goal, they will consider themselves successful in doing something. Remember – “if you stay below sea level for too long, you’ll drown”. At this level, there is no UI design decision. As stories are split into small enough items to work on, the design starts to take shape as they become more granular.

A good user story is an example of use. They should follow a format:
As a [type of user]
I want to [perform some task]
So that I can [achieve some goal]

They should describe the goal, not the solution.

When moving towards a UI solution, use Constantine and Lockwood’s “Task Case”.

The next step is to define the UI tools for each of the system responses that will allow it to meet its responsibility to the user. UI tools can be three types:

  • Container – contains and presents information
  • Action – allows execution of an action
  • Actionable container – contains and presents information, and allows it to be acted on through selection or manipulation.

Once we have a list of the UI tools, it’s straightforward to create a basic paper prototype, and test it with real people, get feedback and refine it. This saves the time investment in creating and refining a real prototype.

Recommended further reading
Designing the Design Process –;jsessionid=ipItXBeszOt5o2aYbZ?cookieSet=1&journalCode=hci

The powerpoint from this session also includes further explanations and useful diagrams.

Agile 2006: Agile Requirements Workshop: Essentials for Planning, Design, and Facilitation – Ellen Gottesdiener

Tuesday 13:30-17:00


Facilitating an agile requirements workshop requires a great deal of preparation and particular facilitation skills.


Workshops are different from meetings. They require more pre-work, and anything that must be decided in the workshop should be clarified beforehand. Workshops often encourage “serious play” rather than just discussion.

For Agile Requirements workshops, it may be necessary to hold one or more per release or iteration. The whole team participates, including customers, QA/testing, and developers. The customer can help to identify who needs to be represented. Good workshops should have no more than fifteen participants at the most. Surrogate users are not ideal – the customer’s needs can’t be guessed. If it can’t be avoided, get more training for the surrogate users.

The facilitator needs to use tools to jump-start workshops, e.g. for a workshop to produce use cases, provide a list of good verbs to use and some examples. The facilitator also needs to manage the “chaos”, and bring out the introverts. One of the greatest skills in facilitation is observation.

When designing a workshop, the purpose must be clear – why is this workshop being held? It may be necessary to consult with the participants prior to the workshop to ensure the purpose is correct. It must be linked to the project purpose, and for requirements workshops, the higher level scope should have already been agreed on.

It may be necessary to create a workshop planning team. If the workshop goes off target or isn’t working, the planning team can call a break and discuss how to adjust the process. The workshop facilitator must be neutral. The workshop should have defined behavioural rules – ensure the team know them, and call out if they are broken.

It must be clear what “done enough” means in the workshop. When are the models good enough, or complete enough? How precise must each deliverable be? The facilitator must know this in advance. The workshop products should be listed in components – models should be broken down to lead the group in tasks to get to them.

The workshop space is important – the room needs to be set up ahead of time, food is important – don’t work through lunch.

Kickstart the workshop activities – begin with an image – “imagine you are a user trying to … [fill in the blanks] – what pieces of information do you need to input?”

Always complete the workshop with a retrospective on the workshop – how did it go?

Key points

  • Prepare properly for agile requirements workshops.
  • Use energizer activities to get people involved at the beginning.
  • Define outcomes of workshops more clearly.

Recommended further reading

Decide how to decide –
Ground rules resources – Roger Schwarz
Team Retrospectives for better Iterations Assessment – Ellen Gottesdiener
The powerpoint provides a great deal of further information and examples.

Agile 2006: The Planning Game – Chet Hendrickson & Ron Jeffries

Tuesday 09:00-12:30


This is a simulation of an agile project, to demonstrate the impact in business value of releasing earlier, the importance of knowing business priorities in order to get the most value and using velocity to estimate release dates.


This was one of the highlights of the conference for me. Ron and Chet have played this game over and over, and it clearly shows – it’s funny, it works like clockwork, and the messages reveal themselves through the game without needing to be called out. If you haven’t played the Planning Game, and you get a chance to attend one of their sessions, don’t miss it.

The planning game simulates the planning of an agile project. We are told that this project must be completed within six months. There are forty five “story cards”, each numbered, with different numbers in each corner, and our first task is to arrange them in six columns to show management how we will complete the project. Ron and Chet will play the roles of Management, as well as fickle Nature.

We know this is a trick but we can’t figure it out, so we arrange the cards randomly with more at the start and fewer at the end. Along comes Nature and tells us that in our first iteration, we completed four stories. This is disasterous – we had eight planned. The team next to us have completed exactly what they predicted. This is confusing, how are we supposed to know what we can get done?

One of the other teams informs Management that they are unable to complete the project within six months. Management, understandably, is not very happy. “How long do you need?”

“Seven months”, say the team. Hmm. Management decide that one extra month is not too bad, and the team have at least been honest enough to admit that they can’t complete the project on time. “But no longer,” say Management, “or you will be fired. Now plan your next iteration.”

We rearrange the cards for the next iteration, and Nature dictates that this time we once again complete four. We aren’t doing very well here. It’s clear to most people that we can’t complete the project in time. Management are even more impressed with the team who identified this earlier. The rest of us are in the doghouse. How long do we need?

Based on our past performance, we estimate that we need twelve months. With nothing else to go on, we simply use the number of completed stories – 45 / 4 = 11, with one left over. The group average is around nine. The team who asked for seven admit that they actually need longer. Management are not happy.

We break, and try to decode the numbers on the cards, but we can’t. We discuss what Nature was looking at when he came around to tell us what we’d got done. Was he doing some complicated math? We don’t think so. We don’t know. It’s frustrating, but it’s fun, and the lessons are pretty clear. How can you plan projects without knowing how fast you can work?

After the break, Ron and Chet tell us which numbers represents the effort required for the stories, and what our velocity is. Then they give us the chance to replan the project from scratch. Now it’s easy – we can complete in nine months. We argue over which of the stories should go at the beginning and the end.

We eventually put most of the big stories earlier since they represent more effort and more risk, so we should get them out of the way earlier. Then they suggest that each story could have equal value, which would mean we’ve really messed up.

This is another important lesson, and the game drives it home perfectly. We can’t guess the business priorities. If we don’t know them, how can we effectively plan the project?

We finally get this final piece of the puzzle, and they share with us how the value of the stories is represented. Now we can plan properly, and make sure we get the most value for the least effort in the first iteration.

The final exercise is the most powerful. We need to decide when to release.

Ron has created a spreadsheet that graphs the value realized by the business depending on the release date. The logic works like this:

  • Each month, development costs the company x units
  • Each month, the released features generate the company y units
  • Y is the total number of units of value released so far
  • The highest value features are completed in the first iterations

Key points to apply

  • Focus on reducing release time – ultimate goal is to release every sprint to maximize business value.
  • To maximize business value, it’s vital to stack rank stories based on the maximum value realized for the least effort

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: