Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Deborah Hartmann Preuss on Feb 16, 2008
"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.
Transforming Software Delivery: An IBM Rational Case Study
18 agile and lean practices for effective software development governance
SCM best practices for multiple processes, releases & distributed teams
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
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
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
9 comments
Watch Thread Reply