One of my favourite tools for giving and receiving feedback is the Perfection Game. It is a powerful tool to give constructive feedback in a non-threatening way. It transforms feedback from an attack or personal judgement into a constructive act of jointly improving software, articles, conference sessions, blog entries…

The Perfection Game lowers the barrier for giving feedback. It makes it much easier for me to give feedback faster and earlier, and to ask for feedback. It is useful for any situation where you want to ask or give feedback in a constructive way.

The Perfection Game is simple, but not necessarily easy and not always well understood. So how does it work?

• Someone presents their work, like a session proposal, a text, or code, and asks for feedback.
• You (the reviewer) rate the work on a scale from 1 to 10, based on how much value you can add. 10 means that the work is perfect for you. In other words, 10 means you don’t see any way in which it can be improved.
• You explain why you rated the work like you did. What makes up this number? What did you like about it? What should be kept?
• You give concrete suggestions for improvement, i.e. actions that would make the work perfect.

An example of a perfection game applied to a session proposal is:

I would give this session proposal an 8 out of 10.

What I like about it:

• catchy title, the abstract makes me want to attend
• well thought out process, seems realistic for 90 minutes

To make it perfect, I would:

• explicitly describe benefits for managers, because it would be good for the discussions to have the manager’s perspective in the room
• make the link with agile development explicit, so that it appeals to a wider audience

Some remarks:

• The rating is not a judgement, it is an indicator of how much possible improvement you see in the work.
• The Perfection Game focuses on the work instead of the person; feedback is in the eye of the beholder.
• Your improvement suggestions should be concrete and actionable; what would you do to improve the work?

It’s also great for perfectionists like me, to see the positive things and accomplishments as well

I’m co-organizer of Mini XP Days (1 April, to be announced) and XP Days Benelux (early December). We apply agile principles to organizing it, to make it an agile agile conference. We are feedback addicted and use the perfection game both during the conference, to get feedback about sessions, and in the iterative session review and improvement process, to help presenters develop quality sessions.

The Perfection Game is useful for any work product, code, text, design ideas, documents, blog entries, anything you are creating and you want to improve – it can help you get into a habit of constructive feedback and joint improvement, so that you’ll deliver better results faster.

So please do try this at home! (and work!)

• The Perfection Game is part of the Core Protocols by Jim and Michele McCarthy; I also recommend their entertaining & informative podcasts.
• The Perfection Game is similar to the scaling question from the solution focused approach.
• Perfection Game summary
• Yves Hanoulle has written an article on the Perfection Game and other Core Protocols.
• Perfection Games remove noise from developer feedback

I’ve been asked to do some presentations and workshops around lean and software development, which gives rise to some reflections on what’s currently going on around ‘lean’ (thanks to Willem for the good conversations on this topic and for pushing me to publish this blog entry )

Lean is becoming more and more of a hype, see people talking about lean methodology, lean certification, religiously implementing practices and tools like Value Stream Mapping, A3, Removing Waste (hey, I don’t like you you don’t add value, you’re waste!)

Lean is however not about practices & tools. It is primarily a philosophy, a way of looking at your organisation. Lean is about continuous improvement and developing the capability of the organisation and the people capability for improvement (see the Toyota Kata for more about this system that underlies lean).

Lean is inherently empirical, focusing on learning to see things as they are, not as they ought to be. Lean manifests itself in different contexts with different sets of principles and associated practices and tools. Lean works out differently for production processes, for services, for startups, for product development, even for software development there are different interpretations (listen e.g. to the Devnology interview with Mary and Tom Poppendieck)

I notice that a lot of conversations take place at the level of practices and tools, which are the most concrete manifestations. It is much easier to talk about tools, lean ‘methodology’ or even having a check list of observable lean practices. There is no general lean methodology, although different organizations can have a situated, continuously evolving methodology of their own, guided by lean principles.

Practices and tools are manifestations of principles and philosophy in a specific context – they’re specific solutions to specific problems in a specific context. They might or might not work in another context, even if that context is similar. But you won’t know if something works until you’ve applied it and got actual feedback from practice. This is related to what Dave Snowden writes about innovation diffusion:

Context is everything and often neglected. Something that works in one context may not work in another even if they are very similar. Ideas and practices need to have enough flexibility to adapt and ideally to combine with existing practice and other ideas. It means that pilot approaches have an inherent problem in that the initial success results in a specific context with a lot of effort. It won’t necessarily scale.

…and even when things worked out when you applied a practice or tool in your context, then you should be wary of confusing correlation with causation (doing the practice and having success does not imply a causal relation, it could be just correlation or even coincidence) and the retrospective coherence trap (everything looks logical and explainable in retrospect, but this does not help in predicting how things are going to work out).

Practices and tools are most concrete and easier to talk about, but they are the least important part of lean. They are highly situational,  almost random in a sense. To quote Dave Snowden again:

There is a paradox in that highly codified, highly abstracted material diffuses best (…), but is the least likely to be innovative or novel.

So people get stuck in tools, practices, methodologies, instead of focusing on philosophy and principles. The philosophy and principles are generative, setting up conditions that let a lean system emerge. Kanban for Software Development as presented by David Anderson and others is a good example of this.