Indeed, I guess the thing to understand is the cadence at which you do this. I think, as Michael suggests, that if they were done too frequently it would perhaps endanger the team’s own ability to look inwards and improve.

Dan

Interesting story – I’m quite tempted to try it out I guess every team should attempt to stay in contacts with it’s partners and actively seek the feedback required to do a better job.

Sune

Nice to hear form you as well. I must say I miss some of our debates about how to save the world – or at least part of it

Thank you for the 2 extra points which makes perfect sense. So much in fact that I might chose to copy your great suggestion.

Thanks!

Michael

You’re right, there is a danger in focussing solely on the perception of how the team is performing held by those outside the team; you could very well end up continually reacting to outside input which may just be manifestations of root causes that are all too apparent to members within the team itself.

I think this retrospective would be good to be done on perhaps a quarterly basis.

Having thought about the subject a little more since writing this post, there are a couple of points that I perhaps should have made in explanation:

1. This is about developing the relationship between customer and team, agile approaches tend to rely upon a strong relationship between customer and team and most early stage adoptions tend in my experience to focus on the team’s capability and requirements for change and not that of the customer. The first principle in the Agile Manifesto states that:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

It is easy to measure the value of software given access to the relevant information but in my experience, there is more to satisfying the customer than just that and the idea for this retrospective attempts to address that by at least asking the question about how the team could improve in the eyes of their respective customer.

2. In my past, most of the teams I have come across have been of the assumption that it is their job to write software. A discussion with their sponsor or customers often yields some interesting ancillary expectations. I’d like to think that by using this retrospective, these aspects may be surfaced and better yet, that a way of measuring against them could be defined. I would imagine that this would have the benefit growing the team’s capability to deliver holistically very much more quickly.

Dan