More on A3 Problem Solving

from Tomas Björkholm

Scrum, Agile, Lean & Kanban- coach

A3 problem solving template

One of the core tenets of Lean Thinking is Kaizen – continuous process improvement. Toyota, one of the successful companies in the world, attributes much of their success to their highly disciplined problem solving approach. This approach is sometimes called A3 thinking (based on the single A3-size papers used to capture knowledge from each problem solving effort).
Here’s a real-life A3 problem solving example and template. This double-sided A 3 document contains an A3 problem solving template on one side and a real-life example on the other side.

A3 template

This example was developed by Tom Poppendieck and Henrik Kniberg and used in conjunction with Deep Lean 2009 in Stockholm and Agile 2009 in Chicago. The example is based on a real case, and we use it regularly when teaching and coaching lean problem solving techniques.

Gladwell Tweaking Steve Jobs

I’ve always loved Apple. My first real computer was a Mac+ that I bought in 1986. I have come to love Malcolm Gladwell’s work and while I loved The Tipping Point, I became a full fledged fan after reading Outliers. So I was interested when this article from The New Yorker popped up in my reading list. The following is a repost of that article… and it’s insightful. (or at least I thought so…)

Annals of Technology

The Tweaker

The real genius of Steve Jobs.

by Malcolm Gladwell
November 14, 2011


Jobs’s sensibility was more editorial than inventive. “I’ll know it when I see it,” he said.

Not long after Steve Jobs got married, in 1991, he moved with his wife to a nineteen-thirties, Cotswolds-style house in old Palo Alto. Jobs always found it difficult to furnish the places where he lived. His previous house had only a mattress, a table, and chairs. He needed things to be perfect, and it took time to figure out what perfect was. This time, he had a wife and family in tow, but it made little difference. “We spoke about furniture in theory for eight years,” his wife, Laurene Powell, tells Walter Isaacson, in “Steve Jobs,” Isaacson’s enthralling new biography of the Apple founder. “We spent a lot of time asking ourselves, ‘What is the purpose of a sofa?’ ”

It was the choice of a washing machine, however, that proved most vexing. European washing machines, Jobs discovered, used less detergent and less water than their American counterparts, and were easier on the clothes. But they took twice as long to complete a washing cycle. What should the family do? As Jobs explained, “We spent some time in our family talking about what’s the trade-off we want to make. We ended up talking a lot about design, but also about the values of our family. Did we care most about getting our wash done in an hour versus an hour and a half? Or did we care most about our clothes feeling really soft and lasting longer? Did we care about using a quarter of the water? We spent about two weeks talking about this every night at the dinner table.”

Steve Jobs, Isaacson’s biography makes clear, was a complicated and exhausting man. “There are parts of his life and personality that are extremely messy, and that’s the truth,” Powell tells Isaacson. “You shouldn’t whitewash it.” Isaacson, to his credit, does not. He talks to everyone in Jobs’s career, meticulously recording conversations and encounters dating back twenty and thirty years. Jobs, we learn, was a bully. “He had the uncanny capacity to know exactly what your weak point is, know what will make you feel small, to make you cringe,” a friend of his tells Isaacson. Jobs gets his girlfriend pregnant, and then denies that the child is his. He parks in handicapped spaces. He screams at subordinates. He cries like a small child when he does not get his way. He gets stopped for driving a hundred miles an hour, honks angrily at the officer for taking too long to write up the ticket, and then resumes his journey at a hundred miles an hour. He sits in a restaurant and sends his food back three times. He arrives at his hotel suite in New York for press interviews and decides, at 10 P.M., that the piano needs to be repositioned, the strawberries are inadequate, and the flowers are all wrong: he wanted calla lilies. (When his public-relations assistant returns, at midnight, with the right flowers, he tells her that her suit is “disgusting.”) “Machines and robots were painted and repainted as he compulsively revised his color scheme,” Isaacson writes, of the factory Jobs built, after founding NeXT, in the late nineteen-eighties. “The walls were museum white, as they had been at the Macintosh factory, and there were $20,000 black leather chairs and a custom-made staircase. . . . He insisted that the machinery on the 165-foot assembly line be configured to move the circuit boards from right to left as they got built, so that the process would look better to visitors who watched from the viewing gallery.”

Isaacson begins with Jobs’s humble origins in Silicon Valley, the early triumph at Apple, and the humiliating ouster from the firm he created. He then charts the even greater triumphs at Pixar and at a resurgent Apple, when Jobs returns, in the late nineteen-nineties, and our natural expectation is that Jobs will emerge wiser and gentler from his tumultuous journey. He never does. In the hospital at the end of his life, he runs through sixty-seven nurses before he finds three he likes. “At one point, the pulmonologist tried to put a mask over his face when he was deeply sedated,” Isaacson writes:

Jobs ripped it off and mumbled that he hated the design and refused to wear it. Though barely able to speak, he ordered them to bring five different options for the mask and he would pick a design he liked. . . . He also hated the oxygen monitor they put on his finger. He told them it was ugly and too complex.

One of the great puzzles of the industrial revolution is why it began in England. Why not France, or Germany? Many reasons have been offered. Britain had plentiful supplies of coal, for instance. It had a good patent system in place. It had relatively high labor costs, which encouraged the search for labor-saving innovations. In an article published earlier this year, however, the economists Ralf Meisenzahl and Joel Mokyr focus on a different explanation: the role of Britain’s human-capital advantage—in particular, on a group they call “tweakers.” They believe that Britain dominated the industrial revolution because it had a far larger population of skilled engineers and artisans than its competitors: resourceful and creative men who took the signature inventions of the industrial age and tweaked them—refined and perfected them, and made them work.

In 1779, Samuel Crompton, a retiring genius from Lancashire, invented the spinning mule, which made possible the mechanization of cotton manufacture. Yet England’s real advantage was that it had Henry Stones, of Horwich, who added metal rollers to the mule; and James Hargreaves, of Tottington, who figured out how to smooth the acceleration and deceleration of the spinning wheel; and William Kelly, of Glasgow, who worked out how to add water power to the draw stroke; and John Kennedy, of Manchester, who adapted the wheel to turn out fine counts; and, finally, Richard Roberts, also of Manchester, a master of precision machine tooling—and the tweaker’s tweaker. He created the “automatic” spinning mule: an exacting, high-speed, reliable rethinking of Crompton’s original creation. Such men, the economists argue, provided the “micro inventions necessary to make macro inventions highly productive and remunerative.”

Was Steve Jobs a Samuel Crompton or was he a Richard Roberts? In the eulogies that followed Jobs’s death, last month, he was repeatedly referred to as a large-scale visionary and inventor. But Isaacson’s biography suggests that he was much more of a tweaker. He borrowed the characteristic features of the Macintosh—the mouse and the icons on the screen—from the engineers at Xerox PARC, after his famous visit there, in 1979. The first portable digital music players came out in 1996. Apple introduced the iPod, in 2001, because Jobs looked at the existing music players on the market and concluded that they “truly sucked.” Smart phones started coming out in the nineteen-nineties. Jobs introduced the iPhone in 2007, more than a decade later, because, Isaacson writes, “he had noticed something odd about the cell phones on the market: They all stank, just like portable music players used to.” The idea for the iPad came from an engineer at Microsoft, who was married to a friend of the Jobs family, and who invited Jobs to his fiftieth-birthday party. As Jobs tells Isaacson:

This guy badgered me about how Microsoft was going to completely change the world with this tablet PC software and eliminate all notebook computers, and Apple ought to license his Microsoft software. But he was doing the device all wrong. It had a stylus. As soon as you have a stylus, you’re dead. This dinner was like the tenth time he talked to me about it, and I was so sick of it that I came home and said, “Fuck this, let’s show him what a tablet can really be.”

Even within Apple, Jobs was known for taking credit for others’ ideas. Jonathan Ive, the designer behind the iMac, the iPod, and the iPhone, tells Isaacson, “He will go through a process of looking at my ideas and say, ‘That’s no good. That’s not very good. I like that one.’ And later I will be sitting in the audience and he will be talking about it as if it was his idea.”

Jobs’s sensibility was editorial, not inventive. His gift lay in taking what was in front of him—the tablet with stylus—and ruthlessly refining it. After looking at the first commercials for the iPad, he tracked down the copywriter, James Vincent, and told him, “Your commercials suck.”

“Well, what do you want?” Vincent shot back. “You’ve not been able to tell me what you want.”
“I don’t know,” Jobs said. “You have to bring me something new. Nothing you’ve shown me is even close.”
Vincent argued back and suddenly Jobs went ballistic. “He just started screaming at me,” Vincent recalled. Vincent could be volatile himself, and the volleys escalated.
When Vincent shouted, “You’ve got to tell me what you want,” Jobs shot back, “You’ve got to show me some stuff, and I’ll know it when I see it.”

I’ll know it when I see it. That was Jobs’s credo, and until he saw it his perfectionism kept him on edge. He looked at the title bars—the headers that run across the top of windows and documents—that his team of software developers had designed for the original Macintosh and decided he didn’t like them. He forced the developers to do another version, and then another, about twenty iterations in all, insisting on one tiny tweak after another, and when the developers protested that they had better things to do he shouted, “Can you imagine looking at that every day? It’s not just a little thing. It’s something we have to do right.”

The famous Apple “Think Different” campaign came from Jobs’s advertising team at TBWA\Chiat\Day. But it was Jobs who agonized over the slogan until it was right:

They debated the grammatical issue: If “different” was supposed to modify the verb “think,” it should be an adverb, as in “think differently.” But Jobs insisted that he wanted “different” to be used as a noun, as in “think victory” or “think beauty.” Also, it echoed colloquial use, as in “think big.” Jobs later explained, “We discussed whether it was correct before we ran it. It’s grammatical, if you think about what we’re trying to say. It’s not think the same, it’s think different. Think a little different, think a lot different, think different. ‘Think differently’ wouldn’t hit the meaning for me.”

The point of Meisenzahl and Mokyr’s argument is that this sort of tweaking is essential to progress. James Watt invented the modern steam engine, doubling the efficiency of the engines that had come before. But when the tweakers took over the efficiency of the steam engine swiftly quadrupled. Samuel Crompton was responsible for what Meisenzahl and Mokyr call “arguably the most productive invention” of the industrial revolution. But the key moment, in the history of the mule, came a few years later, when there was a strike of cotton workers. The mill owners were looking for a way to replace the workers with unskilled labor, and needed an automatic mule, which did not need to be controlled by the spinner. Who solved the problem? Not Crompton, an unambitious man who regretted only that public interest would not leave him to his seclusion, so that he might “earn undisturbed the fruits of his ingenuity and perseverance.” It was the tweaker’s tweaker, Richard Roberts, who saved the day, producing a prototype, in 1825, and then an even better solution in 1830. Before long, the number of spindles on a typical mule jumped from four hundred to a thousand. The visionary starts with a clean sheet of paper, and re-imagines the world. The tweaker inherits things as they are, and has to push and pull them toward some more nearly perfect solution. That is not a lesser task.

Jobs’s friend Larry Ellison, the founder of Oracle, had a private jet, and he designed its interior with a great deal of care. One day, Jobs decided that he wanted a private jet, too. He studied what Ellison had done. Then he set about to reproduce his friend’s design in its entirety—the same jet, the same reconfiguration, the same doors between the cabins. Actually, not in its entirety. Ellison’s jet “had a door between cabins with an open button and a close button,” Isaacson writes. “Jobs insisted that his have a single button that toggled. He didn’t like the polished stainless steel of the buttons, so he had them replaced with brushed metal ones.” Having hired Ellison’s designer, “pretty soon he was driving her crazy.” Of course he was. The great accomplishment of Jobs’s life is how effectively he put his idiosyncrasies—his petulance, his narcissism, and his rudeness—in the service of perfection. “I look at his airplane and mine,” Ellison says, “and everything he changed was better.”

The angriest Isaacson ever saw Steve Jobs was when the wave of Android phones appeared, running the operating system developed by Google. Jobs saw the Android handsets, with their touchscreens and their icons, as a copy of the iPhone. He decided to sue. As he tells Isaacson:

Our lawsuit is saying, “Google, you fucking ripped off the iPhone, wholesale ripped us off.” Grand theft. I will spend my last dying breath if I need to, and I will spend every penny of Apple’s $40 billion in the bank, to right this wrong. I’m going to destroy Android, because it’s a stolen product. I’m willing to go to thermonuclear war on this. They are scared to death, because they know they are guilty. Outside of Search, Google’s products—Android, Google Docs—are shit.

In the nineteen-eighties, Jobs reacted the same way when Microsoft came out with Windows. It used the same graphical user interface—icons and mouse—as the Macintosh. Jobs was outraged and summoned Gates from Seattle to Apple’s Silicon Valley headquarters. “They met in Jobs’s conference room, where Gates found himself surrounded by ten Apple employees who were eager to watch their boss assail him,” Isaacson writes.

“Jobs didn’t disappoint his troops. ‘You’re ripping us off!’ he shouted. ‘I trusted you, and now you’re stealing from us!’ ”

Gates looked back at Jobs calmly. Everyone knew where the windows and the icons came from. “Well, Steve,” Gates responded. “I think there’s more than one way of looking at it. I think it’s more like we both had this rich neighbor named Xerox and I broke into his house to steal the TV set and found out that you had already stolen it.”

Jobs was someone who took other people’s ideas and changed them. But he did not like it when the same thing was done to him. In his mind, what he did was special. Jobs persuaded the head of Pepsi-Cola, John Sculley, to join Apple as C.E.O., in 1983, by asking him, “Do you want to spend the rest of your life selling sugared water, or do you want a chance to change the world?” When Jobs approached Isaacson to write his biography, Isaacson first thought (“half jokingly”) that Jobs had noticed that his two previous books were on Benjamin Franklin and Albert Einstein, and that he “saw himself as the natural successor in that sequence.” The architecture of Apple software was always closed. Jobs did not want the iPhone and the iPod and the iPad to be opened up and fiddled with, because in his eyes they were perfect. The greatest tweaker of his generation did not care to be tweaked.

Perhaps this is why Bill Gates—of all Jobs’s contemporaries—gave him fits. Gates resisted the romance of perfectionism. Time and again, Isaacson repeatedly asks Jobs about Gates and Jobs cannot resist the gratuitous dig. “Bill is basically unimaginative,” Jobs tells Isaacson, “and has never invented anything, which I think is why he’s more comfortable now in philanthropy than technology. He just shamelessly ripped off other people’s ideas.”

After close to six hundred pages, the reader will recognize this as vintage Jobs: equal parts insightful, vicious, and delusional. It’s true that Gates is now more interested in trying to eradicate malaria than in overseeing the next iteration of Word. But this is not evidence of a lack of imagination. Philanthropy on the scale that Gates practices it represents imagination at its grandest. In contrast, Jobs’s vision, brilliant and perfect as it was, was narrow. He was a tweaker to the last, endlessly refining the same territory he had claimed as a young man.

As his life wound down, and cancer claimed his body, his great passion was designing Apple’s new, three-million-square-foot headquarters, in Cupertino. Jobs threw himself into the details. “Over and over he would come up with new concepts, sometimes entirely new shapes, and make them restart and provide more alternatives,” Isaacson writes. He was obsessed with glass, expanding on what he learned from the big panes in the Apple retail stores. “There would not be a straight piece of glass in the building,” Isaacson writes. “All would be curved and seamlessly joined. . . . The planned center courtyard was eight hundred feet across (more than three typical city blocks, or almost the length of three football fields), and he showed it to me with overlays indicating how it could surround St. Peter’s Square in Rome.” The architects wanted the windows to open. Jobs said no. He “had never liked the idea of people being able to open things. ‘That would just allow people to screw things up.’ ” 

Karl Scotland on Kanban, Flow & Cadence

The following is from Lean IT thought leader, Karl Scotland. He pulls lots of great info together explaining how kanban in the real world.
Bob H

Kanban, Flow & Cadence 


There has been some noticeable increase in interest in Kanban recently, with a number of people asking for more basic info, and more people writing new blogs and articles. This is my attempt to describe in more detail my take on it all, which I refer to as Kanban, Flow and Cadence.

  • Kanban – Controlled Work
  • Flow – Effective Work
  • Cadence – Reliable Work


A Kanban system is a mechanism for controlling the work in the software development system. Kanban can be defined as “visual card”, as shown below – kindly written for me by Kenji Hiranabe [?] at Agile 2008.

The origin of kanban is the Toyota Production System. Taiichi Ohno, in his book Toyota Production System, wrote:

“The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.”

Kanban is what enables a pull system for just-in-time work.

What does a Kanban System look like for software development? Very simply, there is a queue of work, which goes through a number of stages of development until its done. When work is completed in a stage, it goes into a downstream queue for the next stage. When someone needs new work to do, they pull it from their upstream queue. This can be depicted as below.

That looks very like a typical Agile Task Board, with maybe a few more steps, although there is nothing to say there can’t be a single development stage. However, there is one more important element which really defines a kanban system – limits. There are two basic limits – Queue limits and WIP limits.

Queue limits are designed to avoid premature work. This how just-in-time is achieved. The limit should be large enough to keep the team busy (i.e. there is always something in it for the team to start work on), but small enough to avoid premature prioritisation (i.e. having things sitting in the queue for too long before they are begun). Ideally the queue should be FIFO, although this is a guideline rather than a hard rule, as sometimes available skills or other resources mean that it is not always possible.

Work In Progress limits are designed to reduce multi-tasking, maximise throughput, and enhance teamwork.

Reducing multitasking is beneficial for two primary reasons.

1) 20% time is lost to context switching per ‘task’, so fewer tasks means less time lost (from Gerald Weinberg, Quality Software Management: Systems Thinking)

2) Performing tasks sequentially yields results sooner. As the diagram below shows, multi-tasking A, B and C (on the top), delivers A much later, and even C slightly later, than sequentially (on the bottom).

A great exercise to demonstrate the effects of multi-tasking was described by Clarke Ching.

Throughput is also maximised by decreasing WIP. Simple examples of this effect are traffic jams, where traffic speed reduces as more traffic builds up, and CPU load, where application performance goes down as CPU load increases. The effect can be be explained by looking at Little’s Law for Queuing Theory:

Total Cycle Time = Number of Things in Progress / Average Completion Rate

Therefore, to improve cycle time there are two options; reduce the number of things in process or improve the average completion rate. Of the two, reducing the number of things in progress is the easier, and once that is under control, then the more challenging changes to improve completion rate can be applied.

Finally, by having fewer work items in progress, then the team is able to focus more on the larger goals, and less on individual tasks, thus encouraging a swarming effect, and enhancing teamwork.

Limiting Work In Progress like this can seem unusual for teams, and there is often a worry that team members will be idle because they having no work to do, but are unable to pull any new work. The following guidelines can be useful to help in this situation.

  1. Can you help progress an existing kanban? Work on that.
  2. Don’t have the right skills? Find the bottleneck and work to release it.
  3. Don’t have the right skills? Pull in work from the queue.
  4. Can’t start anything in the queue? Is there any lower priority to start investigating?
  5. There is nothing lower priority? Find other interesting work.

They key question here are what constitutes lower priority investigative work or other interesting work. Essentially it is work which won’t create any work downstream, will improve future throughput and can be paused as soon as existing kanban related work is available. Lower priority work could be spikes or analysis for known impending work. Other interesting work could be refactoring, tool automation, personal development or innovation.

WIP limit sizes can depend on type of work and size of team and should be adjusted to achieve maximum flow. One approach is to start small (e.g. a limit of 1) and increase as necessary. Another is to start larger (e.g. a limit of half the team size) and reduce until the sweetspot is achieved.

The consequences of using a kanban system are that the Product Backlog can be eliminated, because the immediate queue is the only work of interest, timeboxed iterations (i.e.Sprints) can be eliminated, because work is pulled as necessary, and estimation can be eliminated, because work is not planned into iterations.


Flow describes how the work in the system can delivery maximum value. As Mary and Tom Poppendieck write,

“In lean enterprises, traditional organizational structures give way to new team-oriented organizations which are centred on the flow of value, not on functional expertise.”

In particular, Lean emphasises ‘One Piece Flow’. This means moving one piece at a time between stages in a workflow as opposed to moving batches of work between stages in a workflow. The ‘One Piece’ in a Kanban system for software development can be thought as the Minimal Marketable Feature, as described by M Denne & H Cleland-Huang in Software by Numbers.

“A minimal marketable feature is a chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity”.

The kanbans should be minimal so that they are as small as possible in order to enable progressive delivery to realise the product sooner, reduce feature bloat and focus on the the core features which are the most important, and minimise complexity because each feature has a cost to a user.

The kanbans should be marketable in a number of ways.

  • Table Stakes – these delivery parity to the competition and are the minimum needed to be in the game
  • Differentiators – these differentiate the product from the competition and delight the user
  • Spoilers – these nullify a competitors differentiator and raise the bar for parity
  • Cost Reducers – these reduce cost and improves the profit margin

A useful guideline is that an MMF is marketable if it is something that could be written about on a product blog.

The kanbans should be features which are distinct, deliverable and observable. The INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable) as described by Bill Wake, can also be useful for applying to MMFs.

The Marketable element of MMFs means that they may sometimes be larger than typical User Stories, which often break work down such that while they can be incrementally delivered, and show some element of value, they are not marketable in their own right. Therefore, it is important to understand an MMFs Value Stream in order to deliver the whole MMF as quickly as possible. A value stream describes the steps, delays and information required to deliver a product, and can often be used to decide the steps in an initial kanban system. With large MMFs, the User Stories become more of an analysis technique in order to enable incremental delivery of an MMF, without losing sight of the overarching MMF. I describe how a continuous flow can be achieved with MMFs in The Anatomy of an MMF.

A number of techniques can help manage the relationships between MMFs and User Stories in order to realise the benefits of both. One is User Story Mapping, as descried by Jeff Patton.

I have also recently been working in a regulated environment where User Case Goals and Sub Goals have provided the MMFs, with the detailed scenario paths and steps providing the additional details.

A further enhancement is to use two-tier Kanbans, with one tier for the MMFs, and another for the User Stories.

The consequence of applying the concept of Flow is that emphasis is placed on using larger, value-focussed MMFs, rather than smaller, more incremental Stories.


Cadence is the approach to achieving commitment and reliability with a kanban system. I often get a question something along the lines of,

“If the team isn’t estimating or planning with fixed time-boxes, how can it make reliable commitments?”

To quote Mary and Tom Poppendieck again,

“A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”

The time-boxed iteration is one form of cadence, which couples planning, review and release together. A kanban system de-couples these events and allows them to have separate cadences, as well as adding two additional ones. Throughput is the amount of output of a process in a given period of time, and Cycle Time is the length of time to complete a process. The relationship between the two is:

Throughput = WIP / Cycle Time

Throughput allows forecasting of future capability, without needing to specify what might be delivered. Cycle Time allows commitment by becoming an SLA with the business (see Kanban Commitment). Where the size of work varies, from large new features to small fixes and change requests, then a classification of MMFs can enable a range of cycle-times. Both Throughput and Cycle Time can be charted and trended, in a similar way to XP’s Velocity, as a means to encourage the team to improve. A Cumulative Flow Diagram can also make visible how the work is flowing through the system and highlight bottlenecks.

For longer term forecasting, a quarterly planning cadence focusses on quarterly goals and objectives. MMFs can subsequently prioritised to meet those goals and objectives. A regular release cadence will build up trust that the team will work to its full capacity and throughput.

Other cadences, are daily stand-up meetings, and regular retrospectives and Operations Reviews as described by David Anderson. Some teams are using a Retrospective Kanban to signal when a retrospective is necessary, and I have already blogged briefly about Kanban and Retrospectives.

The consequence of Cadence is that commitment and reliability is achieved though measurement as opposed to planning.


They key points of Kanban, Flow and Cadence are:

  • A Kanban System manages the workflow in a way which allows the Product Backlog, Timeboxed Iterations and Estimations to be eliminated.
  • Flow is about effectively delivering maximum value by focussing on optimising the value stream of larger MMFs
  • Cadence allows iteration input and output to be de-coupled and achieves commitment and reliability via measurement rather than planning.

Further resources and information can be on my Kanban Page, including most of the material which has influenced and directed my thinking.

reposted from Karl Scotland’s AvailAgility blog.

Essence of Agile from Henrik Kniberg

I love Henrik’s agile slides. His work is quick and to the point, and visual enough to keep you interested and occasionally make you laugh.
Bob H