Agile 2006: Team Dynamics – Esther Derby

Monday 15:30-16:15


Only 5% of teams ever reach the “high performing” stage – but being aware of how teams form and what practices are needed can help to increase the chance of becoming a true high performing team.


It takes social engineering to make great teams – it doesn’t happen by accident. Good teams that people have worked on tend to be small, passionate, and focused on one common goal.

In teams with more than ten people, communication overhead grows, and teams tend not to perform as well. Good teams usually have an agreed-upon approach to the work – XP has specific practices that promote this – pair programming, refactoring, coding standards, and so on.

Teams should be made up of people with complementary skills – not the same skills, although there should be some overlap. Good teams have interdependent interim goals – such as user stories – which mean they can be successful quickly. As is especially true of agile teams, they make commitments to each other and are not hierarchical.

Team creation goes through several stages (refer to the powerpoint for the diagram of the model):

Orientation: “why am I here?”
The team need to get clear on this first!

Trust building: “who are you and can I trust you?”
Mistrustful teams are guarded, hold back and are less creative. Trustful teams accept feedback and deal with conflict. They trust in each other’s professional competence, and that their intentions for the team are good. In teams with one star performer, trust for others is low, and they tend to be less productive.
Avoiding conflict erodes trust, by resolving issues people build trust.

Goal clarification: “what are we doing?”
When teams aren’t clear on this, they become apathetic, and irrelevant competition starts to happen.

Commitment: the team ask “how will we do it?”
If this is absent, the team will snipe at each other. People who don’t have power and control over what they commit to, don’t commit. Removing the fear, and allowing people to make small promises means they can commit to something realistic.

Implementation: in agile projects, this is done through stand-up meetings, retrospectives, reviews, and talking to customers.
High performance: at this stage, teams are having fun, and producing. Only around 5% of teams ever reach this stage.

Renewal: There are some critical skills necessary to achieve high performance. Teams must navigate conflict. Often people don’t hear each other properly, and conflict can be down to misunderstanding – in these cases it’s good to review the data. Peer-to-peer feedback – not just up and down – is necessary to build trust on high performing teams.

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.

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.

Agile 2006 – Introduction to Agile Project Management – Sanjiv Augustine

Sunday 15:30-16:15


Agile project management is different to traditional project management, lean principles can be utilized to manage at the value stream level and reduce waste.


Agile teams are self organizing – team members have a clear set of responsibilities, and they have the control and power to fulfil them. Trust the team, and they will learn to self organize, it requires a shift in mindset.

Often in large organizations, much of the agile mindset is already happening at grass roots level. Agile adoption just makes it explicit.

It is important in agile project management to manage at the value stream level. This concept comes from lean software development and manufacturing principles. This is the job of the agile project manager.

In traditional waterfall project management, work was done in large batches: design, dev, test, rework – there is a lot of “inventory”. In contrast with agile, small pieces of work move more quickly through the system. In agile projects, the focus should be on project throughput. Reduce utilization – developers should work on only one project at a time, and focus on only one story to avoid the waste in switching tasks.

With more trust between customer and team, a lot of waste in the process is reduced through collaboration. With agile, requirements do not need to be bloated upfront since change is allowed – this lifts a load since corrections are easy and fast.

Reflections, or retrospectives, should be used in agile projects to analyze, adapt and improve processes and practices. The team should answer the questions: what’s going well, what can we improve, and what obstacles or issues are facing the team.

Key points

  • Manage at the value stream level.
  • Reduce utilization of developers – they should only work on one story at a time, one project at a time.
  • Reduce waste through collaboration, and investigate other techniques.

Agile 2006 – Planning and Tracking on Agile Projects – Mike Cohn

Sunday 14:15 – 15:00


The first question on a project is always “when will you be done?” Agile planning takes place on three levels, using relative story size and previous performance (velocity) to plan iterations and releases.


Agile teams plan at the release, iteration and daily level.

Release planning describes “Here’s where I want to be” – so that we can figure out the best way to get there. Releases usually comprise multiple iterations, because stories are “done” at the end of each iteration – not necessarily cohesive. Estimates at this level are ball park numbers – it should take no longer than 3 minutes to get to the estimate for each story. During release planning, the team explore the solution space and negotiate how they can satisfy the customer’s needs.

At the iteration level, tasks are estimated in “hours I thought a lot about”. There is no negotiation on schedule or budget at this level – long iterations with varied lengths don’t work. At the end of the iteration, get feedback of what’s done and left to do.

At the daily level, the daily stand up meeting is used to plan the next day’s work and synchronize the team. This should not become a status meeting.

Humans generally are bad at estimating the duration of a task, but relative sizes are more straightforward. Some teams use t-shirt sizes to estimate stories, but it is difficult to agree on the relativity – is a large story twice the size of a small one, or three times? Story points, which are the most commonly used now, make this straightforward.

A common mistake is to consider the skill of an estimator important – it isn’t. Regardless of time, people can agree on the size of a piece of work.

To estimate velocity, use a range. When considering the long term average, look back 4-5 months and no longer, as the team’s situation will have changed too much if you go back any further. Use the velocity to look at the release plan and estimate where we’ll finish at the slowest velocity and expected velocity. These estimates can be used to reprioritize the stories.

Burndown charts show progress. Teams generally work best when they have slightly aggressive, but not unrealistic, schedules – which is why the end of the burndown chart is usually steeper. Burndown charts raise questions – they don’t answer them, but they identify areas for further discussion and commentary.

The powerpoint contains diagrams, further explanations, and photos of example taskboards.

Key points to put into practice:

  • Use velocity to estimate the relative likelihood of stories being completed in a release, and use this to drive reprioritization.
  • Use burndown charts to identify areas for discussion, where further explanation is needed.
  • Track velocity only about 4-5 months back – changes in the team’s situation can cause velocity to change over time.

Agile 2006 – A Story of Stories – David Hussman

Sunday – 13:30-14:15


How to collaborate and write effective user stories.

Requirements gathering has evolved over time into the form of use cases. Good use cases are short, simple, focus on the use cases and stay current through continued collaboration. Bad use cases replace collaboration, are long and expensive to write.

Burying requirements in long documents doesn’t work. People can’t find or estimate them. Testers, developers and customers interpret them differently.

As an alternative, collaborate to write small, short chunks of work as user stories. Write them down on 3×5 cards and post in a common area for easy access. Let the customer say what done means – and write it on the cards as acceptance tests. In a healthy community, everybody writes the stories.

Hold “story jams” to create the stories (think like music jams – let the creativity flow). Use a long table and invite lots of people. Create personas, and walk through a day in their lives. The list of stories doesn’t need to be complete after the story jam.

Good user stories conform to the INVEST acronym:

  • Independent – breaking dependencies increases agility, so that the business can choose the really valuable stories.
  • Negotiable – they can be changed. Build a ubiquitous language, so that everybody knows what the story really means.
  • Valuable – in terms of the customer, or whoever it’s being built for.
  • Estimable – sized appropriately for accurate estimates.
  • Testable – it’s a story smell if they can’t be tested as done.
  • User stories work because they are available, they bring people together, build trust, promote innovation and are humane. Stories are completed only when the customer signs them off.

Key points to put into practice

  • Review user stories against the invest acronym.
  • Create personas and walk through a day in their lives.
  • Don’t focus on completing ALL of the stories in a story jam.

Recommended further reading

Being Jane Malkovitch – the Life of an XP Customer (included in conference materials)

The powerpoint presentation contains photos and examples of personas, story jamming, and further explanations.

Brainstorming “Done”

Being a new Scrum team, one of the things we’ve had difficulty with is actually completing the stories we set out to do in our Sprints. A lot of our tasks were pretty big, they didn’t move very quickly across the taskboard, we were  forgetting things like documentation, and the team wasn’t owning the estimates.

We decided to try something suggested to us by another Scrum team that we’d been talking to, who had been messing with Scrum for a year or so (they work for a different company nearby, we’ve recently started up a conversation and it’s great to get input from outside).

The idea was to brainstorm what it means to be “done”. We started with around ten or twelve criteria like coded, tested, and documentation completed. But when we brainstormed and broke it down further, we ended up with nearly thirty things identified. They’re pretty generic – I’ll list them at the end of this post.

The next step was to go through the list for every story that we took on in Sprint planning. Not every single thing on the list applied to every story, although most of them apply in most cases. For each item on the list, we created a task. This meant that task creation was no longer something that was owned by any one team member, and almost all of the tasks were a lot smaller – for example, we had to call out separately a task to review code, to review documentation, and to review acceptance tests, which we hadn’t done before. In this sprint, we’re tracking progress at a much more granular level, which means it’s far easier to see where the real hold ups happen, and harder to forget things.

This exercise isn’t completed yet though. The next step is to review the critieria at the end of this Sprint, identify the gaps, and fill them in. For example, I don’t think that “documentation written” is specific enough. If our documentation contains screenshots, a flow chart and a technical overview, let’s call that out. It sounds like over-planning, but it’s not – it really helps the team to see clearly what the tasks are and start to share them out more – which I think is one of the biggest challenges of being Agile.

The other thing we need to do is to write a sentence for each criteria to really clarify what it means to have met it. Watch this space for further updates on how this goes!


  • Story written
  • AB tests identified
  • UI designed
  • HTML written
  • Code written
  • Code reviewed
  • Unit tests written
  • Unit tests passed
  • Documentation written
  • Documentation reviewed
  • Acceptance criteria defined with stakeholders
  • Acceptance criteria reviewed and approved
  • Acceptance tests written
  • Acceptance tests published
  • Functional tests written
  • Manual tests carried out
  • Tested accessibility
  • Acceptance test done
  • Automation testing scope defined
  • Automated tests written
  • Automated tests run
  • Bug fixing
  • Regression done after bugfixing
  • Regression testing defined
  • Pseudo localised
  • Pseudo loc testing completed
  • Deployed to lab
  • Ready to present to stakeholders
  • 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.

    Waterbaby …

    Yesterday I went waterskiing! Despite the very early Saturday start, it was worth it – the weather was windy, but really warm and sunny.

    This is my third time on water skis. Last year was the second time I’d ever been, and having done it once before (and not been tooooo bad for a first timer) I thought I’d go straight on to the rope. Newbie waterskiers can start off holding a bar at the side of the boat, but I’d been there, done that … anyway, long story short, last year I could barely stand up. I had very unstable waterskis, apparently, not ideal for beginners. Honest.

    So, this time I was back on the bar to start with, with more stable skis, and wow, it was so much easier! This time I managed to actually ski on the rope, standing up properly (knees still knocking, but hey ho). I still have a way to go before I (deliberately) move on to just one ski :)

    Today my arms ache, but I’m definitely going back next year!