Crucial Conversations, Respect and Kanban

About a month ago, Benjamin Mitchell kicked off a thread on kanbandev called How does the Kanban Method reduce fear about role changes if change is emergent/unpredictable, mainly a discussion of what Kanban meant by “respect”. I couldn’t quite put my finger on it at the time but I was not completely satisfied. Now that I have finished reading Crucial Conversations: Tools for Talking When Stakes are High (Patterson, Grenny, McMillan and Switzler) I have a much better sense of what I was missing from that conversation.

This excellent book is all about how to handle better those crucial conversations where opinions vary, the stakes are high, and emotions run strong. Highly recommended, and I have added the related books Crucial Confrontations and Influencer to my reading backlog too.

One (of many) very relevant part of the book explains how mutual respect helps to create a safe environment into which all participants in a crucial conversation can contribute. And without safety, the book argues, real dialog is impossible.  Where mutual respect needs to be created, focus on similarities instead of differences.

Now I can draw a parallel with what we do when we use Kanban to surface, investigate and address difficult process issues in organisations. Whether we are acting as internal staff or external facilitators, our task is to get the heart of things, to be “seekers after truth” (Senge-style). This requires dialog! Hence the “Respect for people” pillar of Lean, the “Respect current roles and responsibilities” of Kanban, and Deming’s “Problems are 94% in the system”. To these I could add some favourite phrases such as “it’s about the work”, “organisations have needs too”, and several more that move the focus away from the person to the work and to the broader system, creating safety. Speaking from recent personal experience I can say that they really help, together of course with the facilitative mindset that goes with them.

So when I hear hear managers or team members personalise their criticisms of others (“they’re so unprofessional”), see references (even in jest) to “evil management” or consultants speaking in ways that seem disrespectful of their clients, I cringe and (increasingly) I challenge. How do we improve anything by starting with blame? Instead, what reasonable explanations might there be for the behaviours we observe? What might we all be missing?

It’s easy to judge (and yes I see the irony: perhaps I’ve just been a little guilty of it myself here) but it doesn’t get us very far. Catch me making more serious infringements and you are invited to call me out :-)

The A3 challenge

My previous post has been sitting there at the top of my front page for too long now, and it doesn’t reach my usual levels of positivity!  So let’s change that with a quick challenge:

  1. Can you relate the features in your development backlog (or at least the prioritised and in-progress portion thereof) to an identifiable business initiative?
  2. If – for real or in your imagination – you justified (compellingly), scoped and planned each of these business initiatives in just two sides of A4, how many of the features in your backlog would deserve a mention?

I take it for granted that you organise most of your development work by feature.  Large initiatives are allowed sub-initiatives, each also described (compellingly still)  in no more than two sides of A4 (real or imaginary).

The “A3″ of this post’s title refers to an A3 report, presented on a sheet of A3 paper (the size of two sheets of A4).  I wholeheartedly recommend John Shook’s Managing to Learn if this concept is new to you.

Learning together: Kanban and the Twelve Principles of Agile Software

This post is a spin off from the recent Scrum/Kanban debate.  Not wanting to let a situation go to waste, it seems a good time to affirm shared values, which I do here via the Twelve Principles behind the Agile manifesto.  I’m grateful to Joshua Bloom for his excellent input.

Commentary on the twelve principles of agile software

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

Kanban: Check. We pull business value through the system, creating flow.  It should be recognized however that sometimes we create value by means other than delivering software (sometimes even by not delivering software!).  Furthermore, the act of improving the system generates value as it increases the capability of the wider organisation to generate value.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Kanban: Check. We actively limit work-in-progress (WIP), facilitating late prioritisation and minimising the impact of change on lead times.  We actively work to clarify the customer’s priorities so that the team can manage risk by properly sequencing work.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Kanban: Check. We make deliveries at intervals consistent with customer need and transaction cost.  We seek to minimise transactions costs attributable to the software development process, thereby making shorter delivery intervals economically optimal.  Highly advanced teams look towards continual deployment concepts to limit the inventory of complete yet not deployed software. We believe the best requirements come from software already depoyed being exercised by the customers/users. Achieving flow to the end-user generates higher value faster.

Business people and developers must work together daily throughout the project.

Kanban: Check. The development team and customer must learn together, in relation to both the problem domain and the delivery process.  The visual element of Kanban promotes transparency and creates triggers for customer interaction.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Kanban: Check. Build processes that respect individuals; empower them to learn and to improve the system.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Kanban: Check. Visualization and models allow face-to-face conversations to scale effectively. Limiting WIP prompts teams to have conversations DURING difficulties.

Working software is the primary measure of progress.

Kanban: Delivered business value is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Kanban:  We work within and share responsibility for the capability of our system; sustained long-run capability cannot be built at the short-term expense of the individual.

Continuous attention to technical excellence and good design enhances agility.

Kanban: Check.  And we look to increase capacity by identifying and reducing the failure demand that results from inattention to quality.

Simplicity – the art of maximizing the amount of work not done – is essential.

Kanban: Check.  Furthermore we actively manage work-in-progress, minimizing work not finished.

The best architectures, requirements, and designs emerge from self-organizing teams.

Kanban: Check, and process too. Leaders (inside and outside the team) must foster emergence, not squash it.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Kanban: Check. Continually even.

Conclusions

So there you have it, no fundamental conflict but a couple of clarifications and some changes of emphasis too.  It has to be said that these small differences do add up to a shift of mindset, but it is one that much of the Agile community has taken on board as a result of the increasing influence of Lean.

If I were to pick out a key thought it would be this:

The development team and customer must learn together, in relation to both the problem domain and the delivery process.

This lesson would be recognised by much of the Agile community I’m sure.

What are your “red button” phrases?

Self-management” is one of mine.  A blog  post on 5whys.com didn’t take the trouble to fully explain the concept in a way I approved of, and it provoked a less-than-charming tweet.  Sorry.  Very graciously though, Roy Osherove (the target of my disdain) gave me a the opportunity of a guest post:

Leadership and the mature team

Please give it a read. And be nice to Roy, he deserves it!  For the record, I actually agree with much of his original post, most especially in the value of coaching as a leadership model.

Another favourite red button of mine is “strategic” – a while back I had a team that in my presence would refer to it as the “the ‘S’ word”.   It bugs me particularly when it is used to refer to technologies or applications, and “X is strategic” means “our strategy is to use X”, and that, sadly, is the sum total of any strategic thinking.

So what are your red buttons, particularly in the realms of software development, IT leadership and leadership/organisation in general?