Scrum "Shock Therapy" How To Change Teams FAST

While he was updating his paper for Scrum "Shock Therapy," Scott Downey of Rapid Scrum found one of the original emails he wrote about how he boosted dozens of teams into hyper productivity. He and Jeff are going to be talking a lot about it at the Certified Scrum Master and Certified Scrum Product Owner courses we're giving in Los Angeles the last week in February, so they've both been thinking hard about bringing a large number of teams quickly to hyper productivity, and really how to engage in fundamental transformation of a company.

Jeff just finished teaching a class in Amsterdam and is traveling to Copenhagen to give a class there. As he's on the road, I asked Scott if I could post that email here. He kindly agreed.

The Framework of Scrum provides many options for customization and interpretation for each Team. In my experience, most teams just starting out are so overwhelmed with choices and potential that they can't find a constructive way to start. I have known of teams that spent so much time designing their Scrum Board, for example, that Management lost patience with them and the Scrum Framework because a Scrum Board was all they ever produced.

It occurred to me one day that Scrum Teams are the customers of the Scrum Master. If we don’t already know it, Scrum teaches us that customers of our enterprise don't really know what they want until they have seen it, or at least something to define what they don’t want. So why would we expect Scrum Teams to know how to set up, for example, their Sprint Planning Meetings if they haven't seen a working prototype?

This approach was documented in the Agile 2009 presentation titled “Shock Therapy” (available at http://www.rapidscrum.com/resources.php), coauthored by Jeff Sutherland and Bjorn Granvik.
When I join a team as their Scrum Master, I issue a few non-negotiable rules (gently if possible, firmly if necessary). These rules remain in effect until the team has met three criteria:

1. A minimum of 240% increase in Velocity
2. They have completed three consecutively successful Sprints
3. They have identified a good business reason to begin changing rules

My initial rules are roughly these:

Everyone on the team will attend a Scrum Training session.
I conduct an extremely condensed Introduction to Scrum course and the entire team comes together for a single session. Until everyone has been trained, we won't begin our first Sprint.

Sprints will be one week long.
I justify this by pointing out that there is a reason geneticists study mutations in Fruit Flies instead of Elephants – they want to see the mutations quickly and adapt their studies accordingly. So do I. Teams generally hate this part as much or more than anything else I require of them but I have been able to coax every team into giving me at least four, one-week Sprints as a trial. Here's a favorite exchange of mine that almost always comes up:
Engineer: "But I can't do anything in one week!"
Scott: "Then simple math suggests that you can only do four nothings in a month."
Interestingly, by the time the teams have met the three criteria for changing this rule, only one so far has ever elected to change it.

Scrum: Looks Like We Created an Industry!

• 
  
  • 
    
  • In the last month there were 10,964 Scrum jobs posted at simplyhired.com. This is probably less than half the real jobs 
  • out there for Scrum. In a good month we have 200,000 new jobs in the U.S. and the unemployment rate goes down. Is
  • Scrum generating 10% of those new jobs?
  • Last 30 daysClear
  • Title
    • Java Developer172
    • Software Engineer168
    • Project Manager132
    • .net Developer116
    • Senior Software Engineer102
    • Business Analyst63
    • Senior Java Developer63
    • Web Developer61
    • Software Development Engineer55
    • Scrum Master48
  • Company
    • Amazon512
    • HP192
    • Cybercoders182
    • Randstad Technologies153
    • Microsoft151
    • Volt Information Sciences142
    • Robert Half Technology130
    • Dell95
    • Lockheed Martin90
  • Job Type
    • Full-time964
    • Permanent578
    • Contract396
    • Part-time220
    • Temporary97
    • Internship38
    • Telecommute
    
    

Agile Manifesto - original 2001 notes from Snowbird

Jon Kern has surfaced a very cool historical artifact from the original Agile Manifesto 2001 meeting in Snowbird, Utah. If you download this document you can see all his notes from the meeting.

Medication

Dan Mezick
I'm pleased to add this content to Jeff's blog regarding pain medication and the Agile Manifesto.

Delivering software as a team is a highly intentional act. If we say we want working software, the results are by no means assured. Confronting reality, at the level of group, is the name of the game in software development. The alternative is pain medication...


Medication

If you check out the Agile Manifesto, you find that we often medicate with the things listed on the right in the Values section.
Medication is usually in the form of a pain killer of some kind. The whole right side of the Agile Manifesto lists various forms of medication that enterprises, departments and teams use to relieve various forms of pain.
Examples of pain-killing medications:

• Processes and Tools
• Comprehensive Documentation
• Contract Negotiation
• Following a Plan

Lets look at each in turn:

Process and Tools

We medicate away from facing [Individual and Interactions] by focusing on processes and tools. We focus on these, and away from [Individual and Interactions] because we might have to get real and face the reality of people and interacting with them. We might have to get some new social skills! Ouch, that smarts. Where are my pills?

Comprehensive Documentation
This usually manifests as the need for “perfect” and “comprehensive” requirements. We medicate with these, and avoid dealing in the reality that what we must create is [Working Software]. We focus on perfection in requirements, and away from STARTING. Starting is risky and who knows what might happen? The reality is we cannot learn till we pay attention, and we do not pay attention till we start. Got that? OK, so START NOW with your imperfect non-comprehensive requirements. It’s going to be (perfectly) OK.

Contract Negotiation

OK, OK we need to know what to build. I agree. Let’s also agree that it is unreasonable to expect everyone to know exactly what they want, 100%, at the start of the process. We focus on contracts instead of [Customer Collaboration] because this stuff is hard. So, we medicate with the contract. It gives a sense of control, see? That stops the pain of dealing with what is in fact an uncontrollable, increasing complex, high-change world.

Following a Plan

“Planning” usually shows up as “prediction-in-drag”: in effect, a wild-ass guess masquerading as planning. If prediction is so very easy, why isn’t everyone a stock market winner? See it? Prediction is difficult… and way over-rated. Plans are great and we need a direction … and a general way to move in that direction. But let’s not pretend we can predict very much at all. Instead, let’s [Respond to Change]. Ouch, that hurts because I might have to question my beliefs, to address any really unusual changes. I might have to re-factor my model of reality.
That’s a whole lot of hard work, making painful edits to what I currently believe.
Ouch, that smarts. Where are my pills?

Dan Mezick is the author of The Culture Game , teaches and coaches Agile at New Technology Solutions, and helps create community (and events) via the Agile Boston and Agile Connecticut user groups. Reach him at dan@newtechusa.net, via the Blog, or Twitter.

Google Automation of my QA Strategy

Bug Prediction at Google

What's the problem?

Here at Google, we have thousands of engineers working on our code base every day. In fact, as previously noted, 50% of the Google code base changes every month. That’s a lot of code and a lot of people. In order to ensure that our code base stays healthy, Google primarily employs unit testing and code review for all new check-ins. When a piece of code is ready for submission, not only should all the current tests pass, but new tests should also be written for any new functionality. Once the tests are green, the code reviewer swoops in to make sure that the code is doing what it is supposed to, and stamps the legendary “LGTM” (Looks Good To Me) on the submission, and the code can be checked in.

However, Googlers work every day on increasingly more complex problems, providing the features and availability that our users depend on. Some of these problems are necessarily difficult to grapple with, leading to code that is unavoidably difficult. Sometimes, that code works very well, and is deployed without incident. Other times, the code creates issues again and again, as developers try to wrestle with the problem. For the sake of this article, we'll call this second class of code “hot spots”. Perhaps a hot spot is resistant to unit testing, or maybe a very specific set of conditions can lead the code to fail. Usually, our diligent, experienced, and fearless code reviewers are able to spot any issues and resolve them. That said, we're all human, and sneaky bugs are still able to creep in. We found that it can be difficult to realize when someone is changing a hot spot versus generally harmless code. Additionally, as Google's code base and teams increase in size, it becomes more unlikely that the submitter and reviewer will even be aware that they're changing a hot spot.

In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range. Source-based metrics that could be used for prediction are how many lines of code, how many dependencies are required and whether those dependencies are cyclic. These can work well, but these metrics are going to flag our necessarily difficult, but otherwise innocuous code, as well as our hot spots. We're only worried about our hot spots, so how do we only find them? Well, we actually have a great, authoritative record of where code has been requiring fixes: our bug tracker and our source control commit log! The research (for example, FixCache) indicates that predicting bugs from the source history works very well, so we decided to deploy it at Google.


For details click here ...

Powerful Strategy for Defect Prevention: Improve the Quality of Your Product

A classic paper from IBM shows how they systematically reduced defects by analyzing root cause. The cost of implementing this practice is less than the cost of fixing defects that you will have if you do not implement it so it should always be implemented.

1. First understand your architecture and where the bugs are coming from by type, severity, component, and point of injection during the development life cycle.

2. You will find 80% of the bugs come from 20% of the code. Mapping these defects on a component architecture will show swarms of bugs around specific components.

3. Apply bug spray through a carefully prioritized automated testing strategy. Find the biggest problem that occurs when doing final regression testing prior to deployment. Implement an automated test that makes this problem impossible to happen again using the detailed knowledge developed about bug infestation in your product. Write a single test that can prevent 100 common problems. Then go to the next highest priority problem and repeat. Doing a few automated tests a week will eventually make your build bullet proof with remarkably few tests.

In three months, one of our venture companies cut a 4-6 week deployment cycle to 2 weeks with only 120 tests. It took one person three weeks to write the test and eliminated several weeks of work by an entire team. It reduced defeats, radically reduced support calls, and the customers liked the new release enough to buy more product, raising revenue.

Everyone should implement this. The return on investment is astronomical. I thought this was basic stuff but our investors say almost none of their companies have implemented it until we invested in them. The developers are often junior, right out of university, and the managers are domain experts, not engineering experts. We have to teach them the basics.

Experiences with Defect Prevention

by R. G. Mays, C. L. Jones, G. J. Holloway, D. P. Studinski

IBM SYSTEMS JOURNAL. VOL 29, NO 1, 1990

Defect Prevention is the process of improving quality and productivity by preventing the injection of defects into a product. It consists of four elements integrated into the development process(: 1) causal analysis meetings to identify the root cause of defects and suggest preventive actions; (2) an action team to implement the preventive actions; (3) kickoff meetings to increase awareness of quality issues specific to each development stage; and (4) data collection and tracking of associated data. The Defect Prevention Process has been successfully implemented in a variety of organizations within IBM, some for more than six years. This paper discusses the steps needed to implement this process and the results that may be obtained. Data on quality, process costs, benefits, and practical experiences are also presented. Insights into the nature of programming errors and the application of this process to a variety of working environments are discussed.

How to Use Scrum in Hardware Development

Many hardware designers ask how they can do Scrum for hardware development. This is the future for hardware. Software will be a key component and the hardware design will need to change every sprint. The winner will be number one and probably not be Toyota. Their software development is antiquated and they already have 12M lines of code in the Lexus. Trying to even maintain that without Scrum will cause significant delays.

Joe Justice built a 100mpg car using principles of agile, lean and scrum. How did he do it?

Posted on December 2, 2011 

First of all let me tell you that your STG01 (the 100mpg car) looks great. I am tempted to buy it now, what a great model. There is so much I want to talk to you about; we’ll see how much we can fit into this one hour. You want to start with telling us about your career so far and your touch points to project management. And then tell us how you got started on the agile concept.

Agile for me was the de facto standard. When I graduated college the first job I took was with an agile software development group. I didn’t even know it was agile, it was just the way business was done there. At that time I was writing one of the first web services for .NET 1.0. Then I was poached by a consulting firm that did Microsoft enterprise software. Agile was becoming hotter and hotter, and customers were requesting agile more and more. So for several years I never worked with anything except agile software development, I didn’t know any other method!

Some of these teams were quite large, maybe more than 50 team members, and sometimes these were distributed teams working from multiple countries at once. Again I didn’t know any other method than agile software delivery – working with the principles and values of agile, lean and scrum we found ways to co-ordinate multiple teams during larger and larger project deliveries. As these deliveries grew to multiple teams, I began to interface with more teams with hand-off points and joint deliveries. They were using some other method; it turned out to be waterfall. It was so painful, so much time was caught up in change request and a lot of it came to rely on the theatrics of the project manager to convince the client that they needed a change request. And none of the teams I was on needed to do that, the client was just aware of the current state of the project and able to re priortorize. It was very much less dramatic and as a result far more efficient.

I started studying this other method, trying to figure out what it was and why it seemed so painful. And why the people on the team I was with were excited, eager, and creative. Contrastingly, the folks on these other teams were often very depressed, quite literally, and looking forward to going home. They often needed to work week nights and weekends to meet some goal that a project manager had mentioned in passing and the client had taken to be gospel. Again I was struck by this, which didn’t happen on the teams I had been working with because it was continuously iterative and work was completed in priority order. So I began studying this in earnest. And really only discovered what agile was once I learned what waterfall was. To me again agile was just the way you did work, I was lucky enough to be born right into it. I began to become very passionate about it once I saw how concrete these differences were. And the difference wasn’t that you had a high performing, creative team just magically. But there was a creative high performing team because of a specific type of project methodology and project management approach. Once I found that it was repeatable, with different teams, and there were these set of principles that could be applied again and again to avoid teams becoming so disheartened, so 9 to 5, so pathetic, so uncreative. It became something like a personal mission for me, and I become very passionate about it.

Now at WIKISPEED, again I did not know any other way to run a project. When I was on the automotive design project and then on the ultra efficient automotive challenge the only delivery method I knew was agile, lean and scrum. It came to be incredibly effective for us. It developed a very different type of car than what is on the road now. It became a very efficient car, a very quick to develop car and a very inexpensive to maintain car. Again it is not that I set out to build an agile, lean or scrum car, I set out to make an ultra efficient car with this whole team of volunteers all over the world. As the team lead who determines the project methodology, it enabled us to have this high energy high performing team, high creativity, high velocity team, and to do so much in so much less time.

Don't miss the rest of this article. It is incredible!

An Alternative to Kanban: One-Piece Continuous Flow

    Jim Coplien

I'm pleased to be visiting here as a guest this week at Jeff's invitation. The topic at hand is kanban. Unfortunately, this entry is a bit long, because I want to go beyond the usual level of sound bites afforded to an important topic.


A Terminology Tour
Kanban is a Japanese word that just means sign. It is used to control work in progress, in the context of a production line where flow has already been established (Ohno, Toyota Production System, Chapter 2). The concept has found its way into software development, where it is often contrasted with Scrum or suggested as a complement to Scrum implementations. However, though most uses of the term hearken back to its origins in the Toyota Way, its popular use misconstrues much of its original intent.

The Toyota Way is a system of building things that, as a formalism, goes back to the mid-20th century, and has explicit roots in the early 20th century or even the latter 19th century. It is the way Toyota runs. Many other Japanese companies, starting with Toyota's suppliers but including many others, follow the same principles of overlapping development phases, self-organization, and learning. We find many of these companies mentioned in Harvard Business Review's The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka. This is the paper that inspired Scrum, and Jeff Sutherland continues to work closely with Nonaka today, as Jeff describes in "Takeuchi and Nonaka: The Roots of Scrum."

Takeuchi spent six years studying Toyota and summarized the apparently paradoxical culture in the book Extreme Toyota. The historic relationship between the Harvard Business Review paper, and Toyota, is sometimes indirect, though the principles of the two align well. For example, the notion of starting design before analysis is complete (which we will revisit later, below) is explicit both in the Takeuchi and Nonaka paper and in Liker's description of the Toyota Way. The use of versatile, diverse teams comes out both in the Harvard Business Review paper and in Extreme Toyota.

As Jeff''s blog describes, it's important to distinguish The Toyota Way from Lean. "Lean" in its common, vulgar use — particularly in methodological settings — is too often interpreted as a shallow way to apply Toyota Way tools to production without adopting its deeper foundations. Kanban is one such tool. It can be a powerful part of a production system that already has working flow, but it's crucial to understand that the foundations of flow must come first. In this article, the term "Lean" will arise occasionally in quoted material that, unless explicitly mentioned otherwise, refers to the Toyota Way.



Scrum is a framework for building product that is based on The Toyota Way. There are few differences between their fundamentals: e.g., the Toyota Way has a Chief Engineer which Scrum splits into a Product Owner and a ScrumMaster. As we'll discuss below, Scrum is neither built on kanban nor has a need for kanban, because it is ideally suited to a mechanism for limiting work-in-progress called one-piece continuous flow.


How is Kanban used?
In Toyota, kanban is used in two major ways. The original application of kanban (as a sign — see the example at the right, from Liker's book The Toyota Way, Chapter 2) was to placate a failure mode in the Toyota Production System. Sometimes you can't have one-piece continuous flow, because of impediments like multisite development, poor organizational structure, or bad assignment of workers to work locations. If you are a supplier far away from your consumer, you need a semaphore to synchronize the handoff of goods. The kanban card is that semaphore. When the consumer is running low on parts, the consuming work cell puts a kanban card in a supply cart that requests additional supplies. The cart is wheeled to the point of supply. Its arrival is a signal to the supplier to build more and to fill the cart, after which it can be wheeled back to the consumer. The consumer can initiate the request a little while in advance, giving the supplier time to respond to the request, or the supplier can keep some inventory on hand so that most requests can quickly be satisfied.



The supplier builds inventory which is put in a cart and delivered to the point of use. The cart is left there. When the cart starts becoming empty, you put a kanban card (a sign) in it giving information on projected need, and the cart is again taken to the point of supply so it can be filled up. You don't have kanban without the muda (waste) of moving the card and the cart, of the cost of storage for the inventory. You don't have kanban without the mura that comes from low-bandwidth communication between the supplier and consumer. By definition, kanban is based on having muri: instead of continuously flowing, the work bunches up. So this failure mode creates a need to limit work in progress. A disciplined use of kanban limits work in progress.



The other application is within a work cell, to ensure that only a limited number of parts (usually one) are on the table in front of the worker at any time. The table has kanban squares drawn on it. Parts being worked on must be within one of these squares. If parts stack up, it means that there is overproduction somewhere. If I'm a producer, I should produce something only if I can see that my neighbor needs, or is about to need, the part I build. I build that part to deliver to my neighbor just in time. Kanban squares are also used at a larger scale on the factory floor, as placeholders for pallets of parts or for larger parts (see figure at right; from leanmanufacture.net).


Kanban is a Wasteful Fall-Back for Repetitive Manufacturing Work
Kanban applies to repetitive work — building the same item again and again. Liker — author of The Toyota Way and highly regarded authority on the Toyota Production System — tells us:

Not everything can be replenished based on a pull system; some things must be scheduled. Take the example of high-end products, like a Rolex, a sports car, or those killer high-tech golf clubs advertised by Tiger Woods. Whenever you are buying a special or single-use item, you have to think about what you want, consider the costs and benefits, and plan when to get it. In a sense, you create a schedule to purchase, since there is no immediate need for it. (Chapter 9)

That is what software is like: We rarely build the same thing again and again. In manufacturing someone has to build any new parts that we need. In software, we can reuse a function as many times as we want by adding as many calls to it as we like, or reuse a class by instantiating a new object of it. Much design is based in innovative, incremental aggregation and extension of existing artefacts. This is particularly true in software, but also extends to industries such as building architecture and construction. Few design jobs plough totally new territory, yet none knowingly crafts a replica of past construction. It is about building new things to a scheduled market need rather than stochastic, repetitive production of the same basic form.

Liker goes on:

TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System... The challenge is to develop a learning organization that will find ways to reduce the number of kanban and thereby reduce and finally eliminate the inventory buffer. Remember: the kanban is an organized system of inventory buffers and, according to Ohno, inventory is waste, whether it is in a push system or a pull system. So kanban is something you strive to get rid of, not to be proud of. (Chapter 9)

Note: The presentation by Jim Shore and Arlo Belshee introduced by David Anderson on this topic may be of interest.

Software Has Misappropriated Kanban
The fascination with kanban in Europe and North America has its roots in misinformation about how kanban fits into the Toyota Way, but there is a cultural element to the misunderstanding as well. Kanban is properly applied as a selective, detailed fix to a specific problem. It is not a philosophy of development. Sharon Begley observes:

Westerners prefer abstract universal principles; East Asians seek rules appropriate to a situation. (Sharon Begley, "East Versus West: One Sees Big Picture, Other Is Focused,"The Wall Street Journal, March 28, 2003.)

Taichi Ōhno, who invented the kanban system, tells us in his landmark book Toyota Production System:

Close supervision of the kanban rules is a neverending problem...
Rule 6 urges us to reduce the number of kanban... (Chapter 2)

The ideal is flow rather than kanban. Again, Liker advises us, "inventory buffers are used judiciously where continuous flow is not possible today. But the ideal of flow provides a clear direction." (Liker, The Toyota Way, Chapter 8)

The word kanban is also used as the name of a recently packaged methodology based on visualizing and mathematically analyzing work in progress. We see teams adopting this form of kanban, as a tool or methodology in its own right rather than as a worldview, without first having built foundations and disciplines of one-piece flow. Kanban (the methodology) discourages teamwork and increases the risk of not completing agreed work loads within a time box like a Sprint. It does give managers a lot of flexibility. That is, it allows the Product Owner to come to the team in the middle of the Sprint and stop what they are doing while introducing a new PBI or task. This interpretation of kanban sells to managers feeling a need to regain the control they lost with Scrum. The ability to patch things up, rather than solve root problems, gives a higher sense of immediate success without having to ponder long-term consequences of short-term decisions.

These misunderstandings of the Toyota foundations are deep, and though they often have kanban as a common thread they are not limited to software. If we look at Kanban.com we find a claim from the director of IT at CVG Systems: "To get the most benefit from kanban, we needed a closed-loop solution that would support a continuous-flow process, a solution that any of our suppliers could access easily." Kanban is a stopgap in the absence of one-piece flow — not a method to achieve it.
It is about separate groups controlled by a kanban protocol that replentishes inventory on demand (pull instead of push), in a highly structured way. It is a six-step, highly structured process (Ōhno, Toyota Production System, Chapter 2)


A Truly Lean Solution: One-Piece Continuous Flow
Instead of depending on kanban, true Lean eliminates mura, muri, and muda — inconsistency, lack of continuous flow, and waste. Instead of tracking the movement and processing of materials, a good Scrum co-locates the teams or the devices that make the artefacts. The foundations of Scrum encourage one-piece continuous flow. Team members swarm around one PBI at a time. A common dysfunctional alternative is "swim-lane Scrum:" each team member individually taking ownership of a PBI through the stages of the process. If an individual gathers up multiple PBIs, or tries doing all the tasks in the PBI at once, you can get the context switching that comes from having too much work in progress. Kanban says to track the number of PBIs in progress, supported by pseudo-queuing theory math, to limit how many cards can be on the task board.

Good Scrum practice follows The Toyota Way by instead focusing on a single PBI at a time, building on the team's intelligence and self-organization — rather than a method — to manage work in progress. There are no longstanding subteams in a Scrum team: the Developers work together as a unit. It's individuals and interactions over processes and tools. If the team works as a unit, it eliminates the problem of waiting for work items to arrive from another development stage. It also eliminates both the inventory necessary to keep the development team busy at the local site, and the inventory being readied for shipment in parallel at the supplier. Kanban fundamentally depends on both of these inventories.

One-piece continuous flow can take place in a single team working as a tightly-knit unit, in a single work cell (or Scrum team), to apply several transformations to work in progress (which is limited to a single piece at a time). The team does a little analysis, a little design, a little building, and a little testing all at once in very short cycles. Individuals are multi-talented, reflecting the Toyota concept of chaku-chaku. See the illustration at right, taken from Figure 8-4 in The Toyota Way. It reflects a quite unstructured way of working, as Takeuchi and Nonaka relate in the Harvard Business Review paper:

Rather than moving in defined, highly structured stages, the process is born out of the team members' interplay... A group of engineers, for example, may start to design the product (phase 3) before all the results of the feasibility tests (phase two) are in. Or the team may be forced to reconsider a decision as a result of later information. The team does not stop then, but engages in iterative experimentation. This goes on in even the latest phases of the development process.

Liker underscores one-piece flow in Chapter 3 of The Toyota Way:

... the one-piece-flow cell is the ultimate in lean production. It has eliminated most of Toyota's eight kinds of waste.

In fact, the ultimate goal of lean manufacturing is to apply the ideal of one-piece flow to all business operations, from product design to launch, order taking, and physical production.

Pair programming is one of the best analogies we have in software. There is no coder and no tester: there are two developers working together in a work cell continuously testing and developing until the work in progress is done-done-done. Good pair programming is quite unstructured. Because the feedback loops happen locally and immediately there is no need for a literal kanban card. Because it happens as two minds working as one, there is no need for kanban squares below the keyboard. Again, Liker says, "In a one-piece-flow cell, there is very little non-value-added activity like moving materials around. You quickly see who is too busy and who is idle." (The Toyota Way, Chapter 17)

It doesn't stop at pair programming. One-piece continuous flow is a staple of the techniques we teach ScrumMaster Certification course attendees to apply across the entire team throughout the sprint. In the Velocity Game exercise we emphasize that the entire team should work on one PBI at a time — swarming instead of playing Swim-Lane Scrum. The pace is frantic but the flow becomes smooth after two or three sprints — because there is complete visibility of who is doing what, second by second. Kanban cards would just get in the way. Good development teams are like football, hockey or basketball teams. The players and artefacts of the game are the most important considerations to understand the nature of work in progress.

Pair programming as a technique depends on having the larger Scrum flow in place: good enabling specifications from the Product Backlog, self-organization and task selection among the developers, and so on. The same is true with the other forms of flow within a Scrum team. It's not a quick fix, and there is no quick path to building the foundations of quality and efficiency. In fact, kanban was one of the later additions to the Toyota Production System because it had to wait until the broader flows were in place. As Ōhno relates, "Outsiders seem to think that the Toyota Production System and kanban are the same thing... But... Unless one completely grasps this method of doing work so that things will flow, it is impossible to go right into the kanban system when the time comes." (Ōhno, Toyota Production System, Chapter 2)


Kanban: A Good Fit for Teams that View Work as Firefighting
Toyota production plants and Scrum teams exist to build product. The literature speaks of successful application of kanban in the service industry, analogous to firefighting or hospital emergency rooms. It's tricky to schedule your next fire unless you live in the world of Fahrenheit 451. Many development teams run in firefighting mode, often with "swooping" from the Product Owner during a Sprint. And getting into a discipline is hard: it's easy to want to be able to react immediately to customer change instead of integrating a request into the business plan, and it feels good to release whenever you see fit. Some Scrum teams never learn the disciplines of planning and estimation. It is easy to see how these organizations gravitate to kanban.

It is difficult for these teams ever to develop a true sense of teamwork and working together, of feeling a sense of ownership for completing work to a forecast, or to develop the disciplines of long-term planning and enabling specifications that are at the foundation of long-term value. The problem with kanban (as with Scrum-butt) is that the resulting poor execution won't kill you. In his book, Liker expresses astonishment at the ignorance of supposed Lean practitioners, and has seen as much as 80% reductions in inventory after their understanding is clarified (Liker, The Toyota Way, Chapter 14). He says:

I have visited hundreds of organizations that claim to be advanced practitioners of lean methods... [H]aving studied Toyota for twenty years it is clear to me that in comparison they are rank amateurs.

He feels that less than 1% of companies outside Toyota "get it." (Liker, The Toyota Way, Chapter 1) Many of these companies are following the pop buzzword Lean instead of the core Toyota Way. The Scrum framework, as defined, has carefully avoided this trap (see "Takeuchi and Nonaka: The Roots of Scrum").

The same is true in software. Teams that have done both have found that kanban can actually afford less visibility to the business of work in progress than Scrum does, and take away the sense of teamwork and "positive pressure" that comes from the flow of a Scrum team (see Samuli Heljo's reflections).

Taking on Kaizen Mind: Back to the Foundations
A good Scrum team automatically enjoys the provisions of kanban when practicing one-piece continuous flow. It is a built-in way to limit work in progress while encouraging teamwork. It gives team members time-boxed autonomy to carry out their plans while enabling them to better meet their planned forecast. Such maturity may be a foundation for later addition of techniques like kanban, but both the inventor of kanban and our experience suggest that it is likely to founder without a framework like Scrum that first establishes the discipline of flow.

Thanks to Gertrud Bjørnvig, Neil Harrison, Kenji Hiranabe, Bojan Jovičić, Jens Østergaard, David Starr, Jeff Sutherland, and Stefan van den Oord for comments and clarifications.