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.

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

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.

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.

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.

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”.

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.

Kaizen Camp: Seattle–What We Did at Camp

This year’s Seattle Kaizen Camp was awesome.

I loved the range and diversity of the attendees, with people from health care, education, government, software development, and a host of other occupations. We had attendees from college students to C-Level management. We were once again very close to gender parity. And we had people from across the US, as well as Europe and Asia.

All this to discuss our experiences with continuous improvement, Personal Kanban, and lean.

The weather co-operated, so most of our 75+ sessions were held outdoors in the beautiful Seattle summer. Just warm enough to be comfortable.

Sessions included:

• Kanban at Home
• Failing Well
• Lean Contracts
• The Cynefin Framework
• Accelerating Innovation
• Metaphors to Convince Others of Lean Principles
• Resilience with Kanban
• Extreme Self-Organization
• Personal Kanban Experiences

and more .. about 70 more.

What was most important for Tonianne and me as organizers was the speed at which people created topics and the depth of conversations.

All the topics and conversations were conceived of, led, and participated in by the attendees themselves. There were no official speakers, no lengthy powerpoint presentations, no middle-of-the-day sugar crashes in dark rooms. Kaizen Camp: Seattle was people practicing Lean, Personal Kanban, and Continuous Improvement talking about what they did and how they did it.

We are looking forward to Seattle’s event next year, but in the interim we have several planning across the US.

Coming up later this year (announcements for each will be made soon):

• Kaizen Camp: Boulder
• Kaizen Camp: SoCal
• Kaizen Camp: NYC

Please come to one near you!

Several of the Photos and notes have been posted here.

Kaizen Camp: Seattle 2012

Following last year’s excellent “Seattle Lean Camp,” we are now nearing Kaizen Camp:  Seattle 2012. (We did have a name change, so as not to confuse us with another set of camps with the same name.)

Kaizen Camp is July 24-25, again at the beautiful Center for Urban Horticulture. Yet again, we have award-winning food trucks catering the event (both with vegetarian options), so no boring food! Already the event is nearly half full, with attendees from software, government, health care, manufacturing, education, and more.

The diversity of voices and ideas is unparalleled – which is exactly what we were aiming for. Lean ideals and principles will be discussed. People sharing their success stories as well as their challenges. Different disciplines working together to create new ideas and explore continuous improvement.

Last year we were blessed with great conversation, learning, food, and near gender parity. Judging by the buzz so far, this year promises to be even better.

What to expect:

1. Great sessions
2. Conversations with other smart people
3. Learning about what is working
4. Strategizing about sticky problems
5. Exploring ways to create better working environments, systems, processes, and policies

What you will be spared:

1. Dull speakers
2. Bad boxed lunches
3. Canned presentations
4. Being silent while others talk at you
5. Sales pitches from consultants pretending to be speakers

Cost and Sponsors

Kaizen Camp: Seattle is $79 early bird and $99 late bird. With all this learning, two awesome meals, a full day of snacks, and a T-shirt from Nordstrom, that’s a steal. We couldn’t do this without our sponsors:

• Nordstrom Innovation Labs
• Modus Cooperandi
• University of Washington
• University of Washington – Bothell
• LeanKit Kanban

See you there!

Why I’m Excited About Lean Camp

JUST LET ME LEARN!

Hallway conversations are almost always what people peg as their favorite parts of conferences. Yet conferences rarely provide ample space and time for people to have these conversations. When we actually converse with our peers or with the speakers, we learn more and, more importantly, we retain more. We are actively engaged in the learning, rather than just being spoken to.

When Jeremy Lightsmith and I sat down to plan a conference, we didn't spend any time on the format at all. We both knew we wanted conversation, learning, and community over talking heads, big names, and locations. The Open Space model was a logical fit for the Lean Camp we wanted to create.

I am very excited about Seattle Lean Camp because it embodies some central ideas.

1. The Future of Work – In the last several years, science has uncovered some startling new truths about how we learn, how we collaborate, how we are motivated, and why we work. Through the intersection of Lean techniques, neurophysiology, and social economics, we are learning that humans respond better to respect than remuneration. Additionally, changes in the way we communicate and the cost of information storage and dissemination has had profound impacts on the workplace. As the workplace becomes more social and more humane, it also is becoming more innovative and less reliant on traditional top-down management.

2. Learning and Creation – Lean Camp is about value creation from the outset. While many attendees have been headliners at other conferences, at Lean Camp they are there to share their wisdom and learn from others – just like everyone else. The potential topics at Lean Camp are as varied as the participants. At Lean Camp we want to find new solutions to old problems in a dynamic, charged environment.

3. Cross-pollination - Conferences that are for one industry and attended by only people in that industry miss the opportunity to really learn from others. At Lean Camp, we already have attendees representing software design, government, manufacturing, medicine, academia, graphic design, engineering, and more.

4. Gender Balance – I have been pleasantly surprised to see something very near gender parity in the people signing up for Lean Camp. After years of putting on conferences in both software development and engineering, this is certainly a first for me. I'm looking forward to asking attendees what drew them to Lean Camp to find out why we are enjoying such remarkable attendance

5. The Fallacy of Work / Life Balance – Work life balance is more than personal and it is more than a choice. Whether we are employers or employees, we need to recognize and respect that “work” is part of life, not some opposing force we balance with life. Studies already show that companies with a strongly collaborative corporate culture have weathered the current economic downturn better. Pre-Lean Camp conversations have drawn focus on this fallacy and toward respect in the workplace.

6. Low Inventory – W. Edwards Deming warned us of keeping inventory in our companies decades ago. Inventory are those things that we create, believing they are value, but then need to maintain and mange those things. For manufacturing, inventory might be the parts you need to make your product, or the products themselves. We want to make just enough and at the right time. For a conference, inventory takes the shape of expensive speakers, venues, large elaborate dinners, and many sponsors with special needs. In creating Lean Camp, we've specifically kept our inventory low. Even though everyone who comes to Lean Camp will receive a free T-Shirt and free food from two of Seattle's premier gourmet food trucks, and will enjoy spending time at the University of Washington's beautiful Center for Urban Horticulture, Lean Camp is only $50.

7. Great Food – Those who know me, know when I’m around food can’t be far away. This year at Lean Camp we have two of Seattle’s premiere gourmet food trucks providing free lunches to all attendees. On Saturday we have Where Ya At Matt? with his awesome Cajun selection. On Sunday we have Pai’s with his highly acclaimed Hawai’ian and Thai works of art.

8. Clothing – Nordstrom’s Innovation Lab is making sure that everyone who attends also leaves warmer and happier with a beautiful Seattle Lean Camp T-Shirt.

9. Value Cascade – So what we have here is a beautiful setting, smart people, an open format in which to think, great food, and a stylin’ t-shirt. All for $50.

This year in Long Beach, California, the LSSC put on a conference that explored Lean and kanban in software development. We had a wonderful turnout and fantastic conversations that resulted. With Lean Camp, we are hoping to take those conversations and combine them with creative minds from other industries. We want to explore the personal, the teams, the governmental, and the corporate views of these emerging ideas.

I am excited about Lean Camp's potential to unlock new ways of thinking about work, about life, and about the future. More than anything, I’m excited to see what community grows from this. We’ve built a strong community of practice for kanban and lean with Seattle Lean Coffee – what comes next?

Thank you for all who have signed up thus far and looking forward to seeing the rest of you there as well.  (And I’m looking forward to the food ….) 

Building Collaborative Teams

Modus Cooperandi builds collaborative teams using lean and agile management techniques and social media to enable communication and effectiveness.

Lean Coffee Seattle - Every Wednesday Morning

Modus is pleased to invite everyone interested in lean thinking to Lean Coffee Seattle. These happen every Wednesday at 8:30 to 10:30 am at Uptown Espresso at Westlake and Republican.  See you there!

Jim Benson to Speak at Social Media Breakfast March 2010

Jim Benson will be speaking at the Social Media Breakfast in Bellevue, Washington, on March 16, 2010. The topic will be: Lean Organizations, Social Media and the CIA.

Jim Benson to Speak Feb 2, 2010 at SeaSPIN on Personal Kanban and Software Development

Tonight Jim Benson will be Speaking at SeaSpin. This talk goes through a project his team did in early 2007 that used a hybrid XP / Personal Kanban approach to managing a widely distributed team and what they learned in "the early days." Here is the write up from the SeaSPIN site.

February 2 Meeting

Construx Software, 10900 NE 8th St Suite 1350, Bellevue, WA

Food & networking from 5:45 to 6:45 (pizza, salad, soda ) Announcements from 6:45 to 6:55 Presentation from 6:55 to 7:55 Doors close at 8:30

Personal Kanban and Kanban for Distributed Teams presented by Jim Benson

Kanban is rapidly gaining popularity in software development. How are teams and programmers migrating from straight agile to Kanban, or to hybrids like Scrumban or Scrow? How has this worked in the past? How do distributed teams make this more challenging? How can managers and teams best apply these new methodologies?

Jim Benson describes introducing both Agile and Kanban to development teams, focusing on a team he led in 2007 which built a complex transportation management prototype using nascent technologies and a team of cowboys – none of whom had used agile or been particularly collaborative before. How did he do this?

The answer: Subversion!

Let Jim take you on a journey of mystery and intrigue as he tells you how he fooled a bunch of programming malcontents into being a Lean, collaborative, highly effective work force.  It’s like the A-Team, but with Skype.