LEAN Opinions

Kanban: Delta Team Month 2: Learning & Results

2011-07-04T15:02:00.001-04:00

Last month, I blogged about my initial visit to the Delta team who were starting to use the Kanban method. I focused on what they had learned from initially visualizing work flow.

One aspect of the Kanban method is to see, understand and even anticipate problems. We must understand the problem before we can solve the problem. The Kanban board exposes only part of what we must see. There is more to the Kanban method than the Kanban board. Here is a part of my notes that I shared with the team leaders after the initial meeting about the high level problem.

"Delta had been unable to establish a reliable velocity due to a number of issues that still have to be addressed. They have some work to do before they renegotiate their agreement with the business. Delta needs to agree on goals, settle their process to learn their lead time and cadence, then negotiate policies.

I sensed their unarticulated goal was to improve employee satisfaction by removing uncertainty. I suggested another goal is to settle and understand their processes so they can "make promises they can keep... most of the time." Goals need to address all stakeholders: team, customers and the business."

Last week I again observed their daily stand up and listened to what they had done and learned from a few specific suggestions I made.

1. Visualize Work flow: "Walk the board from right to left in daily standups. Focus on finishing cards. This practice promotes pull and flow."

I polled the team at the end of their stand up. Most team members appreciated seeing the work. It made conversations more specific and problems more apparent. One team member did not find value in visualizing the workflow since he could see it in VersionOne. That's fine. We should respect the current process. If it works, keep it.

2. Limit WIP: "Limit the number of features in progress. This seemed the easiest way to begin to limit work in progress."

As it turns out, the organization is approaching the end of a release cycle and no more features were to be started. So I observed only one feature in flight. The team learned that three features could keep the team busy. They learned that one feature was keeping the team busy but are not sure that is sustainable. We will need to learn more.

3. Revisit Visualize Work Flow: "Consider putting your other (significant) work on the board, perhaps in separate swim lanes. This "other" work is one reason they can not achieve reliable promises for lead time and delivery cadence and needs to be made visible and analyzed."

My brief instructions here were not sufficient for Delta team to act so we spent a bit more time. We identified 4 types of work. New dev, defects (outside of current features), urgent, and "other" that included meetings, business projects, etc. We identified stakeholders for each. We discussed demand analysis, figuring how much time historically has been spent on each.

Learnings: Without stable teams and demand, getting to reliable promises will be hard. While the team is fairly stable, the amount of "other" work can become a big demand from time to time (like it will with testers in the next month or so). Demand analysis will reveal the actual variation in demand. Then we can explore options and have conversations with product management.

And defects are difficult to estimate up front. Our current commitment is # of defects. But we don't know the amount of work. So making reliable promises is hard.

Next visit, I will be curious to hear more about how the release process worked. Everyone cringes when the talk about it. Interestingly, Product Management started a Feature Level Kanban board. I could see right away that some teams had a lot of features to finish. Wishing them the best.

Kanban–Visualize Workflow: Learning and Results

2011-05-30T10:27:00.001-04:00

I recently introduced the Kanban method to several people in an established tech company as part of a training class. The leaders of the Delta development team were keen to get started right away. I encouraged them to create a team kanban board to visualize their workflow.

A couple of weeks later, I had an opportunity to observe Delta team's daily stand up meeting and listen to what they had learned. They had their kanban board up with columns and queues, done defined, and current product work on the board.

Learning and Results

Really helps those outside the team see what is going on. This makes visible the effort wasted when work is pulled in flight. This was a big concern for the team who had spent time grooming stories for a feature only to have the feature replaced or stripped down just before engineering. The company lives in a competitive, volatile market space. Product managers strive to ensure their product remains cutting edge. So Delta team and the business need to figure a way to manage productively in this environment. I'm not sure anything has changed yet but at least the team feels better now that they have a way to show the impact. Once they have reduced the lead time, Product Management can wait to prioritize features (makes product management happy) and teams can finish features quickly before priorities change (makes team happy).

Management and internal customers respect the process. This result was actually from the operations group who had created their board after Kanban training they attended several months ago. Prior to the kanban board, the ops team was interrupted frequently for "urgent" work. The kanban board stopped this behavior completely according to the ops manager. Stakeholders could see that people were busy working on important items and had a voice in prioritizing the backlog. Just using a kanban board to visualize the work can have an impact of organizational behavior.

Really helps the team see what is going on. The board makes visible progress and team priorities. The team and business analyst in particular do not feel as desperately rushed when a new feature is introduced at the last moment. It will still be a scramble, but instead of feeling like the whole feature must be groomed, stories are groomed and pulled by engineering. Other stories can be elaborated and groomed while engineering is working on ready stories. Delta is trying daily grooming instead of a rushing to groom the backlog just before sprint planning. This adds flexibility and reduces chaos.

Makes visible the backlog items that are not flowing. Delta team marks cards with dots to show how many days a card stays in each column. They also tag cards that are blocked. Problems and delay is apparent.

It takes just minutes a day to maintain the board.

I made a few suggestion to establish goals and work in progress limits. I'm very interested to visit Delta team again in a couple of weeks to hear what else they have learned.

Kanban: Foundation for Leadership

2011-05-18T09:47:00.001-04:00

I presented this talk last night at the Agile Local Interest Group for PMI Atlanta.

Kanban: Foundation for Leadership

What can project managers do to support and lead Agile adoption?

Get started now – Visualize work flow
Earn the authority to Lead – this is about people
Do what makes Lean sense

Lean-Agile Waste

2011-05-09T10:29:00.000-04:00

Coming from a Lean background, I look for solutions that reduce waste and promote flow. No one likes to think of the work they do as waste. Understandable. Still, we need a way to identify and describe activities that are unnecessary or necessary but not valuable to the customer.

The Agile Manifesto provides some clear guidance on waste. Waste is simply the items on the right of the Manifesto. Solutions are items on the left.

For some, this is an Aha moment when I explain it in my Improve Agile class or at conferences.

We still need to do what makes Lean sense and take a disciplined approach to continuous improvement. When looking for potential causes of problems identified in a retrospective, look to the items on the right as potential causes. Remember, some of these activities are necessary. Then when considering solutions, validate that the solution has a bias for the items on the left.

This thinking promotes a more Agile organization.

PMI Atlanta Agile LIG Kickoff

2011-03-16T14:44:00.001-04:00

Published with Blogger-droid v1.6.7

PMI Atlanta kicked off the Agile Local Interest Group (LIG) last night. Over 70 participants engaged in the kick off to begin to shape what the Agile LIG would become. Dwight Husband and Phyllis St. John, representing PMI Atlanta leadership, opened with some background comments. Special thanks to John at CCCI for sponsoring the meet-up… and the pizza.

Dennis Stevens of Synaptus presented the program. You can follow the presentation deck on Slideshare. He started briefly with the evolution of project management, primarily focusing on software development, that resulted in the traditional, predictive approach. Key points included Taylor's work specialization, Gantt's task management chart and the waterfall method all of which became highly utilized for software project management. Dennis objectively discussed the benefits and some shortcomings of these methods.

Next, he briefly reviewed documented instances where agile ideas, at least what we now think of as Agile, had been used with great success since the 1960's through 2001. Seventeen of these pioneers convened to identify commonalities in their various approaches and differences with a more traditional approach. Their conclusions became the Agile Manifesto. A few years later, agile project management thought leaders met to discuss the project management role in agile projects. Their conclusions became the Declaration of Interdependence.

With the history lesson completed, Dennis moved on to key areas of interest to the group, the recently announced PMI Agile Certification. He spoke with authority as a member of the PMI Agile Community of Practice Steering Committee and involved in developing the Agile Certification. Dennis introduced the six key knowledge areas.

At the end of the presentation, we facilitated a survey to discover what the meeting participants interests were related to Agile. Why would they continue to attend and participate? Here is the raw output. The Agile LIG will review and prioritize the backlog with the intent of serving the PMI and broader Agile community in Atlanta.

Gantthead

2010-10-12T14:45:00.001-04:00

Taming the Agile Enterprise: Value Network Mapping was picked up in Gantt Head. Pretty cool.

Value Network Mapping

2010-09-07T15:38:00.001-04:00

We recently published “Value Network Mapping: Taming the Agile Enterprise” on the Synaptus website. Here is the Mind Map we used to prepare the paper.

Feeding the Agile Beast

2010-08-18T22:57:00.001-04:00

My presentation at the Lean Software and Systems Conference has been released on InfoQ.

http://www.infoq.com/presentations/Feeding-the-Agile-Beast

Summary
Dean Stevens proposes a way of integrating the business value concept into everyday Agile activity in order to achieve a higher value for an enterprise.
Bio
Dean Stevens consults with business executives committed to operational excellence, blending expertise and experience in Operations Management, Lean Principles, Project Management and IT to develop high impact solutions.

Changing Cultures

2010-08-16T08:11:00.001-04:00

Some things change a lot and some things are very consistent.

Leadership characteristics are consistent. “The best leaders were competent, caring and benevolent” concludes Robert Sutton in Good Boss, Bad Boss.

Process management principles are consistent. Deming’s principles are remarkable relevant over time. “Appreciation of the System” and “Knowledge of Variation” continue to guide us to “make value flow” to the customer. These principles are being applied widely including the Agile movement for software development.

Technology changes a lot. “Advancing technologies and their swift adoption are upending traditional business models” according to a recent McKinsey article.

And our business environment changes. It is increasing more complex and changes rapidly. Company cultures are built on processes supported more and more with technology. Technology can be a big driver in changing cultures. Is it hard? Yes. Is it necessary? Again, yes.

Culture is very hard to change. Environment will change culture but probably not fast enough. Strategy is needed to understand the environmental change and develop solutions, including advances in technology, that make a difference in the business.

Re-Think Transactions

2010-08-02T01:00:00.000-04:00

One classic example of Re-Thinking is the customer check-in at the airport. Remember when you had to stand in line for the agent to check you in. It was time consuming for the customer, expensive for the airline, and a bottleneck for the process. That was before self-check-in at kiosks or on-line. Self service check in was a win-win for customers and the airlines.

Self service transactions have become wide spread and can have a significant impact on both customer and employee experience. Done well, self service transactions can be very positive. Done poorly, they can be a disaster.

Re-thinking transactions requires change, much of it beyond technology. Here are a few “how’s” that changed in the case of self-check-in.

New Technology: Technology had to be developed and harnessed.
User Experience: Unlike the code driven menu’s the agents used, the user interface had to be simplified so the typical passenger could execute the transaction. Better KISS.
Exception Handling: While typical transactions could be automated reliably, user errors and more complex requests still required an agent’s help. Better get this right.
Training: Agents had to be trained to train and assist users (passengers). Their job changed a lot.

We use capability heat maps to identify and explain Re-think ideas. Just as importantly, heat-maps guide us to understand and change the how’s.

I’m a Bit-Smith

2010-07-19T21:55:00.000-04:00

I ran across this HBR blog recently “Do Your Knowledge Workers Have a Bit-Smith?”

“To succeed at anything, you need to have the right tools for the job. In today's knowledge-driven world, that means having customized and up-to-date information technology that allows you and your team to improve your performance. This technology needs to be created and maintained by a person who understands both the work content and the tools needed to support the job: a bit-smith.”

When people ask me what I do for a living, I tell them I’m a business consultant. OK? We deliver technology that makes a difference to the business.

Now, I can just tell them I’m a Bit-Smith.

Organizational Complexity

2010-07-03T22:50:00.001-04:00

I had a chance to catch up on some reading this weekend. McKinsey Quarterly published “Putting Organizational Complexity in It’s Place”. It starts, “Despite widespread agreement that organizational complexity creates big problems by making it hard to get things done, few executives have a realistic understanding of how complexity actually affects their own companies.” We help business leaders gain this understanding with our Enterprise Analysis approach that follows the steps proposed in this article.

Survey the Scene. We interview employees about their activities considering business value, performance and risk. Think of risk as something that can get in the way of reaching business value. Complexity is a often a significant risk.

Draw a map of what’s really going on. We map the Value Stream using business capabilities and heat map the capabilities (presented in a soon to be published white paper, Taming the Agile Enterprise: Value Stream Mapping for Knowledge Work).

Reduce – and Redirect – Complexity. We deliver technology that makes a difference to the business. The capability approach helps us consider how technology can support personnel to simplify and improve processes. We often use A3 problem solving and Lean principles to develop and implement solutions including training.

Follow the Terrain

2010-06-27T17:57:00.001-04:00

Peter Bregman recently blogged “Don’t Get Distracted by Your Plan.” It’s about getting lost on a hike. To get un-lost, you must look at the map AND your surroundings. In our Pragmatic Leadership class we teach a similar principle. “When lost in the forest, if the map does not agree with the terrain, in all cases follow the terrain!”

Of course, we are using hiking to explain business leadership. We develop strategic plans but we work the real world. The real world changes. Keep the strategy in mind but be responsive customers, competitors and markets. To accomplish this, your organization must understand how they can support the strategic objectives.

We facilitate Agile Enterprise Analysis that guides organizations to communicate the plan AND make the necessary changes to the business activities.

5S and Software Engineering

2010-04-25T09:00:00.000-04:00

Don Reinertsen’s keynote at the recent Lean Software and Systems Consortium (LSSC) Conference in Atlanta was excellent. One point that stuck with me was that some common Lean tools could be misapplied to product development. No doubt. These same tools are misapplied in other areas: office work, sales, manufacturing.

He mentioned 5S specifically. A Lean consultant facilitates a 5S event. The chief benefit was that all the staplers will be in the right place. This is an extreme example to illustrate a point. I don’t believe the point was that 5S has no place in product development. Instead, 5S can be misapplied.

A big benefit of 5S is as a teaching tool. We can demonstrate Lean thinking by working through the 5S steps in our environment. Find a place where there could be pragmatic benefit in addition to a teachable moment. Identify a capability in the Simple quadrant of the Cynefin framework (I really liked the talks on Cynefin too). For example, I have applied 5S to help organize a client’s SharePoint site. It did not take long and it provided real business benefit.

Alan Chedalawada talked about Standard Work. Standardize is the fourth S. 5S is how you apply it effectively and one way to learn about continuous improvement. Start by standardizing the particular simple capability to provide a baseline of what we do now. Then go through the 5S steps. When you get to Standardize again, you should be able to show some business benefit.

There are places in product development organization that will benefit from 5S. Simple capabilities and some complicated capabilities. There are some that won’t. Complex capabilities. The art and science is to know the difference. Just make sure you provide the learning too if you don’t want to become a punch line.

How Much Analysis is Enough

2010-02-13T14:21:00.001-05:00

Part of the A3 problem solving approach is root cause analysis. When we diagnose why a problem occurs, the most apparent reason may be a symptom. Addressing the symptom will not keep the problem from happening again. So some effort to get to the real cause of the problem is valuable. Maybe not fun, but valuable.

Here are three approaches.

QIO: If the cause and solution are obvious, then just do it. This is a Quick Improvement Opportunity. Be careful though. Is it really the cause or just a symptom? Is the solution really viable? Do the stakeholders agree? This can be the easy way out and will not lead to real change.

Six Sigma: The Six Sigma DMAIC process requires a pretty thorough examination: process analysis, statistical data analysis, validation. This may be necessary for complex problems but too much for most problems and organization.

Basic problem solving. Learn and apply these four skills and you can understand 80% of your problems. These are easy to learn and easy to understand. Understanding is critical to facilitating change.

Basic flow chart
Pareto Analysis
6M’s: Consider the possible sources of problems
5-Why: Ask Why five times

In any case, test your solution. Talk to stakeholders. Experiment. Try it. Pilot it. Check the results.

Storytelling: So how much analysis is enough? Enough to tell the story. Enough to engage stakeholders and facilitate collaboration. Enough to get to a plan for change. Basis problem solving is a good place to start.

Kanban for Continuous Improvement

2010-01-12T07:00:00.000-05:00

Kanban provides four key components to manage one or more work group. These provide a basis for improving flow.

Output. Kanban cards describe the output.
Timing. Velocity describes the rate work is completed.
Sequence. The column header describes how the work moves through the group.
WIP. The amount of work is limited in each column.

As team leaders or business managers, we establish or at least understand each of these. Now we look for performance problems for each of these. Quality issues for output. Velocity is not meeting our expectations. Rework is work not in sequence. Limiting WIP is the lever to find more problems and drive improvement, but only after the first three are under control.

Intentional Change

Sometimes the fix to a problem is obvious. Do it. Sometimes a quick fix only addresses the symptoms. No surprise there. Recurring or more difficult problems can be addressed with just a bit more… structure, discipline, effort. I hate using any of those words. But sometimes a problem needs a bit more attention and intentional collaboration.

Write it down. A couple of sentences for each of these steps. Use it to talk about the problem, gain consensus, and make a plan. Revise it as you get input.

Problem Statement. This is the problem statement you observed above. Use a metric is you have one. What is happening and what should be happening.
Why? Consider how each might contribute: Technology, process, management, or personnel. Then consider why.
Solutions. Consider more than one. Make a list of potential solutions. Sort them into what we can do ourselves and what requires support outside the team (our manger will have to get money or work with other teams). I almost always look first for ways to simplify. Complexity is a killer. Select the one we can get done quickly and works.
Plan. List the steps to our plan. Leave a column for due date and assignment. Make Kanban cards if you like.

A little time spent on the front end will lead to more effective change in the end.

Ideas to Execution

2010-01-03T21:02:00.000-05:00

Or “Problem Solving for Entrepreneurs.”

My current clients own and manage several small and midsized business. They have done well but know they can be more successful. They are entrepreneurs.

“We have good ideas but have problems with execution.” Yeah. Many of my clients do. Entrepreneurs tend to be creative. Execution requires discipline. How do we blend these to get from Ideas to Execution.

The A3 Problem Solving Process

First, we facilitated a couple of strategy sessions with the management team resulting in six focusing objectives to be accomplished in the next 100 days. We documented this on a single page – an A3 document. It is really a story telling template. Now everyone can look at it to see what the management team expects, their thinking, who is responsible, and how it will be measured.

Strategy Deployment with A3’s

Next we helped develop an A3 document for each focusing objective. Very quickly, we had a list of tactical objectives necessary to execute their ideas.

Are they perfect? Probably not but we can adapt as we learn more. Did we always make data driven decisions? No. We still have work to do. We feel good about the direction. And we have much better focus and metrics than we did just a few weeks ago.

Change Starts with Dialog

Why are these so powerful? Collaboration. Dialog. Engagement. We took many of the stakeholders through the problem solving process. They helped develop the story and solutions. When the time comes for them to contribute, they understand their role and why it is necessary.

Execution Requires Accountability

The A3 lists the tactical objectives to accomplish the change. Next to each is a name, due date and reviewer. Once a week, we will meet to talk about progress, address obstacles and coordinate efforts.

Yes it requires commitment, practice and discipline. But they are starting to believe the results will be worth it.

“… plans are useless, but planning is indispensable.” - Dwight D. Eisenhower

Cycle Time Analysis

2009-12-27T12:53:00.001-05:00

Dennis Stevens clarified some Lean metrics for the Kanban/ Agile community in a recent post Lean Times. Why is cycle time important or useful in software development?

Agile practitioners discovered early that cadence is an important metric. Velocity is measured as units produced per iteration.

Cycle Time is also a cadence and, as Dennis and Lean literature define it, is time per unit produced (on average). Roughly the inverse of velocity.

Is this distinction important in software development? Maybe. I'll share some thoughts.

Takt time is an important piece of "Specify Value in the Eyes of the Customer". Cycle time directly relates to Takt time. This relates our pace with what the customer wants. This part of Lean Thinking promotes customer focus.
Cycle time can be figured for each operation across the value stream. At a high level, it can help us design the organization. How many people/teams do we need in each operation. This analysis helps us create Flow.
Cycle time can be figured for each operation inside the "Agile Black Box" (maybe, roughly). This provides another way to "see" bottlenecks. This analysis helps us "Identify and Eliminate Waste" (which improves flow).
Cycle time presents a different mindset and creates a subtle and consistent sense of urgency. Cycle time allows us to track progress more frequently than by iteration. Perhaps we avoid some early gold plating and the end of the iteration rush. This mindset consistently engages employees.

Cycle Time Analysis can help us scale Agile. These points are directed to those charged with managing the larger value stream, not just inside the Agile Black Box.

My conclusion? This is more relevant to stable operations and less applicable to ad-hoc, less mature operations. If we are planning Kanban or already doing Kanban, a little time spent on Cycle Time analysis may help your team and business learn to "see" your operation a little more clearly.

Do what makes Lean sense. Cycle Time analysis is a proven tool. If it makes sense, try it. If it doesn't, then do something else.

Performance Management

2009-12-14T10:00:00.000-05:00

My client is facing a BHAG, a big hairy audacious goal as coined by Jim Collins. They acquired a competitor and have a chance to double revenue in one of their divisions. That’s the good news. Of course, they have to figure out how to deliver. That’s the BHAG.

We help companies use technology to improve performance. In a short time, we developed a capability value stream map. This is a bit different than a traditional value stream map and works well for a services company. You can learn more in “Re-Think: A Business Manifesto to Cutting Costs and Boosting Innovation.”

The result, we identified several critical activities that must be addressed. There are many important things that should be done, but the critical things, both urgent and important, must be done.

What do we do now that we have this information?

Stop doing things that not valuable. It is amazing how much effort is being wasted on things we think we should be doing but don’t add any value.

Focus on improving the urgent things. We can’t fix everything. Fix the most urgent things. Kaizen provides a way make these both more effective and efficient.

Measure these key activities. Keep it simple but relevant. Technology can help. Use the information if you are going to spend time collecting it.

Assign accountability. Set targets for these metrics and assign responsibility. Insist on timely reports and follow up discussions.

We addressed the most urgent capability even as we were developing the value stream map. And we designed a technology solution that accomplishes each of the four points above and that we can implement quickly. But there is much more to be done in a short time.

Don’t Call it Waste

2009-11-29T11:57:00.001-05:00

Waste is a loaded word. If my peers identify my activities as waste, how does that make me feel? There is a real risk of creating a negative culture around Lean implementation when a positive, participative culture is required. Remember when we replace ‘problem” with “opportunity for improvement?” We are doing the same thing with “waste.”

I noticed LEI changed their wording of Lean principles. Step 2. used to be (paraphrased) “Map the value stream and eliminate waste.” Now it reads “Identify all the steps in the value stream for each product family, eliminating whenever possible those steps that do not create value.” They eliminated the word “waste”. Or at least replaced it with “those steps that do not create value.” Waste was a single word to describe “those steps that do not create value” but the word “waste” carries a lot of psychological baggage with it.

Recently, I have been following discussions on Kandev Yahoo Group where some technology thought leaders are using Lean concepts in software development. In a recent discussion, several key members have decided to eliminate a focus on the word “waste.” They make it clear that things like delay, WIP, and defects must be addressed. Suggested mantras include “Focus on Value” and “Promote Flow”.

In my work, I rarely use the work “waste” either. Too negative. Although, in one engagement I blogged about, the informal rallying cry became “Stop doing Stupid Things.” Talk about a loaded word.

But, I always look for waste, even if I don’t use the word. I find the biggest improvements by identifying big waste early in the engagement. I look for excess WIP, delays, and rework on the value stream map. Almost always, there is some big waste that everybody knows about that has never been addressed. Sometimes, the big waste is within the scope of their control to resolve. They just did not know they were empowered to fix it. In other cases, the problem requires change outside of their control and now we have a way to talk about it.

Why not just skip this step? Won’t we find all the waste when we start looking at Flow? Maybe. If the process has only a few activities and we are certain the activities are value added and necessary. Software development may be such a case. But maybe, we get so focused on Flow, we make the work flow through an unnecessary activity. Maybe we loose an opportunity for a early team win by not addressing the big, obvious waste quickly.

There is great opportunity to improve performance by assessing “those steps that do not create value.” Stop doing unnecessary thing. There is also risk in promoting a negative culture through blame and personal judgment by calling it “waste.” So, don’t call it waste, but make sure you look for it.

Thinking Outside the (Agile) Box – 3. Supermarkets

2009-11-09T09:19:00.001-05:00

In Thinking Outside the Agile Box, I concluded that LEAN concepts, starting with a Value Stream Analysis, provide an approach to support Software Development Teams. In the last blog, I addressed how information flow promotes shorter lead times and higher quality at a lower cost. I also noted the need to simplify and control handoffs.

There will be places in your value stream where work does not flow smoothly without waiting. We need a buffer between these activities. In our example, the Backlog is such a buffer. We defined the Backlog as “Inventory of groomed and prioritized features ready for development.”

We also want to control the amount of requirements in the Backlog to promote quality and keep lead times short.

Supermarkets

Lean uses the idea of Supermarkets to control handoffs when flow can not be achieved. 50 years ago, Lean innovators were enamored with the efficiency of American supermarkets and used the idea as a control mechanism. The grocer decided how much shelf space was required, then the farmers simply stocked the shelves in the required space. It was largely self managed with near real time feedback.

Think of tomatoes. You want to have enough to sell but not so much that the produce spoils before it is purchased. Your supplier bring fresh tomatoes twice a week. You need a bin that holds a bit more than what you expect your customers will buy in half a week.

Requirements are also somewhat perishable. In the case of our Backlog, we know the cycle time and we know how often we want to replenish the backlog. And we want to have a bit more to make sure we don’t run out. Since we know the cycle time and we know how often we will plan, we can figure the maximum size of the backlog. Some Agile methods already think this way, at least inside the Agile box, during Sprint planning.

FIFO Lanes

Another way to simplify handoffs are FIFO Lanes (first in first out). This keeps a small amount of work between activities. Let’s think inside the Agile box for a moment. After development but before testing, we may have a FIFO lane where several features wait to be tested in a batch (Kanban boards are an example of FIFO lanes and are gaining recognition in software development). FIFO lanes may also be useful inside our Business Analysis box.

Use Supermarkets when you have to deal with batches of information. Use FIFO lanes downstream of where the work is scheduled . These methods promote self-organization with real time feedback. Now we can schedule in fewer places and at a higher level. These reduce the need for detailed command and control scheduling and promote and promote flow.

Thinking Outside the (Agile) Box – 2. Flow

2009-11-02T08:10:00.002-05:00

In Thinking Outside the (Agile) Box, I concluded that LEAN concepts, starting with a Value Stream Analysis, provide an approach to support Agile Development Teams. In the last blog, I discussed Cycle Time. In the next several blogs, I will introduce other specific concepts.

Information Flow

The concept of flow in is to get from concept to valuable working software without interruption. Think of a single feature in our example from the last post. The people, the documentation, the tools, and everything else are a means produce the feature. The focus is the feature. The Value Stream Map helps us see the feature move from concept, through business analysis (as requirements), through software development (as code), to valuable software (as features).

Ideally, we would like to go from concept, through business analysis, to software development, to the end uses without any waiting. To do this, we have to think “start one, finish one”. Each activity focuses on one feature at a time. In reality, we just want to get better.

Handoffs

One big key to promote flow is to eliminate or simplify handoffs. We accomplish this by having one person or team performing value added work on one feature at a time. Then moving that feature to the next value added activity. LEAN is sometimes described as eliminating waste. Waiting is a form of waste. Eliminating waste, all the non-value added stuff like waiting, is just a means to promote Flow.

But we see one big interruption in our example Outside the Agile Box, the backlog where the requirements wait to be transformed into features. The bigger the backlog, the longer the lead time, the worse the flow.

There is probably a lot of waiting inside each of our boxes as well. Agile actually promotes flow in software development inside the Agile Box. And we need to look inside the other boxes, Business Analysis in our example, as well to promote flow.

Quality and Cost

We have talked about getting features through the system faster by thinking about Flow. Flow also helps improve quality and cost. In our example, we want a feature to get to software development soon after business analysis is completed. These could even overlap. Otherwise, the requirements go stale. Sure they may be documented, but the texture and detail in the minds of the business analysts and customers are lost as time goes on. The result is lower quality of information and more rework (cost). So we want to keep the backlog as small as possible, that is limit the work in process.

Cycle Time and Flow

In the last post I discussed cycle time. Flow is another reason to synchronize cycle time between Business Analysis and Software Development. If Business Analysis is producing too much, the backlog grows and Flow is hindered. Understanding cycle time is critical to improving Flow.

Thinking Outside the (Agile) Box – 1. Cycle Time

2009-10-31T22:11:00.001-04:00

In Thinking Outside the Agile Box, I concluded that LEAN concepts, starting with a Value Stream Analysis, provide an approach to support Software Development Teams. In the next several blogs, I will introduce these specific concepts.

Sample Value Stream Map

Let’s keep this very simple, a high level map with only three elements. Work flows through business analysis, to the backlog, then to software development.

Business Analysis – Develop a groomed and prioritized backlog of features.
Backlog – Inventory of groomed and prioritized features ready for development.
Software Development – Engineer working software ready for deployment.

Your VSM would include more detail and may be defined differently. This is sufficient to discuss how these concepts work.

Cycle Time

Cycle time is a key metric for monitoring and managing the system. Cycle time is the frequency of features delivered to the customer. For example, we plan to deliver a project with 500 features over a three month period. Figure there are roughly 32,000 minutes in three months (3 months x 22 day x 8 hours x 60 minutes). We have 32,000 minutes to complete 500 features so we requires a cycle time of roughly 64 minutes per feature (or story point, or function point depending on the development approach).

Why is this important? Cycle time provides the required cadence to deliver the project. Each performer in all activities knows whether they are working at a pace to be successful. Management knows pretty frequently if something is getting behind and can provide the necessary support. Very simple, very timely, very manageable.

Cycle time also encourages focused effort with the idea of start one, finish one. This promotes quality and discourages bad multitasking. Working on a months worth of features and delivering them all at the end of the month makes the idea of cycle time less useful. The idea is to deliver at a consistent pace.

Challenges

Why? We are Thinking Outside the (Agile) Box. The other activities need to be synchronized with the development teams. Otherwise, they are doing too much or not enough. And that is bad.

Cycle time is not lead time. Lead time is the time it takes for features to get from one point to another. Total lead time is from customer request to delivery. Lead time is duration measured in time. Cycle time is a frequency in time/unit.

Variation. OK. We are not making widgets here where the cycle time is not necessarily going to be consistent. Many agile teams are already using Velocity (feature per iteration) and burn-down charts as a cadence. There is evidence that this cadence is fairly reliable. Notice cycle time is simply the inverse of velocity.

Estimation. Hey, this is all based on unreliable estimates in the first place. Right. And by measuring early and consistently, we have a better and early idea of where we stand relative to the estimated plan.

We don’t know the number of features at the beginning. Then we don’t really have a way to track performance to plan. But we can track to service level agreements. And we can still use cycle time to synchronize activities.

It won’t work here. Maybe. Maybe not. Smart people in complex processes have figured out how to use it beneficially. Why not give it a try. You will learn something, refine it, try it again. PDCA you know. This is pretty easy to try.

Thinking Outside the (Agile) Box

2009-10-28T22:38:00.002-04:00

I attended an IIBA panel discussion last night. One thing that struck me was that the panel members all said their product development was still primarily "traditional" (I thought waterfall). They appreciated the potential of Agile (deliver better, faster and more reliably leading to competitive advantage and delighted customers). They have even had some successes with team agile.

Team agile can lead to significant productivity and quality improvements for the software development team. But the development team is only one element of the entire process. To realize the full benefits, we need to Think Outside the (Agile) Box. Enterprise Agile is needed but seems elusive. Changing thinking is hard.

Business Leaders

Make no mistake. Business leaders must lead the change to gain competitive advantage and delight customers through enterprise agile. While they suspect there is a better way, leading towards those potential benefits is tempered by the risk, ambiguity of the future state and how to get there.

Starting Towards Enterprise Agile

Fortunately, there is a way for to learn more about the benefits, risks and challenges with minimal investment. LEAN concepts help the business understand and simplify the software development process around the Agile Team. Both Agile and Lean concepts and techniques can be applied. One great thing about both methods is experimenting and keeping what works.

Value Stream Analysis

A LEAN Value Stream Analysis, from customer request to customer acceptance, helps the business leaders understand the potential benefits and challenges. Consider it a learning engagement.

The customer or business cares about working software solutions that solve business problems. The solution starts and ends with the customer or business. The Agile Team is one piece of a larger process. The business leader requires a way to see this larger process, the value stream.

Of coarse, there is no agile enterprise without competent agile teams. And teams encounter enterprise impediments. So engaging in Enterprise Agile can help address impediments outside of the team making the whole system better.

The results? Improvement opportunities will be clear. And the potential impact will be significant.

A Lean Approach

A Lean analysis helps business leaders see a way forward that makes sense. An enterprise level value stream map helps the business leader understand the opportunities. A roadmap is developed through analysis and application of Lean concepts. A3 problem solving demands collaboration and coordination to rapidly implement improvements.

Lean and Complex Adaptive Systems

2009-10-21T00:39:00.002-04:00

I read a recent blog, The Dangers of Complex Adaptive Systems, where Alan Shalloway noted “CAS is mostly useful at the team level. I believe there are some dangers at higher levels in most organizations.”

But CAS is just a way to help us understand the system. Both Agile teams and the enterprise, the organizations that manage software development at higher levels, are complex adaptive systems. Agile methods have helped at the team level. Lean concepts provide an approach to manage the enterprise.

First a couple of relevant quotes from Edwards Deming: “A system is a network of interdependent components that work together to accomplish the aim of the system.” “A system must be managed. It will not manage itself.”

CAS has several key attributes including system behavior (process), self-organization (talent), feedback loops, and external influences. Lean thinking addresses each of these.

System Behavior – A business level Value Stream Maps help us to “see” the network of processes. I have heard, “The software business is not production.” But I have used it effectively in several cases. We used a capability value stream model in other engagements that worked out quite well. Lean provides a way to appreciate the system.

Self-organization – Lean helps us understand how to accomplish the aim of the system. Simplify it (reduce complexity) through waste elimination, strive toward flow and use pull. Attack each with the A3 problem solving process. A3 Problem Solving demands dialogue that leads to self-organization. This is a people focused activity that leads to improvement in the value stream.

Feedback Loops – This is continuous improvement. Feedback can be reinforcing or resisting (balancing). Look, observe, listen. It has to be done intentionally. Mis-understanding the feedback can lead to bad decisions. Value stream mapping and A3 problem solving can help clarify the feedback.

External Influences – While there are many forms of external influences, leadership is the key influence. Leadership may be internal to the organization but it is often outside of the value stream. Leadership establishes the aim of the system through a focus on customer value.

I do agree with Alan’s conclusions. Leadership is needed. Agile is great for teams but team agility is not a very big problem to solve anymore. The enterprise level is much more complex and Agile may not be sufficient.

Lean concepts provide an approach to manage the CAS at higher levels in software organizations.

Standard Work in Agile Development

2009-10-15T19:57:00.002-04:00

Agile approaches are a great example of standardized work in practice. What?!? John Shook addresses serious misunderstandings in Five Missing Pieces in Your Standardized Work. I will discuss how several of these are addressed in Agile.

http://www.lean.org/shook/2009/10/five-missing-pieces-in-your.html

Don't Confuse Standardized Work with Work Standards

Management must "first, clarify your work standards" by providing these four basic elements. Then, allow the team to self organize and develop their team standardized work.

Work Standard 1: Timing. Takt time is simply the available time divided by units of customer demand. For example, we have agreed to deliver 500 features in 3 months which gives a takt time of roughly 62 minutes. So our average cycle time should be less than 62 minutes. In other words, we should complete a feature every 62 minutes. While this is an elegantly simple team management metric, knowledge work is more complex (units of customer demand vary significantly in complexity and uncertainty) and requires a different approach.

The purpose here is to understand what the customer wants in terms of timing . Agile does this very well, just a little differently. Agile effectively establishes a takt time for each unit of customer demand. For example, over the next sprint, which tasks will we complete? And Agile methods use buffered project plans and/or burndown charts to connect customer demand to actual performance at a high level.

Work Standard 2: Sequencing. Determine the sequence of producing the work. What approach will be used? What tools are required? For example, to unit test or not to unit test? The essential sequence is pretty clear but management needs to be clear.

Work Standard 3: Standard Work in Process. Establish the standard amount of work in process. Agile methods understand the impact of work in process on agility. This must be managed throughout the organization, however, to support flow through the entire value stream.

Work Standard 4: Required Output. Define the customer requirements. Agile does this very well through frequent conversations and feedback. Management must support methods of business analysis and customer collaboration to deliver what the customer wants.

Don't Confuse Standardization with Commonization

Standardization provides a foundation for improvement. But different teams may do the same work differently. Is this standardized work? Sure. Work is standardized for each team and that is OK according to Shook. Commonization is finding the One Best Way and enforcing compliance on all teams. Shook suggests this is a sure way to stifle creativity.

Don't Try to Impose Standardized Work Without Also Providing a Structured Improvement Process

Agile promotes self-organization to achieve high performance. Teams will develop a standard way of working together. This provides a foundation for improvement through retrospectives, inspect and adapt, PDCA, etc. This is all great stuff. Software engineers are smart and will achieve improvement through self organization. Improvement will be faster and more effective when approached in a disciplined way.

I found it interesting that Agile methods have many of these elements of standardized work baked in. I look forward to his next blogs in which Shook promises to address standardized work in knowledge and creative work.

IT Alignment: Target Business Processes

2009-10-12T20:31:00.002-04:00

IT alignment is important, but how can we get better… or get started? These recent insights on CIO.com, Make IT Business Alignment a Reality, provide some thoughts. I have a success story related to the following statement.

Target Business Processes

“My underlying theme when talking about alignment to anyone in the company is the opportunity to gain greater value from current or planned IT investments. We can’t do that alone; the bulk of that value comes from improved business processes. So I have the dual goals of selling the business on the idea of letting IT lead process reviews and instilling a business-focused attitude in my team. Neither can be achieved overnight.” Roman Coba, CIO, McCain Foods.

First, a little background. My client is a $4 billion sales, marketing, and distribution company with a complex technology infrastructure. The client CTO sponsored our engagement to improve the business IT alignment. This was an Enterprise Business Analysis engagement AND we used a lot of LEAN Thinking.

Value Comes From Business Processes

We mapped several high level value streams and identified the specific business processes most in need of technology attention. A side note, none of these areas were in production or distribution. The key here was to engage the entire organization and agree on what was most urgent, and as importantly, what did not need to be addressed immediately.

Next we took a deeper look into the specific process that needed more attention. We used a few LEAN tools including value stream mapping, 5 why, and fishbone diagrams but we intentionally kept it simple. We used just enough to inspire dialog and learning. And we always had a few business analysts on the team. The key here was to help the business through the root-cause analysis with an approach they could understand.

Pretty quickly, we had business and technology people supporting a common understanding of the problem. The solutions sessions went pretty smoothly. We felt like we could make improvements that could make a difference to the business.

Results

The business developed a better understanding of their processes and recognized the need for them to streamline their process prior to automating it.
In more than one case, the existing technology solutions were sufficient. The business required additional training.
In another case, the business withdrew 19 of 22 technology requests. They realized only three would add value quickly.
Since the business was fully engaged, these decisions seemed reasonable instead of like excuses.

In the cases where the team decided technology improvements were required, we had a lot of information to define the business case and functional requirements.

Using a LEAN approach to facilitate business analysis is a great way to improve IT alignment.

Business Analysts: A Key to Companies' Success - CIO.com - Business Technology Leadership

2009-10-12T13:59:00.001-04:00

Business Analysts: A Key to Companies' Success - CIO.com - Business Technology Leadership

Posted using ShareThis

Bringing Lean to Software Development

2009-10-06T09:38:00.002-04:00

I re-read Poppendieck's essay, The Challenges of Bringing Lean to Software Development. You have to understand the business and customer first. Re-Think helps technology folks better understand the business and customer.

If we look at the Internet through Licklider’s eyes, we see the real purpose of software – it does the routine thinking for us so that we can turn our minds to more complex problems. If we look at the evolution of the Internet, we see what developing software is really all about. At its core, software development is the process of gradually finding ways to turn over more and more of what we know to computers so that we have more space left in our minds to discover ever more interesting things.

Stop Doing Stupid Things

2009-10-05T12:52:00.003-04:00

Stupid is a loaded word. I hesitate to use it but, what the hell, it is part of a good story. Early in my consulting career, I worked with a manufacturing company. During my introduction to thirty or so welders, one of the more talented and experienced in the group, shouted, "We just do stupid things." I love that kind of honesty.

First, I need to say that businesses usually do not do stupid things on purpose. A definition of stupid is "Given to unintelligent decisions or acts." Individuals and businesses are not stupid and do not carry out "unintelligent actions" on purpose. Sometimes they make "unintelligent decisions" that lead to "unintelligent actions". I help them see these "unintelligent decisions".

The LEAN Approach

Immediately after the introduction, I gathered the plant manager, the area supervisor, and several of the welders including the vocal one. I told them I wanted to understand the "unintelligent action" he was talking about and make and intelligent decision to do it better. The plant manager nodded his approval. While he was skeptical that some guy off the street (me) could show him how to run his business better, he restated his commitment to learn to do the work better. Good. Identify value. And we established management commitment.

I asked the vocal one to explain the specific "unintelligent action" he mentioned previously. As the group described the process, I drew it out on a flipchart. In a short time, we agreed with the process. I re-drew the process as a value stream map. Then I asked some clarifying questions to get estimates on wait time and wasted effort. Now we all had a common understanding of the process and managed to see the problem. Good. Map the value stream. Identify the waste.

Next, I talked a little about how to make the product flow. Now, they could see the current flow was haphazard and disruptive. They knew it before, but now the could see it. We listed several options to improve the flow and selected a couple of things we could do immediately. We made a list of tasks to make it happen. Good. We had a plan improved flow and eliminate waste.

Finally, I asked the group the most meaningful question. "Is there any reason you can not do this by yourself, without permission from management, without spending money, or without help from other areas." They all agreed that could make it happen. Their supervisor, with a wry smile, agreed that there was no reason to keep doing things the old way, the "unintelligent actions", now that they had made an "intelligent decision". Good. They recognized their empowerment.

Results

This all took less than 45 minutes. They had three big pieces of paper to show others to implement the changes. Admittedly, this was only one small change to streamline the business. It required very little management attention. The actual improvement was relatively small. The biggest benefits were learning to see the "unintelligent actions" and feeling empowered to stop doing stupid things.

I worked with this company for almost a year on their Lean journey. Much of my work focused on management and information flow using their ERP system. I used the same Lean approach to help them see and resolve their "unintelligent actions".

Information Management

Many Lean engagements start on the shop floor where we look for product flow. If we leave it there, we are missing much of the benefit. I have found that the Lean approach yields great results in other areas of the business, including information management, by focusing on information flow.

How great could we be if we learn to see the "unintelligent actions" and learn to make more "intelligent decisions" when applying information technology to solve business problems?

Leading to Commitment

2009-09-30T11:00:00.005-04:00

This is the final post on LEAN and the Tyranny of the OR. LEAN challenges us to focus on "Continuous Improvement and Learning." Obviously, we must also focus on the pragmatic practice to "Get today's work done." Jim Collins tells us in Built to Last that great companies figure out how to do both to overcome the Tyranny of the OR.

Get Today's Work Done

Most jobs require nearly all of a persons time and more. When do we possibly have time to work on continuous improvement? Right. Think back when you started your job. I'll bet you are doing some things more efficiently now. You are more productive and probably deliver higher quality work. Well, that is improvement. You were motivated to invested time to get better. The company (hopefully) supported you in your learning.

Why do we stop? First, I think people get good enough to meet expectations. It is the difference between compliance and commitment.

Second, they don't know what to do next or how to do it. This requires a different kind of leadership.

Commitment and Compliance

Compliance reflects the following attitudes. They understand the benefits. They will comply with the letter of the law. Compliance could be as little as doing enough to keep their job. Most successful companies achieve a culture of compliance. They will get the pragmatic things done. Compliance is when we put in our time, meet the budget, performance metrics, goals and objectives, and get along with our boss and peers. In sports, settling for compliance is why talented teams underachieve.

Commitment reflects a more determined attitude. They want it. They will make it happen. They will create whatever structure are needed. Individuals, much less groups, can not achieve commitment without knowing what they want and how to get there. Commitment is an attitude and can not be commanded. Commitment requires leadership.

Leading to Commitment

If managers look at their work as leading to commitment instead of leading to compliance, they might actually achieve it. LEAN principles provide an elegantly simple approach.

Use problem solving to bridge what actually is to what can be in each of the first three principles. In LEAN, the A3 problem solving method helps you lead people through the thinking and learning process. Respect people and peers by involving all stakeholders in the proposed solutions and implementation plans.

Understand the actual philosophy in the group. Employees and many mangers are often skeptical with the written philosophy statements. What does your group actually believe? In the Background section of the A3, make sure you consider long term philosophy as well as the pragmatic results. It is your opportunity to teach the company's philosophy.

Understand your actual processes. Understand the value stream. Teach and learn using processes. It leads to much more focused conversations and effort. It is not about what the manager wants or who is to blame, it is about making the group better. A3 uses process maps to guide conversations through the root cause analysis. Use data that the majority of people can understand.

Understand and respect your people. Give them what they need in terms of standard work methods, training and tools. More importantly, challenge them to solve their problems. An A3 assignment is a sign of respect.

Managing just the pragmatic practices to hit the quarterly numbers, reward results, encourage competition, and get today's work done leads to compliance and average results.

Leading to Commitment engages your people to produce superior results.

LEAN and the Tyranny of the OR - People

2009-09-21T15:33:00.003-04:00

This is part four of LEAN and the Tyranny of the OR. How do we focus both on the principle to "Respect People and Foster Teamwork" AND the pragmatic practice to "Encourage Competition". Actually, this happens all the time in sports. But I want to provide a few thoughts on the matter.

Encourage Competition

I believe competition can bring out the best in each of us. We must strive for personal excellence and put forth a strong effort to succeed. I expect my teammates, employees, leaders and partners to behave in this way. Competition, within the rules, exposes character and competence.

Competition is also a great motivator. The reality is that we compete for all kinds of worthwhile things. Football players compete for a position in the starting lineup. Mangers compete for a promotion. Graduates compete for the top jobs in their profession. And businesses compete for customers. Competition is here to stay.

Destructive competition, however, can not be tolerated. I'm not just talking about knee capping your Olympic skating competition (and teammate). Destructive competition is actions outside of the rules and can also be hard to see. Unfortunately destructive competition is sometimes acceptable, and even rewarded, in a corporate culture. Actions contrary to the principle of "Respect People and Foster Teamwork" are destructive competition.

This is a big topic. It is about relationships and leadership. I want to talk about a key skill, dialog, and how it contributes to this principle.

Dialog, then Decisions

Simply put, dialog is "listening with the intent to understand" (The 7 Habit of Highly Successful People, Covey).

Here is a more detailed description. "In dialog, there is a free and creative exploration of complex and subtle issues, a deep listening to one another and suspending one's own view. By contrast, in discussions, different views are presented and defended and there is a search for the best view to support decisions…" (The Fifth Discipline, Senge).

Senge suggests several conditions to support dialog.

Suspend assumptions (learn to recognize your assumptions)
Regard one another as colleagues (no title in the room)
Use a facilitator (inquiry is good but defensiveness indicates discussion)
Practice on easy issues

It is important to note that there is a time for dialog and a time for discussion and decisions. It is necessary to know which one you are practicing.

Respect for People

Why bother with Respect for People and Foster Teamwork? Unleashing the mind power of the entire organization will help your organization perform at a higher level. Harnessing your suppliers capabilities and support is also essential. Dialog and respect are a great way to do this. It may not happen at all without it.

This is not soft stuff. We respect people for their ability and commitment to perform. We show respect by engaging in meaningful dialog. We can respect a different point of view even if we don't agree with it. We might even learn something.

Dialog is essential to respect and learning. Start with individuals. Then engage your teams. If you are brave, engage your peers. Engage with business leaders when given the opportunity. Tie it together with the other Toyota Way principles. A focus on the process (LEAN Value Stream or Re-Think Heat Map) is a great place to identify issues and initiate dialog. Use dialog to promote long term philosophy.

Back to reality? Dialog requires trust. Destructive competition violates this trust. Corporate culture often rewards destructive competition. So it is not easy. It requires true leadership. Anything else will be seen as insincere.

Leaders have an obligation to engage and promote dialog. People need to understand the expectation on them. They must understand how they are performing relative to those expectations. This is respect. Same with teams. Same with suppliers. They need to understand expectations and their performance. And managers must understand how to support them. Dialog is necessary to growth, learning and high performance.

Line of Sight & Clarity to Strategy

2009-09-16T17:55:00.001-04:00

I'm re-reading The Fifth Discipline by Peter Senge. It is both fascinating and challenging. The big question I had the first time I read it was "Great! But how does this help strategy translate into action?"

The tagline for our company was "Bridging Strategy and Execution." We led engagements to identify, develop and deliver strategically relevant projects. The Fifth Discipline was a big influence while developing the approach and leading engagements.

What we sold was high-impact technology and process improvement projects. And we delivered. Many clients also recognized the soft benefits of organizational learning. One VP even said that the greatest benefit was that his people were talking about the business now instead of finger pointing.

So we could do it. But I always had a hard time explaining it.

Assimilate

Here are a couple of excerpts from a paper I wrote trying to explain the benefits of a capability modeling engagement.

Phase 1:

Strategic Articulation workshops help executives frame strategic intent more clearly and provide executive guidance to performers as they develop and execute strategic projects.

Phase 2:

Capability Model workshops require performers to assimilate the strategic intent as they consider each key activity. Since many activities are cross-functional, effective assimilation requires performers to identify and resolve conflicting tactical objectives, priorities and roles. This provides tremendous organizational learning, understanding and alignment.

Phase 3:

Establish cross functional teams to identify and develop the focused projects necessary to gain and sustain performance improvements.

Line of Sight, Line of Clarity

And here is an excerpt from The Fifth Discipline.

"In 2003, [the business unit] designed 'line of sight' meetings, bringing different organizations together to talk about how these issues were linked to their day-to-day businesses and activities. Then came 'clarity of sight,' a series of small group sessions involving fifteen to twenty-five participants."

"A 2004 survey showed that the people in [the] business unit were well ahead of others in their understanding of the corporate strategy and how it related to their work."

I know that we could only identify and develop high-impact projects after were had gained "Clarity of Sight" with the strategy. I just did not know how to explain it.

LEAN and the Tyranny of the OR - Process

2009-09-14T18:00:00.000-04:00

This is part three of LEAN and the Tyranny of the OR. How do we follow both the principle to "Focus on Processes to Produce Results" AND the pragmatic practice to "Reward Results".

Reward Results

Traditional management provides guidance and controls through financial targets, goals and objectives and performance metrics. Managers are rewarded for hitting these numbers. This is typical management by objective. This concept was expanded with the balanced scorecard approach to include financials, operations, customer and learning. The best companies were doing more.

Focus on Processes

Process improvement initiatives have produced mixed results - TQM, LEAN Thinking, Six Sigma, LEAN Sigma. Some companies have embraced process improvement and demonstrated extraordinary business results. Even the companies that tried and abandoned this focus probably demonstrated some significant instances of success.

But these local successes did not translate to overall business success and probably likely lead to more damage than improvement. Why? We focus on the wrong processes and use the wrong approach.

The Problem - Focus on the Wrong Processes

Focus on all of the process. There are simply not enough resources to do everything all at once. A key management responsibility is to allocate resources. You have to prioritize.

Focus on the process we know. For example, if we know production, we focus on production even if the problem is in sales. This is human nature. And reinforced by the organizational structure.

Focus on the symptom. If sales are down (symptom) due to production issues (real problem), trying to sell more will not help. Real problems are often harder to see.

Another Problem - Use the Wrong Approach

Use the tools we know. If I am a carpenter, I'm going to use a hammer. I may just need a bigger hammer. We had better get the right people in the room. In one case, my client pre-supposed a grand IT solution but found that a little process improvement and training delighted the customer.

Don’t finish the fix. Working around a broken process can help temporarily but doesn’t really fix the business process. Once things appear to get better, we loose focus and the problem reoccurs. This process discipline is really hard.

Big Effort Solutions. Large scale initiatives take a long time to show results. Many smaller solutions usually consistently deliver results. Besides, big solutions rarely deliver the expected ROI.

A Proposal - Focus on the Right Processes

In my previous post, I mentioned that a Re-Think engagement tee's up the approach to achieve this AND. A key deliverable is the Heat Map that defines a companies activities, the business value of each activity, and how we are performing. The real result is a greater understanding of the business based on core principles and strategy.

Management can use the Heat Map as a focusing tool to identify the critical few process that require attention. It will not be all of the processes. It may be the processes we don’t know very well. We can now look beyond the symptoms.

Only now are we ready to develop solutions. Look at the problem closely - use a variety of views and with the right people in the room (I prefer a LEAN approach). Finish implementation; not always exciting but important to change habits (Project Management). Avoid big effort solutions - often a small change at the right place can yield big results (Theory of Constraints).

LEAN and the Tyranny of the OR - Philosophy

2009-09-09T09:59:00.003-04:00

I started talking about LEAN and the Tyranny of the OR last week. I invited discussion around the question "Why is it hard to consistently base decisions on long term philosophy?"

The Problem

My initial observation was the demand to "Hit the quarterly numbers."

I received some good, thoughtful input to describe the challenge. Here are a few select quotes.

"If you don’t make the quarter, you won't be at the Christmas party."

"The long-term may be important, but the short-term is always urgent and only sometimes important (Covey reference)."

"In the long run, everyone is dead."

"Risk. Greed."

Looks like strong motivators of Fear and Greed. I don't expect these to go away. In fact, focusing on short-term results is critically important.

Managers already feel tremendous focus on the short term results. They do not feel that same focus on the long term philosophy. Management is sending the OR message.

So how do we overcome the Tyranny of the OR? How do we get everyone to "Base decisions on long term philosophy" AND "Hit the quarterly numbers."

A Proposal

Help managers consider long term philosophy and strategy in terms of WHAT they do routinely. In effect, help them learn and focus on the WHY behind their daily WHAT and they can realize the "Genius of the AND".

This is a powerful part of a Re-Think engagement. (I introduce Re-think in my post on Re-Think Organizational Learning) It is pragmatic. It does not take a lot of time. It is effective. This is the first step to get your organization STOP fixing the 80% that is working and focus on the 20% that will make a difference.

AND, it tee's up the approach to achieve the AND for the next three LEAN management principles:

Focus on Processes to Produce Results AND Reward Results
Respect People and Foster Teamwork AND Encourage Competition
Continuously Improve and Learn AND Get Today's Work Done

LEAN and the “Tyranny of the OR”

2009-09-02T15:41:00.003-04:00

I’ve been answering some questions in LinkedIn lately. I read one this morning that made me think. “What approach can you use to drive quality and excellence into the business (paraphrased)?” The LEAN approach naturally. But I had a hard time explaining why. LEAN concepts sometimes seem paradoxical to the real world of business. So I thought I would start to work through it here.

I started with The Toyota Way by Jeffery Liker. Liker is a leading authority on what makes LEAN work. He describes four major categories of management principles in his 4P model (Philosophy; Process; People and Partners; Problem Solving) and provides in depth explanation and examples of successful LEAN enterprises.

Next, I reflected on some of the challenges organizations have embracing these principles. In other words, when we are under pressure and have to make a decision, what paradoxical objectives cause us to abandon these principles? Obviously, there are many influences and many different situations depending on the organization. But I hope these are reasonable.

This is what I came up with.

Principles		Objectives
Philosophy
Base decisions on a long term philosophy	OR	Hit the quarterly numbers
Process
Focus on processes to produce results	OR	Reward results
People & Partners
Respect people and foster teamwork	OR	Encourage competition
Problem Solving
Continuously improve and learn	OR	Get today’s work done

Then I considered the “Tyranny of the OR” presented by Jim Collins in Built to Last. Collins describes it as “the rational view that cannot easily accept paradox, that cannot live with two seemingly contradictory forces at the same time. The ‘Tyranny of the OR’ pushes people to believe that things must be either A OR B, but not both.”

The challenge is to figure out how to do both. “Highly visionary companies liberate themselves with the ‘Genius of the AND’ – the ability to embrace both extremes or a number of dimensions at the same time.” And it’s not a balancing act. In your business, how will you do both.

There are a lot of obstacles to achieving the “Genius of the AND”. It requires commitment. It requires hard work. It requires us to address fear and greed, both individually and in the organization. It requires us to learn and experiment. It requires us to change. And change is hard.

At least LEAN concepts can provide guidance to those brave organizations committed to operational excellence.

Talent: Necessary but Not Sufficient

2009-09-01T11:04:00.004-04:00

As a business process consultant, I frequently encounter resistance in talent driven areas. Think sales, software development, management or basketball. Talented high performers often find process and systems restrictive. Not all, but some. And because they are talented and smart, they often make a good case for resisting. The reasoning is generally expressed as “I perform at a high level and your system will only hurt my performance.”

Talent matters in basketball more than some other sports. A system is also necessary to guide teamwork. How do they work together? Let’s look at a couple of examples.

In the late 1980’s, Michael Jordon routinely led the NBA in scoring averaging 34.6 points per game but won no championships. Coach Phil Jackson put in a system, his triangle offence, and in the 90’s Jordan scored less averaging 30.5 points per game and won 6 championships. His personal performance was restricted and team performance improved.

In 1996, Princeton beat the defending NCAA basketball champions UCLA. UCLA certainly had more talent since Princeton did not even offer athletic scholarships. Coach Pete Carril employed what became known as the Princeton System and could compete with more athletically talented teams. Princeton also won 13 Ivy League titles during Coach Carril’s tenure showing that they could outperform teams with similar talent. The system matters.

I once heard an observation that the only person who could limit Michael Jordan’s scoring was Dean Smith, his college coach. Smith is considered one of the great college coaches of all time and coached great talent across four decades. He employed a system that, while arguably limiting some of his player’s personal performance, consistently delivered very high team performance. He provided the leadership to get some of the great college talent to play within his proven system.

What can we learn in business from these examples of talent and system? Individual personal performance does not necessarily lead to team success. Systems matter. Leadership matters.

Re-Think Organizational Learning – The Unexpected Result

2009-08-14T14:45:00.002-04:00

Ric Merrifield recently published Re-Think: A Business Manifesto for Cutting Costs and Innovation that introduces new ways to “see” the business and overcome the “How Trap”. What? Read the book. Ric does a good job of walking you through it in a non-technical way.

Unexpected Results. I was fortunate to work with Dennis Stevens, an early collaborator with Ric on this approach, on a major engagement using the Re-Think approach. Sure, we improved efficiency and customer satisfaction, but the company recognized something more, something not expected.

“It has also helped make the approach basic enough to be understood and applied by employees at every level of the company.” You will find this little tid bit buried in the introduction. Wow. Imagine everyone, from executives to performers to administrators, seeing the business essentially the same way. What is most important, what needs to be done better, what needs to be done more efficiently? Then, how can I help? Here are a few comments to illustrate the benefit.

“We don’t need to work on that.” A line manager and IT manager were discussing a list of 22 IT requests. After Re-Thinking his area, they agreed that only three of these requests would really help his department’s performance. And these were not the three at the top of his list before the Re-Think. Focus and prioritization is a great benefit. Imagine how much money, time and wasted effort could be saved with this understanding and clarity of purpose across the organization. What if everyone could work on the three important things and not waste time on the 19 much less important things?

“We agree, these are the top three areas to focus on.” The executives agreed with the results of the initial high-level Re-Think. The mandate was to “Improve Customer Satisfaction”. The expectation was to do something different, not just work harder at the same things. Where do you start to implement a vague strategy like this? This initial high level Re-Think involved directors, senior managers and customers who came to a focused consensus on these three areas. This foundation ensured that the few managers responsible for these areas could count on support from the others.

“These are great requirements.” One IT manager appreciated the clear, focused business requirements. Following the high-level Re-Think, a more detailed Re-Think was performed in the specific areas. A major benefit of Re-Thinking activities in terms of purpose and outcome are the ability to communicate with the technology group. They have to think in these terms. Additionally, the Heat Maps provide a visual tool to facilitate conversations, see how activities connect, and reveal opportunities to apply new technologies.

“We are talking more about improving the business and less about blame.” The sponsoring executive mentioned this unexpected result of the Re-Think engagement. Re-Thinking clarifies what we are doing in terms of purpose so conversations don’t get bogged down in misunderstandings. After a Re-Think, we have a greater foundation of understanding and we can talk about more important things. A business manager can talk to an IT analyst in terms of what we want to do without either having to be technical experts in each other’s area. Same with managers in different areas. And since they agree what activities are most valuable and in need of attention, and they see how the different activities work together, they can focus on performance.

Re-Thinking helped everyone learn about their business and how their work contributed to the bigger picture. With that understanding, they can do their jobs better.

LEAN is More Than Cost Cutting

2009-08-10T17:08:00.002-04:00

I read a recent article in the Wall Street Journal recently, Latest Starbucks Buzzword: “Lean” Japanese Techniques.

Why did Starbucks start on a Lean initiative? Cost cutting! Sales down, profits down, growth down. Cost control was necessary. This is a business after all. Lean provides proven techniques to significantly improve efficiency and reduce costs. The article describes some of the efficiency improvements. And “Cost cutting helped Starbucks produce better than expected profits.” Success!

The article focuses on streamlining processes and the financial results. Which is great. It is what most executives see on financial statements. LEAN is more than cost cutting. There were other benefits as well – perhaps even more important benefits because they will drive long lasting results. If you read the article carefully, you will see them. I’ll point out a few that interested me.

“Motion and work are two different things.” I like that phrase from the article. Many of the techniques, like the spaghetti chart, help people see the wasted motion. That’s important. To see the waste. Not just the managers but the performers. Engaging the performers and teaching them to be problem solvers helps develop exceptional people. Improving productivity one time today is good. Teaching people to improve a little bit day after day is the real lesson.

“Now, baristas … grind beans for each batch.” Wouldn’t it be better to grind it all at once at the beginning of the day, or week Or buy it already ground? Not if your value proposition is high quality coffee and ambiance. Grind it fresh. Let your customers smell the coffee aroma, hear the grinding, taste the freshest coffee. Besides, it costs less. This also illustrates one of the counter-intuitive aspects of Lean. Bigger batches mean more waste and higher cost, not efficiency. Baristas have to grind, pack, store, then find the coffee if they do it each morning. This is wasted motion that Lean eliminates. So Starbucks gets some productivity benefit. They also get happier customers which is more important.

Customer satisfaction scores increased significantly, at least at one of the stores in the article. I expect it will increase at many others too. If you are not spending time on wasted motion, you have more time for your customers. And they get their coffee faster and fresher. If you can do it faster and better, customer satisfaction follows. And you get the benefit of lower costs and productivity.

Cost cutting and productivity are great benefits of LEAN. They are the sizzle that sells. You can delight your customers and employees as well as the accountants. This soft stuff, the people stuff, is what makes LEAN truly LEAN.