Open Space Agility Handbook Book Review

I’ve been playing and experimenting with the idea of pulling people into agile transformations instead of pushing them for several years. I find the idea holds great promise and these days I try to integrate it into my work as an enterprise lean/agile consultant whenever I can.
I found the Open Space Agility movement/framework headed by Daniel Mezick pretty useful as a way to structure/guide my way.

Daniel and a couple of colleagues just released a short and sweet handbook about Open Space Agility.

OpenSpace Agility Handbook on Amazon

Tho book provides very useful introduction and guidance for those interested to move from the Push/Mandate world to the Pull/Invitation/Opt-in/Consent world that is much more aligned with Lean/Agile thinking of “Respect People”, “Individuals and Interactions” and “Self-organized teams”.

Especially as this idea is disruptive to how agile transformations typically happen these days (as do other types of changes/transformations), having a “big picture” and a book, especially one so clear and instructive will help the idea “cross the chasm”.

If you’re already familiar with Open Space Technology you will find the “Open Space Agility” specific extensions coverage most interesting. If you’re new to Open Space Technology this handbook provides an “executive summary” of what you need to know if you’re considering inviting it into your organization.
Even as an early adopter and a follower of the Open Space Agility movement I found some illuminating details in this book so I highly recommend it for anyone considering launching a lean/agile initiative or is frustrated by the oppression and lack of energies around an existing initiative.

Here’s some of my previous materials around this theme:

Pull-based Change Management Blog Post

Lean Kanban France 2014 Interview around using Kanban/Pull as an enterprise change management approach

Boosting Agile through Invitations

 

 

 

Helping with Kanban – Thoughts from reading Helping by Edgar Schein

I recently read Helping: How to Offer, Give, and Receive Help by Edgar Schein (actually I listened to it on Audible and then read it again on kindle to better process/digest). I can highly recommend it if you are interested in ways to become a more helpful consultant, manager, person – one who is able to actually help people/organizations rather than just dispense advice/suggestions. I’m not doing a full review of the book here but there are a couple of points I found very interesting in the relation between the Helping approach and the Kanban Method, which I wanted to put out there. I will probably talk more about this in my Lean Kanban North America 2014 Interactive Workshop in San Francisco on May 8.

The key theme in the book is that in order to provide helpful help you need to be build the helping relationship – not jumping to the expert/doctor role of dispensing advise/diagnosing but first listening, understanding, working through what Schein calls Humble Inquiry which starts with Pure inquiry – understanding what is happening without trying to influence the client in any way. Only then moving to Diagnostic Inquiry which directs attention to other aspects in the story and Confrontational Inquiry which asks what-if questions thereby hinting at suggestions (which is close to the Doctor/Expert role).

“This kind of inquiry can best be described as accessing your ignorance and, because it is genuine inquiry, it is appropriate to call it humble. The helper becomes open to what may be learned through observation and careful listening. The helper’s expectations may be incorrect, and it is the helper’s willingness to accept new information that elicits trust and makes the client feel better about having a problem”

If we look at what we are trying to do with Kanban – it is quite similar. We start with understanding the system by visualizing it. Not trying to diagnose/probe too deeply before we understand – actually before the client/clients understand. Accessing our ignorance – we don’t know HOW the system is working, we don’t know how it SHOULD be working. Which is exactly what Schein is trying to do with process consulting – to build the understanding together, not be in a position to understand FOR the client but WITH the client. In Schein’s perspective this not only minimizes the chance we will dispense generic advise based on our experience of similar events but will help to equilibarate the relationship between helper and helped – listening and respecting the situation helps the client/helped gain back “face” that he lost by asking for help. If we don’t “bring the helped up” by doing this there is a chance he will “bring us down” by trying to be very critic and unaccepting of our suggestions by the way.

“Starting out in the process consultant role is the most likely to facilitate status equilibration and to reveal the information necessary to decide on what kind of help is needed and how best to provide it. Only when some level of trust has been established is it possible to get accurate information that allows the shift to the expert or doctor role. As the helping process proceeds, the helper may shift among all three roles many times as the situation demands.”

This humble inquiry approach is also aligned with our approach towards management workshops in AgileSparks. Our instincts over the years pointed us away from diagnosing and presenting solutions and towards a more humble exploration of the system/context in parallel to presenting some useful patterns like Kanban, Scrum, ATDD. I try to emphasize the diagnostic role of these patterns/frameworks and the fact that even when we go out of the room with a decision to do something, it is basically a continuation of this “humble inquiry” (I didn’t use the term until today obviously…). We are obviously shifting roles from process consultant to doctor and expert and one of my main takeaways is to be more conscious about the role I’m playing and whether it is the effective/helpful one at the moment. I’m definitely jumping to the doctor/expert one faster than I should – and I will try to work on that using some tips and tricks from the book.

To summarize – and as I answered Bob (Marshall) yesterday – this book leaves me: startled (discovering new perspectives of how I’m doing things), a bit ashamed (for being more of a Doctor/Expert), alert (to the potential of being more helpful using this approach) , curious (about whether I can actually leverage it and what will happen if I do), rejuvenated (by getting a fresh perspective to something so core to my work). So bottom line the Helping book was quite helpful.

Art of Action by Stephen Bungay – Book Review

The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results

Before Lean Kanban Central Europe 2011 I never heard of Stephen Bungay. He delivered a magnificent keynote that ended the conference (you can see the slides here but the video is just for participants) and so I became interested in his work inspiring Business Strategy by Military Strategy especially as espoused by the Prussian Army in the 19th century. I recently finished his book The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results and wanted to recommend it to anyone reading my blog as well as share some thoughts.

A key concept in the book is that we are operating under increasing forces that obstruct our ability to predict what will happen, create total alignment on actions our organization takes and on the effects/impact the actions people eventually take will have. This is referred to as “Friction”.

A key model in the book and in Bungay’s work is that friction is caused by 3 gaps – see below.

The Problem

The Solution

I found a very strong connection between the different gaps and the approach to closing them and what we are doing in Lean/Agile world. I think this model brings a lot of sense into some of the key agile practices.

The strongest connection is to User Stories. User Stories provide a very strong focus on Intent (if you do them right, that is the “So That” part…). They don’t go into the details on purpose, leaving them to the next level to hash out. We start with very high level User Stories and then break them down level by level, sometimes handing down a branch of the User Story to a different team/group, similar to the way mission commands can be handed down to the different units participating in the mission. It is important for the team working on the story to understand the context. Bungay recommends two levels up is just right. So Be aware of the Epic/MMF this story is part of as well as the Product/Theme/MVP we are currently working on. More is too much, Less is too little.

I love the concept of Briefing and Back-Briefing so much that I want to experiment with renaming “Iteration Planning” into “Iteration Briefing” and “Back-briefing” and adjusting the format of the meetings accordingly. Good teams already do something like that I think, which is a good sign that this model is a good way to look at things and explain them.

Look forward to more concrete ideas for how to leverage Bungay’s work in Lean/Agile. In the meantime my full comments/notes are available on the Amazon Kindle site and best would be to actually read the book. I think you will enjoy it.

(If you are really interested in my conclusions from the book, comment here and let me know, maybe I will enrich this post some more…)