Since success is a rarity and failure much more common, we limit our learning opportunities by that success focus.

However, many also do not understand how the scientific process actually works. We therefore tend to build experiments that are invalid.

In Episode 4 of Collaberwocky, Corey Ladas, Jabe Bloom, and I discuss thoughtful failure.

Do you find the role of manager repeatedly maligned?

This is more than just “It’s lonely in the middle.” There are significant positive shifts in making the workplace more productive, efficient and effective. However, each of these shifts has been accompanied by changes in roles – and these changes are rarely clearly spelled out.

In Episode 3 of Collaberwocky, Jabe Bloom, Corey Ladas, and I discuss how to speak from power in this new uncertain world.

It seems that different rungs of the corporate ladder come with different perspectives. None are complete and all have their own biases and areas of focus.

Further, many management theories give rise to a sort of class warfare between the different rungs. “My manager doesn’t understand me.” “The C-Level suite are out of touch.” “The people who work for me are idiots.”

Far too often, this causes the rungs to appear so far apart that people cannot even fathom having productive conversations. Corey, Jabe and I mull over these issues.

After doing Lean Coffees for a few years and hosting Lean Camp Seattle last year, it became clear to me that conversation creates information – and that was compelling.

So we launched Collaberwocky, a series of conversations about collaboration.

This runs exactly like a Lean Coffee. We get together with a few participants, we build a kanban, vote on what we’d like to discuss, then we discuss.

The first five episodes are with Corey Ladas, author of Scrumban, and Jabe Bloom, CTO of the Library Corporation.

This first Episode is “Intentional Cooperation” in which we discuss creating teams and processes that intentionally foster collaboration.

It’s $2.99, or free if you have Amazon Prime.

This is the first in our new MemeMachine Series, which will be little eBooks like this that introduce a topic and begin discussions.

Here’s the writeup for it from Amazon:

Business runs on decisions. Recently, we’ve discovered that people aren’t the great decision makers we thought they were.

Business relies on estimates, plans, and projections – and we all know how accurate they tend to be. Careers are made, careers are broken based on accurate estimation and planning.

But what if the successes and failures of these projects were not based on the prowess of those making the plans? What if success or failure were more often the result of a more complex set of events?
Why Plans Fail directly addresses our ability of to plan, to forecast, and to make decisions.

Written by Jim Benson, an urban planner, software developer, and business owner who has planned and built everything from small software projects, to houses, to urban freeway systems – Why Plans Fail is told by someone with much skin in the estimation and planning game.

This short work is the first in the Modus Cooperandi Mememachine series – which looks specifically at underlying issues that directly impact the success of teams, companies, and individuals. The Mememachine series is meant to start conversations and advance discussion.

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 ….) 

“There are two ways to slide easily through life: to believe everything or to doubt everything.
Both ways save us from thinking.”

Alfred Korzybski

Over the last several years, I’ve studied a lot of processes and watched communities grow around them. I’ve been a member of many of these communities. As processes gain credibility, they generate excitement. As excitement mounts, the human desire for perfection plays a funny trick on us: we begin to identify with the process.

The fact that we get our “blackbelts” or certifications doesn’t help with this. We’ve now invested ourselves in the process and we want to use it. And why not? By and large these processes are pretty cool. We see ways they can make life better. And we love taking the easy way out, so we treat the process as an absolute.

But by now we’ve all read the news that the map is not the territory.

A guy named Alfred Korzybski said this, and if you don’t know him, you should. He was a smart guy. He is the father of something called general semantics which basically says that language is fallible and it messes with our minds, our relationships, and our ability to get things done.

This is a big problem for business.

There is no one burger, there is no one process

Is this to say we should stop talking or looking at pictures? Is this to say that we should have no process?

No.

What this means is this, and only this: In business, all process is at best an attempt to describe or control reality. It will always be improvable, it will always be fungible, it will always be to some extent wrong.

While we can be well-versed in Agile practices from software,  traditional management from large business and government, Lean practices from Toyota and beyond, newer tools like Positive Deviance, and in a wide variety of creative or visualizing techniques – these aren’t enough.

Every project with every client involves some invention, because the context of every client or team is unique. Business says that it wants predictability and repeatability in its processes across the organization. What ends up repeating is failure – even if the process works well in some places.

Why?

Repeatability in process is a range, not an absolute.

In the Modus Press books, we may tackle a concrete concept like Personal Kanban or Scrumban, but our writing always hinges on continuous improvement and process evolution. The goal isn’t to apply a process, but instead to understand our work, our lives, and our relationships better so we can make more informed or enlightened decisions.

In business, we can take lessons from Six Sigma or Covey’s 7 Habits or Extreme Programming and apply them to any group at any time – but only if it’s relevant to their context. I’ve used computer programming techniques with social scientists in Vietnam and manufacturing techniques with technical support groups in West Virginia. The ideas in any process are always to get people to work together. But there must be a healthy ecosystem of ideas for success to flourish.

We should always be suspect of the objectivity of salesmen of a single product.

While that is a nice, quotable, and glib statement (please feel free to tweet it to death), it comes back to what Korzybski taught us. Process is a pattern language. You see – if language is inherently flawed – the more we limit our business vocabulary to a single process, the less language we have to work with.  The less language, the more opportunities to use imprecise words, apply ill-suited ideas, and ultimately and unnecessarily fail.

How to succeed

Success is the actual process. Everything else is a means to that end. Having teams and an organization that understands the current nature of their work, embraces the idea that improvement is always possible, and has a good culture of communication is the only way to start.  Further, we need to understand that failure is a building block of success. Controlled small failures that teach valuable lessons provide the only stable foundation.

Failure is like an explosion. Explosions hurt, they blow things up. So we fear them. But between 1680 and the 1860s, inventors stopped fearing explosions and invented the internal combustion engine. (There’s a chain of them and I don’t want to fight with people’s favorite historic interpretation.) That explodes all the time and has changed the course of history. They key is … little non-destructive explosions.

 

Sometimes Heroes are Useful

It’s three o-clock in the morning and you’re awakened by the unwelcome beep of a text message. You don’t even have to look at your phone to know what it’s about. Good news always sleeps ‘till noon, as the saying goes, and so you surmise (quite rightly) that somewhere – somehow – something’s gone wrong with the servers and the site is down. Your business is based entirely on global eCommerce. Every minute the site is down customers are annoyed and sales are lost.

You stumble out of bed and make your way to your office downstairs. Your wife sleepily yet pointedly reminds you on your way out that this is the fourth time this month. This is not news to you. And to be honest, her count may even be on the conservative side. For months now, the site has been springing leaks on a weekly basis. The team is disgruntled. Some have left, while the ones who’ve remained are feeling powerless. The issues are too numerous. They simply can’t keep up.

You get into your office, boot up your laptop and find two team members chatting about the problem. Dave has already isolated it, and is in the midst of fixing it. That indicates it’s a problem with the fulfillment system. Dave knows his way through that code better than anyone. If it were a problem with search, Ryan would be all over it. If it were with transaction processing, Mei would take care of it. As for the other parts of the site, well, they don’t break.

For now.

The six other team members no longer bother responding to pre-dawn texts. They assume (quite rightly) that whatever problem’s presented itself relates to one of the three typically problematic systems, and that one of the three aforementioned “heroes” will take care of it.

As the team lead, you just have to wake up and be present – but the heroes will get the job done. Soon it’s just you and Dave in IM, though you’re not even talking. Then Dave types, “Try it now.”

You run through a quick perhaps even haphazard battery of tests, and everything looks fine. You know Dave’s fixes work.

You close your laptop, and go back to bed.

The next morning at work, everyone’s busy fixing bugs. No one even mentions the problems that arose in the middle of the night. This is the status quo.

~

While it may seem depressing, many on-line businesses will find this scenario familiar. It is not an edge or extreme case. When teams create complex software and a lot of hastily released code, they end up with something called “technical debt.” In essence, technical debt is releasing something (and it can be anything –  from software, to a car, to food in a restaurant) that can work most of the time, but is likely to be returned.

When teams release software with a lot of technical debt, a few things happen. First, the team becomes unhappy, knowing that they’ve released a questionable product and that bugs are going to come back. Second, if the bugs are numerous and severe (causing outages like those in the story) heroes show up to save the day.

Heroes tend to be armed with razor sharp, double-edged swords.

The Edge that Solves

On one edge, they quickly cut through to the heart of the problem: they fix the code, and get the site up and running. While that’s wonderful and everyone can be is relieved for the moment, it’s just that - for the moment.

The Edge that Cuts

The second edge of that sword cuts into the team. While the hero gets the site up and running, no one knows what he did or why. His code was never vetted, tested, or“refactored” (a fancy word coders use for “edited”). So in the end, the hero has created undocumented code that no one else can go back and work with. Every time the hero touches the system, they fix the symptom (the outage) and exacerbate the problem (technical debt).

That’s not optimal, and everyone knows it. But frequently organizations suffer from so much technical debt that focus is placed on putting out fires at the expense of creating value. More fires equate to more undocumented code. More undocumented code makes it more difficult to fix the root causes of the problem. If the root cause remains, we continue spending time and money responding to it.

In Agile, we’ve declared hero culture to be a detriment because it creates and perpetuates technical debt and introduces inefficiencies. The Agile solution to team heroes is to cross-train – to make sure that many people on the team have the capability to fix the code. That solution is backed up with coding standards, unit tests, and other practices designed to avoid sloppy code and remove the need for heroes in the first place.

So, we have our solution. Simple! But wait – what about all the technical debt that remains? We still have heroes. We still have not found our coding nirvana.

Why?

Because coding is inherently messy, and it always will be. If it weren’t messy, it would be automatically generated by software writing software. If it weren’t messy, coders would make $35 an hour. If it weren’t messy, we wouldn’t need Agile to begin with.

So, technical debt is a fact of life. Heroes are a fact of life.

Should they be?

Nope.

So let’s think about this a minute.

We have a group who knows their product. We  have individuals on the team who have hyper-specialized in response to the reality of the system. We have a system that is breaking often and requiring emergency repairs.

Many Agile coaches would put systems into place that removed the heroes from their stations and cross-trained others in the group. Is that the right solution? Maybe.

Maybe not.

The other people on the team are overworked just keeping up with all the technical debt hitting them in the face. Catastrophic failures currently require immediate intervention by someone with specific knowledge. Every minute is worth millions of dollars. This is NOTnot the time for cross-training.

It’s hero time.

So, in a traditional system, the hero’s tasks would be lost in the shuffle. The code enters the system, patches the problem, and people go on about their work. That’s not good either. Hero time cannot be blind-faith time.

But what if we’re using a kanban on this team. For the non-heroes, we have a simple value stream of:

And that works fine, because those coders are doing things by the book. Their code has unit tests, it meets coding standards, they are pairing, have code reviews, and so on. The legitimately generated new code has ample safeguards for quality.

The heroes, however, are responding to a threat-in-progress. Their task is to code it and forget it; get the site up and running at all costs. To make matters worse, these heroes are brilliant problem solvers. This means that their code is not only undocumented, it’s completely confusing to read. It works, but no one can tell how it works. They saved the day, but left this nugget of ingenious-yet-impenetrable code gristle for people to chew on later.

At the time though, and this is important, they successfully got the system up and running immediately. They routinely save the company from ruin. And that’s a good thing.

So let’s rationally solve this problem. Let them be heroes, but give them a different value stream that gets the fix in and then responsibly refactors and integrates that fix with the rest of the system.

The new hero-embracing value stream might look like this:

So we extend our hero metaphor a bit with some familiar characteristics.

1. Above The Law: The hero is uniquely gifted with the ability to release production code without any testing. The goal for the hero, when invoked, is to fix the problem and get the system running asap, no questions asked.
2. Jimmy Olsen is Needed: Immediately upon release, the hero teams with a normal human being to refactor their genius code into something that is maintainable, readable, and avoids future technical debt.
3. Bat Caves & Arctic Fortresses: Heroes need to be introspective. “With great power comes great responsibility,” says the Batman. After a situation where a hero action is invoked, the team or even part of the team should meet and discuss the issue, why it happened, and how to strike at its root cause and ensure it does not reoccur. This gives the crime fighter the ability to stop the next crime before it starts – really taking advantage of their gifts.

Number 1 in this list ensures that mission-critical problems are dealt with immediately and decisively. Number 2 ensures that the hack is not the final solution. Number 3 ensures that the team learns and quickly sets out to improve the system to avoid future calls to the hero.

Ultimately, we’d like to build systems with no technical debt. Our processes are, of course, aimed at that lofty goal. But like it or not, we do have emergencies that necessitate rapid fixes. We have but two choices – boldly stand up and face reality, or continue to solve technical debt with more technical debt until the software implodes.

Which do you choose?

(“Superhero Down-Time” Photo by Jason Stanley)

No Flow = No Profit

When coders have crazy unreadable code its referred to as “spaghetti code.” Single strands of code are impossible to trace through the tangled masses coders can weave. When this happens, it becomes incredibly difficult to understand the original intent of the code, the order in which changes were made, and how to go about making things better. This creates something known as “technical debt”. As time goes on, the difficulty in interpreting the code makes it time consuming and expensive to expand upon or to fix bugs.

It strikes me that this is very similar to the specifications that I have seen through the years. At project conception, one person might sit down and write a spec. Between conception and the start of coding, any number of people might edit that spec, introducing, editing, or removing features from the project. As the project begins and progresses, the spec is altered even more. Change orders occur. Off-line detailed conversations are hastily added to the spec or worse yet, included as an addendum. Soon we have spechetti – a document that has been through the hands of many, with differing intents, reflecting dozens of unrecorded conversations.

Spechetti creates a type of “legal debt.” Teams are required to satisfy difficult-to-decipher legal code that can be easily interpreted differently by others. Conflicts grow as interpretations diverge. Interpretations diverge the more granular (and difficult to find) operational clarity is in the spec. This makes the product time consuming and expensive to finalize.

The goal for projects should therefore not be to create a comprehensive spec that can be argued about at completion, but to create a legal and management system that actually drives agreement, clarity, and good business decisions while the project is in-flight. To do this, emphasis is placed on contracting for operational imperatives and not implementation specifics.

Existing contracting mechanisms create legal debt as a matter of course. We need a new kind of collaborative, non-punitive contracting system that replaces mounting legal debt with a mechanism that actually creates social, creative, and business capital.

Well, that sounds easy doesn’t it?

Tune in next time for what will kick off a series on Agile Contracting.

Also, be sure to check out everything else from Modus Cooperandi Press.

DO THE RIGHT THINGS

Personal Kanban

Machines need to be productive.

People need to be effective.

Productivity books focus on doing more, Jim and Tonianne want you to focus on doing better. Personal Kanban is about choosing the right work at the right time. Recognizing why we do the things we do. Understanding the impact of our actions. Creating value – not just product. For ourselves, our families, our friends, our co-workers. For our legacy.

Personal Kanban asks only that we visualize our work and limit our work-in-progress.

Visualizing work allows us to transform our conceptual and threatening workload into an actionable, context-sensitive flow. (We see what we are doing.)

Limiting our work-in-progress helps us complete what we start and understand the value of our choices. (We cannot do more work than we can handle – choose work wisely!)

Combined, these two simple acts encourage us to improve the way we work and the way we make choices to balance our personal, professional, and social lives. Neither a prescription nor a plan, Personal Kanban provides a light, actionable, achievable framework for understanding our work and its context. This book describes why students, parents, business leaders, major corporations, and world governments all see immediate results with Personal Kanban.

Following World War II, U.S. automakers focused on increasing productivity to meet a seemingly insatiable domestic demand. Meanwhile in Japan, faced with a decimated economy and limited resources, Toyota discovered their success hinged not on increasing productivity, but effectiveness. To this end, the nascent auto manufacturer launched a fairly radical campaign: to create a culture of continuous improvement, where the workforce had clarity of purpose and the ability to affect change. This innovative way of thinking (later called “Lean”) transformed this small island nation into a world-class producer of recognizably high quality automobiles. Toyota’s reputation for excellence rested on destroying the myths of productivity and control, replacing them with effectiveness and flow.

The secret to their success can be the secret to yours.

Personal Kanban borrows from several Lean principles and practices. With just two simple acts – visualizing work and limiting work in progress – Personal Kanban gives us clarity over our work and our goals, and the unprecedented ability to deal with distractions, manage expectations, make better decisions, and ultimately find a healthy balance between our professional, personal, and social lives.

It is a simple, elegant mechanism that helps us manage ourselves, but also lets us share our work, our goals, and our epiphanies with others. It is a visual launch pad to personal effectiveness, spontaneous collaboration, and an integrated life.

Personal Kanban: Mapping Work | Navigating Life discusses not only the mechanics of Personal Kanban but also how concepts like the flow of work and systems of continuous improvement are easily incorporated into how we live.

Advance praise for Personal Kanban

Personal Kanban is a must read for knowledge workers and their leaders who recognize that old productivity models don’t apply to knowledge work and seek a more realistic and centered approach. The ideas are deceptively simple but in that simplicity is their strength. As soon as I finished reading it, I started drawing out the landscape of my projects and felt much the better for it.
~ Carmen Medina, Deputy of Intelligence (Retired), Central Intelligence Agency

Personal productivity systems usually fail in practice because of complexity and they don’t reflect the collaborative nature of real work. Personal Kanban provides the simplest structure that could possibly work and lets you achieve a state of flow.
~ Ross Mayfield, CEO SocialText

Personal Kanban shows you just how revolutionary the technique is, and is a must read for student to senior citizen who wants support to do fantastic work. Personal Kanban is simplistic and will become second nature; not only does it change with you and your life, it will change your life.
~ Patty Beidleman, Pre-school Teacher, Non-Profit Organizer, Caregiver and Mother