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 Preuss on Mar 18, 2010
Conflict is actual or perceived opposition of needs, values and interests, which may occur internally (within oneself) or between people or groups of people. We talk about "healthy" and "destructive" conflict, and generally we have worked very hard to eliminate it. There is a whole professional field of study called "conflict resolution - a range of methods for alleviating or eliminating sources of conflict.
Some, however, maintain that conflict "resolution" is illusory: that it is impossible to change others, and that effective conflict resolution is more about self-awareness than about 'strategies' for 'dealing with' others. For those of us coaching "self-organizing" teams: how do we navigate in this territory?
Lyssa Adkins, author of Coaching Agile Teams maintains that not only does "resolving" conflict not work - it can also be counter-productive. "On great agile teams, conflict is constant and welcomed by all as a catapult to higher performance." In her ADP2009 keynote, and in this Better Software article, she presented a model developed by Speed Leas for helping teams learn to de-escalate from destructive conflict into constructive forms of conflict.
Focus on language. What people say and how they say it is the main key for assessing the level of conflict on an agile team. The team will be in conversation frequently, so there will be many chances to focus on language. Pay attention to the words people choose.
At level 1, team members engage in conflict openly and constructively.
At level 2, the conversation changes to make room for self-protection.
At level 3, distorted language such as overgeneralizations, presumptions, magnified positions, and either/or emerges. Real issues get lost.
Level 4 becomes more ideological.
Level 5 is full-on combat.
The goal of navigating conflict is to de-escalate. Knock it down a notch or two. ...Teams - even new ones, even broken ones - can often navigate the conflict by themselves, even conflict in the level 3 range. Even if it's not perfect or the "complete" job you could do for them. ... If you observe long enough (which should feel like a really long time) and decide that your intervention is needed, there are a few response modes you can employ [these are described in the article] ...
Teams that actively navigate conflict and de-escalate regularly can learn to thrive in level 1 conflict... They dance on the edge of discomfort - just enough so that they can come up with the best ideas and build upon one another to find astonishing new possibilities. This is how they use conflict as a catapult to high performance.
Ironically, our Agile community - seemingly bursting at the seams with coaches - suffers no less than others from unhealthy conflict. In Escalation is Killing Agile – Can We Please Stop It? Rally coach and trainer Jean Tabaka made an appeal to the community at large to stop the destructive one-upmanship over Agile methods. Some mistook this for a plea to avoid conflict. Not so, she later replied in Escalation is Killing our Healthy Conflict in Agile:
Some ... [inferred] that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must. In this model, Kaner insists that, to get to high performance, we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.
Transforming Software Delivery: An IBM Rational Case Study
18 agile and lean practices for effective software development governance
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
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!
I love this article.
One of the model's I use is the Bruce Tuckman: Forming-Storming-Norming-Perfoming.
Most (80%)team's (better word in this case would be groups) don't pas the storming phase because they want to avoid conflict.
My friend Jim McCarthy says they are not avoiding the conflict but are avoiding the resolution. (The conflict is there, it might be hidden now. It will exp(l)ose at some time)
I know people that were proud they never ever had one discussion in their 10 year old marriage. We are 10 years later. They still did not have one conflict. They are no longer married. (Without any conflict or discussion.)
A technique I use with teams to take quick decisions (and to see where peopel don't agree with eachother)
is Decider
liveingreatness.com/files/core-protocols-3.03.h...
Planning Poker is also a technique to see conflicting idea's.
Relative estimation can do the same.
If people don't speak up enough in relative estimating meetings. I sometimes let them do the estimations in silence. (Moving the cards in silence.) It might look strange but doing things in silence, makes the conflict more clear.
Yves
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.
1 comment
Watch Thread Reply