More on Retrospectives

On Tuesday last week, I attended Rachel Davies’ course on Retrospectives. My overall impression of the course was good, and I came back with lots of new ideas to try. I’d definitely recommend it.

Along with the practical learnings, the key takeaway for me was that it’s not as easy as you think to facilitate a retrospective. You have to get the true picture from different perspectives and guide a conversation towards a meaningful end – while staying neutral (never easy) This is why activities are important, to uncover the things that won’t ever get mentioned in conversation.

My highlights:

  • Lots of relevant information and references for further reading.
  • Seeing the timeline activity in action – using coloured post-its for good / bad / neutral makes it work a lot better than all one colour. Rachel also takes it one step further and uses funky shaped neon post-its for the team to highlight areas of fun and stress. Although this seemed like overkill at first, it does illustrate trends.
  • Emotional timeline – it was great to actually see this work, again it’s something I hadn’t used and wasn’t sure on, but it really did show up the patterns well, even in the example one we used.
  • Watching other people, as always, makes me see things that I’m doing that don’t work so well – for example, how important it is to write down what people are saying and not what I think they are.

Not so great:

  • Powerpoint overkill, especially at the beginning – I found it a bit difficult to stay tuned for the first part of the session, and would probably have preferred handouts (paper or electronic).
  • Difficult to really demonstrate retrospective activities with a group of people who’ve only just met – more simulated situations or role-plays might have been better.

Before I went, one day seemed like enough to become an expert on retrospectives. As always, the more you know … the more you realise there is to know!

Agile Retrospectives – trying the techniques

This was previously posted on my old blog, Spike the Poodle. 

After reading my new (autographed!) copy of Esther Derby and Diana Larson’s book on Agile Retrospectives, this week I tried some of the ideas out in our team retrospective. I really recommend reading the book and trying the techniques, I’d be interested to hear about other people’s experiences with them. Ade Miller also highlighted some ideas this week, including an article from Industrial Logic.

Firstly, we had a clear goal for the retrospective rather than just continuous process improvement, which was starting to get stale. I started the retrospective by asking the team to sum up the Sprint in one word, which actually gave me a great insight (especially since I’d been away for most of the Sprint!) The team had come really close to completing all of the work they’d committed to, closer than in any previous sprints, and everybody felt that they’d nearly made it but not quite. The team seemed to like the exercise, and they’ve suggested using song titles or animals next time. I’m particularly intrigued by the song titles suggestion :)

We used a timeline to gather data. I drew the team’s burndown chart on the white board and asked them to record events that had happened on post-it notes and stick them against the relevant part of the chart. What worked well was asking them to think back through the Sprint about what had happened, but since the burndown chart was fairly flat it didn’t really generate a great discussion in itself. I think this activity would work particularly well with a spiky burndown graph.

I asked the team to stick red and green dots on the positive and negative events. The good thing about this activity is that you actually get some surprising results – some of the things that I thought were really bad, and might have devoted more time to discussing, didn’t actually have any sticky dots on. It really did make it clear what the significant events were, however there were a lot!

We spent quite a bit of time talking about what was causing the main issues, and eventually we agreed on two areas we wanted to address: how we manage bugs during the Sprint, including bugs that relate to the current stories as well as new bugs that don’t, and how we can do better at getting things done. We spent too long discussing the issues, but this was partly because we weren’t really sure before the retrospective what our main issues were – next time, I think we will have a clearer goal which will make the meeting more focussed. I also need to get better at timeboxing! We identified a list of solutions for managing bugs better, and then used voting to decide which ones we should use.

I asked the team to choose up to two solutions to try for the next Sprint, so that we weren’t making too many changes all at once. Interestingly, most people didn’t want to be limited to only trying two things and wanted to do them all at once. We compromised and identified three things to try over the next two weeks.

Next time, I plan to focus on what we can do to get better at getting things completed within the Sprint. This has been a key issue for us, and I’ve also spoken to people on other Scrum teams who have the same problem, so I do plan on posting updates on what we come up with! In the meantime I will also be attending Rachel Davies’ workshop on retrospectives, so hopefully our next one will go even more smoothly.

Agile newbies can still add value

I discovered today that even as a relative-agile-newbie, one of the most useful and rewarding things you can do is to try to help another Agile team with their problems. This is a scary concept: letting me and my limited experience with Agile loose to try and advise somebody else on how they can do things.

I’m spending this week working in our Bellevue office, with a group of my colleagues who are just starting out on their first Sprint. They’ve done the CSM course, and they’re just starting to see how quickly Scrum brings problems to the surface.

It’s actually surprising how much value even a relative-agile-newbie can add, particularly within a group of people who want to learn from each other. It’s a great experience, and if you get the chance to work with another team, try it (just make sure they can’t blame you afterwards). I’ve recognised so many things I’ve done, or still doing, that I want to change. I’ve spent time discussing the problems the other team are having, hearing other people’s views on the world, and it makes me think about what the agile principles are, what the Scrum rules are, and how I’m not following them as well as I thought. Things can slip out of your mind and trying to find the tools to solve other people’s problems helps reinforce them back.

The best bit ever is that I think I’ve actually come further than I realised. On the odd occasion, I’ve actually had an intelligent answer. Most of them may have been parroting what somebody else has told me, but this stuff starts to feel like it’s sticking. I’m still a Agile newbie, but I’m becoming an Agile junkie. I’m having fun with this.


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: 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 – 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: Agile Testing – Brian Marick

Sunday 16:15-17:00


One role of an agile tester is to ask questions and catch the error and exception conditions. Testers generally focus on what goes wrong. They have a familiarity with bugs, they look at bugs, learn from them, and generalize. In agile projects, developers should get better at anticipating bugs.

With test driven development, the UI can be created, then the logic implemented. In test driven development, the sequence is:
Write a failing test -> Make it pass -> clean the code.

Cleaning the code is very important.

Exploratory testing or rapid testing is another form of agile testing.