Clarke Ching - More Chilli Please

Commitment Based Management - Conversations for Action

Several months ago I asked Sanjiv Augustine, author of the delightful and useful book “Managing Agile Projects” if he’d mind me sharing the section in his book where talked about Fernando Flores’s work and (what we at VISION) call Commitment Based Management. It’s a great primer on the subject.  During the next year I hope to share an example or two of how we use the Conversation for Action (below) for diagnosing co-ordination breakdowns and thier waste.  It’s one of those things that’s obvious in retrospect …

But, in the mean time, here’s Sanjiv’s excerpt:

Activity: Link Language with Action

From a business value perspective, transforming exchanges are useful only if they result in business outcome-oriented commitment, action and accomplishment. The language/action perspective stresses that most of the actual work in organizations happens through the making, keeping and coordination of individual commitments.  People make commitments and deliver on them through performance or action.  Transforming exchanges and concomitant business value can only materialize if the networks of these commitments that exist in organizations are coordinated effectively.  A large part of Agile Manager’s work thus involves engaging in conversations that create and coordinate team member’s commitments, and orient these commitments towards transforming exchanges of information.  There are three important types of conversations that enable action-oriented transforming exchanges: conversations for action, conversations for possibilities and conversations for disclosure⁴. 

Conversations for Action

A conversation for action is a series of speech acts – meaningful acts of speech – that generate explicit coordinated action,⁵  as illustrated in Figure 7-4.

Figure 7-4.  Basic Conversation for Action

An effective conversation for action begins with a customer making an offer or request that has clear conditions of satisfaction.  This is followed by a performer’s promise with a clear completion date and time, and subsequent performance – action to deliver on the promise.  When the job is complete, the performer makes a declaration of completion.  Finally, a declaration of satisfaction by the customer completes the cycle, and it begins again with another offer or request.  The cycle emphasizes what people do while communicating, how work is accomplished through language and how effective communication can result in effective coordination of the work. 

 

On agile teams, a clear example of a conversation for action takes place in every iteration:

· User stories are estimated and prioritized in the Iteration Planning meeting.  Customers identify user stories for an iteration in order of priority. Working with the team the project manager creates an iteration plan with a backlog of user stories to be completed. The backlog represents outstanding “requests” of user stories to be completed;

· Team members accept responsibility or “promise” to implement user stories from the iteration plan and perform work to complete them during the iteration;

· Team members follow their “promise” with the “performance” of user story implementation; and

· At the next Iteration Planning meeting, team members “declare completion” of the user stories.  Customers then “declare satisfaction” by accepting the user stories they requested.

 

How can this knowledge help the Agile Manager?  It can help because, by understanding the structure of effective conversations for action, Agile Managers can enable transforming exchanges of information during the iteration.   For instance, they can help ensure that customer requests are clear to the development team by requesting clear conditions of satisfaction in the form of acceptance tests.  They can help manage customer expectations by ensuring that promises made by the development team are grounded in experience.   They can coordinate the performance of team members to ensure that they are delivering on the right commitments.  Finally, Agile Managers can ensure that customers make explicit declarations of completion to eliminate any confusion on the part of the development team.

 

 

 

Conversation for Action Example

Agile Manager:  David, could you please implement this loan performance user story completely by close of business tomorrow?  [request with clear condition of satisfaction]

 

David: Well, I need to finish another story I’m working on before I can begin this one.  I’ll complete the loan performance one by noon the day-after-tomorrow [promise].

David:  I’ve completed the loan performance user story as you requested. [declaration of completion]

 

Agile Manager:  (after verifying it) Yes, it looks good. Thanks for completing it [declaration of satisfaction].

 

Agile Managers can also apply the knowledge of conversations for action to their own requests of team members: specify clear conditions of satisfaction when requesting work, and clear declarations of completion when accepting completed work. 

Conversations for Possibility

Collective action on project teams creates results that are beyond the capability of any single team member.  Conversations for possibility are transforming exchanges of information that create the background and opportunities for action to be taken collectively.  They are team conversations that reinterpret current and past events as a basis for future possibilities.   A common example of a conversation for possibility is scenario planning (to be covered in Chapter 9).   Scenario planning involves brainstorming potential future scenarios based on current and past realities.

 

Agile Managers can help spark creative dialogue and transforming exchanges on project teams by initiating conversations for possibility.  All activities connected to the Guiding Vision, including Release and Iteration Planning, are opportunities to engage in creative conversations about future possibilities of the product or application being developed.  Project reflections, where process pros and cons are evaluated, are also another good forum for these conversations.

Conversations for Disclosure

Conversations for disclosures reveal our interpretation of events and realities to each other.  Truly transforming exchanges of information cannot take place unless team members understand each others’ interpretations of reality.  One of the most important effects of collocation is that team members in close proximity of each other are pushed to understand each other and disclose much more than they would otherwise.  This deeper understanding of each others’ interpretation of events and realities is needed before team members can align and coordinate effortlessly with each other.  The close personal interactions on agile teams create several opportunities for disclosing and synchronizing team members’ views with each other.   Disclosure is aided not just by speaking, but also by effective listening.   

 

The Agile Manager can enable transforming exchanges through conversations for disclosure known as assessments.   Fernando Flores provides the script for delivering assessments shown in the sidebar⁶.

 

Script for Delivering Assessments

Assessor: [Name], [negative assessment]; [positive assessment].

Person assessed: [Name], thank you for your assessment. I appreciate your sincerity. I would like to have further conversations with you about the topic.

Assessor: Thank you.

Person assessed: You're welcome.

 

Source: The Power of Words by Harriet Rubin, Fast Company, January 1999.

 

Here’s example of a personal assessment that I received in a team meeting:

 

Deirdre: Sanjiv, You are not doing enough to support business expansion at our largest client; you did a good job managing the last project there.

Sanjiv: Deirdre, thank you for your assessment. I appreciate your sincerity. I would like to have further conversations with you about the topic.

Deirdre: Thank you.

Sanjiv: You're welcome.

 

As you can imagine, delivering and receiving assessments is not easy for software development professionals who have been trained over a lifetime to be polite to each other.  But assessments are sometimes necessary for team members to speak the truth to each other, especially when they share responsibility for the success or failure of a project.  They are especially useful when things begin to go wrong, and team members need to speak frankly and honestly with each other.  Assessments are great transforming exchanges, because trust builds up very quickly when people are able to speak honestly to each other.

Thank you, Sanjiv, for sharing.

Commitment Based Management and High Probability Selling

I’ve been in my new job about 8 months now and during this time I’ve been learning about Commitment Based Management, VISION’s secret weapon.  My impression so far is that it is a very, very powerful lens for seeing how things do get done (or don’t, which is more typical).  It’s a len’s for seeing the flow of actions and commitments within an organisation.  I’m wowed! because I know understand Agile – and the need for agile – much better … and I’m still “learning to see”. 

I’m sorry for being vague and I don’t mean to be a tease – I will share more, but just now I’m not confident enough with CBM to write about it on my blog.

In the mean time, if you’re interested to learn about Commitment Based Management then I recommend you take a look at High Probability Selling by Jacques Werth.  It is based on Flore’s work (although he doesn’t credit Flores anywhere).  The first 4 chapters are online free.

High Probability Selling is really a method of inquiry. The inquiry is designed to arrive at a meeting of the minds and result in mutual commitments between the salesperson and the prospect by determining whether:

A. The prospect needs, wants, and can afford our product;

B. The prospect is willing to define his Conditions of Satisfaction which, if met, will result in the purchase of our product;and,

C. The commitment the prospect makes with regard to his Conditions of Satisfaction is specific as to all the necessary particulars and is absolute and unequivocal.

Although I’ve only so far read up to chapter 5, I’ve found it a comforting read.  Possibly [unintended suck up here] … because it reads like my boss wrote it.

[The HPS book was kindly suggested to me by James Bullock]

Three ways to enable transforming excahnges

I was thrilled last year when I opened Sanjiv Augustine’s brilliant new book “Managing Agile Projects” when found a reference Fernando Flores. 

Flore’s was a very young finance minister in Chile before being imprisoned during the Pinochet regime.  It seems he spent most of his spare time in prison thinking, as you would, and when he was finally released he went on to become a very rich consultant, practicing his special and unique form of managing and design businesses – what is now known as Commitment Based Management.  I joined VISION Consulting specifically because they (I mean we) are one of the few organizations practicing Commitment Based Management.  CBM compliments the TOC, Lean and Quality thinking perfectly and it provides an elegant  framework for understanding Agile too.  I’m slowly learning the Flores approach and working with my colleagues to join up the thinking between Agile and Commitment Based Management.  Some of this work will appear in my book.

Anyway, as I was saying, Sanjiv’s book has a section on Flore’s work.  His book is fascinating because he looks at both project management and Agile just a little differently – a little more profoundly even – than most other Agile books.  I liked what he’d written about Flore’s work and Sanjiv has kindly sent me some copy to share with y’all.

Today, we kick of with a brief introduction.  It refers to 3 ways to enable transforming exchanges, one of which is linking language with action, but future postings will only cover linking language with action.

TRANSFORMING EXCHANGES

Transforming exchanges are exchanges of information between people that result in personal transformations: each person participating in the exchange gleans some new insight, some new experience or some new learning. 

Take the example of an acceptance test, when a customer first sees a demonstration of a requested feature.  The customer may learn something from the ex-change about the restrictions in system implementation.  Or she may get some new insight into further possibilities.  The development team may learn something from the customer's initial response.  Was the feature exactly as she had imagined it, or was it implemented differently from the way she had described it? The customer's reaction usually speaks volumes to the development team, and they will learn much as a result.  The acceptance test serves as a great vehicle for transforming exchanges of information. 

If there aren't sufficient transforming  exchanges between team members, their work will be disjointed and lacking in end-value. Agile methodologies enable transforming exchanges through several practices covered above.  However, there is still a need for Agile Managers to recognize transforming exchanges as such and enable them in  fuller fashion.   The three activities presented next: encourage feedback, build trust, and link language with action; all con-tribute towards amplifying the intensity of the transforming exchanges on your agile team.

Anyway, thanks for sharing Sanjiv.  More to come.

I want to write about ... but I'm too busy

I want to write about lots of things but …

I want to write about John Seddon’s fantastic work on apply Lean and Quality thinking to service organizations.  Take a look at all of his articles and you’ll see why.  John’s approach made a huge difference at a very large former employer and I’ve been influenced deeply by the stuff he taught them.  For instance, John talks about two types of demand: value demand and failure demand.  Value demand is the demand we want from our customers (e.g. can I buy a new product please?).  Failure demand is demand we don’t want from our customers and is caused by mistakes we make (e.g. You’ve charged me the wrong amount again this month, can you fix it please).  Value demand make money and is good.  Failure demand causes rework and is bad.  How much failure demand, BTW, is there in your software development system?

I want to write more about Fernando Flores work on Conversations for Action and Hal Macomber's brilliantly simple email course called Let’s play catch (it’s free too).  This stuff is good and I’ve just started working for a fantastic consulting company that lives and breaths Flores stuff.   But the trouble is … it’s hard stuff to learn, it’s hard stuff to teach, and I’m not allowed to talk about much of the training I’m getting in my new job since they (I mean “we”) consider it the major source of our competitive advantage.  That said, I’ve been trying to read Flore’s and Winograd’s “Understanding Computers and Cognition” but OMG it’s hard reading.  Hal’s course is much easier and much quicker.  I’m going to write about this stuff but I need to get my head around it first.  It’s too important for the world to not know about it.  Stay tuned.

I want to write about Marcus Buckingham’s extraordinary new book The one thing you need to know about Great Managing, Great Leading and Sustained Individual Success.  This book has changed my life.  I read it in 2 days about 6 weeks ago and it’s absolutely changed how I manage and think about managing.  It’s made a difference.  It’s all about getting people to work to their strengths and avoiding their weaknesses.  I can’t do it justice here.  Go buy the book then buy it’s predecessor Now, Discover your Strengths, read the first few chapters, then do the online test (you need to buy the book to get a special code). 

I’d like to remind you to go buy Audible.com’s 45 minute presentation from Dr Robert Cialdini.  I’ve listened to this a dozen times now and I learn more each time.  I’ve also lent the CD to over a dozen different people and it’s been a hit.  And it costs less than $3.

I’d like to setup amazon associates to these links, but who can be arsed?  It’s only money – and right now I prefer having the time.

I’d like to  tell you a bit more about Ship it! A Practical Guide to Successful Software Projects by Jared Richardson and Will Gwaltney.  But I haven’t finished it yet.  I “met” Jared via the new AgileBookClub yahoo group where he (cunningly) mentioned that the book is on sale this week (how’s that for a generous plug from me?).  I took a squiz at the Introduction and free excerpts and bought a hard and soft copy straight away.  Based on my reading of the PDF so far … it’s going to be a classic.

I’d like to tell you about a whole lotta other things but I’ve just run out of steam.  Thanks for listening and, just in case you’re wondering, I never recommend anything that I don’t totally and utterly believe in.

Don't miss: Conversations for Action

I blog to learn from my writing and to share.  Today, you can skip straight to the sharing bit clicking straight to the “lets play catch” website and signing up to Hal Macomber's mini email course, which I recommend at the end of this blog.  Or, you can continue reading and get there just a few minutes later.

A few years ago I came across Hal Macomber’s Reforming Project Management weblog.  This was in the days before XML feeds, RSS and bloglines but I was checking his blog every day to pickup his latest gem.  Hal seemed, to me, to have GOT what I was trying to GET: he was practice lean thinking, he was well versed in Goldratt’s stuff, he was doing it and he was writing about it.  Over the years we have become good email buddies.  Even though  he doesn’t blog so much these days my respect continues to grow.

Enough gushing.  In a few moments, I want to point you to Hal’s latest freebie offering – a mini-email-course – but before doing that I want to tell you my story.

One day I was looking through Hal’s “About Hal” section on his website and I was intrigued when  he said that his “preoccupation with operations effectiveness finally paid off when [I] learned about workflow, Fernando Flores' linguistic-action reinterpretation of work.”  What?, I thought, A guru I don’t know about?  I hunted around the web for more info on Flores but I didn’t find bugger all (apart from this fastcompany article that points out he was once Chile’s Finance minister and a political prisoner and these two WSJ articles).  I found a couple of books on amazon.com (here and here), both of which are – to be honest –  fairly hard going. 

Intrigued, I was, ignorant I remained.

At about the same time I discovered the Agile Software Development movement and bumped into my now good friend Hubert Smits through the AgileScotland group which he had started (and I now run).  It turned out that Hubert was working for Vision a Irish-owned consulting company that not only practiced the Flores' stuff but now owned BDA, the company started by Flores.  Hubert told me more about Flores' work, I met his boss, we chatted, months passed, one thing led to another, and now – since February – I’m working for them on contract.  My boss and good mate Jorge has been sharing the Flores' stuff and I’ve picked up bits and pieces as I go.  I see why Hal was impressed:.  Flores' theories and practices make things work.  He has filled a gap in my own knowledge that I truly didn’t even know was missing.

I’m still an amateur, but Flores’ stuff revolves around conversations, commitments and trust.  To put in my simplistic words, it is much easier to manage if people make good commitments that keep.  If they keep their commitments then trust develops.  High trust organizations need less ceremony, paperwork and bureaucracy to keep things flowing.  Conversely, in organizations where people don’t keep their commitments, there is generally low trust, the costs of enforcing commitments are high and they are very hard to manage.  Contrast a software development team that keeps its commitments by delivering projects on time and budget with one that doesn’t.  Where would you rather work?  Which would you rather have as your supplier?  Which has the most paper work?  Which team’s customer tries to drive productivity by enforcing arbitrary deadlines?

This trust, commitment, conversation stuff kinda obvious I suppose, but it’s not so easy in practice because most of us aren’t taught how to do it.  Some of us do this intuitively (not me, to be fair), but what Flores did was figure out a framework for having conversations that result in kept commitments and build trust.

I’ve nicked the following diagram from vision's website that shows what is known by Flores devotees as “the loop”.  It shows the typical flow of a conversation.

What this simplified version of the diagram doesn’t show is the many ways and places where the conversation can go wrong.  But it’s not hard to fill in the gaps: think of a recent conversation you had where either you made a commitment or one was given to you, match it to the diagram, then think of all the ways it went wrong or might still go wrong.  One of the killer problems, for example, in software development is “requirements ambiguity” which in terms of  “the loop” happens when the “Conditions of Satisfaction” aren’t clear.  Writing the tests for each requirement before building the code and prototyping both clarify the “conditions of satisfaction”, bypassing much ambiguity and preventing lots of expensive rework.  [And this is, of course, horrendously easier to do in an iterative/incremental/agile environment than a waterfall environment – have you ever tried to write all of the tests for a 150 page requirements document, up front, when the requirements keep changing all the time?].

Now, finally, back to Hal Macomber.  Hal has recently come up with a FREE mini-email-course “lets play catch”, which teaches the fundamentals of “the loop”.  Each day he sends a series of brief, daily emails with explanation and simple actions for you to do.  He also gives you access to an hour long MP3 webcast which is worth its weight in gold.  Maybe one day he’ll write a book about it.

Warning: this is another one of those things, like google, that on the face of it appears simple and “common sense” and so, you might be inclined to undervalued it.  Don’t.