It is six years now since I introduced Retrospective Dialogue sheets to the world and I continue to get great feedback about the sheets. Now I’m running a little MVP with the sheets via Amazon, but first…
In the last few months Alan Baldo has translated the planning sheet to Portuguese and Sun Yuan-Yuan, with help from David Tanzer, has translated two of the retrospective sheets to German.
Thank you very much Alan, Sun and David!
I also updated the Sprint Retrospective sheet (above): version 5 has removed all references to software development. While can still be used by software teams it is more general. Actually, the sheet was largely domain neutral already which explains why it has been used in a Swedish kindergarten for retrospectives.
In the meantime I’ve been busy with an MVP experiment of my own – which has taken a surprising amount of work to get up and running – and you can help with.
Right now this is market test, the printed sheets are only available in the UK I only have a few sheets in stock so this is a “Buy now while stocks last” offer.
If you are outside the UK (sorry) and want a printed sheet, or find stocks have run out, or want a different printed sheets please contact me and I’ll do my best.
Assuming this is a success then I’ll get more sheets printed, arrange to sell outside the UK, add more of the sheets to Amazon and make a renewed effort on translations. Pheww!
So now I need to ask for your help.
If you have used the sheets and find them good please write a review on Amazon – there are a few but there cannot be too many.
Conversely, if you have never tried a Dialogue Sheet retrospective please do so and let me know how it goes: I am always seeking feedback. Download and print for yourself or go over to Amazon and buy today – you could be the first buyer!
When I deliver Agile training for teams I run an exercise called “The Extended XP Game”. It is based on the old “XP Game” but over the years I’ve enhanced it and added to it. We have a lot of fun, people are laughing and they still talk about it years later. The game illustrates a lot of agile concepts: iteration, business value, velocity, learning by doing, specification by example, quality is free, risk, the role of probability and some more.
When I run the exercise I divide the trainees into several teams, usually three or four people to a team. I show them I have some tasks written on cards which they will do in a two minute iteration. They do two minutes or work, review, retrospect then do another two minutes of work – and possibly repeat a third time.
The first thing is for teams to Get Ready: I hand out the tasks and ask them to estimate, in seconds how long it will take to do each task: fold a paper airplane that will fly, inflate a balloon, deflate a balloon, roll a single six on a dice, roll a double six on two dice, find a two in a pack of cards and find all the twos in the pack of cards. Strictly speaking, this estimate is a prospective estimate, “how long will it take to do this in future?”
Once they have estimated how long each task will take someone is appointed product owner and they have to plan the tasks to be done (with the team).
What I do not tell the teams is that I’m timing them at this stage. I let the teams take as long as they like to get ready: estimate and plan. But I time how long the estimation takes and how long the following planning takes.
Once all the teams are “ready” I ask the teams: “how long did that take?”
At this point I am asking for a retrospective estimate: how long did it take. The teams have perfect estimation conditions: they have just done it, no time has elapsed and no events have intervened.
Typically they answer are 5 or 6 minutes, maybe less, maybe more. Occasionally someone gets the right number and they are then frequently dismissed by their colleagues.
Although I’ve been running this exercise for nearly 10 years, and have been timing teams for about half that time I’ve only been recording the data the last couple of years. Still it comes from over 65 teams and is consistent.
The total time to get ready to do 2 minutes of work is close to 13 minutes – the fastest team took just 5.75 minutes but the slowest took a whopping 21.25.
The average time spent estimating the tasks is 7 minutes. The fastest team took 2.75 minutes and the slowest 14 minutes.
The average time planning once all tasks are estimated is just short of 6 minutes. One team took a further 13.5 minutes to plan after estimates while another took just 16 seconds. While I assume they had pretty much planned while estimating it is also interesting to note that that team contained several people who had done the exercise a few years before.
(For statistics nuts the mean and median are pretty close together and I don’t think the mode makes much sense in this scenario.)
So what conclusions can we draw from this data?
1) Teams take longer to estimate than do
Everyone taking part in the exercise has been told – several times – that they are preparing to do a 2 minute iteration. Yet on average teams spend 12.75 minutes preparing – estimating and planning – to do 2 minutes of work!
Or to put it another way: teams typically spend six times longer to plan work than to do work.
The slowest team ever took over 10 times longer to plan than to do.
In the years I’ve been running this exercise no team has ever done a complete dry run. They sometimes do little exercises and time themselves but even teams which do this spend a lot of time planning.
This has parallels in real life too: many participants tell me their organization spend a long time debating what should be done, planning and only belatedly executing. One company I met had a project that had been in planning for five years.
2) Larger teams take longer to estimate than small teams
My second graph shows there is a clear correlation between team size and the time it takes to estimate and plan. I think this is no surprise, one would expect this. In fact, this is another piece of evidence supporting Diseconomies of Scale: the bigger the team the longer it will take to get ready.
This is one reason why some people prefer to have an “expert” make the estimate – it saves the time of other people. However this itself is a problem for several reasons.
But, those same notes include research that shows that people are better at estimating time for other people than they are at estimating time for themselves, so maybe this isn’t all bad.
However, this approach just isn’t fair. Especially when someone is expected to work within an estimate. One might also argue that it is not en effective use of time because the first person – the estimator – has to understand the task in sufficient detail to estimate it but rather than reuse this learning the task is then given to someone else who has to learn it all over again.
3) Post estimation planning is pretty constant
This graph shows the planning delta, that is: after the estimates are finished how long does it take teams to plan the work?
It turns out that the amount time it takes to estimate the task has little bearing on how long the subsequent planning takes. So whether you estimate fast or slow on average it will take six more minutes to plan the work.
Perhaps this isn’t that surprising.
(If I’ve told you about this data in person I might have said something different here. In preparing the data for this blog I found an error in my Excel graphs which I can only attribute to a bug in Excel’s scatter chart algorithm.)
People underestimate longer periods of time (typically anything over 10 minutes), and overestimate short period of time (typically things less than two minutes).
Not only do trainees consistently underestimate how long it has taken them to get ready – which is over 10 minutes – but teams which record how long it takes to actually do each task find that their estimates are much higher than the actual time it takes. Even when teams don’t time themselves observation shows that they do the work far faster than they thought they would.
5) Less planning makes more money
One of my extensions to the original game is to introduce money: teams have to deliver value, measured in money. This graph shows teams which spend less time planning go on to make more money.
I can’t be as sure about this last finding as the earlier ones because I’ve not been recording this data for so long. To complicate matters a lot happens between the initial planning and the final money making, I introduce some money and teams get to plan for subsequent iterations.
Still, there are lessons here.
The first lesson is simply this: more planning does not lead to more money.
That is pretty significant in its own right but there is still the question: why do teams which spend less time planning make more money?
I have two possible explanations.
I normally play three rounds of the game. When time is tight I sometimes stop the game after two rounds. In general teams usually score more money in each successive round. Therefore, teams who spend longer in planning are less likely to get to the third round so their score comes from the second round. If they had time to play a third round they would probably score higher than in round two.
This has a parallel in real life: if extra planning time delays the date a product enters the market it is likely to make less money. Delivering something smaller sooner is worth more.
This perfectly demonstrates that doing creates more learning than planning: teams learn more (and therefore increase their score) from spending 2 minutes doing than spending an extra 2 minutes planning.
The second possible explanation is that the more planning a team does the more difficult they might find it to rethink and change the way they are working.
The $1,600 shown was recorded by a Dutch team this year but the record is held by a team in Australia who scored over $2,000: to break into these high scores teams need to reinterpret the rules of the game.
One of the points of the game is to learn by doing. I suspect that teams who spend longer in planning find it harder to break away from their original interpretation of the rules. How can you think outside the box when you’ve spent a lot of time thinking about the box?
In one training session in Brisbane last year the teams weren’t making the breakthrough to the big money. Although I’d dropped hints of how to do this nobody had made the connection so I said: “You know, a team in Perth once scored over $2,000.” That caused one of the players to rethink his approach and score $1,141.
I’ve since repeated the quote and discovered that simply telling people that such high scores are possible causes them to discover how to score higher.
* * *
I’m sure there is more I could read into all this data and I will carry on collecting the data. Although now I have two problems…
First, having shared this data I might find people coming on my agile software training who change their behaviour because they have read this far.
Second: I need more teams to do this to gather data! If you would like to do this exercise – either as part of a full agile training course or as a stand alone exercise – please call (+44 20 3286 4292) or mail me, firstname.lastname@example.org, my rates are quite reasonable!
I’m surprised to find I’ve written over 60 pages so far! Still, this is very much a work in progress, there are a few more chapters to add to part 1: The Product Owner role.
But it is part 2 which I’m itching to start writing: the tools of the trade.
For those who don’t know, the beauty of LeanPub is that you can buy my unfinished book now and you will receive updates – to your iPad, Kindle, PC, whatever – as they are produced.
That means three things to me.
Firstly I can receive your feedback – what do you like? What did I get wrong? What else should be in there?
Second, money is feedback, the more of you who buy the book the more motivated I am to write it – I like seeing sales, it tells me people want this book. And if you don’t buy… well maybe I should pivot and abandon it.
Third, it gives me a little beer money.
The bad news is: you also get my dyslexic spelling and grammar.
With some final words I’d like to draw this mini-series on the Product Owner to a close and open a new chapter with a new book. I’ve written six blog posts in the last two months and I have drafts for more but there are other things I want to blog about.
I have drafts for more posts and ideas for even more. So its time to make this into another book: Product Ownership. This is on the LeanPub site now and you can buy it. So far it just contains a new prologue story but I’ll add these posts soon as the first chapters.
Ever since I wrote Little Book of User Stories I’ve thought there should be a companion volume: “Little Book of Product Ownership”. The intention is for the first part of the new book to discuss the product owner role – and whether it should even exist – and then quickly get into the tools of Product Ownership.
Now some closing words…
While I’ve suggest a lot of things that a Product Owner should do, and a few that they should not do, there are really no hard and fast rules about what a Product Owner should or should not do.
In the language of business schools: there is no contingent way of being a product owner, every product owner and organization is different and they need to find their own path. I cannot give you a flow chart for what a product owner does or should do, nor can I give you a set of rules to say “When the customer says Foo the Product Owner should do Bar.”
Every Product Owner has to work out what is right for them because every organization is different. And every organization will – rightly or wrongly – expect different things from the people it christens Product Owner.
Additionally every team is different and contains different skills and experience. As a result every team will differ in what it needs from the Product Owner(s) and how the team members can support the Product Owner and share the work.
And every Product Owner is themselves different and brings different skills, experience and insights to the role.
Job #1 for a newly appointed Product Owner is to sit down and decide what type of Product Owner they are expected to be and what type of Product Owner they want to be:
They may be a Backlog Administrator taking instructions from others.
They may be a Subject Matter Expert using their expert knowledge of the domain to decide what the right product to build is and help other team members understand the details of what is being built.
They may need to analyse internal process and business lines using the skills of Business Analysis.
They may need to get out on the road to meet customers – and potential customers – to understand the market and where the opportunities are using the skills of Product Management.
They may need to call on skills from other fields to: Project Management, Consulting and Entrepreneurship to name a few.
But a Product Owner is not some other things:
If they were a developer they need to accept they will not be coding any more. There simply isn’t time and anyway, they need to trust the team.
If they were a Project Manager, Development or Line Manager they need to resist any urge to tell people what to do or look too far into the future. They need to re-focus on value not time, and recognise that their authority comes from their competence not from a position on a chart.
Product Owners from a Business Analysis background need to look beyond Business Analysis, specifically they need to immerse themselves in the world of Product Management.
While Product Owners who were Product Managers probably have the easiest ride they too need to change, they need to think more about internal stakeholders, processes and delivery.
Every Product Owner and everyone working with Product Owners needs to read and reflect on the role. Hopefully some of the words in my recent posts – and the new book – will help with that – and hopefully some of you might like to hire me for advice or a training course – just call 🙂
Finally, I sincerely believe there are better Product Owners and not-so-good Product Owners, and that some organizations (teams, companies, enterprises) which offer a better environment for Product Ownership and equally there are those which are downright hostile to product ownership.
Surprisingly I’ve never blogged about the Strategic Product Owner / Tactical Product Owner model, this is surprising because it is a model I both find again and again and advocate again and again.
I find lots of companies who have a version of this model in place, they have created the model to deal with their own situation. But few of these companies realise that this is a reoccurring solution and is quite legitimate. (I should write it up as a Pattern but I haven’t written any patterns for a while.)
More importantly I find that many companies and individuals faced with problems around Product Owners benefit from adopting this model. Specifically, as I’ve already mentioned there is a lot of work for a Product Owner to do and one way of doing this is to share the load.
If I were to write this up as a pattern the thumbnail version would say something like:
The Product Owner lacks the time – and sometimes skill – to fill the role fully therefore split the role in two. One person, the SPO (Strategic Product Owner), looks long term, they focus on customers and strategy. The other, the TPO (Tactical Product Owner), focuses on the near term (this sprint, the next sprint, the next quarter). The TPO spends most of their time with the delivery team while the SPO spends most of their time with customers and senior stakeholders.
Sometimes the Product Owner lacks time simply because – as I’ve said before – there is so much work the Product Owner should be doing they simply don’t have time.
Sometimes they lack time because the team is large, or the team lack domain knowledge (and therefore need to ask the PO lots of questions). Sometimes POs need to travel a lot to meet customers and even the most talented PO can’t be in two places at once.
They may also lack time because they have another job to do. While I think the Product Owner role is a full time job sometimes the person who is the right person to hold the role – usually because they command authority – needs to combine the work with another role.
For example, on a trading desk the Product Owner should probably be a senior trader who both knows the domain and has the authority to say Yes and No to features. But by definition such a person lacks time. Normally I’d want a dedicated Product Owner in place but sometimes the only way to have the necessary authority is to have another job.
And sometimes the person who is should be Product Owner – think our trader again – lacks the skills and experience to do the role. So again they need help.
The key thing about the SPO/TPO model is that the two people who hold the role need to speak with one voice. If they do not then the model will fail. Ideally the SPO will stand in when the TPO is unavailable and vice verse.
There is another occasion when the SPO/TPO model can be useful: big teams.
Ideally there is one product owner, one team and one stream of work. But sometimes there are several products, teams and streams. Here you might have an SPO who looks at the long term and several TPOs each of whom works with one team on one stream.
Now, like all good patterns this one is not without its downsides…
I’ve heard Scrum-advocates argue against this model: One True Product Owner they say. And they have a point… putting more people between the delivery team and the customer does detract from communication.
One of the problems software development faces is when multiple people think they have the right to say what is built next. Another problem occurs when the customer is remote from the development team and multiple people mediate what is asked for.
Ideally developers can talk to customers directly but that is often not possible or desirable – I won’t go into the reasons right now. So a good solution is One True Product Owner.
But then the One True Product Owner becomes a bottleneck so we split the role SPO/TPO. Yet every-time we introduce another link – another person – between the coders and the customer the greater the propensity to introduce problems. So it becomes a balancing act.
Nobody in between can be ideal.
One person can make it better.
Two people can be an improvement over one.
Three… I need some convincing this is an improvement over two.
Four… I find it hard to believe that having four people mediate the voice of the customer is an improvement… unless of course you previously had five!