Yes – the title isn’t a typo. This goes back to KataCon 4 in Atlanta. Though I had attended all of them, this was the first time I actually spoke at one. My task was to follow Rich Sheridan and share why I thought his message was a powerful one for an audience of Kata Geeks even if he wasn’t specifically talking about Toyota Kata in his company.
As an experiment, I took the sound recording from my talk and synchronized it with the slide deck. (That is harder that it sounds, by the way.) As another experiment I am sharing it via hosting on WordPress (the back-end of this site) rather than YouTube or a similar host. It is a little over 13 minutes long, and there is another experiment below it.
Key points from this great TED talk by Joi Ito, the director of the MIT Media Lab.
You can’t plan the path, you can only set the direction. He talks about the “compass” guiding a project that followed a route which was totally unpredictable. There was no way to plan out the path to success from the beginning.
Instead, at each step, they asked “Where are we now?”
“What do we need to do next?”
“What’s in the way of doing that?”
“How do we deal with that?”
I’m paraphrasing here, of course, but the key is that once again we have an instance the Improvement Kata pattern in the wild.
One of the artifacts of Extreme Programming as practiced by Menlo Innovations is the Story Card. In the purest sense, a story card represents one unit of work that must be done by the developers to advance the work on the software project.
But the content and structure of the story card make it much more powerful than a simple task assignment. The story card is written in a way that engages the programming pair doing the work.
Before a story card is created the team works very hard to identify the primary persona that represents the human being who most benefits from their work. That persona gets a name, a face, a biography. She has wants, needs and aspirations.
(c) Menlo Innovations. The primary persona is shown in the center of the target. There are two shown in the second ring, and three in the third ring.
Why? A couple of reasons.
First, it establishes priority of effort. In software development compromises must be made between optimizing the interface and workflows for various users. By identifying the primary persona, the team says “This person’s use of the software will be optimized.” Other users will certainly be accommodated, but any compromise will break in favor of the primary persona.
Menlo, for one, works very hard in the up-front design process to smoothly integrate the workflow created by their software into the larger context and workflow that their end-user is trying to carry out.
The other effect is more subtle. It humanizes the “user” as the developers are talking about what their code does, or does not, do.
Rather than simply set out a feature in an abstract way, the story card focuses on granting an ability to the main persona. The process of creating the personas, and developing the persona map humanizes the group of people that would traditionally be thought of as “the users.”*
Thus, the feature would be described something like this:
“Sara is able to select her choice of color from a pull-down menu of options.”
Then the developers write code that enables Sara to do this, quickly and easily.
This is a simplification, but it suffices to set up my main point.
Who Are You Optimizing Your Improvements For?
Let’s translate this thinking into our world of continuous improvement.
Who is your key persona? Who are you enabling with your process improvement? What will this person be able to do that, today, he cannot?
Rather than saying “The lowest repeatable time does not exceed 38 seconds” as a target condition, what if I said “John is able to routinely perform the work in 38 seconds when it is problem-free.”
I don’t know about you, but I feel a lot more emotionally engaged with the second phrasing. This is doubly true if John is an actual person actually doing the work.
What about scaling to other shifts, other operators?
Yup. I agree that at some point your target condition is going to shift to “Any trained team member” but what I tell people today when they are trying to go there first is this:
“If you can’t get it stable with one person, you are never going to get there with multiple people.”
You have to get it to work once first. Then introduce the next layer of complexity. Start simple. One step at a time. Control your variables.
I have been experimenting with this linguistic shift in my Toyota Kata classes and consulting.
If you are in R&D this is an even more direct application back to Menlo’s model.
Training = Giving People Ability
I also ran an experiment with a client HR team that was charged with developing a comprehensive on-boarding training process.
Rather than do the traditional thing, which is take the laundry list of topics they are supposed to try to cover, and trying to figure out how to stuff everything into the time they have been given (40 hours, which is really more like 35 hours), I asked them to experiment with the following:
For each skill they have been asked to train, write it on a separate 5×7 card in the form of “[The learner] is able to _________.” In other words, describe the skill as an ability that someone is able to demonstrate.
Then determine how they will test that skill. Do that before they even think about how they are going to teach it.
Then develop training experiences and exercises that they believe will allow the learner to pass the test.
Software developers will recognize this as “test driven development” – start with the unit test, then write the code.
Testing Your Target Condition
As in the example above, a target condition should also be testable. By stating what we will observe or measure when the target condition is met, we are constructing a “unit test” of sorts.
By stating what we will observe or measure first, we can separate “solved” from “the solution” and open up the possibilities of what solution(s) we will experiment with.
—————–
In the culture of many more traditional software development and I.T. organizations, “users” can be almost a derogatory term, with an implied, usually (but not always) silent “dumb” appended to the front. We write Books for Dummies so they can understand our brilliant systems.
In this TED Talk, Amy Edmondson of the Harvard Business School talks about “How to turn a group of strangers into a team.” Although long-standing teams are able to perform, our workplaces today require ad-hoc collaboration between diverse groups. The question is: What kind of leadership, and what kind of structure, contributes to working together on the problem?
For those of you unfamiliar with her work, I’ll add that I have found anything that she writes or speaks about is worth reading or listening to.
The key message starts around the 10:00 minute point:
“When teaming works, you can be sure that leaders, leaders at all levels, have been crystal clear that they don’t have the answers. Let’s call this ‘situational humility.’ It’s appropriate humility. We don’t know how to do it.”
[…]
“It’s hard to offer up an idea that might be a stupid idea if you don’t know people very well. You need psychological safety to do that. They overcame what I like to call this basic human challenge: it’s hard to learn if you already know. And unfortunately, we’re hardwired to think we know. And so we’ve got to remind ourselves – and we can do it – to be curious; to be curious about what others bring.”
Which brings me to the quote I pulled for the title of this post: It’s Hard to Learn if you Already Know. As Amy Edmondson points out, “we’re hard wired to think we know.”
To counteract this we need to construct different artifacts that focus our attention on our shared understanding vs. trying to advocate a particular position.
Creating The Structures of Teamwork
As obvious as this is when we say it, if we want to create a culture or social structure of teamwork this must be done deliberately. This is especially important in environments where ad-hoc groups must collaborate very quickly. So… what works? I don’t know. But we do have the tools to figure it out.
Structure to Focus on The Problem
When two people are talking about a problem while looking at each other, they tend to equate “the problem” with “the other person.” Rather than trying to reach a shared, common understanding, the tendency is to try to convince the other person to adopt their point of view.
But if we introduce some kind of artifact – an A3, a Learner’s Storyboard, a shared keyboard and monitor – that physically turns people to look at the problem rather than at each other, the dialog changes.
“What we’ve got here is a reason to communicate.”
Think about the key difference between people looking together at the information versus someone at the front of the room, facing everyone else. The tone shifts from “tell me” to “work with me.”
Think of the key difference in a meeting between everyone sitting at the table talking about the problem vs. what happens if someone stands up and starts to draw it out on a whiteboard.
What companies like Menlo Innovations, Kaas Tailored, Toyota, and others do is construct physical artifacts to focus people’s attention away from the person and toward the information. The information becomes neutral, vs. being attached to someone. If something isn’t working, we can work together to fix the issue vs. fix blame.
The “Lean Tools”
Let’s take something as simple as standard work. What is it for?
One interpretation could be that I watch you perform the work, and if you violate the procedure, you fail the audit for not following the standard.
But the other interpretation is that we have a neutral point of comparison for how we think the work should proceed if it is problem-free. Seeing, or detecting any difference reveals a problem of some kind. We are invited by this information to look at the problem and seek to gain more understanding.
Of course, just sending an invitation doesn’t mean people come to the party. Shaping that conversation in constructive directions is what leadership is about.
And, as always, I write these posts mostly to clarify my own thinking by trying to explain it to someone else (you). I’d love to know what you think, so post comments!
I’m going to break a rule of blogging and acknowledge I’ve been pretty much offline for quite a while since the last post. But I also want to push through what I started because this all leads to more.
====
My next pages of notes I took at Menlo were about crafting a message for a Kata Geek audience – what is it about Menlo’s process and culture that is relevant to them (you?).
Again, I am going to pretty much transcribe my notes, though I am going to edit a bit as I wrote them in first person as though I was Rich, and I am not going to do that here. In the end, these became a foundation for the keynote I ended up giving following his.
Key Point: These words are mine, and no one else’s. I do not pretend to speak for Rich or anyone else, I was simply consolidating my own thoughts by using a possible talk as a vehicle for myself.
Theme: The Improvement Kata: Experimenting to create a deliberate culture.
(Scene 1: Exposition)
We are probably all after the same thing: To create a workplace where people are excited to come to work every day.
That experience has little to do with the work itself. It emerges when we can create a culture where:
Fear has been extracted.
Ambiguity (that causes fear) has been eliminated.
Relationships are strengthened every day.
I believe Menlo has created that culture. What I want to do today is discuss how you can use what you are learning with Toyota Kata to create these things in your own organization… Even (especially!) if you are not in charge
(Note – this part may be a little confrontational)
If you are in charge, there is nothing and no one stopping you. It is a matter of knowing what you really want, and being accountable to yourself and your team to create it.
Joy is very different from happiness. Joy is what we experience with the release of creative tension (figuring it out).
Success vs a challenge
Winning a game against a tough opponent.
That feeling we get when “it works!”
We can also experience joy with relief or resolution from psychological or physical danger – the same brain chemicals are at work – but this is DRAMA, not creative attention. We don’t want this, because it is relief from FEAR, not a sense of accomplishment.
(Scene II – “The Call”)
To create joy in others, you must fist look at yourself.
Cross the bridge
Be fearless
Take a step
Self-empowerment
Give yourself permission to NOT get everything right the first time – EXPERIMENT
“The most dangerous thing you can do is try to pretend you know when you don’t” – leads to paralysis by fear of discovery.
Until you can comfortably say “I don’t know” to yourself, you will be unable to learn.
“Find a a coach / be a coach” with whom you can create a bubble of safety to explore your own threshold of knowledge as a change agent. Arm yourself with allies.
(Scene III – “Walk into Mordor”)
In a large organization, middle management sets the tone.
This is the end of the notes I was taking, but these themes get explored more deeply as I continued this journey.
One of the things Menlo does (and I am sure they are not the only ones in their business who do) is create user personas – a biographical profile of a fictional person who represents a category of potential user for the software they are developing.
In Joy, Inc, Rich Sheridan describes the often contentious process of then forcing the customer to pick a single persona as the primary user – the persona whose needs will drive all decisions about optimization. That person goes in the center of their three rings.
They allow two personas in the 2nd ring, and three in the 3rd ring.
As they make design decisions about their code and user interface, they always defer to the innermost rings. That doesn’t mean that someone in a ring further out won’t have their needs met, but they will meet those needs in ways that don’t compromise the process for personas closer to the center.
Persona Mapping for KataCon
In the spirit of being a temporary Menlonian, I worked paired with Craig (over the phone, and in a shared Google Doc) and we developed a persona map for KataCon. Of course, had we done this correctly we would have gone back in time to the previous KataCon, gotten the profiles from the attendees lists, interviewed people, and put together profiles for “typical” people who attend.
Since we couldn’t do that, we pushed past our threshold of knowledge and combined experience with a bit of speculation. I did confirm some of our assumptions via a phone call to Dwayne at Lean Frontiers who graciously answered my questions as he was driving across Indiana.
This process forced us to actually think about who was in the audience, and why they were there – what they were seeking from their participation in the conference. As Rich and I talked about his message, and later on as Craig and I worked on our “Experiential Workshop” we used the names of these “people” rather than generic terms like “participant” or “audience.” I found that really focused our conversations.
Who Do You Optimize Your Process For?
This really begs the general question: Who is your process optimized for?
Is it optimized for the person doing the work?
For the customer’s specific experience? And if so, who is the “customer persona” you are optimizing THAT for? For example, for an ideal retail experience, a mom with two kids in tow would be a different customer than a single guy. You likely get both, but if you have do something that slightly compromises one in order to optimize the other… who is in the center ring?
The 2018 Toyota Kata summit (KataCon4) ended several weeks ago. During the first three summits, I posted daily updates. This time I didn’t. Since the conference ended, I started a couple of posts trying to summarize but it’s been difficult. Here’s why – Starting last December when I visited Menlo, I’ve been learning and thinking so fast that by the time I wrote anything down, what I wanted to say had changed.
So KataCon4 was, for me, an event along a timeline, and I haven’t been able to separate those three days from everything else.
As part of my own effort to reflect and consolidate where I am, I am going to do my best to write up where I have been along this little journey and share it with you.
Even now, I am probably going to do the best I can to capture this stream of consciousness, not necessarily a concrete insight (yet).
Raw Notes from Menlo
I’m going back to December. What follows is largely unfiltered from the notes I took on a yellow pad while sitting in Menlo’s work space. Some of this is just my impressions, some of it is thoughts for a message for KataCon. I’m going to format the notes as quotes, to distinguish them from any afterthoughts I am adding as I review them to write this.
Menlo 12/12
Wow!
I am the only person here not talking to someone.
Possible themes
Experiments –> Culture
Deliberate, purposeful
Innovation follows the IK pattern. Learn it. Use it on everything you do.
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
– John Gall
That quote (above) is painted in big letters in one of the two meeting rooms at Menlo. The rooms have glass walls facing the work area.
Thought: Imagine creating a screenplay like this.
What I meant here was I could totally envision a workshop of writers all working on scenes that would assemble into a comprehensive story. The organization seems that robust for coordinating multiple parallel efforts toward a common, integrated goal.
—————–
Quick ( <5min ) stand-up meeting on how to handle communicating a mistake to a client.
——————-
Possible application for [client] staff meeting:
Staff member has fixed daily time for dealing with “action items”
At meeting, estimate time to complete.
Create a “story card” put on board.
Follow up next day.
What was done?
What was learned?
——————–
Thought: the structure drives the IK pattern more than the conversations.
The structure has evolved with this purpose – to ask and answer the “5 questions” automatically, unconsciously, as an inherent part of the work.
They don’t ask the 5 questions, but as a part of the daily routine, the answers to them are explicitly, or implicitly, discussed.
——————-
“Structure” = “Routines & Rituals” –
The embedded repeating patterns are deliberately designed into the work.
Designed to: Common understanding of…
Maintain direction and challenge between Menlo and the client.
– Developed iteratively through HTA process.
Get a thorough understanding of the current condition (workflow, personnas, etc)
Establish successive target conditions
– Story cards and deadline = delivered, testable function = change in current condition
Iterate against unknowns toward TC
Verify new TC
This process highly structured but organic and evolving as required to meet needs as we learn.
It is a complex system, anchored, evolved from simple systems that worked.
You can’t copy it, you have to develop it through your own deliberate learning.
Started with “Let’s try it” on a small scale, even though there is tons of literature describing it.
——————
How we feel [values] drives how we think.
How we think drives what we do.
Get crystal clear on your values.
What emotion are you striving to create? (JOY!)
What will you absolutely do?
What will you absolutely never do?
Next Post: Making this relevant for the Kata Geeks.
