Tracking change and innovation in the enterprise software development community
Posted by Deborah Hartmann Preuss on Feb 16, 2008
Over supper one night, a group of senior practitioners found themselves comparing notes on how they use (or don't use) the Retrospective Prime Directive with teams. Professor and writer Philippe Kruchten kicked it off, sceptical that it's really possible to say "...we understand and truly believe that everyone did the best job..." It was such an interesting conversation that Linda Rising, with permission, wrote it up in this InfoQ article. Rising and others, including Esther Derby, Norm Kerth, and Mary Poppendieck joined the fray, relating their best and worst experiences using this tool with teams."Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand."The conversation began when Kruchten challenged this:
Really? I have met subversive, obnoxious, really destructive people during my career as a developer and consultant. In most cases, I could not do much about them. Work around or without them. ... Just saying that I "truly believe," is not acceptable to me.This challenge resonates: how can we possibly use this practice when the top execs in our organization are under investigation for fraud? Or when everyone knows there's a slacker or malicious malcontent on the team?
The Prime Directive is not about reality. It's about enabling the brain to focus elsewhere, just for a short time, in order to maximize learning... I know that when I ask people to "sign up" for the Prime Directive, they are thinking exactly what you are thinking, and that's OK. They are just pretending for a short time, but it's enough to put those judgments aside so that the team can learn.Owen Rogers:
...it took me a while to get it. The impression that I got from reading Norm's book is that it was just something that you just read at the start of a retrospective -- like an incantation. I tried it a couple of times but no magic. So I abandoned it. ... it requires more than just reading it out. You really need to have a discussion with the participants about what it means before the lights come on.Consultant Ainsley Nies, who spent many years teaching and running retrospectives at HP, suggests taking the Prime Directive out of the meeting room and back to one's desk or home - as a helpful context for personal reflection:
Remember to apply the Prime Directive to yourself! In my Personal Retrospective Workshop we discuss how our futures are greatly influenced by how we talk about ourselves and our experiences ... many folks noting that they are more likely to apply generous interpretation to others than to themselves, and ultimately how this affects their work.Read the entire conversation on InfoQ: Questioning the Retrospective Prime Directive by author and teacher Linda Rising.
A ScrumMaster’s Checklist: Product Owner, Team, Dev Practices, Organizational
3 reasons why you should add Automated Error Reporting to your application
Collaboration, facilitation, leadership, coaching and team building - new skills required for Business Analysts on agile projects. Download the Agile Business Analyst to read more.
Up to this point and even in the first half of this article I continued to be skeptical of why it would make sense not to call out if an individual was not performing up to what was expected... but now I think the light bulb has gone on, I only hope I can remember this when I need to apply it.
For what it's worth, I'm personally truly believing that everyone is doing the best he can. I can understand and empathize when someone isn't truly believing it, though.
What I find dangerous is the notion I seem to read in some of the comments above, that you should *pretend* to *truly believe* that everyone did his best. To me that sounds counter to acting authentically, which I feel is very important for open honest communication.
Ilja makes an important point: authnticity is essential to personal and team development.
My experience on retrospectives has been that team members not performing well, or getting distracted will own up to it themselves, thus removing the need for anyone to believe (or pretend to believe) otherwise. That is when the process feels healthy. Rather than faking this belief thing, I feel it is better to foster a culture throughout the daily working life that allows people to fail, to be distracted, to goof off -- and to own their behavior.
The retrospective is not a time to evaluate performance, I agree, but it is also not a time to lie about reality.
I think perhaps the prime directive is an outmoded idea more suitable to teams not used to discussing things openly. I hope most Agile teams these days are beyond that.
I never understood the Prime Directive to ask us to lie about reality. I never understood it to ask us to *not* own our own behavior. And I always tried to get that across in the discussion of the PD at the start of a retrospective.
I guess I always had the Second Directive in mind, when using the Prime Directive: "We accept the responsibility to change at least one of the conditions that made our best less than we now want it to be."
I like the second directive very much (and appreciated the link to The Responsibility Razor -- good stuff).
On reflection, I don't agree with myself that the prime directive is outmoded, just the way it is applied. The ideas of belief in others, trust, and respect should be applied every day, all the time, not just at the retrospective. I like to think that is what I do, which is why (perhaps) I have never actually used the prime directive in a retrospective. The same concepts are just sort of implicit.
:)
Perhaps, depending on the climate of the room, it's sometimes necessary to allow people the option to leave if they can't buy the Prime Directive?
I have had some times when I have been very demotivated at work, and during these times I did some lousy work. But it was still the best I could do - given all the other things that were happening around me and my mental state at the time. A lousy job was the best I could do that day. I think everybody - by definition - is always doing their best.
I think the prime directive is true and you should really believe in that to perform the retrospective.
I wrote more about it in this post
franktrindade.wordpress.com/2008/04/10/dont-bla...
Cheers
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Download
new Adobe®
Flash® Builder™
JBoss vs. Websphere
Cost, Performance,
Efficiency,
Innovation
IBM wins.
Book excerpt
How are messages
stored by
Apache ActiveMQ?
Jason H Christensen presents the evolution of mobile devices, how to integrate mobile systems with the cloud and use RESTful services, what is a basic mobile architecture and how it can be implemented
Kresten talks about current languages and problems they solve. He tries then to portray the language that would take us to the next level helping to tackle issues we face today such as concurrency.
Tim Smith introduces the licenses offered by Oracle/Sun and Microsoft, with a focus on how they may affect third party implementation such as Google’s Android platform.
Russ Miles and Toby Hobson outline many factors to be considered when adopting a cloud solution, creating a wider view of the cloud from the development and business perspective.
Kelley Horton discusses the reasons why her organization transitioned to Lean-Agile, the approach used and the visual tools helping them minimize WIP, concluding that visibility leads to success.
Alex Blewitt, Kevin Seal and Alex Buckley answer Java modularity-related questions: when is modularity needed, how to address it, and what are the improvements in OSGi-based development.
Adam Blum discusses the current trends in mobile development and smartphones, trying to predict what will happen in this area over the next 5 years so a developer would know what to expect.
Roy Osherove discusses the difficulties met when trying to test code embedded in a framework (cog), presenting several solutions to create unit tests for cogs, using Silverlight code as example.
9 comments
Watch Thread Reply