Fifteen (yes, 15) Kinds of Waste in Knowledge Work

15? I thought it was 7

Traditional Lean Manufacturing recognizes 7 kinds of waste: Transport, Inventory, Motion, Waiting, Overproduction, Extra-Processing, and Defects. These are considered forms of muda, non-value adding activities.

There are two other categories that interfere with the delivery of value: mura - process stress, and muri - people stress. These stresses are considered impacts that "lead to" waste.

Waste in Knowledge Work

Lean practitioners in Knowledge Work (e.g., software, IT, any kind of cognitive effort) have identified three additional categories of muda: Talent, Resources, and By-Products.

In addition, for knowledge work, making a difference between mura/muri "stress" and the waste they cause is an academic exercise only. In the real world they all need to be eliminated.

Why categories of Waste?

Why bother knowing categories of waste? To raise awareness and help establish an "Eyes for Waste" culture. Often waste is just what we swim in and we don't perceive it.

What do we do about it?

You can do formal "Value Stream Analysis", but honestly that's mainly useful for convincing ineffective executives and non-contributing PMO's to cut themselves out of the delivery flow. "80%" of the time waste will be obvious.

Just stop it.

Other times finding the best way to get rid of it will be a challenge. As with all things Lean, don't expect to be perfect right away, expect to uncover waste like an excavation of ancient Troy, with yet another layer underneath.

Sometimes the solution will be upstream, higher up, or systematic. Often it will require new habits, practices and behaviors.

And as always, be scientific and explicit in your waste removal experiments.

15 Kinds of Waste

Here's the list of the 15 kinds of waste in knowledge work:

Muda - non-value adding activities (pure waste)

In knowledge work, the traditional manufacturing waste categories are considered slightly differently.

Transport Waste

Transport waste is any kind of hand-off. Across geographies, departments, between teams:

• Any time “the work” has to leave one person’s head and be picked up by another
• Any effort needed to move information from one format or tool to another in order to make it useful
• Every upstream/downstream work item transfer between “concept and cash”
• Any “interface mismatch” 
• Include all the effort needed to “coordinate”

Be on the lookout for:

• Any time “explanation” is needed for hand off
• Any kind of “extract”, “transform” or “load” of work artifacts
• No permanent place for work visualization
• No permanent team space for collaborative work

Inventory Waste

Inventory waste represents unneeded latency. It appears in backlogs, work-in-progress, and queues throughout the value stream. In knowledge work it is also the "left behind" item that is paused during task switching. Each paused item, regardless of granularity, is inventory waste.

It is also seen in:

• Any item in any unfinished or "wait" state
• Any effort needed to pause or "hibernate" a work item
• All open decisions yet unresolved without experiments to conclude them

Look out for:

• Having to "get back up to speed"
• Unread emails, emails flagged "for follow up"
• Team is unable to prioritize a single "most important thing" to finish today

Motion Waste

Motion waste is any time, effort or action spent getting to the work. Knowledge work motion waste includes setup, access and record-keeping.

• Any electronic, physical or mental actions needed to get started
• Meetings without agenda or purpose; meetings that didn’t need a meeting to accomplish the same thing
• Effort to record data for non-emergent metrics
• Effort to prepare reports that simply describe the work (“status reports”, “red/yellow/green”, etc)
• Any effort to produce unused metrics, estimates or reports
• Searching for information not on visual management system
• Any use of magical thinking "metrics" like story points and velocity

Look for:

• TPS Reports
• Metrics collection to "the third decimal"
• Leadership/management does not "go and see" by visiting the workplace visual management system

Waiting Waste

Waiting waste is obvious, right? Any delays - internal or external. Dependencies, approvals, etc. Once you get past the big, obvious ones there are all kinds of wait wastes throughout the work day like sand in the gears.

The "waits" are often small, subtle, and built into the culture and DNA of individual and organizational behaviors. Changing these and establishing new non-wasteful norms will take continual attention and practice.

Some of the places you'll find waiting waste include:

• Third party (outside of team) supplier timing
• Approval requests that are always approved
• Meetings that don’t (can’t) start/end on time
• Meeting “pre-work” unavailable or undone
• Decisions postponed (e.g., key person not present)
• Waiting for email responses
• Work hiatus at sprint boundary (scrum teams)

Be on the lookout for:

• People “checking their phones” during some other event
• “We never expect to start until 5 min. after”
• Rescheduling previously rescheduled meetings
• Frustration from friction
• “Stuck Tickets” 

Overproduction waste

Overproduction waste is fundamentally a mismatch between expectation and delivery. In particular, miss-prioritization, over-engineering, and miss-understanding of the customer's value.

There are many sources of this:

• Too large of batch sizes
• Anticipating requirements/acceptance criteria
• Ill-defined process transitions 
• Upstream/downstream coordination failures
• Repackaging information in different forms for different audiences
• Reliance on ceremony rather than fact

Watch out for:

• Analysis Paralysis that end with "all of the above"
• No communication with customer 
• Missing/incomplete acceptance criteria
• “Pulling in” multiple work items, scrum “commitments” (quotas)

Extra-processing waste

Extra-processing waste comes from re-work, duplicated work, and redundant work.
The most obvious of these in the software development world is "technical debt". but it also comes from:

• Inconsistent processes between team members
• Vendor mandated “upgrades”
• Emails that cc everyone, “reply all” cascade
• Product quality via testing after work completion
• Meetings with people who don’t need to be there
• Decisions with no follow up

Watch for:

• Groundhog Day: “Again??”
• Random queue growth
• “Testing” as a bottleneck
• Effort spent having to deal with sprint “leftovers” (scrum teams)

Defect Waste

"Defects" is the type of waste most people think of when they think of process wastes. It is the seventh, and last, of the traditional manufacturing wastes. It comes from failures in production, and the solution is normally process-focused: build quality in rather than checking for it afterwards, remove from the process any chance of making a defective choice, etc.

In knowledge work it also includes:

• Unclear process, non-understood process, wrong process, erroneous process
• Failure to solicit feedback, ignoring feedback – feedback cycle too long
• Disagreement on “best practice”, lack of best practices, and not following them
• Experiments with no data collection
• Assuming you actually have the "best" practice

Look for:

• Customers don't return
• Focus on “due dates” over quality
• “Spell check did it”
• "That's how we've always done it"

Talent Waste

Talent waste is the first of the three additional waste types that have been identified in knowledge work. It is caused by failing to leverage the skills, knowledge and capabilities of the team.

It includes:

• Timing gap between any training and using that training
• Lack of training, unused training
• Only “leaders” in isolation make decisions or are allowed creative activities
• Non-challenging, repetitive, or boring work

Watch out for:

• Anytime anyone fails to speak up
• Command and control management style
• Anyone left on the bench
• “What value is my work?”
• No humor allowed

Resources Waste

Resources waste is redundant, ineffective, or inadequate tools or working conditions.

It includes:

• Any tool that makes it hard to do the job
• Tool versus team’s best practice mismatch
• Forcing a process to fit the tool
• Letting the tool do your thinking
• Non-ergonomic desks, noisy work areas, "open plan"
• Nowhere to work collaboratively, no team space, no physical visual management space
• Slow equipment (e.g., laptop boot, Wi-Fi bandwidth)

Watch out for:

• “We’re using tool X so we’re Lean”
• Working from home in order to think
• Hunting for conference rooms

By-Products Waste

By-products waste in knowledge work comes from failing to leverage lessons learned, and missing opportunities for skills transfer.

Eliminating by-products waste is the practice of "yokoten", or sharing the learning.

You see by-products waste in:

• No/few Communities of Practice, “Lunch and Learn” sessions, “Science Fairs”
• Undocumented Best Practices
• Un-monitored experiments
• Abandoned kaizen efforts
• Kaizen is not part of the team's visual management system
• Undocumented decisions, meetings without follow up

Look for:

• “No time to improve, we have work to do”
• Management owns skills transfer channels
• Boring retrospectives that go nowhere and accomplish nothing

Mura - Process Stress that Leads to Waste

Process stresses are all those things that prevent flow, that cause turbulence and intrinsically prevent delivery of value.

While these are considered "stress" that cause waste, in the interest of "root cause" resolution I recommend dealing with them directly.

Unevenness stress - waste

Unevenness waste is caused by large variations in the granularity of work items reaching the team.

Please note that teams should have a well-defined (and constantly improved) intake process that breaks work into appropriate "small batch" or one-piece flow work. The "stress" in this waste is due to restrictions on the team that prevent them from owning their own intake process.

Included are:

• No/ineffective intake/triage/sort process
• Assigned intake process
• Multiple customers and “Line jumpers” – everyone wants to be first
• Missing/incomplete escalation process
• New work must be “done now”

Watch for:

• Unable to determine "most important" work item of the day
• Difficult to “walk the board”
• “Clogs in the pipe”
• Customers call team members directly to expedite their pet items

Inconsistency stress - waste

As with Unevenness, Inconsistency is a stress on the process that wastes teams' cognitive skills, problem solving capacity, and forces them to spend time "deciding" what to do rather than actually getting things done.

There are a number of causes, including:

• "Everything" is a special case
• No two people do the same thing the same way
• No visual management system to capture the team's unified understanding
• Unclear work types/categories
• No agreement on "best" practice
• Unclear/missing process transition rules
• No Kaizen process for continuous improvement (e.g., no PDCA)

Look for:

• “Three step” process definition (To-do, Doing, Done)
• “I thought we agreed . . . “
• "What did we do the last time this happened?"

Muri - People Stress that Leads to Waste

People stress is anything that takes the joy out of work. As Deming's Rule #12 says:

Remove barriers that rob people in management and in engineering of their right to pride of workmanship

 Absurdity Stress - Waste

The first kind of people stress is demanding things that are simply ridiculous. In knowledge work this is usually a fundamental disconnect between the people "assigning" work and the people doing the work. Executives who imagine themselves "inspirational"  will claim that asking for the impossible it a legitimate way to challenge the team, and "forces" them to creative levels they would not have obtained on their own.

This is wrong. It is not sustainable. A "creative" death march is still a death march.

But it also comes in less toxic forms that nonetheless diminish teams. They include:

• Excessive scope
• Confused scope
• Undefined minimum viable product
• No line of sight to customer value
• Decisions made without team input

Listen for:

• "Think outside the box"
• "Steve Jobs demanded a lot from his people, too"
• "Don't tell me the odds!"

Unreasonableness Stress - Waste

The fundamental cause of unreasonableness stress is an expectation of heroic efforts. Most often the root cause is upstream from the team, decisions made for the team, promises and deadlines that "have to" be met.

It also includes:

• Leadership needs to "save face"
• Focus on dates, not quality
• No business rationale for dates
• Politics over value (promises made without data)

Watch for:

• Celebrating and rewarding overtime
• Tracking hours
• Crisis mentality
• Weekend work
• Using story point (numeric) quotas

Overburden Stress - Waste

Overburden stress comes from violating another of Deming's rules, this time #8:

Drive out fear

The sources of overburden are, sadly, too many to count. A few of them include:

• More than one manager, delivery lead or  Product Owner
• No “Andon cord”, negative reaction to Andon Cord
• Numeric goals or production quotas
• Leadership decisions are not questioned

Be on the lookout for:

• “Blamestorming”
• “Matrix management”
• Command and control, micromanaging culture
• Culture of fear, lack of trust, no joy in work 

Summary

Waste is the most obvious and immediate was to make improvements. You should expect at 30% reduction in cycle time from creating and reviewing your visual management system. The key is to make everything visible

Kaizen is an ongoing process – you will be in constant cycles of waste removal.

In every activity, every report, metric, meeting, email, . . . constantly ask:

• What is the customer value in this?
• Is this really the best way to do this?
• Are we learning anything from this?

Look “upstream” for resolution – apply Systems Thinking – look for systemic solutions. But don't ignore the simplest: Stop doing the dumb stuff.

Share your learning – create a Kaizen culture. This is a cultural shift. Don't use slogans and rewards.

Develop Eyes for Waste!

What is the software "Andon" cord?

“Andon” is the “stop the train” system used in Lean Manufacturing to encourage teams to be aware and immediately raise any issue, no matter how small, that might impact quality and value.

The heart of the system is the “Jidoka” mindset. 

Jidoka is the attitude of “Problems are Treasures” – the first response of leadership when the Andon is pulled is to say “thank-you”. Regardless of whether a real issue or a false alarm, the response is always, “thank-you”. 

What does this mean for software teams? 

Recently there was a event that surfaced with one of the teams I was working with.

There had been a situation where the normal test procedures/environment protocols were not followed. My understanding was that things worked out, but should not have happened that way.

There were a number of potential “Andon moments” where "stopping the train" would have been useful:

1. the recognition of the underlying problems that necessitated the deviation,
2. the lack of satisfaction with regular “best” practice,
3. the decision to not follow procedure,
4. dealing with the difficulties of the work around,
5. dealing with the consequences arising from the deviation,
6. the moment it was mentioned in standup,
7. scheduling a follow-up to discover root cause,
8. placing on the improvement backlog the need for exploring countermeasures to the root cause,
9. recognizing the need to improve the team’s best practices,
10. etc

The key to implementing Andon effectively is to make it “trivial” to raise the concern. If there were a physical visual management system, jot on a sticky note and put it up. Or perhaps send a message on Slack. Something that requires “no effort” to do.

Next is the response. What are the protocols you implement in response to “stop the train”? These protocols will evolve (under leadership guidance) for each team/product/organization. Does the team triage immediately? Address the issue? Place it on a backlog? Ignore it? I recommend explicitly articulating (publishing, posting and improving) the protocol.

For example, a team I worked with last year had created a three-level “Alert Box”, where anyone could post (a sticky note) with any issue at any level of concern at the bottom level (in addition to putting it on the team Slack channel). If by the time of the next stand-up, the issue had not been dealt with, it was “moved up” to the next level, etc. If it reached “the top” and was still unresolved the entire project (33 people including on/off/near shore) would drop everything else until the issue was dealt with one way or another.

They got to that system as a balance between a number of forces/pressures on the project including the usual suspects: behind schedule, over-promises, new technology, new team members, off/near shore communication, etc.

Posting forced accountability. It was incumbent on managers and senior technical personnel to respond. The person who raised the issue, who “pulled the cord”, was empowered to accept or reject the response.

In addition, senior managers and even the business side Executive VP who was funding the project would routinely visit the team’s Visual Management System to get a feel for how things were going. The VP made it clear that he expected to be tasked to help fix anything that got near the top.

So what would be the recommendation for you? 

Pick something (that will be “wrong” and “won’t work”) and constantly improve it. The first step is mindfulness, that is, everyone simply being aware of what they are thinking and doing. 

Celebrate each time the train is stopped until everyone feels comfortable with raising issues. Say “thank-you” when they are. Show on Leadership's visual management system how management is responding to systemic issues. Etc.

Encourage everyone to constantly ask the Three Questions:

1. Is this of value to the customer?
2. Is this the best way to do it?
3. Are we learning anything?

And if the answer is “no”, pull the cord!

Visual Management for Software Development and IT

Use the Most Powerful Supercomputer on the Planet

The most powerful supercomputer on the planet is right behind your eyes: the human visual cortex. Visual management uses it to help teams think about the work, prioritize the work, improve the work, diagnose issues, communicate across teams, expose problems, eliminate waste, and inform management.

Visual management forms an “exo-brain” that forges team-wide understanding. It provides a forum for experimentation and data collection. It removes blame and focuses defect resolution on the visible articulation of the work, rather than “who did what”.

How can your team take advantage of this power?

Getting Started

Software development, and IT projects in general, are complicated, multi-layered and many-faceted. Effective visual management captures and exposes, all the demands for the team’s time – implicit and explicit.

Step One: Brainstorm “What Do We Do?”

Get the team together and brainstorm a complete “dump” of every kind of work, or thing, that anyone on the team does. At any, and every, level of abstraction. [Use the typical large-room/sticky-note method]

For example:

• Technical, Operational, Leadership
• Everything on our plate now
• All the types of work on our plate
• Maintenance, Defects
• Administration, Bureaucratic demands
• Improvements, Experiments
• Learning/Research
• Communication, Meetings, Corporate Events
• Training
• Accounting/HR demands
• On the horizon/next quarter, looming crises
• Things we've done before
• What we're worried about
• Random fires to put out
• Off the books
• Things we hate to do
• “This will only take a minute” 

Step Two: Brainstorm “How do we do it?”

Teams often start thinking of this during the first session. Go with the flow and encourage continual surfacing of thought.

The types and categories change - you want to shift to thinking about the "process" and "method" beyond the actual work artifacts.

For example:

• Milestones
• Decisions
• Best practices
• Gates (go/no-go)
• Approvals/Reviews/Meetings
• Checklists (things to do)
• “Meta” tasks
• Upstream complications
• Downstream expectations
• Professional behaviors
• Sister team dependencies
• Tribal knowledge
• “Pre-work” and “Post work”
• Previous known tasks, “must do’s”
• Beginning, middle, end
• 3rd party dependencies
• Warnings and boundaries
• Stops and aborts
• Engineering Principles
• Patterns and templates

Step Three: Organize your thoughts

As a team, look at all the ideas and thoughts that have been generated.

Look for patterns, groups, similarities, and cluster those.

For example:

• Categories
• Class/subclass
• Class/attribute
• Precedence
• Simultaneity
• Special cases
• Defects
• Research
• “Executive focus”
• Run the business

The result

You will find there is a lot more going on that you realized. 

Step Four: Build your “first pass” visual management system

As a team, based on everyone’s thinking about the information now seen, lay out your display.

What happens to the work (all work, any work) from “beginning” to “end”?

For Example:

• Swimlanes, zones – stage/state columns
• Separate areas, boxes, connectors, transitions
• Milestones/checklists
• Experiments in progress
• Backlogs and queues
• Policies and practices

Let the team be creative! Use all the walls in the team room. Take over a conference room! Use Painter’s tape, sheets of paper, stickers, sticky notes, string, glitter . . .

Step Five: Review the Result

Challenge the team with the following questions:

• If I had to “mark” all the work I do, does this capture it all?
• For each work item/element we have, can I see each activity that item goes through? What happens next?
• What is missing? What “should be” missing (wastes we can get rid of)
• Where is improvement needed?
• Where do we need to explore the work more thoroughly?

Step Six: Rinse and Repeat the following question every day

Can I tell “at a glance”:

What is the most important thing for the team to finish today?

If you can’t tell, then improving the VMS so that you can, is your most important thing.

Going forward

Expect to completely rebuild the entire display multiple times as the team begins to think more deeply about their work.

Continue to improve the display while you do the work.

Ninth iteration: What is the most important thing for the team to finish, today?

Use the Supercomputer!

As the team works, let anyone and everyone continue to improve and enhance the display. Good (useful) ideas will persist, non-useful ideas will evaporate.

These were all elements added by kaizen from empowered team members.

You should expect to be able to SEE all the work of the team

Summary

Your Visual Management System is meant to make work visible:

• Make it possible to see all of the team’s work in one place (“everything” they spend time on)
• Make visible the steps/states the work goes through, how to get from one to the next
• Make explicit your standard way of working – all policies, assumptions, tribal knowledge, escalation criteria, blocking criteria, . . . 
• Identify all categories and types of work, classes of service, upstream, downstream . . .
• Insure “all work in progress” – off-the-books, admin, maintenance, . . . is visible
• Make it “easy” to see what state the work is in . . . and what comes next
• Make it “easy” to see how “close” it is to finishing (what is left to do)
• Make it easy to capture anything that comes in outside of the team’s normal intake process
• Make visible your continuous improvement experiments
• Make it “easy” to discuss what is most important
• Include all process activities or ceremonies that use team time
• Make it easy to see the things you are doing that are NOT value-adding

 Additional Guidance: This is a Living Artifact

• Sometimes the “most important thing” is to improve/change/enhance the VMS so you can tell “at a glance” what is the most important thing
• Everyone/anyone can suggest/make improvements to the display
• The team will learn/adjust the most effective level of abstraction for the display
• The team will learn/adjust how and how often to update the display (immediately? Twice a day?)
• Display can have multiple levels of abstraction shown simultaneously - the more information the better
• Usefulness and communication are more important than “purity”
• Include any work artifacts the team wants to think about

Lean Principles Make Software Development Anti-Fragile

[part of a series]

The Nature of the Software/IT Domain

Software development projects, and IT projects in general, are complex cognitive endeavors. The more people, teams and technologies involved, the more complex it gets. Further, it is often a very creative process – while many elements (especially those at small scale) are repeatable, more often completely new artifacts must be invented.

When projects start, the executives funding the effort legitimately want to know, how long will this take? That is, how much is it going to cost?

Over the last 50 years there have been many approaches to providing these estimates. Some work better than others, but they all have one thing in common: They will be wrong.

Completion Estimates in Extremistan

Completion estimates are always wrong.  But the interesting thing is they always (nearly always) underestimate the time to complete. Why is that? It is the rare, memorable occasion when a project finishes early.

The fundamental mistake people make is thinking software development lives in Mediocristan, where outcomes are confined to nice clean Gaussian Bell Curves. But it does not.

Software development lives in Extremistan, with fat tails: the “lateness” of any effort is unique, and can be orders of magnitude greater than anything you’ve see so far, or that anyone else has seen.

And these fat tails are nearly always concave – worse and worse.

What do you do when you work in Extremistan? You need protocols for precaution.

Fortunately, Lean Principles provide the basis for those protocols.

Number One: Limit your exposure

Start with the Lean Principle of Small Batch Size. “Batch” can mean the number of items, the size of the work item, the detail and depth of fidelity (e.g., prototypes, MVP's), or the length of time the work proceeds before being “checked on”. All of these are appropriate for software development.

This means that you quickly "surface" the work and see if it is on track, providing the value you expected, conforming to the standards you set, etc.

If (when) things are off-track, they are not off for very long, because only a "small batch" of wrongness has be created.

The ultimate expression of this is the Lean Principle of One Piece Flow, where you only make a single (small) item at a time, with the whole team involved, and then check how you did.

Number Two: Hypothesis and Test – Learn from your experiments

Second is the Lean Principle of Continuous Improvement – the Plan, Do, Check, Act cycle. Underneath is the basic driver of all progress in the last 400 years: The Scientific Method.

Start with the Lean Principle of Visual Management: Before you begin your small batch, articulate everything you know. Make visible (physical if possible) all elements of the work, all artifacts, thoughts, plans, diagrams, code, etc. This is your hypothesis: we hypothesize that running this (visualized) system will lead to an anticipated result.

When your small batch finishes, conduct a thorough forensic analysis what happened. What did you learn? What can be done better? Make this analysis specific and actionable. Collect data (e.g., cycle time) and review against all previous experiments.

You want to learn the “physics” of your domain, as much as possible. Make explicit what you know, why you think you know it, and what it means.

There will still be unknowns - that's the nature of risky, fat tailed worlds. But keep moving forward with skeptical empiricism: use everything you have learned so far, keep learning - and expect to change your mind when new information is obtained.

Number Three: Make That Learning Cycle Immediate

Lean encourages people to continually monitor the progress of the work, and raise any problem immediately. This is the Lean concept of the Andon cord, and the Lean Principle of Jidoka: Problems are Treasures. It means stop work at the slightest hint of any problem, confusion, loss of value, quality concern or waste. 

The response of the entire organization is gratitude to the person for caring enough about the customer to first notice, and then act. The stoppage is treated as a learning opportunity for all people, systems, and artifacts involved.

This in turn drives the “batch size” down to that same level of immediacy. Because the Lean response is to use that call to “stop the train” to improve, right there and then.

Number Four: Eliminate Waste – Signal to Noise

The fourth Lean Principle to being anti-fragile is to Eliminate Waste. There are 15 "kinds" of waste: the list of categories is a learning aid that helps sensitize people to the problem. It is a key part of value stream analysis.

The main value that eliminating waste brings to being anti-fragile is it removes "noise" from the system. This "noise" is unnecessary complexity. Each reduction in complexity will allow you to focus more on the smaller, local scale work. Which again helps limit your exposure to fat tail events.

Your Learning Organization's Ensemble of Projects becomes Anti-Fragile 

These practices (when implemented by competent leadership) create a learning organization that is the heart of being anti-fragile.

Why? Because anti-fragile organizations get better. They learn from each mistake, each problem, each setback, and do better next time. And that's what Learning Organizations built on Lean Principles do.

Any given project, any given moment in the progress of the work, is fragile, open to the unknown possibility of catastrophic failure.

But with Lean, the project ensemble, and the ensemble of projects underway, becomes anti-fragile.

Cadence is for Marching Bands

The big Agile Scaling Methodologies™ make a point of how they establish “cadence” to synchronize teams.

My question is, Why? Why is that something that is good? How does imposing rigidity help improve the work? Improve the knowledge and skills of the teams? And most importantly how does that help provide Value?

It helps lazy executives and busybody PMO’s who never go to the Gemba or care about the work prepare their “status” spreadsheets, but have little use otherwise.

Complex Cognitive Systems

Complex cognitive systems are naturally organic, with patterns and rhythms that are driven by the underlying work they are engaged in.

Communication, through effective visual management (not an electronic system) along with teams interacting with their upstream, downstream and sister teams, is the best way to coordinate work.

Please note the distinction: the underlying work, with its varying cycle times, is the driver for coordination, not an externally imposed drumbeat.

Coordination and any needed synchronization will emerge. It will be based on the individuals on the teams interacting. (I think I’ve heard that somewhere before).

Getting There

For most organizations this will require a change in habit and culture.

Basic steps include:

• Every team has a physical Visual Management System (that they are constantly improving – changing as they learn more about the work and eliminate waste)
• Every team uses real data, such as cycle time, to drive improvements
• Every team uses a scientific method, such as PDCA, to drive daily continuous improvement
• Leadership teams “walk the walk” by doing the same: visual management of their work, fact collection and continuous improvement – this is the key to successfully change the culture
• Teams working on related efforts set up a physical Obeya

The Real Work Begins

Then the real work begins, the work of scientific improvement of the work, elimination of waste, improvement of the culture, enhancing communication, adding habits and practices that support the emergent order and challenge top-down impositions.

This will take time, and most importantly, work, real work by the leadership team.