By Ade Asefeso MCIPS MBA

Copyright 2014 by Ade Asefeso MCIPS MBA

All rights reserved.

Second Edition

ISBN-13: 978-1499774788

ISBN-10: 1499774788

Publisher: AA Global Sourcing Ltd

Website: http://www.aaglobalsourcing.com

Disclaimer

This publication is designed to provide competent and reliable information regarding the subject matter covered. However, it is sold with the understanding that the author and publisher are not engaged in rendering professional advice. The authors and publishers specifically disclaim any liability that is incurred from the use or application of contents of this book.

If you purchased this book without a cover you should be aware that this book may have been stolen property and reported as “unsold and destroyed” to the publisher. In this case neither the author nor the publisher has received any payment for this “stripped book.”

Dedication

To my family and friends who seems to have been sent here to teach me something about who I am supposed to be. They have nurtured me, challenged me, and even opposed me…. But at every juncture has taught me!

This book is dedicated to my lovely boys, Thomas, Michael and Karl. Teaching them to manage their finance will give them the lives they deserve. They have taught me more about life, presence, and energy management than anything I have done in my life.

Chapter 1: Introduction

Agile was originally developed within the software industry and Lean was originally developed within the manufacturing industry. Given their diverse roots, they are not as different from one another as you might expect. In fact, if you peel back the layers of industry specific terms and perceptions, the two approaches are conceptually identical.

Agile and Lean both

Maximize value and minimize waste

Manage time as an asset

Establish a culture of continuous improvement

Enable safe failures

Increase predictability

Proactively adapt to change

Strive to achieve measureable results early and often

Traditionally, the difference between the two is that Agile focuses more on enhancing project management, whereas Lean focuses more on enhancing process improvement. However, in an era of almost continuous change the differences between project and process management are blurring.

Given project/process management convergence, rather than choosing between Agile or Lean, the opportunity is to pick the best of both. With the two approaches being conceptually identical, it is relatively easy to merge them to realize their combined strengths.

Agile’s strength is in managing the processes of how teams create customer value. Agile’s lightweight approach to self-organizing teams helps create flexible work cells that require less management overhead, have fewer handoffs, are less specialized, are more modular, and produce a greater diversity of products/services.

Lean’s strength is in managing the processes of how individuals create customer value. Lean’s focus on continuous flow helps to define the next most important thing to be done by each person in a process and provides techniques to ensure the maximum value is created from separate but interdependent resources.

Together Agile and Lean techniques can be applied to manage work environments with a continuously shifting mix of individuals and self-organizing teams.

Agile Lean organisation can

Operationalize both the execution and enhancement of a process as one management activity; and

Leverage the best use of individual specialization for explicit linear tasks, and diverse teams for indeterminate non-linear tasks.

Chapter 2: Applying Agile and Lean to Complex Business Projects

Find a problem, find a solution. Find a problem, find a solution. This is the problem/solution hymn. One that is widely followed. Yet for every problem solved it seems like two more appear. Is this progress? Or does this hymn create an endless problem solving treadmill from which there is no escape?

In our information intensive, reactionary work environment it appears that problem solving and fire fighting are becoming the job descriptions of more and more people. Within the age of the sound bite there is no time to analyze the root cause of problems. There is only time to stamp out each problem as quickly as possible, knowing full well that the next problem will arrive all too soon.

Lean suggests there is another way. An alternative to the problem/solution hymn is the value hymn. Instead of “find a problem, find a solution,” the value hymn is simply “increase customer value.”

Imagine that someone followed the problem/solution hymn for 30 days. What would they have at the end of that time? More problems! However, if they followed the value hymn for 30 days what would they have? More customer value! Which path would you rather take?

In either scenario after the end of 30 days there may be fewer “problems.” But “increasing customer value” provides a worthy goal. It leads an organization to identify both the highest priority problem/solutions, as well as the product/service enhancements, that maximize customer value.

Conversations about increasing customer value also tend to be less defensive that those about problems. Asking “How can I help you to increase customer value” can be a lot less threatening that asking “How can I help you to solve your problems.”

Our words define our reality. A problem solving culture can be easily identified by its use of the problem/solution hymn. Whereas Lean culture all but banishes the problem/solution hymn and instead continuously increases customer value.

Chapter 3: The Time for 5S Lean Office

5S is five terms beginning with "S" used to create a clutter free workspace:

Sort - Separate needed items for those not needed.

Straighten - Arrange an appropriate location for all items.

Shine - Clean the work area.

Standardize - Establish a standard process for maintaining a clean uncluttered work area.

Systemize - Maintain a consistent standardized approach.

Because 5S was developed by Toyota, the original 5S’s were all Japanese words. That is why there are several different English translations that use different “S” words, but the intent is basically the same.

In Lean Manufacturing, a 5S program is typically the first Lean technique applied to a new environment. The targeted area is literally swept out, clearing the decks for future improvements. After 5S then other Lean techniques such as pull scheduling, workload balancing and waste reduction are applied to cut total cycle time and increase customer value creation.

In Lean Office, a 5S implementation can sometimes be too big a pill for information workers to take all at once. Many of today’s office environments are built on the premise of worker independence. Setting a standard of how employees should maintain their workspace could be considered by some a violation of their rights and lead to a loss of morale; even though it may help performance. Given this, why start a new Lean Office project with a full 5S implementation? There is probably not a more difficult place to start.

As an alternative, consider beginning with only one of the 5S’s. Systemize! Because of the sense independence that can lead employees to perform tasks “their way,” there is typically a lot of process variation; leading to high cycle times, costs, and defect rates. A systemize initiative looks at all the ways a process is currently performed and picks one, or builds a best composite, from the many.

Systemizing makes an easier a first implementation because the “new” process is probably already in use in somewhere. Therefore the organizational change management implications are reduced making it an easier early win. It also establishes the baseline for future improvements. When future process modifications are made after a process systemization, the people impacted by the change all start the journey from the same place.

After systemization takes hold, then other Lean techniques can be applied to continue to build on the early success and solidify the overall return on investment. Once the organization fully understands how to wield the power of Lean, then is the time to determine when and how to (judiciously) apply the other four of the 5S’s.

Chapter 4: The Voice of the Internal Customer

Customer service is about understanding what your customers’ value and then giving it to them. Great customer focused organizations are known for listening intently to their customers and then responding with products and services tailored to what they hear. But how many do this internally and listen to the voices of their own employees as effectively as they do their external customers?

Identifying the Voice of the Customer is a technique for capturing customer feedback in exactly the terms used by customers from their point-of-view. The Voice of the Customer becomes the basis for future product and service enhancements. It helps avoid the internal we-know-better bias that can spring up in any organization.

Typically it is a minority of people within an organization that interact directly with external customers. Yet those involved directly with external customers are the internal customer of a fellow employee. And they in turn are the internal customer of other employees, and so on. Any break or let down in this chain of internal customer support eventually is experienced by the external customer as well.

What works for external customers works just as well for internal customers as well. Here an internal customer is defined as anyone in an organization who receives a work product from anyone else. A work product can be data entered into a computer, information obtained through individual research or analysis, or a decision that was made.

Applying the Voice of the Customer internally is a process of listening to fellow employees about what they value about the work products they receive. Just as with external customers, statements of value and corresponding areas of waste are captured in exactly the terms used by the employee.

Been filling out that form the same way for years? Providing that analysis exactly the same way day after day? You might be surprised what your internal customer would say if you asked them to describe in their terms what the value is of the work you give them. What may appear to be an important and valuable contribution to you might reflect back differently when held up to the mirror of your internal customer’s words.

In fact it can be quite a shock; one that you should prepare for. When seeking out the Voice of the (Internal) Customer:

Ask unbiased questions on what adds value to them and what doesn’t.

Write down (where everyone can see) everything you hear using the exact words.

Do not become defensive as a result of what’s said.

Remember that it’s hard to listen while talking.

Chapter 5: Lean: Getting the Best Out of Limited Investment

In the years of reconstruction following the Second World War, Japanese industry (in general) and Toyota (in particular) had a problem, which was this; how to rebuild a shattered manufacturing base without recourse to either the huge market or the economies of scale available to Western (specifically US) companies, and in the face of severe credit restrictions imposed by the occupying forces (leading to reduced sales and very limited resources to invest in the new plant that everyone thought essential to efficient manufacturing).

At first glance, the task might have appeared hopeless. The image of the relentlessly efficient production line, with huge and specialised machines producing countless numbers of components for rapid assembly by teams of workers, was ingrained in business thinking. Toyota was nearly bankrupt when Taiichi Ohno, the company’s Assembly Shop Manager, took in hand the task of redesigning production. With the constraints in which he found his organisation, and drawing on practices which had been tried with success in other industries in Japan, Ohno’s redefinition of production was on paper clearly focussed on getting the best out of limited investment by.

Building only what is needed.

Eliminate anything which does not add value.

Stop if something goes wrong.

Build only what is needed: That is, build only that for which you already have a customer. This means you don’t have to guess at demand, or hold expensive stock that ties up money and space while it hangs around. This applies at all stages in the manufacturing process; any step in production should build what is needed by the next step, not produce large batches of inventory that wait to be used.

Eliminate anything which does not add value: Which means taking a hard long look at what you and your customer mean by “value”, and making sure both that you’re not wasting effort on activities which make unnecessary things, and that you’re not doing anything to inhibit the flow of this value.

Stop if something goes wrong: If you are only building what is needed at each stage, you are able to identify a defect very close to the point at which it arises (in production systems organised around large batches, defects can go unnoticed for days or weeks).

Take advantage of this by addressing the cause of the defect immediately. This is the fundamental principle of zero-defect manufacturing, based on rapid feedback rather than inspecting the hell out of everything, which has been consistently misunderstood by software methodologists.

The Toyota Production System is also grounded in a set of values enshrined in a philosophy of work that

Respects those engaged in the work.

Strives for full utilisation of workers’ capabilities.

Places authority and responsibility for the work with those doing it.

The most startling manifestation of these values was seen in the authority of any worker on the line to halt the entire production process if they found a defect. These ideas revitalised Toyota (and led to Ohno’s rapid rise in the company; he eventually became Executive Vice President in 1975). While the ideas were common currency in Japan from the 1950s, they did not make an impact on Western industry until the 1980s. Ohno, now retired, had started writing about the Toyota Production System he had pioneered. More significantly Toyota and other large Japanese companies expanded in the 1980s to set up new manufacturing centres in Europe and America.

In motor manufacturing, these companies’ ability to rapidly develop car models for a Western market that was having to re-adjust following the oil crises of the 1970s saw them overturn the dominance of the local industrial giants Ford and GM. The ideas found ready acceptance in fields outside manufacturing, logistics and distribution (for retail and mail-order) have also been revolutionised.

Chapter 6: Road to Agile Development

Rewind now to the 1970s and early 1980s, where the phenomenal growth in capability of computer hardware and (at this time) the steady increase in the connectivity of systems was matched by a corresponding growth in the ambition of software designers, and hence complexity of the systems being developed. This growth in ambition outstripped the growth of tools to support the development of such systems, so in order to produce larger and more complex systems, larger teams were needed.

It was clear that some principles needed to be applied to the organisation of these large teams and projects, and only natural that people concerned with development process looked to what was then regarded locally (at least in the US and Europe) as best practice. Hence the rise of systematic development processes which mirror the product development and manufacturing processes of contemporary industry, specifically with emphasis placed on requirements engineering as a model of specification, and inspection with respect to those specifications as a model of quality assurance.

Taken to extremes, this leads to the extended product lifecycles experienced by the US car manufacturers prior to the lean revolution; requirements transferred as a large single batch to development, the system delivered as a large single batch to Quality Assurance and production. Somewhere along the line, this process of inspection (of requirements, code, system) and formal sign-off was claimed to be the effective model of ‘zero-defect’ development; actually this way of proceeding is pretty much guaranteed to produce defects in the face of any level of complexity or uncertainty in specification.

With the rise of the object paradigm from the mid-1980s, it seemed at last that technology was providing us with some tools for managing the complexity of the systems we wanted to build. However, at the same time, the requirement for systems connectivity experienced an explosive growth (in retrospect, a singularity of sorts) as a result of the phenomenon of the World Wide Web (itself predicated, amongst other things, on the ubiquity of increasingly powerful and low-cost personal computers). So while we now have programming languages and software tools beyond the dreams of the earliest developers, we have still, effectively, been playing a catch-up game.

Enter Agile Development. When the history of Agile is written in years to come, two things will, I think, stand out.

Firstly, the way in which any number of practices and principles long recognised as effective ways of working to deliver software were brought together largely independently by a number of separate groups and individuals.

Secondly, even with hindsight a historian is bound to ask the question; what took us in software so long to get our act together?

Chapter 7: Lean vs. Agile

There seems to be a perception in the IT community that Lean and Agile are two mutually exclusive processes for delivering software. I wanted to talk about it because I had not even thought of Lean as a delivery process at all and I think my view of Lean and how it can be used in IT is diverging with some of the IT community. I am worried that we may be missing the point.

First of all I think it will be useful to talk about Agile. I’ve spent a lot of time talking about this recently because I think it is important. The Agile Manifesto was signed in 2001 by the key individuals involved in the development of the Agile Software movement and if you read it I think that it’s very clear that it belongs at a philosophical level, rather than a practical one. It’s non prescriptive and that is important. The original signatories recognised that there is no ‘one right way’ to build software and this is reflected in the manifesto. It simply outlines principles that we all agree with, at least in the agile community.

Lean also belongs at a philosophical level. Deming’s and Ohno’s work teaches us how to get the best from people and how to build business processes to get the best from them by aligning their futures with that of the organisation. Toyota recognised that there was no ‘one right way’ to build cars and equipped their workforce with tools that supported them in continually improving how the cars were built.

Why do we like Lean in Agile community? Well, at a philosophical level Lean and Agile are incredibly well aligned. They are both about empowering people to get the best results. They are people centric and they teach us how to adapt and improve processes to get the best results from the people we have to solve the problem that we are confronted with.

With this in mind I don’t fully understand how it is possible to follow a Lean software development process. We can only have processes that are more or less efficient than each other in a particular context. There is no ‘one right way’.

What do I mean by that? Well, let me see if I can explain. There are 4 situations where I call on my Lean knowledge heavily. Let’s take them in order…

Lean as a metaphor for Agile

One of the challenges that I feel we have had historically within the agile community is explaining Agile to executives in a way that they can digest and understand. Due to the close parity between Lean and Agile we can use Toyota and others to explain how and why the concepts that we apply in the agile community work.

Improving the efficiency of the software delivery life-cycle.

Through its processes and problem solving tools, Lean provides us with a great tool kit for improving the efficiency of a process. This is where most of the Lean concepts are being applied in IT today. Let me hear you say value-stream maps and waste elimination.

Improving the efficiency of the business processes our IT systems support.

If we improve the efficiency of the software delivery life-cycle we can now deliver IT solutions that support poor business processes at speeds previously thought unimaginable! Lean is putting good process engineering tools in the hands of the IT community. We are now better equipped to work with our business partners to ensure we are building the right solutions and delivering the most value.

Introducing large scale change to organisations.

This is where my focus is today. Toyota, through its consulting division, has been transforming other organisations for many years. They have been at it much longer than we have in the agile community and they have learned many lessons along the way. If we look at what they have learned we can apply the same thinking when we are tasked with transforming an IT division to an agile model. This is all about people, values and encouraging the right behaviours. The process and problem solving tools come much later.

So, I like Agile because the processes that we have developed are more efficient than traditional ones; I can prove this in most contexts with value-stream maps. I like Lean because it helps me to explain these processes, introduce them on both a small and large scale, and most importantly it helps me to continuously improve them over time as we learn. The process that we start with may not be the one that we end with. We learn new things and improve along the way.

I look at Agile and Lean as complimentary. If we study Lean we can become more pragmatic about how we introduce our processes, where they are adding value and where they are just causing issues. Lean also ensures that we focus on people rather than tools, although I worry that in IT we are becoming a little obsessed with the tools (VSM and waste elimination in particular). The Lean Ops movement went through a similar ‘tool age’ before they returned to the people philosophies at the core of Lean.

I really hope the Lean and Agile communities don’t diverge. I feel that agile community have a lot to learn from Lean.

Chapter 8: How Lean and Agile are Different

This chapter is my attempt to clear the air a little bit around this issue. First off I want to make it clear that, in my opinion, the theoretical distinctions between the two concepts are not important enough for teams to change anything they are doing to produce good software. In other words, who cares what you call it?

However, it is useful to understand what each concept is. This allows you to have clear conversations about issues and solutions, and it also makes it easier to see what needs to be done at every level to improve the overall throughput of the team or organization (or, indeed, of the entire value-stream.) The way I see it, Agile and Lean are similar in many ways, and they really complement each other the rest of the way.

Agile

Agile is a framework that focuses on iterative-development and feedback to build out a software product. Agile focuses on quality by making things like test-driven-development, continuous integration, and refactoring essential pillars of the process. By definition, agile fosters the creation of an adaptable and evolving team process it accommodates the fact that each project is different, and processes need to fit the situation. Agile also emphasizes communication and collaboration over documentation; thus, it enables teams to move quicker by resolving things face-to-face. It also considers the customer as part of the team, thereby ensuring maximum feedback reaches the ultimate users, and allowing them in turn to change the course of the work product.

Agile methods usually measure things within the software development world; number of stories (scope), estimates (time), velocity (speed). This in turns drive costs and budgets.

Overall, Agile can be thought of as a framework for the software-construction (planning, development/QA, release) part of creating a product.

Lean

Lean, on the other hand, is a management philosophy. Ultimately, it focuses on throughput (of whatever is being produced) by taking a strictly systems-level view of things. In other words, it doesn’t focus on particular components of the value-stream like code-construction or Quality Assurance, but on whether all the components of the chain are working as efficiently as possible so as to generate as much overall value as possible. Value, of course, includes things like high-quality, and optimized for time and resources.

Lean is based on several things; queuing theory, the theory of constraints, concurrent engineering (set-based development) and delaying commitment to the last responsible moment. Careful metrics (only the ones that truly measure throughput; this often means going one level up) is an important part of lean; this allows everyone to be objective about everything. Speaking of which, Lean software recommends measuring things across the value chain and as extended as that chain can be. It recommends measuring return on investment (ROI), customer satisfaction, customer usage patterns, market share, and so on. This in turn drives budgets and costs within the software organization.

Where they are similar

Both Lean and Agile focus on people over pretty much everything else. They both focus on inspecting and adapting in order to improve the work-product and efficiency in producing it. In other words, feedback is critical from people, from customers, from stake-holders, and from the product itself. They are both quality focused, and they encourage early discovery and more importantly, prevention of defects.

The area where they complement each other most is in the breadth of their world-view. Agile is usually focused very much within the software development team or organization, Lean focuses on the entire system that includes as many workers, partners, customers, and external stakeholders as possible.

How they fit

Having made these remarks, I did like to present this picture: It is a way I like to think of the way Agile and Lean fit together. It is sort of a stack. Lean is a foundational framework, Agile sits on top of it. I’ve also taken a shot at depicting some of the building blocks within each.

How Lean and Agile fit together

It doesn’t really matter I have found that after incorporating more and more aspects of Lean into your Agile processes, the distinctions start to blur. In the end, Lean subsumes everything, and ultimately, the only thing that matters is whether the organization delivers what customers want and like, how fast they can deliver it, and how much money the organization and its customers can make together.

Chapter 9: Why Lean and Agile Go Together

To succeed at the largest scale, Agile software development should use Lean manufacturing principles.

The command-and-control hierarchical organization of large companies is rapidly giving way to a more biological metaphor, one in which a corporate nervous system senses important signals from the market and supply chain and rapidly reacts. At the largest scale, this trend is being driven by principles of Lean manufacturing, which envisions the enterprise as a massive event-driven system, waiting to create products when customer orders arrive instead of building products in advance and holding them in inventory.

Software development has been similarly transformed by Agile development methods. In this arena, the command-and-control ethos is represented by the Waterfall development methodology, which follows a seemingly reasonable pattern of gathering requirements, designing a product, and building and testing. The problem is that requirements are almost always wrong. The Waterfall method does not allow for mid-course corrections, and the beginning-to-end cycle may span a year or even many years.

Agile posits a huge payoff for being highly suspicious of software requirements. In Agile methods, instead of building the whole product, you build the smallest possible useful part and give it to users, who tell you what is right and what is wrong. Agile development is an evolutionary conversation in which incremental steps of two to four weeks lead to feedback that allows requirements to be tested and adjusted. In addition, some functionality is available much sooner.

Quality also increases in Agile projects because using a working system exposes defects right away instead of leaving them to a final testing phase. Many other aspects of Agile are beneficial but beyond the scope of this book.

Agile's popularity has led to a problem: How do you apply it at scale? How can a large project run using Agile methods? One team working on one project in an Agile way is not hard to envision. But what about running 10 or 20 teams, each working on part of a product? How does the list for each iteration get sorted out and synchronized? How does the result of each iteration become integrated into the larger whole?

I've been discussing this topic for a few months with a colleague, CTO of a leading vendor of software and training services to support adoption of Agile development. In addition, I saw a fascinating presentation about tracking Agile projects at London last week in which speakers detailed various methods of tracking progress of Agile projects.

What surprises me is that most advanced practitioners of Agile now use more vocabulary from Lean manufacturing than from Agile. In essence, as a practical matter, good ideas from Agile are being absorbed into a new approach to software development that is more Lean than anything else. Someone else can name this phenomenon, but Lean and Agile are merging.

The fundamental recommendations of Agile methods are focused on creating a rapid feedback loop between the users supplying the requirements and the technologists transforming them into a solution. Agile methods also suggest a variety of engineering practices that increase the quality and stability of code.

Agile has much less to say about how to connect the work of many different teams, and that's where Lean has a huge impact. In a Lean manufacturing system, the work is broken into a set of value streams triggered by demand signals. The output of one value stream leads to others. Value streams may be executed sequentially or in parallel as needed. Eventually, everything is combined into the product. The suppliers for materials needed are alerted through a system of just-in-time replenishment of parts and components called Kanban.

Large organizations that are using Agile are applying a value stream approach in which various development teams are organized in sequential and parallel streams of work so that at the end of each iteration, you get a new version of the product. Sometimes different rhythms of iterations occur; with some work taking place in faster increments followed by the integration of everything every fourth or fifth iteration.

"Large Agile teams manage dependencies through multiple and iterative synchronization points, but they also work to remove them through better design process like Lean's set-based and concurrent engineering approaches," Martens says. "We have come a long way, but I see another decade of major improvement coming from the application of Lean principles to software development." For example, SAP has been using SCRUM and other Agile methodologies for several years at the team level. Herbert Illgner, COO Business Solutions and Technology at SAP, who has been involved with the effort, says that team empowerment and faster feedback cycles with customers are two significant benefits. Illgner added that SAP is expanding application of Agile methods to the entire product creation process using a Lean framework that includes empowered cross-functional teams, continuous improvement process and managers as support and teachers. "We are implementing a large scale SCRUM for software development teams that includes several thousand developers," said Illgner. "We expect to reduce planning overhead, synchronization and integration efforts significantly as we move from individuals and individual timelines to cross-functional teams and time boxed iterations. This is a radical change compared to how software has traditionally been developed and requires significant commitment and support especially from top management."

The Lean concept of Kaizen also has a strong influence on the way Agile is being practiced, filling a gap relating to continuous improvement. The evolution of Agile is primarily focused on evolving the product toward a better fit with requirements. In Agile, both the product and the requirements are refined as more is known through experience. Kaizen, a continuous improvement method used in Lean, focuses on the development process itself. When Kaizen is practiced in an Agile project, the participants not only suggest ways to improve the fit between the product and the requirements but also offer ways to improve the process being used, something usually not emphasized in Agile methods. Eckfeldt described the use of Kaizen snakes and project thermometers to capture process improvement feedback.

"The power of Agile is that it's self-adaptive," Eckfeldt says. "It teaches software teams how to deliver value to customers and how to improve themselves using techniques like Kaizen, allowing them to deal with unique and changing constraints and environmental factors."

In practice, Agile seems to be changing for the better by adopting Lean thinking in a large way. Your customers will get to market 50% faster and are 25% more productive when they employ a hybrid of Lean and Agile development methods. Given the way that Agile fits in to the Lean framework, it wouldn't surprise me if before too long Agile is considered a branch of Lean practice tailored for the software industry.

Chapter 10: Agile and Lean in the office

Work flows horizontally through any organization. As the work flows from one activity to the next, each activity can:

Require different skills and expertise.

Be performed at a different location.

Vary depending on the customer requirements for that unit of work.

Management of different skills and expertise, geography, and customer segments or products is a top down or vertical process. This places the vertical management of activities at 90 degrees to the horizontal process of creating value. The two are cross-purpose to each other.

Consider a company that is organized by functions such as sales, marketing, engineering, production, and customer service. The value stream to launch a new product is a horizontal flow through each of these functional organizations. But the management of a new product launch occurs vertically by separate organizations depending on the current activity. Using vertically centred management to coordinate the horizontal flow of work causes no end of problems. Think silos.

Agile and Lean help to tackle the vertical management of horizontal value streams by establishing a system-wide view of how value is created by the organization. They add a discipline of managing value to managing skills, location, and customer requirements. Maintaining a value discipline helps guide management decision making to optimize the horizontal flow of work.

Does Agile and Lean require senior management commitment for it to succeed?

Agile and Lean can be implemented both from the top-down or from the bottom-up. For an organization to reap the full benefits of Agile and Lean eventually both top-down and bottom-up approaches will be required. But Agile and Lean techniques are easy to adopt. They do not require extensive training or "black belt" certification to get started. Experience can be gained with Agile and Lean prior to rolling them out across an entire organization.

A single group can apply Agile and Lean concepts to a single value stream within that group. For example, a sales organization could apply Agile and Lean techniques to order processing. Most organizations process multiple types of sales order. To get started, Agile and Lean could be applied to just one type of sales order. A value stream map can be created for that one order type and analysis conducted to maximize the value and minimize the waste.

The organization will benefit from applying Agile and Lean to any value stream regardless of its size. The techniques to improve performance are also tend to be independent of size. So in addition to the immediate performance benefits the organization will also learn Agile and Lean techniques that scale as the size of projects scale. Then senior management can be engaged when Agile and Lean techniques are well understood and the projects start to cross interdepartmental boundaries and require management involvement.

How important is leadership for Agile and Lean in the office?

Agile and Lean organizations rely more on leadership than strict command and control structures. Leadership emphasizes modelling the way, inspiring shared values, and enabling others to act in concert as opposed to giving orders. Leadership involves skills such as inspiration, persuasion, and creativity, so those without direct authority can still positively influence others.

Agile and Lean techniques help to establish the value priorities for each value stream of an organization. Once value priorities are established, leadership is critical to maximize value creation and minimize waste, by maintaining shared value priorities across employee (functional), regional, product/service, and customer domains.

Leadership requires permission of the group that is to be led. It is not enough to set yourself or anyone else up as a heroic figure leading the charge. In Agile and Lean organizations, employees agree to be led in the pursuit of value creation and waste reduction. Without this buy-in, change management becomes a much greater effort. With this buy-in, leadership establishes value priorities and identifies where each employee contributes; while employees are empowered within that structure to continuously knock down barriers and search for ways to add value to every activity performed.

How does the concept of span-of-coordination benefit Agile and Lean in the office?

Span-of-coordination is the reach of an individual's or team's responsibilities; involving both leadership and support responsibilities in addition to authority (span-of-control). In the past management hierarchies almost totally functioned under span-of-control. Coordination involves the exchange of ideas, formally and informally, outside of span-of-control boundaries.

In an office environment work can be thought of the flow of ideas from one activity to the next. Sales, marketing, engineering, and customer service all work with ideas; capturing, enhancing, connecting, and promoting them. Lean Office is an umbrella term for techniques to maximize the value of ideas.

Establishing span-of-coordination concepts within an organization helps to maximize the benefits of Agile & Lean by increasing the breadth of individual and team responsibilities. They will be encouraged to maintain a greater system-wide view outside of their particular span-of-control and engage in leading or supporting system-wide efforts to maximize stakeholder value.

Where is the best place to start an Agile and Lean project?

There are four dimensions to customer value creation. The four dimensions of performance are people, process, technology, and time. To power an effective value stream these four dimensions must be synchronized; none overpowering the others.

The best place to start an Agile and Lean project is with a value stream where one of these four dimensions is obviously out of alignment with the other three. The fact that the dimension is obviously out of alignment will help its stakeholders realize the need for change and create a clear target for improvement. Under this scenario, Agile and Lean techniques can be applied to bring the misaligned performance dimensions back in line without having to make significant changes to the other three; greatly simplifying an initial project.

The following are indicators of a good process candidate for a Lean Office project:

So ineffective it would make a good candidate for a Dilbert cartoon

Does not cross functional or organizational boundaries

Has 8 to 16 separate roles, performed either sequential or in parallel

Is somewhat standardized and repeatable with a steady flow of work

The total work time to complete all of the activities is significantly less than time from the start to finish

Can be segmented so that the initial implementation impacts less than 20 people.

How are Agile and Lean different from other process improvement techniques?

Agile and Lean applies a system wide view of each of the four dimensions of performance, people, process, technology, and time. Process improvement, only focused on the process performance dimension, tends to sub-optimize the interactions of people and technologies without regard to the mix of work that occurs over time.

The objective of an Agile and Lean organization is not to improve processes. It is to increase customer value and reduce waste. How a project is named has an incredible impact on the results of that project. Name a project process improvement and the result will be improved processes, but possibly with no benefit to the organization or its customers. Agile and Lean may improve certain process in order to increase customer value. However, if improving a process improvement didn’t increase customer value or reduce waste, then there did be no reason to do so.

Agile and Lean is not about finding one answer or optimum result. Agile and Lean engages employees in continuous improvement. Office systems are complex systems. Agile and Lean assumes that for all but the most trivial environments it's impossible to fully understand all of the upstream and downstream dependencies on a single task. Agile and Lean techniques are designed to enhance operational performance a bit at a time, let things settle to understand both the intended and unintended consequences, and then make additional improvements.

What is the difference between Six Sigma and Lean in the office?

Both Six Sigma and Lean were originally developed for the manufacturing shop floor and have found application in the office environment. Both take a continuous improvement approach to making operating performance better everyday. Both are customer focused and have their roots in quality improvement; though both have evolved to not only improve quality but also increase responsiveness, throughput, and employee and customer satisfaction.

Although their roots are similar, Six Sigma and Lean are two different tools; just as a hammer and a saw are two different tools. Each has sweet spots where they work the best, areas where they are OK, and other areas where they are a waste of time. Over time the two approaches are adopting the techniques of the other, as organizations realize that there is no more reason to build a house with just a hammer, as there is to build a house with just a saw.

Six Sigma's primary focus is on the reduction of variation. Six Sigma uses statistical mathematics to measure and predict variation. Once identified, reducing variation reduces defects and costs; thereby increasing performance. As an approach, Six Sigma does not specify techniques for reducing variation once discovered. Lean techniques can be one of the tools to reduce the variation monitored by Six Sigma.

Lean's primary focus is on maximizing value creation and minimizing waste. Lean assumes that the job of enhancing value creation and waste reduction is never done. There are always incremental improvements to be made. Lean relies on measurements such as Six Sigma or balanced scorecards to establish the status quo and evaluate the impact of change. But Lean is more of an approach for defining how systems should operate to maximize throughput while minimizing service times and waste.

Therefore, Six Sigma is more of a measurement tool to help identify problems and establish when they are resolved. Lean is more of an operations tool to help define from a system-wide perspective the most effective way for work to be performed.

What are the differences between Agile and the following project management approaches: PDCA, DMAIC, and the Five Ds?

Each of these continuous improvement approaches are defined as approaches for conducting continuous improvement programs each represents a cycle of implementation steps or stages; and all are typically represented as wheels. Although each defines what is included in each stage/step slightly differently, the overall contents of each are roughly identical. Whether you use one of these approaches or some other variation, it’s important that:

It is done continuously.

There are sufficient measurements to insure progress is made.

Nothing else is broken.

The primary difference between each of these approaches and Agile is that Agile uses what is known as a time-boxed approach. Any project has three variables: 1) scope, 2) resources, and 3) time. PDCA, DMAIC, and the Five Ds fix the scope and the resources assigned to a project and then determines the time it will take. An Agile time-boxed approach fixes the time and the resources, and then allows the people assigned to the project to determine the scope they can complete given the time.

An Agile time-boxed approach:

Creates sustainable rhythm to continuous improvement approaches.

Allows for powerful feedback loops for increased project estimation accuracy.

Enables resource commitments to easily change at each cycle.

Delivers value at the end of every cycle.

Increases the overall chance of project success.

There is an interesting continuum where each of these particular approaches exists when it comes to problem solving. Consider a scale from one to five where one is "eliminate the negative" and five is "accentuate the positive". On this scale six sigma would rate a one, PDCA would rate a two, and Agile and the Five D's would rate a five. Depending on the organizational culture, one of these approaches or its derivatives may be more appropriate than another.

What are values?

Value is a popular term within the vocabulary of Agile and Lean. Like many popular terms it means different things to different people. Value is something of worth in usefulness or importance to the possessor. To paraphrase another saying; value is in the eye of the beholder. So there is nothing simple about establishing the value of something. It depends on the context and the individual or group assigning the value.

In Agile and Lean there are two primary uses of the word value:

The value of culture or community.

The value of products or services.

The value of culture or community represents the worth of maintaining the organization to the individuals that comprise the organization. These values establish a common sense of purpose, direction, and execution; why the organization exists, where it is going, and how is it going to get there.

The value of products or services represents the worth produced by the activities of the organization. The customers of this value can be both internal and external customers of the organization. These values help to sustain the long term viability of the organization.

There is a tendency to establish the overall value of an organization solely by the value of its products or services. Agile and Lean recognizes that both are important and that the two must be closely aligned and continually enhanced to sustain operational excellence.

How do Agile and Lean enhance value alignment?

High performance organizations are able to tightly align the values of their culture or community with the values of their products and services. As work is performed in high performance organizations the worth of each value set is reinforced and enhanced.

If cultural or community values are not aligned with product and service values, or if the values of each are not commonly shared, business friction increases and the organization will literally be at cross purpose to itself. Decisions seem difficult to make, customers believe you are hard to do business with; employees are de-motivated bureaucratic barriers, etc. Attempting to solve each of these symptoms individually doesn't work. As soon as one symptom is pushed down, another pops up.

Chapter 11: Agile and Lean Value Stream mapping in the Office

Agile and Lean techniques were developed to address both cultural and community values as well as product and service values and:

Establish shared values throughout the organization.

Enhance the activities performed by the organization to maximize those values.

Minimize waste or non-value added activities.

How do you recognize a value stream when you see one?

Value stream is a holistic collection of value added and non-value added activities that chain together to create a customer product or service. A solid definition, but unless you already had an idea of what a value stream looked like, you did probably not be able to use this definition to find one.

If you have ever had the chance to see how a car is made in a factory; that is a classic example of a value stream. The pieces and parts that make up the car enter on one end of the factory and the completed car exits out the other end. It is literally that simple. As the car moves along the production line, activities are performed that add part after part. Each time a part is added, the value of the car increases. The production line is a stream of value adding activities. Hence the name value stream.

The same definition of value stream holds true for the office just as it does for the car factory. Although in an office it is much harder to see. The easiest value streams to see in an office environment are the ones that are triggered by a piece of paper. Office value streams are started on receipt of a request for quote, sales order, invoice, job application, benefit claim, procurement request, etc. You can then follow the progress of that piece of paper just like you could follow the progress of a car being made in a factory.

Each activity that occurs in the processing of that piece of paper adds (or subtracts) value just like adding a part to a car. For example, processing a job application can have the following activities:

Screening the application for fit to open requisitions.

Scheduling a phone interview with applicant.

Conducting a phone interview with applicant.

Scheduling a person-to-person interview with applicant.

Conducting a person-to-person interview with applicant.

Making a hiring decision about the applicant.

Each activity occurs in a new hire value stream that produces value in the form of hired employees. Each has a specific order in which it must occur. The application screening and phone interviews add incremental value because they assist to improve the quality of candidates selected for the person-to-person interviews.

There are hundreds if not thousands of value streams within any office environment. Some are aligned with the flow of paper, others are not. Launching a new product development effort or marketing program are examples of value streams that do not have structured paper flows, but they are value streams none-the-less. In these examples the value streams are associated with the flow of information from one activity to the next, as each activity adds substance and form to the information.

What is the first most important step in value stream mapping?

Although it may seem obvious, the first most important step in value stream mapping is to determine the customer value produced by the value stream. Often the various customers of a value stream share different priorities for what customer value should be created. It's easy to imagine how the engineering, sales, and finance organizations could each have a different view of the highest priority value produced by a value stream.

Take as an example a Request for Proposal (RFP) response value stream. This is a value stream that develops a proposal for products or services at the request of a customer. What is the most important value created by our RFP response value stream?

The innovative solution to the customer's problem that no competitor can match?

Establishing a price for products and services?

A risk assessment of the organization's ability to perform the work at a profit?

Depending on which of the above is the highest priority; the activities that make up the RFP response value stream could be optimized in different ways. Each being perfectly acceptable, but each driving the process a different way.

It is when the value priorities of each stakeholder are not aligned that causes of much of the friction and waste within a value stream. Creating clear system-wide value priorities is a step that must be completed prior to starting a value stream map. These value priorities then set the bar for whether an activity of the value stream adds value or not. If the value priorities of a value stream are ambiguous; the result of the value stream mapping analysis will be ambiguous as well.

What is the difference between value stream mapping and process mapping?

The focus of value stream mapping is on discovering the positive values provided by the activities of the organization, enhancing those values and removing any performance robbing waste.

The focus of process mapping is on discovering the current processes of an organization, establishing the root cause problems with those processes, and looking for solutions. Process mapping is used to find a problem and then find a solution. Then find the next problem and find the next solution. While improvements can be made using this approach, it is difficult to align the problem/solution pairs so that each cycle of problem/solution implementation builds towards a strategic objective.

Value stream mapping focuses on the value produced by the value stream and continuously strive to increase that value. Value can be increased by either adding an enhancement what a customer is willing to pay for, or removing a waste that no one would pay for. The idea is to look at every activity (even those that are not causing problems) and find ways for that activity to increase customer value and reduce waste. A small value increase or waste reduction in every activity performed, times a lot of activities, leads to greatly increased performance and reduced costs.

The result of processing mapping is improved processes. The result of value stream mapping is improved customer value. As has been proven time and time again, it is possible to improve processes without increasing customer value. Process improvement maintains an internal focus. Value stream mapping maintains a focus on both internal and internal customers; the ones paying the bills.

How is value stream mapping different for the office?

The key to value stream mapping in an office environment is what you actually map. The biggest mistake people tend to make is to just map out static activities or tasks. This approach works in manufacturing because typically the labour content is relatively low and alternate flows tend to be relatively restricted.

The recommended approach for the office is to map out the flows most likely to lead to the next incremental increase in value or decrease in waste. The four flows of any office process are responsiblity, information, work, and progress. Using value stream maps to map each of these four flows increases visibility of the interactions and management control points from four different perspectives of a single process. By creating value stream maps for all four types of process flows the impacts of changes made to one perspective can be easily seen for the other three.

What is meant by current and future state value streams?

A current state value stream is a snapshot of a value stream as it exists at the time of observation. A future state value stream is a snapshot of a value stream as it might appear at some point in the future.

Some organizations attempt to skip mapping a current state and move directly to the future state. They say they don't want to waste time on something they know is broken. However, the current state should be clearly understood prior to looking for future areas of improvement. Organizations are complex systems. Without a current state view to use as a baseline it is sometimes difficult to tell if a change actually is an improvement. Or if the change made to improve one area has been made at the sacrifice of the performance of another. Also having a current state map helps to create an accurate transition plan from the current to the future state.

Developing a future state value stream, as part of the implementation planning process, helps to insure that the planned changes will produce the desired improvements. It helps to enforce a discipline of thinking through the impacts of any change. The butterfly flapping its wings in China may have an impact on the rainfall in Seattle. But it is more likely that changing how a sales order is entered will impact on how orders are taken.

Why create value stream maps of a future state not an ideal state?

There is sometimes a tendency to build future state value stream maps to be the ideal, nearly perfect, end objective. Under this scenario a current state model is developed to establish where the organization is. Sometimes called the as-is model. Then a future state model is developed as the ideal future goal. This is sometimes called the to-be model. Then a gap analysis is performed between the two. The gap or difference of the two models forms the basis for a project to reach this perfect future state.

The truth of the matter is there is no such thing as an ideal future state. Even if it did exist for an instant, an instant later the ideal state would change because of a new customer, a new competitor, a new employee, etc. All organizations are in a constant flux of change over time, whether they recognize it or not. Adopting a culture of continuous improvement is the only effective choice for maintaining a high performance organization.

This is not to say that future state mapping should not be conducted. The Agile and Lean approach is to:

Map the current state.

Look for incremental opportunities to improve.

Map how the future state would look with these incremental changes.

Make the incremental improvements.

Rename the future state map to the current state map.

Let the system quiet down to a new equilibrium to be able to measure the true impacts of change.

Then start the cycle again and look for incremental opportunities to improve.

After a couple of cycles, improvements that would have been impossible to achieve when starting from the original current state map, will present themselves as viable alternatives. Innovations that would not have been considered using a single big bang project approach.

Chapter 12: Agile Lean and Waste

What is waste?

Waste is anything that does not directly add to or support the creation of customer value. If no waste is created, then all of the value created by an organization is received by the customer. This is rarely the case.

A key concept is that it is the customer who establishes value. Here the customer can be either internal or external. If the value created by an organization is not perceived by the customer as valuable then the difference is considered waste.

Waste can also be produced directly by an organization at the same time it is creating value. Anything that is not considered to be value received by the customer is waste. The basic test of waste is: if given a choice, would the customer pay for it?

For example, suppose an error was made in a product or service. Customers prefer not to pay the price to produce an error, or the price to fix it. Therefore the production of the error and its fix are both considered waste. Errors or defects are just one example of seven types of waste that can be created.

What are the tradeoffs in cost reduction vs. quality improvement?

Cost reduction can be easier to achieve

The costs of an organization are easy to see and therefore make a good target for reduction. Reducing cost has an immediate impact on the bottom line so there is immediate feedback on results. This creates a reinforcing cause and effect feedback loop that further encourages cost reduction behaviour. If you try something that is relatively easy and the results are viewed as successful, you will try it again.

Quality improvement is viewed by many as being a much harder target to hit than cost reduction. Most organizations attempt to improve quality by reducing the number of errors or defects. Unlike costs, it’s difficult to make a change that directly reduces the number of errors; the organization is already doing the best it can. In addition improved quality is sometimes hard to quantify. Quality improvement produces a weak cause and effect feedback loop that leads to discouraged quality improvement behaviour. If something is hard to achieve and the results are hard to determine, why bother with it?

In addition cost reduction is viewed as having a linear cause and effect. For each unit of cost saved a unit of savings drops to the bottom line. Quality improvement has a non-linear cause and effect. The closer the organization is to perfect quality the harder and costlier it is to make additional improvements.

Quality improvement builds a stronger organization

The cause and effect feedback loops of cost reduction are not linear over time. In the short term, cost reduction can appear linear when taking a department-by-department view. But over a longer term and applying a system-wide view, cost cutting impacts the overall effectiveness of the organization to create value. A small cost reduction in one area can reduce the cost effectiveness creating value in another. This is also known as a death spiral and its impact can be as bad as it sounds.

Quality improvement is more than reducing defects. Defects are just one of the seven wastes. The other six wastes is; overproduction, waiting, transportation, underutilization, work-in-process, and variation. Attempting to reduce these six wastes is just as easy a target as reducing costs. In fact reducing these wastes reduces costs. They also turn out to be the root cause of many defects, so reducing the other six wastes also reduces defects and improves quality. Improving quality increases stakeholder value and potentially revenue.

Implementing a program to continuously reduce waste engages employees to make the business better every day. Employee satisfaction goes up as employees are empowered to eliminate the barriers of waste in their way. Throughput and response times increase creating a more agile organization to customer needs increasing their satisfaction.

Whereas cost reduction and quality improvement both can increase profits, quality improvement can also increase revenue, employee and customer satisfaction.

What is the difference between waste reduction and cost reduction?

It’s all in the name!

The objective of cost reduction is to reduce costs.

The objective of waste reduction is to reduce waste.

At the end of the day which would you rather have; less cost or less waste?

The problem with cost reduction is that it is not discriminatory. If the only criterion is to reduce costs, then the result is that both good costs (those creating value) and bad costs (waste) are eliminated. Cost reduction does not distinguish between the two.

In many cases cost reduction is performed by asking each department or group to reduce its costs by some percentage. This approach almost guarantees that some good will be thrown out with the bad. A 10% cut in one department may only cut 20% of their fat, but the same 10% cut in another might slice right into the muscle.

Waste reduction is essentially a cost reduction program with built in criteria for where to cut. It seeks to remove all areas of fat but leave the core abilities to create customer value. There is no need to set a stopping point like when 10% of costs are eliminated. A waste reduction program works continually to eliminate all areas of waste; and overtime can far exceed a 10% cost reduction objective.

What if waste reduction can't reduce enough cost?

This question assumes the organization has an active waste reduction program that is continuously searching for an eliminating waste. There are times when the resulting cost savings are not enough. Perhaps an organization’s revenue is dropping faster than their costs? Or the revenue is growing but its costs are stubbornly growing faster? If everything that can be done is being done to reduce waste, then it is time to focus on the value being created?

Perhaps revenue is dropping it is because the customer no longer sufficiently values the product or service being received? If the sales and marketing organization cannot reverse this perception, then it becomes necessary to reduce the value created by the organization.

Costs’ rising faster than revenue is essentially the same problem because customers are not valuing the products or services sufficiently to justify the costs. If the sales and marketing organization cannot increase the customer perception of the value received, then the value (and its associated costs) must be reduced.

Reducing value becomes a case of deciding which value is no longer going to be produced by the organization. This becomes a strategic decision, not a waste or cost reduction decision. It is not one that should be left to the arbitrariness of a cost cutting knife. Other techniques such as value stream mapping can be used as tools in this situation to help maximize the customer value created for a given investment in labour and capital.

How does reducing waste improve quality?

Of the Seven Office Wastes, the seventh one, defects, is the one (and only one) usually associated with quality problems. However, reducing any of the Seven Office Wastes leads to increased quality. When there is less overproduction, waiting, transportation, etc., there is less waste produced within an organization. But when each of those wastes reduced, defects are also reduced and overall quality improves.

For example, overproduction by definition creates work products that are not needed right away. If defects are included in the overproduction, they will not be discovered until later when the work is needed, leading to lots of rework. If overproduction is reduced, then defects as soon as they are created, allowing the process to be fixed before more defects are introduced.

Another example is variation. Having multiple ways to do the same thing leads to confusion. Confusion leads to mistakes. If one person always checks something before passing it on and another doesn’t, the recipient of both work products can cause a defect by incorrectly assuming if the check is always performed before they receive it.

How does reducing waste increase revenue?

Waste is the opposite of value. An activity of an organization either creates waste or it creates value. By definition it is not possible to create both at the same time. If an activity is creating waste, it has the effect of eliminating an equal amount of value. An hour spent creating waste is an hour spent not creating value.

Customers pay for value. The more value provided the more they are willing to pay. Create more value and your revenue will increase. It will increase because customers are willing to pay the value of your product or service. Or it will increase from increased customer retention due to increased customer satisfaction from receiving greater value for a given cost.

What is the hardest waste to remove?

Of the seven wastes, defects is the waste that is hardest to reduce.

Defects are the result of errors or mistakes. Mistakes happen. This can be truer when people are involved. Telling someone to make fewer of defects rarely accomplishes the intended result. Many times the extra pressure of trying not to make a mistake just leads to an increased numbers of mistakes.

However, the other six forms of waste are relatively easy to reduce or eliminate. If someone is overproducing, the process can be changed to produce the value closer to when it is actually needed. If an underutilized process is reduced, then the cost of that process will be reduced.

Where is the best place to look for waste?

At the beginning of a process!

By looking at the processes of most organizations you would think that waste only occurs at the end of a process. That is typically where the quality checks start to appear. This is probably because that is where the errors or defects become obvious. But waste can be introduced at the very beginning and at any step downstream in the process.

For example, errors in a product or service delivery can be tracked back to waste introduced in order processing. And errors in order processing can often be tracked back to waste in the sales process. Yet how many organizations take a close look at waste in their sales process when they are not creating sufficient value in their product fulfilment?

The information dependencies of most office environments are too complex to predict how the presence of waste in one area will cause additional waste to be created in another. All of the employees of an organization should be trained to identify and reduce waste. Adding value creates more value as work moves through the organization. Adding waste early in a process also creates more waste as the work flows downstream. Removing waste from a point upstream in a process eliminates the snowball effect of waste adding more waste, as it cascades downstream through the process.

Chapter 13: Labour Productivity vs. Information Effectiveness

Productivity is a popular measure of process performance. It can be misleading if too much attention is paid just to it. Productivity is a ratio of the customer value produced per unit of labour. When labour productivity is the primary focus information effectiveness suffers and the result is higher costs, poorer quality, and lower customer satisfaction.

The emphasis on productivity causes too much attention to be placed on the labour cost denominator of the productivity calculation rather than the customer value numerator. Reducing the number of hours or cost per hour to produce customer value increases productivity. This then becomes the goal.

For example, investments in information technologies are typically justified by increasing labour productivity. If it takes 8 labour hours to create a unit of customer value and a tool can be created to reduce this to 4 hours; the result is a 50% increase in productivity.

Productivity in our Blood

The use of a tool to increase productivity is something people understand. It is in our DNA. We have been prodigious tool users for a very long time. But too much of a good thing leads to an unbalance.

To say that the only measure for process improvement is productivity is the same as saying the only tool needed to build a house is a hammer. Certainly conceivable to do, but add a few more tools to the tool box and the power of possibilities increase.

Service Time and the Lean Ratio as two additional measures that help identify new possibilities for process improvement. The calculation of service time is divided into two components:

Work time

Wait time

Productivity measures the effectiveness of work time. Reduce work time and productivity increases. But reducing work times may not have an impact on wait time. In fact increasing productivity by reducing work times could cause wait times to stay the same or even increase. Longer wait times lead to increased cost, more errors, and lower customer satisfaction.

Information Effectiveness

If work time is an indicator of labour productivity, wait time is an indicator of information effectiveness. What is waiting during that wait time is information. People are busy. At any point in time they are applying their labour somewhere.

In the typical process information is lazy. It spends a lot of time waiting around for someone to pay attention. And if information is waiting then so is a customer.

Two Perspectives of Improvement

Take the case of customers waiting for their service requests to be completed. Let’s say that the average service time for those requests is 4 weeks and that the total work time to complete the service request is 16 hours.

If we were able to increase the labour productivity associated with the service request by 50% our work time would be reduced to 8 hours from 16. Most organizations would consider a 50% increase in productivity a huge win and a significant cost savings.

From the customer point of view, what used to take 4 weeks would now only take 3 weeks and 4 days. Would the customer even notice the difference? An organization focusing only on productivity may not even notice the problem, but their customers would. Under this scenario you could conceivably reduce the work time to zero and still take 3 weeks and 3 days.

This is a hard lesson to learn. Time after time, organizations attempt to reduce service times by solely measuring and increasing productivity. Paying attention to the wait time component of service time, in addition to the work time, provides a more balanced view that leads to increases in both labour productivity and information effectiveness.

Chapter 14: Effective Information Flows

Let’s face it. Information is lazy. Billions have been spent on information technologies but no one is able to get the right information at the right time in the right format.

Lada’s Laws are an indicator of information effectiveness. Lean Ratio is the second component of Lada’s Laws:

Lean Ratio = Service Time / Work Time

Where:

Work Time = The total time it would take to create a product or service if there were no blockages or interruptions.

Service Time = The wall clock time to provide a product or service to a customer from initiation to delivery

A Lean ratio of 2 or less indicates the effective use of information within an office. A Lean ratio of 10 or higher is more typical. A ratio of this magnitude indicates that even if the people are busy the information is not.

The Paper Mentality

There are two primary causes of ineffective information:

Processes still conforming to paper-based constraints

Data processing systems

An amazing number of processes are still designed as if paper were the primary transport of data. This was the case during the 50s when time and motion studies were popular; but not today. The large investments made in technology have largely eliminated paper. It’s no longer the preferred transport for information. Whereas paper is disappearing, paper-based constraints to processes are still prevalent.

One constraint paper placed on processes was to make them serial. It was too expensive to copy paper to make parallel flows. Since paper was hard to move, batches of work were passed from one person to the next. The arrival of paper was the equivalent of a baton transfer that indicated a transfer of responsibility for who was to work on it next. Since it was difficult to predict the arrival of paper, people were given many different tasks to insure they stayed busy. And once paper started down a process, it was almost impossible to find it until it emerged out the other side.

Today processes are still bound up by these paper-based constraints. Even though most data now travels electronically. In fact many processes have worse performance now than they did when they were purely paper-based.

Serial processes are still the norm. Batches of work must be completed before new work is started. People keep so many balls in the air that more time are spent juggling than working. Exception processing and expediting are 80% of the effort not 20%. And meanwhile, everyone is deluged with data making it harder and harder to find the information they are looking for.

Breaking Free from the Paper Legacy

To achieve a Lean ratio less than 2 requires a clear focus on discarding paper-based constraints. Lean processes are designed to achieve the continuous flow of information from one customer value added step to the next.

Parallel processes are used to segregate complexity and reduce service times. Work is pulled in priority order only when needed so work-in-process is kept to a minimum. Expediting is eliminated and exceptions are reduced by delivering the right information to the right person at the right time.

The Lean ratio is easy to measure and gives an organization a clear target to shoot for. Rather than a goal to work harder or faster, the Lean ratio focuses attention on making information more effective and as a result makes the organization more effective as well.

Chapter 15: Measuring Process Flow

This chapter describes how to use service time as a measure of process flow.

The productivity of people and tools has dramatically increased over the last 20 years. Yet with all of that increase in productivity, things still seem to take too long to get done. The service times of processes have remained stubbornly high.

Traditional process improvement is conducted from the perspective of helping make people more productive. But what about information? It’s impossible to perform any process without information. However, the productivity of information is largely ignored. In most organizations people are busy but information is lazy.

Why Information is Lazy

To understand why this is true, it is necessary to break service time down into two parts. The first component of Lada’s Law is:

Service Time = Work Time + Wait Time

Where:

Service Time = The wall clock time to provide a product or service to a customer from initiation to delivery

Work Time = The total time it would take to create a product or service if there were no blockages or interruption

Wait Time = The total time a product or service, that is started but not completed, is waiting for any work to be performed. The first component of Lada’s Laws defines the two parts of service time from an information perspective rather than a people perspective. For example, consider the following process:

A service request is received via email.

Information about the request is entered into a database.

Phone calls are made to gather additional information about the request.

The additional information is entered into the database.

It is determined which resources are necessary to complete the request.

The request is sent for fulfilment.

For the above example process there are periods of time when someone is working on the service request (work time), followed by periods of time when the request is waiting for someone to work on it. From the perspective of the request’s information, it is alternately waiting and then being worked. For this process the wait/work cycle repeats at least 5 times.

From the perspective of the individual handling the request, they never wait. They work on multiple service requests, one at a time, each at a different step in the process. The individuals performing this work have very little non-value added time.

It is a different story from the perspective of the service request. Whereas the people are busy, the information about the service request is very lazy.

Making Information as Busy as People

Let’s define the following for the process above:

The average work time to complete the process above for one service request (work time) is .5 hours.

Each person averages a throughput of 2 service requests per hour.

At any point in time each person is assigned an average of 15 service requests; their work-in-process (WIP).

Little’s Law establishes that Work-in-Process = Service Time * Throughput. Since Service Time = Work Time + Wait time, the average wait time for a service request is 7 hours; [(15 / 2) - .5].

Based on this information the people performing the process are very efficient. Their average work time equals their average throughput.

However, the service request information is very lazy. For just this segment of the process, the average service time is 7.5 hours. This means that if you put a tag on a service request that entered the process, that same tagged service request would exit the process an average 7.5 hours later.

For that same tagged service request, someone is actually only working on it for a total of .5 hours. For the 7.5 hours our tagged service request is working its way through the process, it is sitting around doing nothing for 7 of those hours. How lazy can it be?

The invention of Lean is how to make information just as busy and productive as the people of a process. Lean does this without adding more people or more automation. It just requires some process design changes.

Chapter 16: Measuring Service Time

It’s hard to measure what you can’t see and what you can’t manage you can’t measure. This makes measuring and managing the flow of work through a process difficult since flow is a concept of time. Time is hard to see. Many organizations are comfortable with taking snapshot measurements that freeze time. But measuring process flow over time can be both hard to conceptualize and hard to do.

The overlap and inconsistencies in use of the common measures of flow and time is an indicator of the complexity. To establish a framework for discussion consider the following definitions of time:

Wall Clock Time – The continuous measure of time between two milestone events.

Cycle Time – The wall clock time necessary to complete a single item of work.

Lead Time – The wall clock time from when a customer request is made until the request is fulfilled.

Service Time – The wall clock time necessary to provide a service from start to finish.

Cycle time and lead time are probably the most commonly used terms to measure process flow. However both measures are just as commonly misused. Cycle time is the wall clock time to complete one cycle or unit of work such as fill out a form or send an email. Lead time is the wall clock time to fulfil a customer request. Both are used to describe the wall clock time to provide any service from start to finish but each usage is incorrect.

To measure the time both to fill out a form and send an email is actually the sum of the two individual cycle times, or the total cycle time. It’s possible to measure the total cycle time of each step of a process.

Lead time has similar constraints. It is strictly defined as the time from a customer request to fulfilment. If a customer buys a computer on the Internet the lead time is from order submittal to the delivery of the computer to the customer’s location. Good to know, but what if it is also helpful to know the time from order completion to the computer shipment to the customer? By definition that is not called lead time. Partial lead time? Or perhaps total total total cycle time?

Time for a New Approach

Both cycle time and lead time are important measures but their definitions are very specific and do not apply to measuring flow for discrete segments of a process. Service time is defined to fill the gap left by cycle and lead time.

Service time measures the flow of work/information between any two points of a process. It is called service time to emphasize that it is a measure of the wall clock time to provide a specific service either to either an internal or external customer.

Examples of service time (measured in wall clock time):

The time to capture a customer request at a walk-in customer service counter.

The time to finalize a customer request and submit it to engineering.

The time to complete the engineering design of a customer request.

The time to obtain customer approval of a completed engineering design.

Time for Service

Service time could be established for a combination of the above process segments. As well each of the above segments could be broken into more granular service time measurements. In each of the above examples, a service level agreement (SLA) based on service time could be established as a measureable objective for those providing the service.

Lead time and cycle time were originally developed as measures of manufacturing processes. In a non-manufacturing environment their use is limited due to their specific definitions. Or worse their definitions are extended to serve other measurement functions leading to miscommunication and confusion. Service time avoids these limitations by specifying both the service and the time to provide that service, providing an important measure for effectively managing that service.

Chapter 17: Kanban, Kaizen, or Scrum

What do an Andon Board, Kanban, Kaizen, and Scrum have in common? They are all Agile and Lean techniques that can be applied to manage projects. This chapter briefly describes how these techniques work best when tuned to the type work-in-process found in your project.

Andon Board: A Lean term for a visual control device that allows anyone to see and manage the status of the value stream.

Kanban: A Lean term for a visual indicator that indicates when to execute an activity in a value stream.

Kaizen Workshop: A Lean term for workshops to identify and implement improvements to a value stream.

Scrum: An Agile term for a lightweight framework to manage complex projects.

Unfortunately, the above terms are not used consistently by all Agile and Lean practitioners. This in itself is not an issue, but common definitions are useful for clear communications. Current usage may be confusing the concepts behind some of these terms and their fit within organizations.

The term Kanban Board is sometimes used to describe an Andon Board for managing the work-in-process (WIP) of an organization. The board facilitates the movement of WIP from one queue to the next using rules to balance flow and minimize overproduction. It can be a useful tool to help prioritize work and minimize total cycle times.

Agile Scum also has an artefact known as a Scrum Board that is also an Andon Board for managing complex projects. Because of the similar look and feel between the two types of Andon boards sometimes Kanban and Scrum are considered two alternative approaches to accomplish the same goal.

A Kanban Board and a Scrum Board are similar. Both are used to help manage WIP. However the type of WIP that is managed by each is different. A Kanban Board helps to manage the WIP of a value stream or process. A Scrum Board helps to manage the WIP associated with a complex project. A Kanban Board is usually better suited to manage the WIP of individuals and a Scrum Board the WIP of cross-functional teams.

Scrum is actually closer to Kaizen than it is Kanban. Both Scrum and Kaizen are project management approaches to engage cross-functional teams to rapidly complete meaningful improvements within specific time-boxed iterations. In practice Scrum has advantages over the typical Kaizen. Scrum’s approach to managing WIP provides better visibility, prioritization, and predictability of project outcomes over time than Kaizen.

Regardless of what terms you use, managing the WIP of a value stream is different than managing the WIP of a complex project. Visual task boards are helpful for both; but pick the board best suited to your type of WIP. In any case, consider Scrum as an alternative to your next Kaizen.

Chapter 18: Employee Benefits of Agile and Lean in the Office

Cross functional training

Two of the primary wastes found in the office environment are two of the seven wastes; overproduction and of waiting. Both tend to be the result of specialization. If an employee is only trained to do one specialized job, the chances are that on any given day, the employee has either too much work to do or too little. If they have too much work to do, then someone else is waiting for that work; so they have too little to do. If an employee has too little to do then there is a tendency to overproduce by doing something not immediately (or ever) required.

One of the solutions to both overproduction and waiting is cross-functional training so that an employee is always ready to do the next most important thing for the organization. Cross-functional training creates more value for the customer as well as makes the employee more valuable.

Cross-functional training also benefits employees through:

Increased variety of work.

Better sense of contribution and ownership.

Enhanced skill development.

Higher morale.

Continuous improvement

Office environments are complex systems. There can be thousands of integration points as information flows along a value stream. As a result it is almost impossible to understand in detail how a change to one part of a value stream will impact the rest of the system-wide value streams of the organization.

The Agile and Lean approach is to use a program of continuous performance improvement. This approach does not try to accomplish too much at once and risk complete failure, but to make an incremental change to a value stream, wait for the system to settle down, fully understand the system-wide impact of the changes, and then decide what new change to make.

The advantages to employees from this approach is that they

Become engaged in continuous small changes; reducing the risk of change management.

Recognize that barriers to their performance can and are being addressed.

Become change agents and not barriers to change.

Increased responsibility

Scott Adams' Dilbert cartoons are pasted on the walls of almost every office environment. The concepts that form the basis of most Dilbert cartoons are the wasteful practices that employees understand and appreciate but appear to be powerless to do anything about. Lean Office provides a way to engage employees in eliminating the material for Dilbert's cartoons.

Rather than just pasting Dilbert on their cubicle, employees have an increased responsibility to identify and remove the waste from their organization. This is not employee empowerment with a blank sheet of paper. This is a bottom-up empowerment with a focus on removing waste from the organization. Management retains responsibility for the value streams of the organization; employees accept responsibility to constantly remove the waste from those value streams.

Increasing employee responsibility for waste reduction creates a sense of employee ownership and pride for their workspace and becomes a strong motivator for employee performance.

Increased satisfaction

Lean as applied to the office environment can be a very effective way to delineate between the roles of employees and the roles of management. By better defining their individual roles, there is less business friction caused by overlapping responsibilities and unclear expectations.

Lean Office also establishes a stronger linkage between the strategic goals and direction of the organization and the tactical contributions each employee makes towards achieving the defined strategies.

Employee satisfaction is increased through a better understanding of where their contribution fits within the system-wide value creation activities of the organization. They are provided the visibility of how and where they contribute value, and they are given the opportunity to find ways both to increase that value and reduce non-value added activities. The optimum recipe for job satisfaction.

Chapter 19: Customer Benefits of Agile and Lean Office

Increased flexibility

We are moving from the age of mass production to the age of mass customization. Agile businesses are now marketing to customer segments of one. Agile and Lean methods help establish flexible operational value streams designed to adjust automatically to customer demand.

Value stream mapping is an approach called continuous flow to increase the flexibility of customer offerings. Continuous flow takes advantage of just-in-time, pull systems, and cross-functional training to minimize the work-in-process and cycle times. This means that the time from a customer request to the time it is delivered can be shortened to the point where a product or service can be developed and customized specifically for a customer; after it is requested.

Fewer Defects

The cost of quality is free. This statement generates controversy inside many organizations, but to a customer it is obviously true. Customers do not want to pay more for quality. They assume the product or service they receive provides the benefits they requested.

Agile and Lean do not use expensive quality assurance programs that check for defects just prior to providing the customer the product or service. In the world of Agile and Lean, quality assurance is a waste to be reduced as much as possible. Instead Agile and Lean searches for waste within for all activities of the customer value streams; from start to finish. Agile and Lean also seeks to mistake proof processes so that defects cannot occur.

As a result customers see quality improvements from what is not happening. And since the events causing poor quality are not happening, quality actually costs less than free. The organization literally gets money back.

Faster Service

Agile & Lean techniques reduce the time it takes to process any customer request. Agile & Lean do this by reducing all of the wait states that typically occur while processing a request.

Processing occurs in a continuous flow

Take for example the processing of a sales order. By the time the sales order has undergone multiple processing steps the amount of time it waits in various queues can be substantial. Eliminating this wait time can eliminate 90% of the time to process a sales order.

As a result of this faster service, customers don't need to call into customer service to check on the status of their order. By the time they would call the order would already be processed. Not only is the service faster, but both the customer and the organization save from having to check on the service status.

Greater Satisfaction

Agile and Lean provide significant benefits to the organization that adopts it. Agile and Lean organizations provide greater customer value with higher quality at less cost. Agile and Lean organizations generate better returns on their investments in labour and capital. These benefits positively impact the organization's top and bottom lines.

Each of the above are internal benefits to the organization. There are external benefits to their customers as well. From a customer point of view an Agile and Lean organization provides them the product or service they need, customized to their specific requirements, with the quality they expect, in a highly responsive manner. This is an equation for happy customers; and happy customers buy more, tell other customers of their experience, and become engaged in ensuring the organization's future success.

Chapter 20: Financial Benefits of Agile and Lean Office

Increased flexibility

Agile and Lean provide the means to better manage and measure the return on labour investment. Value stream maps create management visibility into the invisible processes of the office environment. They provide management greater insights on how work actually flows through the organization, where potential bottlenecks exist that rob performance, and where labour investments can generate the largest returns.

The quest to maximize value added work and reduce or eliminate non-value added work also brings into clear focus how labour is allocated to both. The direct impact of reducing non-value added work is an increased return on labour investment. In addition, an indirect impact of Agile and Lean on labour investment results from the increased satisfaction of employees. Happy motivated employees perform better than those that are not.

Better use of the organization's assets

Traditional operational improvement approaches (such as business process reengineering) do not take a system-wide view of how all of the organization's assets are allocated towards producing customer value. Lean Office considers all five drivers of operational performance.

Men and women

Machines

Methods

Materials

Measures

Agile and Lean techniques help to align each of the five M's to maximize customer value creation. The unrelenting hunt for waste in each of the five M's helps insure those assets are effectively and efficiently utilized.

Reduced cost of non-quality

The cost of non-quality as the financial impact due to the production of waste by the organization. When most organizations measure the cost of non-quality they only measure the financial loss due to the production of errors, rework, or scrap. Each of these is a defect, which is only one of the seven wastes. There are six other wastes that are included in a hunt for non-value added activities.

Every waste discovered consumes resources of the organization. In addition to the waste itself, exception processing can represent a significant drain on the organization. Reducing or eliminating waste frees up the labour and capital used to create the waste and to later fix it; enabling these resources to be used in other value added activities and reducing the cost of non-quality.

Improved revenue and profits

The breakthrough thinking associated with Agile and Lean is the unrelenting focus on maximizing the creation of customer value. This becomes the responsibility of every employee in the organization. Rather than just looking at top and bottom-line performance, every set of eyes in the company is looking for the smallest amount of waste in every activity performed in every value stream of the company.

The results are dramatic improvements in the amount of customer value produced by the organization. Even small reductions in waste start to make significant contributions when multiplied by thousands of activities. Increased customer value ultimately increases top-line revenue. Customers are willing to pay for value. Since the increased revenue is produced with higher productivity and less labour and capital expense, profits also increase. Increasing both revenues and profits is a combination to benefit any organization.

Chapter 21: Operational Benefits of Agile and Lean Office

Reduced service time

Service time is the wall clock time necessary to complete one item of value. In the example of a sales order let's assume that an organization receives 100 orders per day. We can determine the service time of the value stream that flows from the receipt of the order until the order is released to fulfilment. For our example, let's assume that the average service time for each sales order is 48 hours. Some orders will take more and some less.

Now let's assume the work time for each order averages 1 hour. Work time is the wall clock time spent performing direct value added activities within a value stream. The 1 hour work time for a sales order includes the time spent by various people for data entry, customer contact, quality assurance, etc. that was performed with regards to processing the order.

In Lean Office, the time difference between the cycle time and the work time is waste.

Reduced work time

Work time is the wall clock time spent performing direct value added activities within a value stream. Some of the work time associated with a value stream can be associated with non-value added work and the rest with value added work. Lean Office strives to maximize the value added work and reduce the non-value added work. Reducing the non-value added work reduces the total work time and therefore the cost, to execute the value stream.

Increased quality

In many environments the primary measure of quality is defects; the number of errors produced. I expand the definition of quality to maximizing customer value added activities while minimizing non-value added activities. A defect is just one of the seven categories of non-value added activities or waste. The root cause of most defects is one or more of the six other forms of waste. Removing or eliminating these wastes increases overall product or service quality.

Another concept of Agile and Lean that contributes to increased quality is "stop-the-line." Stop-the-line allows anyone to stop processing when a defect is found and investigate its root cause. This creates a tight feedback loop between contributors to a value stream.

Immediately stopping the line

Prevents defects from being propagated downstream through the value stream.

Provides immediate feedback to individuals introducing defects; the strongest method for inducing individual change.

Facilitates continuous quality improvement.

Increased throughput

Throughput is the velocity of work performed by a value stream. For example the number of sales orders processed per day or the number of press releases posted per month. The goal of increased throughput can either be

Increase the value produced per unit of time for the same organizational cost, or

Maintain the same level of throughput at a reduced cost to the organization.

Agile and Lean helps to increase throughput by tightly stringing together the value added activity of a value stream in a continuous flow model. As soon as one value added activity of a value stream is completed the next is started with little or no waiting. Eliminating or reducing non-value added activities allows the freed up time and resources to be spent on value added activities. Quality is increased, reducing the number of defects, further increasing the average throughput.

Chapter 22: Strategic Benefits of Agile and Lean Office

Strategic and tactical alignment

Agile and Lean is all about maximizing customer value. With Agile and Lean, the culture of the organization changes so that everyone knows exactly the customer value being created and their role in its creation. The Agile and Lean culture establishes a firm foundation for then tying the strategic direction of the organization with the tactical day-to-day value creation.

Agile & Lean techniques include an approach known as strategy deployment. Strategy deployment is a top down planning process that ties strategic direction to the vital few tactical initiatives for realizing the desired business outcomes. Strategy deployment is an iterative process that starts with analysis of the organization and its market, the formation of an initial strategy, the review of that strategy against existing value streams, and then the feedback to start the next iteration. This consensus building iterative process is sometimes called catch-ball.

When completed, strategy deployment establishes clear links between strategy and its impact on the value streams of the organization. Since everyone in the organization knows how they contribute to the value streams, they understand how they are impacting strategy. This allows the organization to react as a single interdependent system in strategic and tactical alignment.

Increased agility

Agile organization is the ability to be nimble and turn quickly in reaction to market changes. Agile organizations satisfy their customers early and often. Agile and Lean techniques help organizations become more agile by first giving them more visibility and control of their customer value producing value streams. What you can't see you can't manage. Value stream mapping and visual controls provide tools for managing agility.

Quicker time to market

Lean Production techniques were first applied by Toyota on factory shop floors where there was consistency to the number and types of products being produced. But soon Toyota began to apply Lean concepts to their engineering organizations as well. Still today, Toyota can engineer a new car in almost half the time of an American automobile manufacturer.

An Agile and Lean approach works just as well with the repetitive nature of sales order processing and customer service as it does to product marketing and development. Value stream maps provide a system-wide view to focus the work of interdisciplinary working teams; to both align their efforts and to streamline their results. Customer value streams that are tied directly to strategic direction become a vehicle for communicating to all employees customer priorities. The value stream maps become the tools to help maximize customer value creation and eliminate non-value added waste. And through the use of continuous flow, the value stream maps help accelerate the time it takes to define, build, and launch a new product or service.

Greater market segmentation

Henry Ford is attributed with starting the era of mass production in the early 1900s. Mass production enabled the mass market to buy a car as long as they wanted it black. Taiichi Ohno of Toyota is attributed with starting the era of Lean Production in the 1950s. Lean can be described as mass customization. Lean retains the ability (if necessary) to maintain high throughput, but also allows high customization of the product or service.

Good Luck!