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!

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.

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

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.

The Client Management A3: Modus Cooperandi White Paper #2

Lean thinkers seek systemic causes to workplace or project issues. The goal is to find procedural or functional root causes to unpopular behaviors or outcomes. Psychologists warn us of Fundamental Attribution Error, a common human bias that leads us to blame before we analyze.

Lean uses the A3 as a tool to examine problems, hypothesize solutions, and then run experiments to test those hypotheses.

But sometimes, people might actually be the system we want to fix.

In software development, there is the notion of the Persona - which helps software developers build empathy and understanding for those unlucky enough to use their software. At a recent client engagement, we combined Personas with an A3 to some interesting results.

This paper is the result of that endeavor.

The Client Management A3 White Paper is available from Amazon.

In Progress v In Process

After a recent webinar with SwiftKanban, I received an email from a manager in Sweden with several teams that had workflows difficult to tame. He said:

I help teams getting started with Kanban and have some teams that are very similar to the architect example you showed in the webinar. These teams typically struggle with having many tasks and tasks that take a long time. Hence as you mentioned in the talk a "normal" WIP limit is not all that useful. We have tried various approaches such as priority columns or date columns combined with people rows. To some extent it works, but we still struggle to get enough information on the board for it to be really operational.

After some e-mails were exchanged, it became clear to me that we tend to treat the phrases “work-in-process” and “work-in-progress” as interchangeable. But, especially for teams with a great deal of churn, like QC or other external influences to their cycle. This WIP distinction is key to a flowing kanban.

Work-in-process is all work that is on our kanban and is actively flowing through our process.

Work-in-progress is work that we are actively working on right this minute.

These two competing types of WIP have been overlooked or under appreciated because the concept of WIP came from manufacturing - a much more controlled environment than knowledge work. Manufacturing has less churn and less complexity than knowledge work.

So, we can deal with theory later, let’s talk practicalities.

Recursive Work and WIP

If you have a request / revise / revise / revise / revise / release cycle, what is actually your personal WIP?

Let’s say that your value stream looks like this:

Receive Work Request -> Work -> Review -> Work -> Review -> Work -> Final Review -> Final Work -> Release

WIP can get pretty confusing, especially if work items dwell in a review state for an extended period. This, in turn, can be exacerbated by demanding clients who take a long time to review, then demand updated product from you immediately after they finally return their review. (Sound familiar?)

So, your kanban would look something like this (click to enlarge):

The issue here is that a team that is waiting on external tasks, but has a predictable work cycle, can easily lose track of the difference between being responsible for a task and actively working on that task.

It’s easy to conceptualize that we throw the work over the wall into review and then they throw it back - but life doesn't work like that. We’re still responsible for completion for all the work that we have in process, even if it isn't - for us personally - in progress.

So, we can be happy that we’re maintaining our personal WIP limits by not having too many tasks active. We are focusing, completing, and keeping quality high.

But! .. But!

The Review columns still have their own limits. If they are exceeded - that becomes your personal WIP. You are responsible for keeping those lanes flowing.

An unspoken part of your WIP is maintaining what those columns represent, and that’s relationships. Each column is a point of negotiation between your team and whoever is doing the reviewing. Each of those transitions for knowledge work is some things that Lean doesn’t like to admit exists - politics and personalities.

These are intrinsic elements in knowledge work because, whether we like to admit it or not, much of the acceptance criteria of knowledge work is subjective. (Any guess why objective metrics and knowledge work at best have inconsistent results?)

This is a board we describe in our whitepaper Kanban: Diversity and Optimization in Knowledge Working Teams. This board is for a team of systems architects that have several active projects that require some level of consistent monitoring (or at least acknowledgement). However, they also have tasks that are currently requiring a great deal of their attention.

Their active WIP is displayed in the 2x2 matrix on the right in this photo. Their work is on two axes. The vertical axis is time until the project is complete with 4 months at the top and imminent at the bottom. The horizontal axis is the amount of time they are currently spending on the task ranging from a low of almost none to a high of almost all.

As one might guess, this is a subjective view of a domain with extremely high variation. In this case the architects are recognizing the variation in their work and attempting to visualize and manage it.

An Imprecise Closing

Thinking about what WIP means is extremely important if we are going to be honest about the complexities inherent in knowledge work. A dogmatic view of WIP will render Lean and kanban unusable for many teams.

However, the more we open the door for interpretation for what WIP means, the more we are opening the door for people to become lax in limiting WIP in the first place.  In the cases listed here, both work flows will benefit from limiting both types of WIP.

When limiting work-in-progress, we can enact local optimizations that are easy for us to implement and control. When limiting overall work-in-process for a complicated organization, we will have to engage not only mechanistic process measures, but also political ones. Perhaps this is what’s most important. It’s easy to do the former, harder to do the latter - so we optimize ourselves and wish the rest of the organization or our customers would just “get better”.

How We Do Business: Sample After Action Report

When we work with a team for a week, we learn a surprising amount about how the team works, the company’s relationships, the products, and the needs of the organizations. Anyone that’s worked with Modus knows our After Action Reports (AARs) can become quite detailed. Some have been over 50 pages. We thought it might be helpful to show people what a sample AAR might look like. While each AAR is very specific to the needs of the particular client, this one gives a good idea of the range of topics they take on.

Note that this is an actual AAR from an actual week long Launch Ready event. We’ve taken out all the detail that might reveal the client, and left everything else.

Download The Sample After Action Report Here

Modus Cooperandi White Paper: Kanban: Diversity and Optimization of Knowledge Working Teams

Announcing the publication of Kanban: Diversity and Optimization of Knowledge Working Teams – a new Modus Cooperandi White Paper.

Late in 2012, we conducted a Board Walk (a site visit where we meet with teams using kanban or Personal Kanban and help them optimize the board and the team itself) at a client in the United States.  There were 15 individual teams, each of which had its own individually designed boards. Each board had a unique value stream, work item types, policies, and methods for judging completeness and quality.

Both management and the teams were frustrated because they hadn’t yet found a board design that worked for the entire company. They were looking for standardization.

However, each of these boards were, in some way, optimized for each individual team. Each team had its own context and these boards related specifically to that context. Each team was also actively improving their boards on a regular basis – meaning that optimization was continuing.

This white paper contrasts many of these boards, showing the differences in design of each board and the ramifications of those variations.

A PDF of this is available for organizations requiring a bulk purchase. Please write.

Three Questions on Deadlines #2–Jon Moore

We asked our three questions on deadlines of Jon Moore, Technical Fellow and Chief Engineer at Comcast Interactive Media:  

Q1: Do deadlines empower your teams?

I've found that deadlines can cut both ways. On the one hand, an achievable but challenging deadline can really get teams to focus; on the other, a seemingly impossible deadline can crush morale. Having a fixed deadline with variable scope (where the minimum viable product is achievable by the deadline) is a perfectly fine timeboxing mechanism that can line up well with longer lead-time activities that must be coordinated around a big launch--for example, marketing efforts.

Q2: Do your customers expect delivery on deadlines?

Yes, internal customers often expect delivery by negotiated deadlines. In a company with many teams, estimates like ideal hours or story points[1] do not carry well from team to team, but calendar time does. Asking when another team can deliver a dependency serves as a useful unit of exchange.

[1] I have even heard of teams from a different company that estimate in kilograms!

Q3: What are you doing to meet customer expectations (in response to or in lieu of deadlines)?

I've seen have success with tried-and-true mechanisms from Scrum: prepare all the user stories, estimate in story points, then project out based on historical velocity. If the scope/date line doesn't pan out well (or is close), manage expectations with the customer as early as possible to discuss scope/date tradeoffs or risk.

Bio: Jon Moore is a Technical Fellow and Chief Engineer at Comcast Interactive Media, a part of Comcast dedicated to building web and mobile customer experiences.

Three Questions on Deadlines–Asking the industry

Deadlines ... we govern by them, talk a lot about them, gripe about them. But do we use them effectively?

Deadlines are grave ... in fact their original use was quite literal:

… And he, the said Wirz, still wickedly pursuing his evil purpose, did establish and cause to be designated within the prison enclosure containing said prisoners a "dead line," being a line around the inner face of the stockade or wall enclosing said prison and about twenty feet distant from and within said stockade; and so established said dead line, which was in many places an imaginary line, in many other places marked by insecure and shifting strips of [boards nailed] upon the tops of small and insecure stakes or posts, he, the said Wirz, instructed the prison guard stationed around the top of said stockade to fire upon and kill any of the prisoners aforesaid who might touch, fall upon, pass over or under [or] across the said "dead line" .... ["Trial of Henry Wirz," Report of the Secretary of War, Oct. 31, 1865]

~

A deadline is negative inspiration. Still, it's better than no inspiration at all. ~ Rita Mae Brown

Deadlines can be deadly serious. They are set to meet key coordination dates and understanding those real business needs can be the line between success or real business death. Deadlines can help us focus – finding the real value of the work to be done and trimming the waste.

Most of the time, however, deadlines are wishes. They are dates we’d like to get something done by, regardless of all else.  Missing these deadlines has little consequences on customer value, but they cause people to work as if the fate of the company were at stake.

Many people use deadlines, inappropriately, to motivate. They often do this because they have no other way to inspire their workforce or they really do believe that deadlines work for this.

We thought it might be a good idea to ask around – and find out how people are using deadlines. Where are they working? Where are people finding other ways to motivate their workforce?

In this series we have:

(these links will go live as we release the interviews over the course of the week)

• Jason Montague – Director of Application Development at R.W. Baird
• Jon Moore – Senior Developer and Technical Fellow at Comcast Interactive Media
• Jabe Bloom – CTO at the Library Corporation

If you would like to be part of a future interview series, please let us know!

Three Questions on Deadlines #1–Jason Montague

As part of our Deadlines Interview Series, We asked Jason Montague, Director of Application Development at R.W. Baird in Milwaukee, three questions about deadlines:  

Q1: Do deadlines empower your teams?

Wow.  You went right for the jugular on this topic, didn’t you.

Unfortunately, the short answer is YES, I do feel deadlines empower our teams, but NOT in the way you might expect.  Deadline empowerment can lead to wildly varying, primarily negative, outcomes.

To begin, most organizations don’t have a good sense of how to manage software developers or “value” in software projects.  So, instead of working on a way to manage more effectively, they use a very handy (and simple) proxy…deadlines.

For most business leaders who don’t have the time, patience, or inclination to learn about software development, understanding the nature of these projects and all the variables at the disposal of project teams is daunting.  In many organizations, much of the complexity is ignored, or worse, dismissed.  In these organizations, software teams and their importance in the business ecosystem is marginalized and quickly become more order-takers and less partners over time.

So then, what do deadlines “empower”?

Development teams, like any team of people, are motivated intrinsically to do a good job.  If “doing a good job” becomes more about WHEN you deliver over WHAT, HOW, or WHY you are delivering, then those teams will move heaven and earth to deliver ON TIME, ignoring some key concerns.

Common missing components in deadline driven projects:

• (WHAT/HOW) The deep complexity and craftsmanship needed to build a sustainable, resilient, manageable product that will grow and thrive over time.
• (WHY) Why are building this?  Is there a better way?  Can we help make this any simpler?  Should we build it all?  Some of it?  None of it?

When teams are faced with a deadline, the typical response is to focus on the deadline and deliver (no matter what).  This is definitely empowering, and seems like a reasonable arrangement, until you realize the incredible cost associated with missing the WHAT, HOW and most importantly the WHY.

(I can elucidate those costs in another post.)

Q2: Do your customers expect delivery on deadlines?

Yes they do.  And sometimes it is completely rational and unavoidable.  Market pressure, response to regulatory mandates, legal requirements, etc., all require rapid, time bound responses to delivery.

However, in my experience over the last 17 years in (primarily) IT shops in financial services, insurance, banking, and even packaged software products, these deadlines are largely imposed by “managers” as a proxy for leadership.  Customers, and IT managers, simply don’t know what else to do.

Q3: What are you doing to meet customer expectations (in response to or in lieu of deadlines)?

We are attempting to teach a new way of working.  There are a few key steps we’ve taken to help our organization realize that deadlines, although sometimes helpful, can also cause mayhem and colossal long term costs if placed in the center of our work.  These costs can be predominantly avoidable.

Here are some key tenets:

• Ensure your decision makers (the “business”) are engaged and partnering daily, and understand tradeoffs related to their choices.  With good decision making and partnership, we tend to maximize what we don’t build.
• Educate the organization on the virtues of software craftsmanship, and why high quality software is crucial to reduce costs and to go fast.  Architecture is then “baked in” to the process and we find ourselves leveraging our software versus fighting it.
• Teach the organization to “shrink their bets”.  Massive projects take on a life of their own.  And living things tend to create antibodies to change.  With large projects, too much is riding on the vision, plans, and promises of the project and its stakeholders.  When that happens, human nature is to “press on” and achieve project deadlines (even if the project or company is destroyed in the process).
• Teach organizations that learning is the most crucial, and scarce aspect of projects, not money or capacity.  With smaller deliverables, teams can learn how to deliver high quality software extremely fast, and learn a great deal along the way.  Rapid learning allows teams to change course quickly and achieve stunning results in the process, without massive investment in expanded capacity.

When the above conditions are met, customer expectations move away from simplistic models where DATES are the only thing they understand, to active partnership where RESULTS and VALUE once again take center stage.  It’s not that deadlines are all bad.  We understand they will always have a place in our work.  We simply try and make them less important in our daily lives, and treat them as exceptions rather than the rule.

When we do this effectively, we find that deadlines take their rightful place in the background of our work versus in the center of it.  The transition is tough and takes time.  Over the years, we have found it becoming easier and easier to implement due to years of deadline driven management and all the dysfunction and unintended consequences it creates.

Modus Cooperandi Makes Knowledge Work Manageable

Successful organizations need to turn ideas into action. The days where you could hire someone, train them in repetitive tasks, and leave them to repeat those tasks over and over are gone. Today, all employees must have some knowledge of computers, need to react to changes in context, and innovate. Unfortunately, most business practices are from an era where repetitive work was the goal.

We work with clients with very specific goals:

• Help knowledge workers understand how they create value
• Help organizations understand the natural variation in knowledge work
• Define ways to better estimate by measuring true task completion times
• Understand the capacity of work for the individual, the team, and the organization
• Create productive meetings and decrease the need for costly status updates
• Visualize knowledge work using tools like Personal Kanban that help in tracking and management
• Understand why plans routinely go over-budget and over-time
• How to identify and solve problems as they arise

Our aim is to create teams that focus on continuous improvement and, as such, can always communicate what they are creating, what state of development it is in, what impediments to completion they face, and why they are creating that particular product.

Watch the site for case studies, check out the books from Modus Press, and take a look at our client list.

And, of course, contact us if you have any questions.