Agile Goes Big Using SAFe

This week I had the opportunity to meet and hear Dean Leffingwell talk on Scaled Agile Framework (SAFe) and its history. It was fascinating to hear him recount the early days of Agile, and how the SAFe came into existence. What impressed me most was how he continually tied Agile and SAFe back to the teachings of Taiichi OhnoW. Edwards Deming, and to the Lean concepts underpinning Agile. I am a late arrival on the software development scene, and I was working to improve First Call Resolution in an airline call center while people like Dean, Al Shalloway, and Mary and Tom Poppendieck were figuring out how to apply Jim Womack’s  “lean thinking” to software development. It was a great presentation and while I have many more questions than answers, I am sold on the concept that Agile can scale effectively.

The Scaled Agile Framework (SAFe) is a proven knowledge base for implementing agile practices at enterprise scale. SAFe’s primary user interface is a “Big Picture” graphic (http://scaledagileframework.com/) which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level. (The image at the top right is literally just one corner.) If you are serious about process improvement in the IT space, I strongly recommend you check this out.

(http://scaledagileframework.com/)

Image-Detail of the Scaled Agile Framework (SAFe) Big Picture.

The Scaled Agile Framework is a proven knowledge base for implementing agile practices at enterprise scale. Its primary user interface is a “Big Picture” graphic which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level.

The Big Picture describes three levels of scale:
Team, Program and Portfolio. Each of these scales the essential agile elements of Value (requirements and backlogs) Teams (from development team through portfolio) and Timebox (iteration, PSI, budget cycle). This model of agile adoption has been elaborated primarily in Dean Leffingwell’s books Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) and Scaling Software Agility: Best Practices for Large Enterprises, (2007) and his scalingsoftwareagility blog.


Further Reading

Leffingwell, Dean (2011).
Agile Software Requirements, Lean Requirements Practices for Teams, Programs, and the Enterprise,
Addison-Wesley Professional, ISBN 978-0321635846.

Leffingwell, Dean (2007).
Scaling Software Agility, Best Practices for Large Enterprises,
Addison-Wesley Professional, ISBN 978-0321458193.

 

Bob Hubbard, July 2013

Advertisements

Toyota’s People System

I’ve combined a couple of things in this post. The video is from a local news report of how the Toyota Production System (what most of us generically refer to as “lean”. The rest of the post was compiled by the Public Relations Department of Toyota’s Georgetown Kentucky plant. It doesn’t seem to still be on their active website, but I think it remains a great primer on how Toyota uses a superior management system to achieve superior results.
bh


.


The “Thinking” Production System:

TPS as a winning strategy for developing people in the global manufacturing environment

At the 2003 Automotive Parts System Solution Fair held in Tokyo, June 18, 2003, Teruyuki Minoura, Toyota’s  an aging director of global purchasing at the time, talked about his experiences with TPS (the Toyota Production System), and what it means for suppliers and for the future of the auto industry.

At the 2003 Automotive Parts System Solution Fair, held in Tokyo, June 18, 2003, Teruyuki Minoura, then-managing director of global purchasing, Toyota Motor Corporation, talked about his experiences with TPS (the Toyota Production System), and what it means for suppliers and for the future of the auto industry.

Teruyuki Minoura
Teruyuki Minoura

Teruyuki Minoura is confident that the long-standing principles of the Toyota Production System will not change in the future, and that TPS will be able to meet any challenge. He noted that the system originally emerged through a trial-and-error approach aimed at solving practical problems and meeting the needs of the company. Recalling painful memories of the labor dispute of 1950 that destroyed so many friendships, he observed, “Businesses suffer if efforts are devoted to raising productivity when the products themselves cannot sell.” It was through such experiences, that the basic concept of just-in-time was born.

In simplest terms, Just-in-time is “all about producing only what’s needed and transferring only what’s needed,” says Minoura. Instead of the old top-down “push” system, it represented a change to a “pull” system where workers go and fetch only what is required. Tools, including the kanban (information card), andon (display board), and poka yoke (error prevention) were developed to implement the pull system. But, Minoura warns “simply introducing kanban cards or andon boards doesn’t mean you’ve implemented the Toyota Production System, for they remain nothing more than mere tools. The new information technologies are no exception, and they should also be applied and implemented as tools.”

Early in his career, Minoura worked under Taiichi Ohno, recognized as the creator of the Toyota Production System. Ohno, through tireless trial and error, managed to put into practice a “pull” system that stopped the factory producing unnecessary items. But Minoura observes that it was only by developing this “loose collection of techniques” into a fully-fledged system, dubbed the Toyota Production System or TPS, that they were able to deploy this throughout the company.

Why 5 Whys?

I’m a big fan of Pete Abilla’s shumla blog.  Way back in the spring of 2007, the title of Pete’s post was “Ask ‘Why’ Five Times About Every Matter”. This is a quote from the visionary Taiichi Ohno. I’ve re-posted below and I hope you get as much out of this as I have.


“Ask ‘Why’ Five Times About Every Matter”

by Pete Abilla on April 16, 2007

Taiichi Ohno is known to have said that “having no problems is the biggest problem of all.”  He viewed problems not as a negative but as a “Kaizen opportunity in disguise.”  Whenever problems arose, he encouraged his staff to investigate the problem at the source and to as “ask ‘why’ five times about every matter (src).”

In a series of events, where people are involved, mistakes happen.  Functional areas such software engineering, industrial engineering or more general areas such as medicine, law, or sociology — these areas are composed by a series of events, involving people, process, machines, environment, and other items.  Undoubtedly, mistakes will happen. What typically happens in response to mistakes is that blame is thrown around, which builds resistance, then communication fails which could lead to project failure. The better approach is to identify the root causes of mistakes and attacking that, instead of what might be perceived as the cause: Perceived causes are most likely symptoms and not the root cause, in which case the problem was never really solved. This, more rigorous and long-lasting, approach to solving problems is called Root Cause Analysis.

Ohno was fond of using the following example to illustrate Root Cause Analysis:

1. “Why did the robot stop?”
The circuit has overloaded, causing a fuse to blow.
2. “Why is the circuit overloaded?”
There was insufficient lubrication on the bearings, so they locked up.
3. “Why was there insufficient lubrication on the bearings?”
The oil pump on the robot is not circulating sufficient oil.
4. “Why is the pump not circulating sufficient oil?”
The pump intake is clogged with metal shavings.
5. “Why is the intake clogged with metal shavings?”
Because there is no filter on the pump.

There are several tools that can aid in the process of Root Cause Analysis.  Basically, it is a simple approach of asking “why” several times until you arrive at an atomic but actionable item. To visually view the process of the “5-why’s”, a tool called an (Ishikawa Diagram) or a (Cause-and-Effect Diagram) or a (Fishbone Diagram) is often helpful — this tool is referred by either of these.

ishikawa diagram

Main Components of an Ishikawa Diagram

  1. At the head of the Fishbone is the defect or effect, stated in the form of a question.
  2. The major bones are the capstones, or main groupings of causes.
  3. The minor bones are detailed items under each capstone.
  4. There are common capstones, but they may or may not apply to your specific problem. The common ones are:
  • People
  • Equipment
  • Material
  • Information
  • Methods/Procedures
  • Measurement
  • Environment

After completing your Fishbone Diagram excercise as a group, it is helpful to test your logic by working the bones: top-down OR bottom-up like:

this happens because of g; g happens because of f; f happens because of e; e happens because of d; d happens because of c; c happens because of b; b happens because of a.

The excercise above is crucially important — you must test your logic so that it makes pragmatic sense and that the atomic root cause is actionable — that is, you can do something to correct it, reduce it, or eliminate the root cause.

Once you or your team arrive at a root cause for a specific capstone, then you typically “cloud” it to identify it as a root cause. A good rule is that there is typically *NOT* 1 root cause for a problem, but potentially several. Below is a diagram of one fishbone, decomposed:

ishikawa, fishbone, shmula.com

A Few Helpful Hints

  1. It is helpful to pull many people into the construction of these diagrams, as this ensures enough diversity of thought to make sure you get the righ potential root causes.
  2. Keep asking “why” until you arrive at something atomic and actionable.
  3. The purpose of this tool is to answer a question, then brainstorm about how to fix the identified root cause.
  4. Getting more people involved will give them a sense of ownership — and that sense of ownership is very important because now that they feel part of the process, resistance to change will likely be less of a problem.

Real-World Example of Root Cause Analysis

I once helped a large healthcare organization save several million dollars. This organization had the largest call center in California, handling over 8 million calls per year. These were mostly inbound calls, resulting from some internal mistake that caused people to call. My job was to identify the largest opportunity (call type), why are people calling, and eliminating or reducing the root causes.

After pulling log file data and running this enormous data set against my handy-dandy, home-grown regular expression engine (written in Python), we stratified the data into logical stratifications and identified that the largest number of calls into the call center were calls related to a specific product. This discovery naturally begs the question “why” — i.e., this question forms the head of our fishbone: “Why are x% of calls related to x product type?”

We got a cross-functional team together and proceeded with the Ishikawa excercise and identified several root causes. After running the root causes against a prioritization matrix, we went after the low hanging fruit, then the more difficult root causes after that. The result? We demonstrated a quantifiable reduction of inbound calls of this specific type — a reduction of ~8%, which amounted to over $2 Million Dollars in cost savings.

Facts Versus Data

Ohno seems to see a difference in the two.  In his words,

“The root cause of any problem is the key to a lasting solution,” Ohno used to say.  He constantly emphasized the importance of genchi genbutsu, or ‘going to the source,’ and clarifying the problem with one’s own eyes. ”‘Data’ is of course important in manufacturing,” he often remarked, “but I place greatest emphasis on ‘facts.’”

I believe what he means is that data, is a degree removed from the actual place where the phenomena is happening.  He placed a greater value on being where the work is done and where value is added.  Whereas data is often on a computer screen or on paper.  He preferred to be at the source of the phenomena.

More Fish To Go Around

Root Cause Analysis can be used anywhere. In software engineering, it can be used to identify the root causes of bugs in code; in industrial engineering, root cause analysis can be used to identify defects in design; in medicine, root cause analysis can be used to arrive at the reasons for mistakes or lack of patient satisfaction.

Root Cause Analysis is a helpful business tool with application to all areas of business and technology. Eliminating or reducing the root cause is much more effective than fixing a symptom. Involving people in the process will ensure buy-in and the elimination of resistance.

Creating an Improvement Culture

Ohno believed that by empowering each associate to have ownership and improve their work and the Gemba, that is how innovation is achieved and a culture of improvement is created — it is empowering your people to make the right changes using the tools that work — Root Cause Analysis is one of the tools that can help empower your employees and help to create a culture of improvement throughout your enterprise.  One item missed by most people is that Toyota doesn’t just build cars, but it also builds people.  Root Cause Analysis is an effective tool that helps associates feel empowered to make their everyday work better.


Check out Pete’s blog at http://www.shmula.com/

The Amazing Adventures of Kanban

I decided to repost this since it is such a great way to think about the power of kanbans. It’s from Jon Miller from his blog “gemba panta rei” . Enjoy!
bh

By Jon Miller | Post Date: June 17, 2009 12:57 PM (http://www.gembapantarei.com/2009/06/the_amazing_adventures_of_kanban.html)

kanban man

Kanban was born nearly 60 years ago. It’s creator, Taiichi Ohno, intended kanban to combat the evil overlord Overproduction, Mother of All Wastes and her Minions of WIP. The battle is far from won. During those six decades kanban has been through some amazing adventures.

Kanban Gains Superpowers

Pokayoke has the power to prevent mistakes. Jiodka frees people to run machines intelligently, rather than be run by them. Heijunka has the power to take choppy demand and smooth it out. Kaizen has the power to make infinite small improvements. All of these players and their many friends bring order and harmony to a production system. Yet one stands above them all: kanban.

Kanban was endowed with three major powers. First is the the power to instruct the production of goods. Within the Toyota Production System and its imitators, only the kanban has the power to cause things to be made. Second is the power to instruct the movement of goods. Like its first power, kanban can cause things to be moved. Third and perhaps most important, kanban can motivate people towards continuous improvement by reducing its own size. Within a kanban system, the less kanban there is, the more improvement is needed. Like a true hero, the power of kanban increases as it diminishes its own presence. Amazing.

Kanban vs. the Communists

From the beginning, the powers of kanban were awesome. Overproduction was stopped in its tracks, Work In Process (WIP) was slashed, and various hidden wastes were exposed and removed through continuous improvement. Almost immediately kanban extended its reach outside of Toyota, the enterprise within which it was born, to its suppliers.

But there was no way that such drastic action would go unnoticed in Japan, the Land of Wa (harmony). A Japanese communist party member accused Toyota of using kanban to make unreasonable demands on suppliers to deliver products right away. Taiichi Ohno was summoned to the Japanese parliament to testify in defense of Toyota’s use of the cards to order suppliers to make deliveries of parts. In the end, the Japanese equivalent of the Fair Trade Commission instructed OEMs to limit the fluctuation of actual monthly orders to suppliers by no more than 10% from the firm monthly orders placed in advance.

Perhaps kanban was becoming too powerful. The government needed step in to curb kanban’s powers, or at least insure they were always used for good. It was a lesson learned. None of the others, not pokayoke, not jidoka, no tkaizen have been called to testify in front of the government, or to face down the communists.

Kanban: the Fickle Hero

But for all its powers kanban was at times fickle. To kanban, jidoka, SMED and pokayoke were just sidekicks, enablers. Kanban treated both 5S and Visual Controls as givens rather than equals. Kaizen may be an equal partner to kanban, but in private kanban lorded over kaizen because of its power to motivate others to improve. While these various players toiled away at making improvements and building systems, kanban expected that their work was all foundation building for the kanban system. Kanban never said a word of thanks, nor asked for one.

Like a temperamental artist who wants just the right type of bottled water and sandwiches in his dressing room, kanban said “I will only work for you if once the workplace is clean and visually organized, quality is reliable, lot sizes are small and a logistics system is in place to support me.” Kanban would not do the heavy lifting for you. Kanban would let you know when you’re failing, but may not always come to the rescue. Kanban is a powerful but fickle hero, relied on at your own risk.

Kanban on the Global Stage

In the 1980s Taiichi Ohno was invited to the USA to speak about the Toyota Production System. Unfortunately the organizers confused kanban, the most noticeable feature of TPS, for the system itself. Kanban stole the show, overshadowing the shadowing even the system it was designed to enable. This was not what its creator Taiichi Ohno intended.

As kanban took the global stage with hubris, inevitably its powers were misunderstood or misdirected. Without the protection of the limits on demand signal fluctuation, OEMs abused suppliers with what can be best described as quasi-kanban. Kanban saw its name sullied by impostors and imitators. Even when kanban was called to use its powers, too often it was pressed into service without the support of its friends pokayoke, SMED, heijunka, visual controls and 5S. Even when they were nearby, they were prevented from working as a team.

Kanban of 1,000 Disguises

Kanban’s powers were weakened as much was lost in translation. In order to effectively combat overproduction in its new and vastly diverging environments, kanban adopted a thousand disguises. Some were more effective than others. Each time kanban answered the call to battle overproduction, it seemed it was in a different form: a lamp, a card, a square on the floor, a box, a cart.

kanban as signal.png

Kanban continues to be misunderstood even today, with many unsure of which is the true face of kanban. But the battles rages on against the evils of overproduction.

Kanban and the Builders of Invisible WIP

Early in the 21st century, kanban found an unexpected band of allies. These people were prolific builders of invisible but deadly WIP. They were software developers. Appearing not as information traveling with the manufactured work product itself but rather represented on a task board, kanban works tirelessly to control even the invisible WIP of lines of code.

agile kanban.png

Once again, kanban added a new form to its one thousand disguises in order to combat overproduction in on a new battlefield.

Yes We Kanban

Today Kanban finds itself in an uneasy but increasingly important alliance with the Coders through the Limited WIP Society. Flying the banner of kanban’s creator and genius production system designer Taiichi Ohno, kanban has found a common aim with this league of mad scientists: to ultimately defeat WIP and it’s overlord Overproduction.

yes we kanban.png

How much progress will kanban’s alter-ego of Agile Kanban make in exercising its three superpowers across the software development world? Only time will tell.

Kanban Meets Dr. Bahri the Lean Dentist

Kanban may have met its match in Dr. Bahri, the pioneering practitioner of lean dentistry. Dr. Bahri has applied the powers of kanban to instruct the work that dentists and dental hygienists do, to instruct the movement of patients, and to motivate continuous improvement. Wouldn’t it be ironic if six decades into an amazing career, kanban goes for some dental work and finds the power of kanban applied to fixing its teeth?

The villains of overproduction, push and WIP never sleep. The amazing adventures of kanban continue…

Toyota Production System

The “Thinking” Production System:

TPS as a winning strategy for developing people in the global manufacturing environment

At the 2003 Automotive Parts System Solution Fair held in Tokyo, June 18, 2003, Teruyuki Minoura, Toyota’s an aging director of global purchasing at the time, talked about his experiences with TPS (the Toyota Production System), and what it means for suppliers and for the future of the auto industry.

At the 2003 Automotive Parts System Solution Fair, held in Tokyo, June 18, 2003, Teruyuki Minoura, then-managing director of global purchasing, Toyota Motor Corporation, talked about his experiences with TPS (the Toyota Production System), and what it means for suppliers and for the future of the auto industry.

Teruyuki MinouraTeruyuki Minoura is confident that the long-standing principles of the Toyota Production System will not change in the future, and that TPS will be able to meet any challenge. He noted that the system originally emerged through a trial-and-error approach aimed at solving practical problems and meeting the needs of the company. Recalling painful memories of the labor dispute of 1950 that destroyed so many friendships, he observed, “Businesses suffer if efforts are devoted to raising productivity when the products themselves cannot sell.” It was through such experiences, that the basic concept of just-in-time was born.

In simplest terms, Just-in-time is “all about producing only what’s needed and transferring only what’s needed,” says Minoura. Instead of the old top-down “push” system, it represented a change to a “pull” system where workers go and fetch only what is required. Tools, including the kanban (information card), andon (display board), and poka yoke (error prevention) were developed to implement the pull system. But, Minoura warns “simply introducing kanban cards or andon boards doesn’t mean you’ve implemented the Toyota Production System, for they remain nothing more than mere tools. The new information technologies are no exception, and they should also be applied and implemented as tools.”

Early in his career, Minoura worked under Taiichi Ohno, recognized as the creator of the Toyota Production System. Ohno, through tireless trial and error, managed to put into practice a “pull” system that stopped the factory producing unnecessary items. But Minoura observes that it was only by developing this “loose collection of techniques” into a fully-fledged system, dubbed the Toyota Production System or TPS, that they were able to deploy this throughout the company.