Fresh Perspectives on Lean Coffee

The following is a guest post by Victor Bonacci. Question #1: Do you like coffee?

I do. I enjoy it warm or on ice. I love the smell. I get excited with the neurochemical reactions it stirs in me. I find calmness in the process of brewing a cup. It’s a fun word to say: “coffee.”

Coffee is a casual sport. Grabbing a coffee with a friend or colleague is often an impromptu act. Someone is more likely to agree to meet for coffee than to accept my invitation to dinner.

With coffee, the investment is low. Topics are light and change rapidly. The environments where we drink our coffee often vary in eclectic and inviting ways.

Question #2: Do you like meetings?

I’m going out on a limb to guess that you may not hold the meetings in high esteem. A typical work meeting runs too long, is unexciting (if not downright boring) and usually less effective than it can be. The conversation may be more monologue with one person dominating - usually the one who arranged the meeting. The meeting’s agenda is pre-planned with perhaps no collaboration or input.

I don’t know about you, but I see the score as “coffee: 1, meetings: 0.”

Whose Reality Is It Anyway?

This is why I love Lean Coffee. It replaces the tyranny of the meeting with something that is effective, engaging and (dare I say) fun. (We can’t say that in the office, though, where “Fun” is a four-letter word.)

Lean Coffee meetings (I often refer to these simply as “coffees”) are, in the Agile parlance, self-organizing. They get us involved. The coffees stimulate our natural curiosities and keep us from answering multiple choice questions with a “true/false” answer.

You’ve heard the parable of the blind men describing the elephant. We each have our own perspective - our own  “reality tunnel” as Tim Leary was fond of saying. At a coffee, topics get considered and described by any number of perspectives, each voice providing a slight turn to reveal different facets. It’s the “wisdom of crowds” rule: the more voices contributing the the conversation, the closer to the “truth” we can arrive.

I’ve used lean coffees in a multitude of settings, and I’d like to highlight two. If you’re already familiar with the mechanics, it’s easy to imagine meet-ups or retrospectives using this lightweight format, so I’ll skip those in favor of some less obvious applications.

One for the Roadmapping

First let’s consider the workplace. I’ve alluded to using coffees in retrospectives, but what if you’re not a Scrum / Agile shop? There may still be a number of meetings that can follow the Lean Coffee format. One that I’ve had success with recently is tied to the Roadmapping process, a staple of the yearly business cycle. I work with technology folks who, independent of the sales pipeline, are asked to list, size and prioritize some set of initiatives that are either wanted (eg. trying out a new language) or needed (eg. addressing tech debt) by the engineering departments.

When I try to recruit participants (usually a subset of architects, team leads, etc.) for a roadmap planning session, everyone spontaneously seizes up and/or runs from the room. If on the other hand I invite them to a planning coffee, curiosity may outweigh feelings of obligation. When the dozen-or-so victims, er, members arrive, they see an inviting table with index cards, markers and coffee carafes (optional). We chit chat until enough people are there to begin, not always waiting for or worrying about the stragglers. A quick explanation of the coffee rules, and we’re off writing our wishlist items onto 3x5 cards. People are out of their chairs, their brains getting more oxygen then at standard (death-by-)meetings, and the mood stays light. Cursing about this or that “problem” with our current development environment often elicits chuckles from across the table.

Affinity mapping the cards is a fantastic cue for glimpsing the importance of a topic, but we still do some dot-voting after each topic card (or group of cards) is summarized. If we ended the meeting at this point, we’ve already collected more information transparently and asynchronously in under ten minutes than we could have hoped for in a two-hour session going around the table with each representative speaking up in turn. Still, we play out the hour-long event asking questions of and examining the top few topics.

For roadmapping, I’ll take these data (topics cards, votes, added explanations) and compile it onto some shared document. Others throughout engineering are free to read this and add or update as they like. I’ve been successful using other methods (such as DeBono’s Six Thinking Hats) to add more dimension to the list before turning it over to engineering leadership. The CTO appreciates that the entire exercise not only spanned days (not weeks), but also remarks how pleased she is that the department “owns” (has defined and is accountable for) the list. It makes her job of negotiating with other management much easier.

Cast a Wide Coffee

Another application that caught me by surprise came as an offshoot of our community meetups. Like most of our caffeine-fueled sessions, the topics were interesting and the discussions lively at the coffeehouse in February, 2014, and I didn’t want the conversation to simply fade into the ether. So I put the topic out there: recording the coffees to make a podcast. Heads nodded as encouragement and suggestions flowed. So I bought some basic recording equipment (mics, cables, a small mixer) and invited a small number of regulars to a special event.

We arrived to record a show with only a modicum of nervousness. (For my part, I was mostly occupied with the technical aspects of recording.) As soon as we began the actual coffee, however, nerves were forgotten as the conversation took over. There was no script, no set of pre-determined questions to cover. Only the cards.

The Agile Coffee podcast is now twenty episodes into its life, with no sign of slowing down. And although we’ve got a few hundred downloads each week, I find incredible value in simply re-playing the conversations that I’ve already participated in. I hear more, nuances that I missed in earlier listens or applications that make sense to my present self and situation.

We are experimenting with twitter and other media to enlarge the conversation, driving voices to our forums to continue the dialog after the timebox has expired. So far we’ve only recorded the voices of participants physically at the same table, but we’ve got plans to use Skype or other means to bring enough fidelity to have a rich coffee with people geographically dispersed.

Last Call

One final tip I’d give is: no matter how you use Lean Coffee, holding an occasional retrospective on your process will help make future coffees more effective. You may decide to extend or shorten the timebox, for example; or decide to accept new cards (and re-vote) mid-coffee. Changes that allow the group to make the Lean Coffee experience more meaningful should be the goal. You may also come up with alternative applications for coffees during the retrospective, ideas that may otherwise not surface.

And when these alternative uses surface, take a chance and try Lean Coffee. Let others know how you’ve used it, and share your results. Do your part to kill tyranny of the bloated meeting, replacing it with a fine brew of Lean Coffee.

Victor Bonacci (@AgileCoffee) is a coach and community organizer in Southern California. He produces the Agile Coffee podcast and blogs at agilecoffee.com. Vic will be the facilitator of the Agile Coach Camp in Irvine, CA, from April 10-12, 2015.

Lean Coffee Through The Deming Lens

Lean Coffee and Deming:

This is a post geeking out on the intersection of W. Edwards Deming and our Lean Coffee format.  It is brief and assumes some prior knowledge of the System of Profound Knowledge and Deming’s 14 Points. If you don’t know these yet, please go to the sources. Deming’s writings have had a profound influence on the work we do at Modus Cooperandi.

I will now view Lean Coffee through these two Deming lenses:

Lens 1: SoPK:

The System of Profound Knowledge is an acknowledgement that our work creates and is influenced by systems that, like memes, have life and influences of their own often beyond and independent of their creators’ intent. These systems always have unintended consequences and experience change when exposed to the real work which creates variation during normal operations (things don’t go as planned). When exposed to variation, we see how things are operating and learn, making changes (hopefully) to the system to account for the variation (to adapt to it or to quell it), this is gaining knowledge. While all this is happening, our systems have actors (human beings) which have to interact with and react to our system. These people may react well, helping the system thrive, or react poorly by gaming or ignoring the system, or they may be unable to act at all and become trapped in it. This means their individual psychology influences and is influenced by the system.

When we create systems, we need to take into account that there will be other systems, variation, learning, and other people that combine to create an operational whole.

Lean Coffee is a fairly closed and protected system that encourages variation (diversity) of ideas while defining group value in the service of obtaining knowledge. Participants in a Lean Coffee are encouraged by the system to not only participate but to become active agents in the creation of new ideas (knowledge). Being personally heard, driving conversation (especially for those who usually don’t), and feeling joint ownership of both agenda and product is a psychological win that further strengthens the system and encourages usage, more ideation, and more creation.

Lens 2: The 14 Points:

I will eternally wish there were less than 14 points. 14 is a long list and it’s actually fairly arbitrary. Deming himself was constantly tinkering with it, wordsmithing it, letting it evolve. Since he passed away, it’s remained unchanged. So, I believe as Deming would have wanted, I’m going to treat the 14 Points like they are a thing and not a bunch of things.

In my opinion, the 14 points are an admonishment of Theory X management. They are a tireless list of obvious critical failures of top-down management. The list is not nearly as important as the intent.

So, let’s approach Lean Coffee that way.

Agenda driven meetings and events are Theory X style tools. People believe in command and control and they set up their meetings that way. It’s no wonder people hate meetings.

Like the 14 Points, Lean Coffee starts with the assumption that controlling people is dehumanizing. We pay people a lot of money to work for us. We encourage a lot of people to come to our conferences. Then we treat them like objects, like resources.

Normal meetings and agendas are standards, they are management by objective, they are barriers. Lean Coffee seeks to create meeting agendas that are focused on the needs, the interests, and the wisdom of everyone around the table. This shared focus means a few things:

1. Participants are now owners of the process
2. Participants are now owners of the product
3. Bad actors are quickly dealt with by the group (not struck down by the meeting owner)
4. Bad actors are less likely because they will have put their agenda out for a vote and it will or will not have survived
5. Meetings become focused on what we can do, not what we need to talk about.

On Distributed Teams - Kaizen Camp Bangalore

Trust is not between teams, it is between individuals. ~ Sunil

I am in the world’s epicenter of offshoring, Bangalore, India. We just spent several days running a Kaizen Camp and keynoting SolutionIQ's sold out Lean India Summit.

We work a lot with distributed teams and not surprisingly the Kaizen Camp surfaced a lot of issues around offshoring or the perils of distributed teams. (This is a slice of the conversations which were varied and deep.) At Kaizen Camp, we seek to provide people with epiphanies - game changing realizations that will have a direct impact on their work and life.

Here are some that I had or witnessed (and they are very coordinate to what our clients in the states are saying).

Everyone Cares About Making Distributed Teams Work - There are challenges around distributed teams, everyone recognizes that - whether it’s a project manager in Boston or a tester in Chennai. But also to a person, everyone wants to fix it. Yes, some people want to consolidate their teams but most people recognize that talent lies in people and people have homes. Sometimes that home isn’t where you are. The need for project success is important to everyone.

Communication is Key - Information flowing from person to person or group to group is usually sufficient, but not always. The problem here is that “usually” (maybe 70% of the time) is not good enough. Small communication breakdowns create cascading problems for work. Deadlines slide, defects mount, and misdirected designs build upon each other. The ability to communicate current work (who is working, how they are working, what is being done, what is in peril, what discoveries have been made, what requirements are more complex than we expected) is a linchpin for distributed team success.

Communication Can Be Inconvenient - We want to communicate, but we are not always the best at it. Timezones and busy schedules can frustrate this. Deadlines abhor communication. Therefore, quite often, distributed teams will try to solve problems in isolation or simply ignore concerns and soldier on in service of the deadline. Creating convenient and expected lines of communication that account for timezones and don’t carry political weight (why are you slowing us down with this meeting?!) are crucial for successful distributed teams.

Alignment is a Moving Target - Alignment is a mutual understanding of purpose, direction, and expected action. Since our understanding of our projects advance and evolve as the project continues and we are constantly making decisions, alignment should advance and evolve with it. In distributed teams, small and large decisions are made in various offices or by various individuals every day. When they are not communicated, alignment breaks down (quickly). Successful teams require alignment resets much more often than is common.

Understanding Trumps Culture - We are quick to blame cultural differences on breakdowns in workflow or alignment because culture is an easy scapegoat. Most problems we’ve seen, however, are between well-intentioned capable humans on both sides of the pond. The problems are rarely actually cultural, they are usually misunderstandings of work (intent, scope, or complexity) or the result of drift in alignment. Building systems that help keep these on track is a common hallmark of a successful distributed team.

Towards a Shared Mindset - Whether it’s Lean mindset or something else, there was a strong drive to understand why we are working together and how we are going to accomplish our mutual goals. Clarity of thought, of process, and of the culture of the distributed team as a whole (team culture), was foremost in people’s minds at Kaizen Camp. Building a common culture of mutual respect, understanding of the work, and a drive to complete quality product was present in almost every discussion.

Closing

Distributed teams challenges, in my opinion, largely come from the thin mechanisms of communication we create. Communication doesn’t have to be video calls, but it needs to be personal, useful, and understandable.

Jim Benson @ourfounder

Estimation Requires Attention

Last month I was conducting a series of Boardwalks with a large company in Australia. These people had an amazing array of kanban and other visual controls guiding their software development. Most important to me, they had achieved a culture not of continuous improvement, but deep curiosity and introspection. They were looking for any way to get their organization to communicate better internally and work more effectively. They were paying attention. It was beautiful.

What stuck out, however, was one group in particular. This was a group of skilled coders and managers. I’d be happy to have any of them on one of my teams. They had a board that showed all their sprints, the story points for each sprint, and the user stories completed.

It looked like this.

Them: We have a problem and we can't figure out how to solve it.

Me: What is your problem?

Them: We can't get our velocity to stabilize. We get our work done, but the story points are all over the map. Sixteen, Seventy Two, Twenty One? What's wrong with us? Why can't we estimate?

Me: They sure are all over the place.  Look at that.

Them: If we can't get our velocity to stabilize, we're never going to have meaningful estimates.

Me: Yep. Sure looks that way.

Them: Can you offer any advice?

Me: No.

Them ....

Me: What do you notice when you look at the board?

Them: Our velocity is all over the place.

Me: That's what you see when you look at this board.

Them: Yes. It's clear. Just look at the numbers.

Me: You're looking at the numbers.

Them: (confused) Do you have any tips on how to get them more uniform?

Me: You are aware you have no problem here and that your estimation is as close to perfect as its going to get, right?

Them: What?

Me: These features were in your sprint goals?

Them: Yes.

Me: You have a throughput of nine tickets. Make guarantees on six features each time and have three or four nice-to-haves. Then, at your first convenience, stop doing sprints.

Them: But the numbers!

Me: You've proven systematically and empirically that the numbers were bogus from the start.  Focus on the work and not the ritual. These tickets are your real work. These numbers are your imagination. The bank can't run on your imagination.

Them: But some of those tickets were bigger than others. They aren't right sized.

Me: Apparently they are. Your work is uniform and unwavering.

Them: But the numbers....

Me: Are lies.

These developers had a beautifully proven and consistent throughput. They knew their release cadence perfectly. But they were focused on a faulty metric - they were looking at the proxy when they knew the reality.

We see here arbitrary story points numbers that have no value to anyone.

But we also see a very stable number of cards - 7,9,9,9,7. (This is honestly what this team had)

There is natural variation in these numbers. But the trend is clear and actually fairly free of real variation. We don't have enough experience to promise the full nine or even seven tickets, but six as a promise is of clearly low-risk. We aren't looking for a guarantee, we're looking for an honest estimate.

Understanding that there is a comfort level with six stories with a few other stories that are nice-to-haves changes their conversation with their product owner or customer from a "we think we can fit this much stuff we don't really understand in these two weeks" to "our history shows that we can reliably finish six features in two weeks, please give us six things and we'll get them done."

What is worrying is that these very smart people who already got most of this, did not see that their delivery was already stable and consistent. They were so focused on the proxy metric of velocity that they didn't see the real metric of completed work.

If you'd like to examine if your team is actually providing predictable value - I give this advice:

1. Do what you are doing now.
2. Set up a board like this that tracks story points and tickets.
3. Watch both the number of tickets and your velocity.
4. Track when work is actually started and completed. (cycle time)
5. Track number of tickets per sprint. (crude deadline driven throughput)

When you've done this for five or six sprints. Look at the data.

The cards per sprint will give you some vital information:

• actual work completed every two weeks in number of features or stories
• an idea of the natural variation in work items produced every two weeks
• work type breakdown (bugs to planned features to unplanned features to emergencies)

You'll start to understand your work.

When that happens, you can do some real estimation. You can guarantee real results. And you can start to focus on what's really important: quality code, less escaped defects, and work that relates more closely to customer demands.

That number will give  you the best rate at which your team can develop software under sprints.

Why Limit WIP

Everywhere I go, people are suffering from overload. Information, workload, emotional load, political load … all above capacity.

People, probably you as well, start sentence with, “If only I had time to…” or “If I could just…” or “If I were in charge I’d….”

We all feel stretched to the point of snapping.

In the office, this overload means missed deadlines, unnecessary meetings, unnecessary production, and over commitment. All of those things add up to unhappy workers, attrition, and delay.

Delay in that last sentence is misleading. This is not “Harold is a little delayed and will be here in five minutes,” No no no … Delay here means millions of dollars wasted, products not delivered, and careers ruined.

Delay here also means punitive measure to get projects on track, that usually lead to even more delays.

We respond to delays with demands, which is like drinking your way out of drowning.

The only way to finish more work is to only take on as much as your organization can process.

When your work-in-process rises, your rate of completion lowers. It’s very simple math.

Our new book, Why Limit WIP, takes this problem head-on.  The book follows the movements of Eldred, our office everyman, as he is valued, overloaded, devalued, and then later rescued. Eldred shows us how people, teams, and organizations react to overload … and what to do about it.

Right now, I’d be willing to bet your company is doing too much work and creating too little value. As businesses, we don’t survive without creating value … funny thing … the same is true for us as individuals.

Effectiveness scales.

Buy it now!

Fundamental Misunderstandings Lead Directly to Malpractice

Yes, I know I know, Somebody’s Wrong on the Internet!   I am somewhat ranting this morning, because the screenshot to the right is so disappointing. The redacted person is responsible for implementing Lean in his organization, but I see this with all types of systems.

The redacted person, let’s call him Micro, has a fundamental misunderstanding of the guiding principles of how he works. In this case, he believes that customer orders are a push system. Meaning he believes customer orders force work on his production system, rather than events to engage his production system.

For the general public, this is a fairly esoteric concept. But for Lean it’s about as important as an electrician claiming that live wires were okay to grab with your bare hands.

(Trust me, it’s so tempting to go into a lecture on pull systems right now…)

But I’m running into this more and more lately, people who are active in their communities misunderstanding fundamentals of their espoused beliefs. This guy is active enough to participate in open forums, speaking knowledgeably about Lean and answering questions for people just starting out.

Whether you are employing elements of Lean, “Agile”, Six Sigma or any other flavor of standardized process control - you need to grasp the basics first.

In December, I wrote this blog post on making sorbet. In this post, I show that there are fundamental things (a core) to making sorbet. On top of that core you have a lot of leeway to innovate. There is a platform for sorbet that provides it with the minimal structure to be sorbet.

You cannot make sorbet without water. You cannot make sorbet without some sort of sugar. You cannot make sorbet without it becoming cold.

You can make sorbet with just about anything else on earth.

We need to understand the core of our work. We need minimal structure to build upon. Without that structure, we cannot communicate, we cannot plan, we cannot have coherent systems.

In this case, this guy is going to build systems claiming to be Lean that are completely contrary to everything Lean is trying to do.

Please, people who consider themselves coaches, senseis, leaders, managers … learn the systems you are employing and then innovate.

Your Specific is Highly General

Years ago now, William Rowden and I owned a business. In that business we wanted to build amazing software for our clients. We adopted several practices to help us do this. One of the central practices we employed was Test Driven Development – a practice that essentially says you write software like this.

1. Figure out what you want the code to do
2. Write a test that says, “Does this happen?”
3. Run the test and watch it fail (You haven’t written the code yet, so it had better fail).
4. Write your code
5. Run the test
6. Watch the test pass

This is important to do because software development suffers from more product quality issues than brain surgeons in the 1500’s.

But, what happens to people when under the influence of a good idea?

They want to do it more. A lot more.

William and I wanted our coders to write good code that anyone in our company could later pick up and extend with very little hassle. We wanted to build quality in up front.

Therefore, we went looking for “best practices”.

Best practices are like common sense. Everyone says they are the same and everyone does them differently.

The best practices were searching for surrounded something called “code coverage.”

“Code coverage” is a procedural (legal) term that means “Percentage of features in the code with unit tests.”

There were all sorts of people fighting to get to 100% code coverage – meaning that every element of the code being written would have a unit test.

The more unit tests, the more code quality, right?

The more code quality, the happier William and I as business owners would be, right?

That’s exactly right completely wrong.

We have a problem with the concept of diminishing returns. There is absolutely a point where there are too many unit tests. When you have too many, the project bogs down. You are spending so much time fighting waste that you are creating waste.

The community saw this and debates erupted.  … Well, maybe 70% of the code should have tests. No… 65% … No it’s got to be 80%.

They were desperately in search of a rule that would govern code coverage. The rule that would guarantee good product.

Meanwhile, at stately Gray Hill Solutions, William and I were noticing that if told developers that they needed to write tests for code they thought might give them problems – for some strange reason the problem went away.

As with my post on fear a few weeks ago, our professional judgment (while often flawed) is the fuzzy logic of business.

The Important Part

Here is the important part

The more specific a rule is (in this case code coverage) the more generalized a solution it is.

In short

The more specific a rule: the more generalized the application.

When we said, “code coverage must be 80%,” that sounded extremely specific.  But what we were actually saying was “all coders in all situations must have 80% code coverage,” which is painfully general. All tasks in general are now subject to this rule and all tasks, regardless of complexity, will suffer this scrutiny and burden.

When we said, “write unit tests when code is in potentially risky,” that sounds frighteningly general. But what we are actually saying is, “I pay you bozos $150,000 a year to write code. You use your professional judgment and when you have concerns, write unit tests,” much more specific. The worker doing the work can now deal with specific instances of work and apply the right amount of effort to that task.

The problem is that the specific is often much more ambiguous than we want it to be.

We believe that ambiguity diminishes and specificity increases.

That's not how life works. When we encounter knowledge work, there are always a wide range of potential tasks, quality mitigations, and even products. We need process. We need rules. Without them we have no structure to build anything.

However, we need to recognize that there is a threshold where we encounter diminishing returns from our good ideas. Too much process is burdensome, costly (in money and quality), and a natural human tendency. Further, we must understand that the people we are trying to govern are not carrying out orders, but are actively processing information when they work. In order to process effectively, they need to have effective but minimal boundaries (so they stay within the goals of the company) but maximum possible flexibility (so they can act in the best interests of the company and respond to variation in their environment).

Our Management is Often an Illusion

When we look at how a project is doing, we compare it against our intentions and our plans.

We ask ourselves questions like, "I've noticed that over the last several weeks we've been way off schedule. What might make this project run better? "

Then we say, "Oh, I know, we can move some human resources from this part of the project to this other part of the project and we'll finish on time."

We do this and we notice that, rather quickly, we are back on schedule. We track this for weeks.

Our graph might look like this....

After our change, our actual work completion fell right in line!

Then we say, "I made a great decision and achieved my goals."

Good for me.

Well, this is easy math, right? I wanted something, I did it. And my result occurred. I should get a bonus, a promotion, and perhaps a corner office.

This is a correlation. We notice that something happens that happens right when something else does. We then assume that because one change happened and an effect perfectly matched it, that they are related. This type of deep thought also proves beyond a shadow of a doubt that divorces in Maine are directly caused by how much margarine we eat. Less margarine, it turns out, means less divorces. If only we would have known sooner!

Or we could be confusing correlation with causality.

Because we are people, managers often suffer from confusing correlation with causality. Pedants like to wave this in people's faces when an error in judgement occurs, but the fact is - we do this all the time in real life and its nearly impossible to avoid.

Confusion of correlation and causality has some deep seeded roots in our minds. Psychologists call this Illusory Correlation, a tendency in all people to draw conclusions from limited data sets. But simply knowing this isolated cognitive bias doesn't give us anything to act on. Looking at other biases give us a systems-view of what might be happening in the office and, therefore, some ways to avoid it.

Our confusion might stem from any number of well-studied cognitive biases:

Confirmation Bias - a common tendency for people to search out conclusions and data that confirms their original hypothesis.  In this case, I made a change I thought would have a certain result and when that happened, I felt my hypothesis was confirmed. The problem is, there could have been any other number of factors that had an impact on that improvement. Early work could have been hampered by waiting for materials, decisions, or even just clarity. Later work could have been spurred-on by additional headcount. Or, worst of all (and rather common), early work could have been being done carefully and methodically and the time where the team was adhering to the schedule could have been done quickly and sloppily.

Availability Cascade - The more people around you repeat something or the more you repeat it, the more it seems true. So it seems like Steve Jobs single handedly built Apple, but maybe he had some help - otherwise he and Woz could have just stuck it out in the garage. In this case, the more I give presentations about how the shift I made in personnel made this project work, the more it will be accepted as true without any proof whatsoever.

Illusion of Control - We have an innate need to control the world around us. In order to give us a feeling of stability, we generate illusions of control in circumstances where we actually have very little control. In this case, I moved some people around and some change happened. I will then attribute that change to my actions. Now, here's the tricky bit - I now attribute the benefits to the change and am now likely to do it again in a future project. I am now creating a methodology based on my observations. But the improvement might not have been my change at all, it may have been the added attention I was paying to the project. It may have simply been greater managerial and team awareness of what needed to be done. What's sad here is that my illusion of control is based on the bad correlation - and that I really did have an impact, it just wasn't what I thought it was.

Placebo Effect - Following illusion of control, the team may have improved simply because they thought they were getting something that would help them improve. When the team bought into the improvement scheme, they also bought into improving at all. This invokes a Framing Effect where the change being brought frames the decisions and actions of the team. When people buy into a system to move them in a certain direction, the will naturally move in that direction.  Why? Because they have direction! Quite often work groups in the office don't have adequate direction or vision to complete their work. Often, that was what they really lacked - it just happened to be delivered in a box labeled "organizational change" this time.

There are many more of these, but this is already becoming a long blog post. So let's talk about how we might mitigate them.

Mitigation

Just to say this again, being aware of a cognitive bias does not make us immune to the cognitive bias.

To mitigate these impacts, we need to understand one key thing about business decision making - we're never going to have all the information we need. Our goal is not to eliminate the impacts of cognitive bias on our decision making. The goal is to be wary of our own decisions and to be vigilant in asking hard questions.

Do I have enough information?

Is that really the root cause of that effect I am observing?

What is the real risk in what I'm about to undertake?

Everyone is saying our new plan will work, why won't it?

In short, taking a step back and considering the true root causes of problems, the true impacts of potential solutions, and the role that human variables will play in delivery are the key mitigation to cognitive bias issues in our work.

Want more? This is discussed in more detail in our book, Why Plans Fail.

Fearful Features: Making Risk Explicit

Tell me Clarice, are the features still screaming?

Sometimes work is terrifying. We’re asked to do something that we know, or at least strongly suspect, won’t work. Maybe we’re asked to do several things -  many are simple, but one or two make us uncomfortable. We might even place a hard estimate on a task (“It’ll take six hours!) and deep down something doesn’t feel right.

Oh well, I’ll just figure that out later.

We spend a lot of time guessing how long our work will take. Psychologists have shown this to be a foolish endeavor. They point to the Planning Fallacy or to Hofstadter’s Law which both show that we are notoriously bad at estimating complex tasks.

But all our work isn’t complex. So we end up with some pretty reliable estimates and some that are wildly off. Those that are wildly off ruin our otherwise fairly predictable projects.

The tendency here would be to try to get rid of those hard-to-estimate tasks.

Good luck with that.

Certainly, we should always be looking at how long it takes for us to complete things and refine how we project costs and completion times. But variation and difficult tasks run hand-in-hand with knowledge work. Sometimes, we actually have to think about things.

There may a way out of this.

Work runs along a continuum that looks something like this:

Work is either not scary at all, kind of scary (but in a way you can shoot it), and scary in a way that you’re just unequipped to handle. Or, as we might call them, Poodle, Crocodile, and Zombie.

We want to know, when are starting some work, which tasks we’ve been given are we comfortable with (and therefore comfortable with the estimate) or which work scares us and to what degree.

I’ve found that teams will give very definite estimates to tasks they are horribly terrified of actually working on.  Level of apprehension in the team is an excellent barometer for risk currently being taken on. Risk, in this case, is fairly well mapped to taking on complex tasks (in theCynefin sense). And the good news is, there are ways of dealing with complex tasks.

We can then break our work up into Simple / Complex tasks that can be undertaken by a person or a team with a generally clear view of what they are to do and how it will be done.  So Poodle to Light Crocodile tasks can be assigned to people with a modicum of comfort that the time estimate can be met.

Crocodile to Full-On Zombie levels of apprehension, however, indicate that we require a different approach to the completion of the task.

Estimates Are Waste - The first thing to come to terms with this task as it comes at you is that it does not respect your guesswork. Your estimate is as useless as a handgun against Godzilla. Or a zombie…

One Brain Bad, Four Brains Good - Complex problems are complex in their composition, their implications, and their solution sets. When we run into a complex problem that scares individuals on the team, it is likely the solution to that problem is not right on the tip of someone’s tongue. (And if it is they are likely suffering from Belief Bias). We therefore want to work on complex problems in groups to foster conversation about the solution as it is happening and employ multiple points of view to reaching a meaningful conclusion.

Experiments Precede Products - These aren’t tasks we just complete and move on. We need to make sure we actually built the right thing. Each complex problem has multiple potential solutions. We need to test the assumptions inherent in our solution by creating an experiment. This could be a mock-up, a prototype, or even a limited release. Whatever we choose, we need to know that “done” for a complex task means proven.

What all this means

We have two types of work -

• Work we think is safe
• Work we think is risky

We’re still going to be wrong and some risky work will sneak in. However, if we understand that our estimates are often blown out of the water by risky work that was identifiable up-frontthen we can honestly respond to those risks. Right now, we blithely ignore our discomfort and sally forth.

Let’s be honest and get some real work done. Ask which work items worry people and give that fear the respect it deserves.

Listening More Attentively

When I was in university, my housemate Dave had an old King Crimson bootleg in which there's this guy screaming LOUDER LOUDERRRRR LOUUUUUUDDDDERRRRRR! Finally, wanting to spare the rest of the audience from listening to this yahoo any more, Robert Fripp says, "I am hearing requests to play louder, but perhaps this gentleman could listen more attentively." (Exact quote is likely mangled by this being a rather distant memory.) It strikes me this morning that this is what I'm asking / begging / cajoling people to do every day. We could seriously benefit from listening more attentively.

When we are running any type of project, be it a multi-billion dollar construction project, a multi-million dollar software deployment, or even just keeping the lights on in our restaurant - the goal isn't always the big win. The goal is sustainability - both in longevity and in attentiveness.

No human endeavor benefits from neglect.

However, we neglect to be attentive to our real businesses. Opting instead to focus on metrics, deadlines, and other arbitrary elements we set because we are unwilling to listen attentively. Rather than focus on what is really happening - on the subtle changes and nearly inaudible nuances that can provide deep insight - we focus on balanced scorecards or other artifacts. We create the louder, because we are too busy or too important to listen to the softer.

The softer, the more intricate, is often hard for us to discern from just background noise. It's harder to tell if it is an anomaly. It requires work.

But the softer and more intricate is also our context. It's the details. It's what makes that solo anything other than an individual performance. The loud is only loud in contrast. Contrast only makes sense when you are actively contrasting.

We have had clients routinely collect pages and pages of metrics from their teams. These metrics would go up some weeks and down others. The managers would get very happy when the metrics went up. They would be sad when they went down a little. They would become angry when they went down a lot.

The problem here is that they rarely understand the context of their metrics. They had no idea what a normal fluctuation in a number was. They merely knew that up was good and down was bad.

They are listening to the LOUDER of their charts and graphs without hearing the sotto voce of daily work - the cultural rumblings, the unrealized good ideas, the popular workarounds to bureaucracy, how the company is working independent of the arbitrary numbers.

Listening attentively is not easy work and it can be rather capricious. Whenever I listen to music I may have heard hundreds of times before, but is experienced through new headphones or a different format, I can hear things I've never heard before. So the mechanisms are important, but what's also important is to know that we'll never hear everything. We'll always be dealing with some limitations in fidelity.

Which means we, as listeners, as business owners or managers, need to listen as often and from as many perspectives as possible. If not, we'll never understand what is really happening.

- Philadelphia, PA, 24 April 2014

Photo isn't mine, but I'd sure be proud of it if it were. Go here for the original article, it's nice.

Selective Business Hearing

We only see what we want to see; we only hear what we want to hear. Our belief system is just like a mirror that only shows us what we believe.~ Miguel Angel Ruiz

We hear only those questions for which we are in a position to find answers. ~Friedrich Nietzsche

You think your job is hard? I have to tell people that their children have  disorders that cannot be cured. I have to crush people's dreams. ~ Vivian Lam

So, there's always perspective.

Several times over the last few years, I've found myself to be the barer of harsh news. Like my wife Vivian, people are paying me to tell them things that they don't want to hear. Things they aren't prepared to hear. And often, things they simply refuse to hear.

Ordinarily, this would be an opportunity for me to bring up a couple of cognitive biases to illustrate why human beings are so adept at not hearing when hearing is painful. However, a perusal of cognitive biases shows that almost all of them play a part.

The fact is, we are hardwired to avoid pain and fear. It's why courage is seen to be a virtue and not merely taken for granted.

Perhaps the true test of bravery is simply engaging System 2 thinking when it's called for.  It's acting coldly logically in the face of overwhelming emotion.

The position of a therapist, whether diagnosing a learning disorder like my wife or a workplace dysfunction like Tonianne and I might do, is precarious. The truth is often startling, but it's also greatly impacted by perspective and - most annoyingly - truth is not a constant. Truth isn't absolute. It's malleable, even fungible.

I've watched people hear what I'm saying, agree fully, and after two or three minutes of talking come around to saying that observation never happened. They agree to the observation, discuss through a political filter, and then deny the observation. It's fascinating to watch.

To show the degree of this, I'll provide a little more detail. Through direct conversations, people working at the company told me they were specifically unhappy or even angry about a recent change. I went to management and said, "People are really angry about this change." The managers said, "yes they are. We've seen that happening. They're really upset." 

Then they had a discussion where the observation was compared to the culture of the company. The culture (the espoused theory) of the company was that everyone had autonomy and could change their environment however they wanted. Therefore, they could not possibly be angry about this change, because they could unchange it whenever they wanted. Therefore no one was really angry.

"… but, … you do realize they are still angry…"

"No, they're not. Or at least they shouldn't be. … What else did you find?"

Both the quotes at the beginning of this post apply. People have built content filters in their heads specifically tuned to avoid confronting that their espoused theories of work are not in line with what's really happening. This is why so many companies have mission statements and values that relate only tangentially to what actually happens in the office. When the truth of people being upset came into contact with the ideology of the company and there was a discrepancy, the ideology won - even though in winning it made itself even more irrelevant. People were still angry, the change still stood, the company still believed it was open and free.

Truth dissipates easily at the touch of ideology.

Photo by Tonianne DeMaria Barry

Positional Power and Unintended Influence

It's tough to handle this fortune and fame Everybody's so different, I haven't changed ~ Joe Walsh

It was spring. That winter, like this last one, had been harsh. Internally, my client was trying to lead his company to change...to a better tomorrow. He had been working to give his people more autonomy, more agency, and more internal influence. He kept waiting for that cultural winter to abate, for people to thaw out and enjoy working…but it, like winter, happened on a schedule he couldn’t control.

“I don’t know what I’m doing wrong,” he sighed as we ate lunch. “I keep asking people to take responsibility from me. I’m building structures to let them make their own decisions. I am giving people autonomy. But when I get into a meeting with them, they still defer to me. If I offer a suggestion, it becomes a marching order. It’s just a suggestion!”

Recently, another client of mine had a project that gained a rare visit from the CEO. He came and spoke with the team and they had a good time. When he left, the team was energized and excited to keep working. The CEO was excited too.

The CEO was so excited that he couldn’t stop thinking about the project. So, on the plane ride home, he sent them an email saying how excited he was and giving them some thoughts he had about what was going on.

Instantly, people sprung into action - making the thoughts of the CEO the primary focus of the team. The team was excited to please the CEO, but were also a little annoyed. They already had enough work on a complicated project and now they suddenly had to respond to all these new demands. This made people a little uneasy, they were happy to help on the one hand, but annoyed on the other.

Then my client had the wherewithal to actually write the CEO back!

She asked a simple question: “Those things in your e-mail, did you intend for us to consider them or act on them immediately?”

The CEO wrote back, as you might expect, “They were just thoughts, I was excited about the product and our meeting. You guys build what makes sense.”

No one was born a leader. No one was born a manager. We’re all just people.

One of the hardest things for a CEO to accept is that our positional power extends well beyond simply giving orders or being able to fire people or controlling the purse strings.

When we are in management, our words become law much faster than we realize - and this is very hard for us to counteract. Those who are “under” us have to discern when we are having an idle thought and when we are issuing an order. They will usually err on the side of “issuing an order”.

When we have positional power, that power manifests itself as influence. Influence may be something we can wield, but it’s energy. It discharges on its own quite frequently.

Simply being in a meeting can and will alter the ideas expressed and acted upon. Simply writing an excited email, where you are honestly enthusiastic, can have negative repercussions.

One problem I’ve run into many times is that in leadership one of your main jobs is to be constantly identifying options for the future of your organization. You must constantly be devoting time to investigating new markets, products, structures, business models, partnerships, and so forth. Discussing this with “staff” can create confusion, they don’t know if your new thought is some flighty “Hey let’s derail everything and do this!” or just an idle thought or something to be lightly investigated or maybe even just something to ponder.

They are looking to you for actionable advice. They want your words to compel action. That’s all well and good, but enlightened leaders and managers know that they cannot compel all the action, that healthy companies have ideas coming from all directions, and that sometimes a leader needs to just talk.

There is no solution at the end of this blog post other than a call for awareness. As leaders, look to set up intentional structures that let you participate in as much of a peer-to-peer role as possible, but be aware that you cannot ever fully be a peer due to your positional power. Don’t shy away from this. Just understand that that the dynamic is real and impacts your company greatly.

Modus Cooperandi's Speaking and Workshop Schedule

Modus Cooperandi has a great deal of events penciled in on the calendar over the next few months.  Listed in detail below is where you'll be able to find Jim Benson and Tonianne DeMaria Barry presenting talks and workshops all across the globe. This month Jim will deliver the closing keynote at the 9th Annual Emerging Technologies for the Enterprise Conference in Philadelphia, Pennsylvania.  Jim's keynote - Why Can't Johnny Code? Because he's got too much to do." will be presented on Wednesday, April 23 at 4pm.

May proves to be a very busy month for Modus Cooperandi.  Jim and Tonianne will present a half-day workshop at the 26th Annual International Shingo Conference in Sandusky, Ohio.  Reimagining the Gemba: Applying Lean to Knowledge Work Using Personal Kanban will be held on Monday, May 5. 2014 from 1-5pm. For more information on the workshop you can view the video here.

The middle of the month sees Jim delivering a keynote at Dare Festival  2014 in Antwerp on Friday, May 16.  Jim will be presenting - I'm Alive When I'm at Work, Thank You Very Much.  Dare Festival Antwerp is held May 15-17.

May finishes up will be a Lean Panelist at the 2014 IPMA Forum  for the workshop - Assimilating Agile, Lean, and Traditional Project Management which is presented by PMI Olympia on May 21 from 1-2pm.

In June Jim will be a keynote speaker at Agile Australia 2014.  Jim's keynote titled - Embracing Disruption: You Are Your Process will be presented during the conference which will take place on June 17-18. Jim will also be conducting two workshops and following up last year's Kaizen Camp Melbourne with another one, this time in Sydney. Jim's workshop Visual Project Management - See it to manage it will be held in Melbourne on Monday, June 16 from 9am-5pm and again in Sydney on Thursday, June 19 from 9am-5pm.  More information on Kaizen Camp Sydney to follow soon.

To keep up with all the Modus Cooperandi Events you can click on Calendar at the top of any page on this website.

Finding Hidden WIP

Limiting Work in Process (WIP) is not easy.

Our work is largely invisible, which means it’s hard to notice. It creeps up on us. Well, heck, it’s invisible, it just walks right up - bold and unabashed. It doesn’t have to sneak - we’re simply blind to it.

Then, one day, we notice it is there.

Over the last three weeks, we’ve worked with several groups that are shocked when we’ve found hidden WIP. To them, we seem like ghost hunters finding inefficiencies and overload where there was previously only air.

So, how can you find hidden WIP?

It’s easy: always assume it’s there.

When you start from a position of knowing that there’s more WIP lurking, you examine the shadows more closely. Here’s three common shadows:

Big Tickets - People are always asking about ticket sizing. If your tickets are too big they have lots of room in them. Lots of room for WIP to hide. Lots of tasks that you can start and not finish. Lots of ways for the ticket to get stuck. Ultimately, the big tickets have lots of shadows for WIP to hide. Tickets get bogged down because one or more of those hidden tasks is hard to complete. (Note to some: user stories are usually pretty big tickets).

Overfocus on Team Work - Time and again we see teams limit their WIP on a team board, but overlook the individuals. So the team will have a WIP limit of 5 or 6 and be meeting that limit just fine. Upon examination, however, one or two people are involved in every ticket. Since our work is completed by people, overloading them defeats the purpose of the Personal Kanban in the first place.

Self Deception - We put things on the board that we want to put on the board. Everything else ... hmm. We’ve seen software teams overloaded with unboarded support tasks because they weren’t “real work”. We’ve seen researchers overloaded with unboarded administrative tasks because they weren’t “real work.” We’ve seen people with dozens of incomplete tasks that were “too small for the board.”

Tonianne and I now look for these things out of habit. We immediately look for oversized expectations, individual overload, and unreported work every time we see a board.

Image from Cecil Goes Wild ... which could be used to teach kids about hidden WIP.

The Ambiguity Business

As I sit here, rapidly nearing my 50th birthday, I look back at the companies and government agencies I’ve worked for and the companies I’ve managed or owned and operated.

I find that work is heaven and work is hell. It’s uplifting and it’s stressful. It’s rewarding and it can certainly be defeating.

Companies are made up of people. We are companies because we are in the company of others. We have colleagues, associates, and friends. We work with these people, each of whom has their own life outside the walls of the office.

Things rarely go as planned. This is a design flaw in the human brain. We are not very good planners.

But when we do make plans, we put a lot of our hopes into them. The funny things about hopes is that every hope is a solution to a fear. So we also put our fears into them.

When plans begin to go awry, we react emotionally to the collapse of the plan.

I often use this analogy:

Suppose I told you to get in your car and drive down a very long, straight tree lined highway at 100 miles and hour. The car is already on the roadway. It’s pointed in the right direction. The wheels are perfectly straight. I tell you the car is all set. You get in and I’ve removed the steering wheel. I’ve already set the course, all you have to do is hit the gas pedal. You likely wouldn’t want to do that.

This is because there is variation in all automobiles. You know that you’ll have to make little, nearly imperceptible, corrections to the car. The wheels simply won’t stay pointed in precisely that direction.

Steering is part of the system of driving. Constantly making small corrections and, from time to time, making large corrections, is all part of safe driving.

But it’s never been part of safe project management.

There a lot of variation in business and even more ambiguity. We feel that these things are dangerous to predictability, so we try to legislate them away. We create deadlines and budgets and plans … all of which are setting the car in motion with a really great map and no steering wheel.

We have an inherent discomfort with not knowing what’s going to happen ahead of time. That discomfort can manifest itself as healthy excitement and anticipation, or it can become fear and loathing. But, like it or not, businesses that try to ignore that ambiguity and variation are not just forces in business - but primary forces in business - will continue to more slowly and be outpaced by those that prepare for the unplannable.

Further, we need to understand that companies are again made up of people. When plans go astray, we react as people - not as machines. We are disappointed, upset, and even angry. We tend to look for people to blame, rather than acknowledging that variation and ambiguity may be at work.

We are in the ambiguity and discomfort business.

Is Retrospective Coherence a Cognitive Bias?

Why is the past so much easier to predict than the future?

Because it’s already happened.

In 2013, I personally made two very bad decisions that ended up causing a lot of problems. I had no way of knowing that they would be bad decisions because all of my analysis said they would be good ones. (In my defense, I did make good decisions last year as well).

Now, firmly seated in 2014, however, it is obvious that those two decisions were very bad. It is then quite easy to say that those decisions never should have been made because elements of history logically led to their inevitable outcome.

This is just as obvious as the Nazis winning World War II because in hindisight they had better equipment, a better trained army, and discipline. … but they didn’t win. And they didn’t win because of what now seems an equally “obvious” set of variables.

Dave Snowden and others call this “Retrospective Coherence”. Retrospective Coherence is, essentially, looking back in time and creating a coherent narrative around what happened. The accuracy of this narrative is always suspect because the narrative itself can only be based on assumptions of the motivations and methods of decision making that happened in rooms in which we were not present.

When I was a civil engineer, I needed to have a policy from Lloyds of London known as “errors and omissions insurance”.  In essence, I was being insured for overlooking something that might cause a problem in the future.  I was not being insured against negligence - I was being insured against accidentally not doing something right. I was being insured against Retrospective Coherence.

There are some people who define Retrospective Coherence as a scientific process of interpreting the past. There are others who define it as sensemaking. There are others who define it as fabrication. All would be correct.

The problem lies not in available data or in an unadulterated narrative - the problem lies in the known and unknown motivations of those looking backwards. Here we hit what interests me about RC: it’s a cumulative cognitive bias system.

There are too many to detail in a single blog post, but these cognitive biases not only frame how we initially interpret an evolving narrative, but they also impact how we interpret new data, how willing we are to be surprised by alternative explanations, and our ability to empathize with all the actors and decision makers involved. Further, they impact how seriously we treat the problem given the conclusion, what elements of the problem we personally fixate on, and the sample sizes of data we’re willing to accept.

The number of cognitive biases that impact Retrospective Coherence, and the fact that most people engage in it automatically, to me makes it what I call an Uber Bias. An Uber Bias is a cognitive bias that is made up of many other cognitive biases, but is describable as its own system. Retrospective Coherence, The Planning Fallacy, and maybe falling in love might be the three big Uber Biases for me at the moment.

This isn’t to say we shouldn’t make sense of the past, plan for the future, or fall in love. It merely is saying that they are all acts of surprising complexity.

Lunch&Learns Solve Team Training Problems

Do you have limited training budget? Do you have a distributed team? Do you have an immediate training need and can’t spare an entire day or two or three?

Welcome to the real world.

Last year we noticed that most of our clients had at least two, if not all three of these issues, so we started a program we call “Lunch&Learn”. We started getting together with our clients and their teams for 90 minutes on Google Hangout. We would then have an extremely focused training. Then people would go back to work.

It’s been extremely popular, so now we’re introducing it to the world.

The Format:

We meet on Google Hangout. There is a short 30 minute lecture, then 60 minutes of directed conversation. The goal here: To Learn and Immediately Apply.  Afterwards, you get a set of Modus One-Sheets (sample) that describe in-detail a tool or concept mentioned in the lecture. The One-Sheets are helpful future references that reinforce the learning.

Why This is Interesting:

Focus - You pick a topic that is of immediate need to the team. We’ve done topics as broad as root cause analysis and as narrow as  a specific issue raised in a kaizen event or retrospective.

Relevance - Topics you choose are of immediate need to you and your team. You know they need the guidance and so do they.

Immediate Application - The conversation afterwards are geared bolstering the lecture, understanding your context, and helping create ways to quickly apply the learning. Our goal here is to have the Lunch&Learn be so useful that it’s discussed and applied that day.

Real Experts - Modus Cooperandi provides award-winning experts not only to train but directly consult and coach.

Affordable - For less than the cost of admission to an off-site training, an entire team can benefit.

Co-Learning - Don’t just send a select few to go be trained, have the entire team learn together. This is especially valuable for distributed teams who can participate together regardless of location.

Dynamic - This isn’t a one-way webinar, this is a live two-way discussion.  

The First Flights:

Sign up now for a dedicated Modus Lunch&Learn training on:

April 17, 2014

and

April 30, 2014

Workshops Announced

"Lean for Knowledge Work" w/ Jim Benson & Mark Graban

Register Now for Phoenix March 10, 2014

Register Now for San Antonio March 12, 2014

Globally recognized Lean luminaries and recipients of the Shingo Research and Publication Award Jim Benson and Mark Graban will once again join forces and bring their acclaimed  “Lean for Knowledge Work” to the Southwest.

Past attendees of their full-day workshop in Seattle hailed from big business, the nonprofit sector, software, government, healthcare, and education, all interested in the manner in which Lean universally helps visualize, track, and improve work.

Workshops will be comprised of two components, with Jim teaching “Personal Kanban” and Mark teaching “Kaizen” or, continuous improvement.

Register now for Phoenix March 10, 2014

Register now for San Antonio March 12, 2014

Attendance is limited, so register soon.

For more information, please visit www.KanbanKaizen.com.

Personal Kanban Wins the Shingo Prize

Personal Kanban won a Shingo Prize for Operational Excellence this year. This is the highest honor in Lean and we share the award with some pretty august company.

This award is humbling. Shingo awards are usually focused on manufacturing or applications of specific Lean principles with many direct nods to Toyota.

Personal Kanban is strongly rooted in Lean ideals, but it much more focused (as the name implies) on the individual – on us as people.

Tonianne and I are greatly energized by this award and look forward to seeing Personal Kanban continue to grow and thrive.

Read about it on CBS News and the Lean Systems Society sites.

Beyond Agile: Tales of Continuous Improvement Published

After two years of hard work by Maritza van den Heuvel and Joanne Ho, we are excited to announce the Kindle publication of Beyond Agile: Tales of Continuous Improvement. Beyond Agile is:

• Case Studies in Lean/Agile teams involved in continuous improvement
• Examinations in the use of visual controls like kanban for knowledge workers
• Truthful and sometimes painful stories of teams and organizations working for better process

Presented through 10 case studies spread over four continents, Beyond Agile shows that process improvement is owned by no single process, no single school of thought, and no single culture. Whether in India, Spain, South Africa, or the United States, these teams of knowledge workers faced very similar problems, but in very different political, economic, and social environments. Their path of continuous improvement, however, was universal.

These teams saw problems and attempted to fix them. Sometimes with great success, sometimes requiring they go back and try again. But they did not simply complain or ignore the issues.

Many of these stories build on Corey Ladas' book, Scrumban.

The print version of this book is due out in April 2013.

Personal note from Jim Benson:

Maritza and Joanne poured a lot of effort into getting this book to publication. I want to personally thank them and congratulate them, but also ...

Please! From you two things:

(1) Tweet the heck out of this post (see twitter link below)

(2) Congratulate Joanne and Maritza in the comments here.

.. and, of course, check out the book.