Rule of seven retrospective

This retrospective is useful for tackling a single issue or problem, especially for long term persistent issues that are in danger of becoming the accepted norm.

It is an implementation of the “rule of seven” described by Geoff Watts in his recent book Scrum Mastery, and is useful for situations where you want to focus on a specific issue rather than cover a broad base of improvement ideas.  The premise that you come up with seven ideas to tackle the problem before deciding on the best course of action, which can lead to innovative solutions:

I’ve found that the first few solutions or ideas are fairly easy to come up with and, usually, fairly sensible as well. Ideas four and five are a typically a little more off-the-wall and take a little longer to emerge. Ideas six and, especially, seven are sometimes a bit crazy. In ideas six & seven, though, are often the seeds of ground-breaking ideas that can really energise a team and lead to quite astounding solutions.


Set the tone for the retrospective by explaining that a single issue or problem will be explored in depth

Ask the team to come up with one or two long-term issues that are holding them back, then get them to briefly present them to the group.  Use dot-voting to choose the issue that will be discussed for the rest of the session (alternatively the topic can be agreed beforehand to save time)

Lead the team to define the problem explicitly to ensure there is a shared understanding.  The ORID structure is a good way to do this (Watts)

  • Objective: What is happening; who; when.  Fact-based, without analysis
  • Reflective: How do we feel about what is happening; how might others be affected
  • Interpretive: Why is this happening; what effect will this have on the organisation or the project
  • Decisional: What are we going to do about this? (save this for the next stage) 

Once the issue at hand and the well understood by the group, get them to come up with at least seven different ideas to improve matters.  Get the team to write these out on cards as they go.

To wrap up the session, ask which idea or combination of ideas would stand the best chance of mitigating the problem or improving the situation, and help them draw up a plan of action.


Scrum Mastery, Geoff Watts, chapter “Be ADAPTIVE in Retrospectives”

Trust Checklist

Creating an environment of trust is essential if an agile development team is to progress from the basics of their chosen agile framework and begin to make more fundamental changes that will make a real difference.  Trust must exist in both directions and be supported by frequent communication.  If trust is not present, the team will quickly run out of ways to improve and will elect not to tackle things that slow them down, saying:

  • We can’t do this because it’s against policy
  • We don’t want to make the pain visible (to encourage change) as we have safety concerns for ourselves or our colleagues
  • We have tried to change this before and it didn’t work; this is just the way things are here

At this point the capacity of the team to inspect & adapt is limited to minor, cosmetic changes that will have limited impact on the outputs of the team (ie valuable working software).  To improve as a business, the team and the sponsors should be able to answer ‘yes’ to all of the following:

  • Teams have the autonomy to deliver the features that they have been asked to develop in the best way we can
  • There is a safe environment to discuss changes to delivery plans which arise as we learn more about the product through development, or as business priorities change
  • Frequent communication means that big changes in plans rarely comes as a surprise to anyone
  • The rules of the organisation are respected and  people feel able to challenge them directly rather than work around them to get things done
  • Budget holders are free to schedule the features that they think will deliver the most value to the business in the long term
  • People feel that their leaders respect the work they do and the choices they make

Few organisations can genuinely answer ‘yes’ to all of the above, but it is important to acknowledge the areas that need work and have a plan to tackle them, bit by bit.  There must be a sense that “if we don’t like our situation we can change it”, otherwise inspect & adapt becomes inspect & look for another job

Collaboration over Evangelism

All IT fields have evangelists; knowledgable experts who have seen the benefits of their chosen language, framework or product; and can’t bear the thought that we might be missing out.

Repent, ye who do not use TDD

Fig 1. Gather round, and hear wondrous tales of projects coming in on time

I wonder if the terminology may be counterproductive.  The focus of a religious evangelist is on the framework itself rather than the problems it solves.  The end goal is to convert people to their religion, not to instil good social order or enable eternal life after death.  There is no room for debating the merits or underlying assumption of the evangelists beliefs.  People tend to have strongly held views on topics that are evangelised over which can be a barrier to conversation, as highlighted by the crusades and online discussions comparing vi with emacs.

I prefer to keep in mind and end goals that people care about, which are different for every project but usually boil down to simple things like predictability, return on investment, getting the product that was asked for, increasing market share…  These end goals are distinct from factors we as coaches currently believe will have a positive influence on them, such as customer collaboration, minimising WIP, and various other good practices we’ve seen work.  Rather than saving the souls of Prince II practitioners or ensuring developers not using TDD are made to feel suitably guilty, collaborate with people in the organisation by establishing a set of shared objectives.  The conversation will probably go much more smoothly…


Figure 1 photo credit: Drawn by Alfred T. Agate. Engraved by Rolph, J. A. Published 1845,_1841.jpg


Software is made of learning

Pot number 203

This article links the following well established ideas into an approach for starting up complex IT projects

  • It’s better to start building a complex new system and fail a few times than to spend the same time investigating and producing specifications
  • Most developers could recreate yesterdays work from scratch in a more cohesive form in about half an hour the next day
  • If you tell one half of a pottery class to focus on quality and the other to focus on speed, the people that focused on speed will produce the highest quality pots

I read a book that outlines a method of rapidly becoming competent at any new skill with 20 hours of focused practice (Kaufman, 2013).  While advocating the use of quantity and speed during practice rather than ensuring absolute quality in whatever you are practicing, he cites an anecdote from a experiment done in a pottery class (Bayles et al, 2001):

“All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality”

The end results may be surprising to an art teacher but perhaps less so to anyone who has been involved in an IT project involving complex architecture and design:

“It seems that while the quantity group was busily churning out piles of work and learning from their mistakes, the quality group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay”

This example brought to mind numerous planning meetings at the start of projects where it was argued that the framework must be nailed down first, or the overall design must be decided upon.  How many projects have been cancelled with nothing more than theories to show for them?  I also remembered the maxim from my time as a developer where it was often said that during your most productive days of coding, you could almost always produce a higher quality, more cohesive version of the same code the next day in about half an hour.  If a day in which 5 hours were spent coding productively, that might indicate that 90% of the work is actually learning.  Bringing these threads together, I propose a model:

  • The start of a new software project can be defined by the existing level of features and knowledge
  • The cost of implementing additional features is proportional to the knowledge the team have about the general and specific problem
  • Learning general software principles plus specific implementation could potentially account for 90% of the effort on a typical software project

If this model is correct (which is yet to be established; the pottery evidence is anecdotal) then it would make sense to start a project with an emphasis on gaining knowledge on potential technologies and the specific needs to be satisfied.  It has been demonstrated that we learn best by doing, failing and adapting, so rather than spending three months in meeting rooms pouring over architecture and considering what might go wrong, why not hack together a few working systems and feel good when you throw them away?  Celebrate the fact that the two weeks you spend implementing each terrible idea has saved you five years maintaining the wrong system and has produced valuable insights into how to build the right one.


Josh Kaufman, The First 20 Hours: How to Learn Anything … Fast, 2013, Chapter 2

David Bayles, Ted Orland, Art & Fear: Observations on the Perils (and Rewards) of Artmaking, Chapter III


Figure 1

Make them think it was their idea

There’s an old agile coaching adage that if you want a team to adopt a new practice or change their behaviour, you try to make them think it was their idea so that they’ll buy into it.

I recently worked with a team that was new to agile and thought that kanban would be of great benefit to the short-order multi-product backlog they were working from.  Having helped them map out their workflow and measure their system, I had themed a retrospective around Deming’s “red bead experiment”.  I had planned to introduce kanban as a way of improving their system, but before I had a chance to, one of the team said that she had done some research on kanban herself and wanted to know if we could try it.  This gained immediate traction and allowed me to explain more without it seeming like I was pushing an agenda.

The “make it think it was their idea” approach is sometimes criticised as being manipulative, or as a way of tricking a team into doing something they don’t want to do.  In this case there was no such slight-of-hand or deception, as the team came up with the idea independently.  From this experience I would tweak the phrase, and simplify it:

Make them think it was their idea


Keeping it simple makes me faster

Simple design

Fig 1 the Nürburgring Museum Bild-CC-by-sa/2.0/de

While reading Lewis Hamilton’s latest column for the BBC (Hamilton, 2013) I decided that if he ever decides to abandon his effort to reclaim his 2007 world championship, he would be a natural agile product owner.  It would take minimal training for him to make the transition because he is already fulfilling this role at Mercedes AMG, and his instincts seem to be pretty good.

One of the key ways I like to approach my life is to keep things as simple as possible because when it’s not simple, it can be stressful, and when you’re stressed you’re not working at your best.

The effort that goes into designing formula one cars for each race is extraordinary, but they do have the advantage of a simple vision that never changes: Finish as high in the FIA world championship as possible.  A common trait among the all-time great drivers is that build the team around them, communicate the vision to their engineers and provide frequent feedback helping them understand what improvements can be made.  They praise the team in front of the world media when things go well and are not afraid to let them know when the product is not competitive.

Simple products give you a tactical advantage

By Morio (Own work) [CC-BY-SA-3.0 (], via Wikimedia Commons

Fig 2 Lewis Hamilton racing his team mate during a recent grand prix

There are many examples of simple design with a minimal set of initial features being a major competitive advantage.  The release of the first iPhone lacked many of it’s competitors features but chose to release a minimal product to get earlier feedback on the basic concept and let the public outcry over a lack of copy & paste influence their next release (Pichler, 2010). I can relate this case to several release planning discussions of my own, where we looked over our backlog looking for things we could easily defer to a later release.  I can imagine it took a lot of persuasion to dislodge copy & paste from the “must have” column.


The key thing is to make it simpler without getting rid of stuff that I might need to make the car go quicker.

In racing terms, where development continues throughout the season, it would likely be beneficial to try out a new front wing design before all of new aerodynamic theory has been put into practice.  Any slight benefits of the new direction would be realised for more races, and the drivers would be able to let you know earlier if the whole idea was flawed.  This would reduce the cash spent on a flawed design and also reduce the opportunity lost as engineers could move onto more valuable work sooner.

Think like a racing driver

Fig 3 - formula one is a very complex field

Fig 3 – formula one is a very complex sport

Formula one is a complex sport, where winning the race means applying the limited research and development budget to the areas that will provide the biggest performance gain, while keeping the end-product easy to drive and less likely to break down.  The lessons we can take from the likes of Lewis Hamilton, Steve Jobs, and other race-winners are

-Simple products are better.  Don’t clutter the product with features that are unlikely to be used

- Simple products are cheaper to bring to the stage where you can tell if they’re worth carrying on with

- Simple products are difficult to plan.  You need to learn how to think simply, but it is worth it.



Lewis Hamilton, How keeping it simple makes me faster Accessed 28th March 2013

Roman Pichler, Agile Product Management with Scrum, 2010, Chapter 2

Photo Credits

Fig 1 * Bildbeschreibung: Mercedes-Benz W 196, Cockpit der Stromlinienversion * Quelle: ~~~ * Fotograf: Lothar Spurzem * Datum: 1993 im Rennsportmuseum am Nürburgring {{Bild-CC-by-sa/2.0/de}}

Fig 2 By Morio (Own work) [CC-BY-SA-3.0 (], via Wikimedia Commons

Fig 3 By Morio (photo taken by Morio) [GFDL ( or CC-BY-SA-3.0 (], via Wikimedia Commons

Curse of the ScrumMasterPlus

“The role of ScrumMaster works well but needs to be augmented with additional responsibilities to ensure projects stay on track”.  As Scrum becomes more widespread in the IT industry, the agile principles and the Scrum framework have been exposed to a wider audience of people familiar with traditional project management.  This article explores the perceived loss of a project linchpin in overall control of delivery (Adkins, 2010), the anti-patterns this creates, and an alternative approach to the problems faced.

You can't fight in here!  It's the war room!

Fig 1: We need to get this project under control

I’m a ScrumMaster in a firm at the later stages of an agile transformation.  The teams are bought in and often achieve high levels of performance when given the chance.  Recently, my role was transitioned from SrumMaster to Development Manager, incorporating the previous role but adding overall responsibility for all aspects of delivery, and also undertaking line management.  The Development Manager was to be a key role in the new structure by being accountable for the delivery of their team.

While looking for my next role, I interviewed for the position of Delivery Manager.  The recruiter had explained that the firm had previously employed ScrumMasters, but were now looking for people who could carry out this function as well as managing the project end-to-end and be accountable for project delivery.  During the interview we explored the issues of leadership within technical teams and identified the need for release plans, operational support, and many other things to be considered during the course of a project.  Their view was that a Delivery Manager needed to be accountable for these factors.

Side effects

The best Scrum teams I have worked with take an active interest in potential support issues, delivering valuable software, and the effect that their code will have when released to live.  They really care about the product and are one of the product owner’s most demanding stakeholders.  You don’t have to ask them about release implications – they are chasing you to help them track down that Ops manager they need to resolve an impediment with.

Let’s introduce a ScrumMasterPlus to a team like that, make them responsible for ensuring 90% code coverage and accountable for the deployment runbook.

The approach of the development team subtly shifts as a result.  They know they must hit that 90%, but the emphasis is no longer on the benefits of testing but on doing the simplest thing possible to get to 90%.  The team feels less responsible for making sure any deployment issues will occur.  They’re being chased up for rollback plans, which is a problem they can solve, but they are less likely to think about what might have been missed from the bigger picture.

Meanwhile, the ScrumMaster has become tied up explaining the 89% coverage and pouring over release procedures, hoping nothing has been missed.  Coaching the team has become more difficult because they are now fulfilling a key part of the process.  The Scrum coach has joined the rugby match and loses the ability to observe the team as a whole.

Elephant in the room

If it is undesirable to re-introduce the traditional omniscient project manager to address gaps perceived in Scrum, how do we re-establish confidence in delivery?  First, the organisation needs to understand why project managers were omitted from the Scrum framework.  Many project management functions do exist and are vital to success, but responsibility for them has been distributed between the Product Owner, ScrumMaster and Development Team (Pichler, 2010).

Second, go back to the Scrum framework and identify the biggest gap between what you are doing now and what it prescribes.  You probably won’t need to carefully pick through the 16 pages of the Scrum guide(Schwaber et al, 2011) to arrive at your answer; it is most likely to be the thing you’ve grudgingly accepted the business can’t stomach at the moment.  You may even have started to make light of it with senior managers.  This elephant in the room is holding you back, and unless you address it there should be no surprise that you need something more than a ScrumMaster to hold things together.



Lyssa Adkins, Coaching Agile teams, 2010, Chapter 6

Roman Pichler, Agile Product Management with Scrum, 2010, Chapter 1

Ken Schwaber and Jeff Sutherland, The Scrum guide, 2011

Photo credits

Fig 1 From Dr. Strangelove Directed by Stanley Kubrick, distributed by Columbia Pictures [Public domain], via Wikimedia Commons