Scrum Log Jeff Sutherland

Scrum "Shock Therapy" How To Change Teams FAST

2012-01-17T22:14:00.000-05:00

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:

A minimum of 240% increase in Velocity
They have completed three consecutively successful Sprints
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.

They will start out by using my definition of "Done".
This is often one of the thorniest issues to iron out with a team, so I take it off the table until they have some shared success as a foundation. My initial definition of "Done" is this:

Feature Complete
Code Complete
No known defects
Approved by the Product Owner
Production Ready

All estimates will be exclusively in Story Points.
Regardless of the Scrum model you will eventually follow, Story Points are a key part. Some authors recommend using Story Points only for the Product Backlog estimation but require that you shift to hours-based estimates when building the Sprint Backlog. Personally, having learned that hours-based estimates are wrong by a factor of 50% or more, I never want such an inaccurate and easily abused unit in my metrics.

But my reasoning goes further.

Since you must learn to use Story Points eventually – if only for the Product Backlog – it stands to reason that the more practice you get, the faster you learn. So by constraining all votes and estimates to the Story Point scale, teams quickly learn to use this new mechanism for quickly categorizing work.

Again, this one is sometimes met with a ceremonial rolling of the eyes but – so far, anyway – they have all eventually come around to this. It's usually at about week three when I can intentionally spark a debate over whether a card is a 3 or a 5, then have the pleasure of pointing out to them the passion with which they are debating these recently-meaningless values. I also make a point of shouting "BA!" whenever they all vote the same value for a given card. My intent is to show them how often they actually agree in their vote. As the mood on the team lightens up, some teams begin scanning the other votes and cheering themselves when that happens. Only one has returned my "Ba!" with a "Humbug!" In any event, they all start having fun with it and that's important.

We will use a physical Information Radiator.
Not only do I insist on a physical Information Radiator but I also stop all use of any project management software and backlog management tools. I want my teams to get a physical, tactile experience out of the boot-up process so that – even if the cards happen to become electronic later – they can still feel and picture the flow of what is happening.

I have a basic template that I use initially for all teams. It includes four columns that are drawn to be the exact width of the User Story cards we use (to prevent creating rows of cards in a single swim lane). The columns are “Product Backlog”, “Sprint Backlog”, “In Progress” and “Done.” This is usually met with complaints that the board doesn’t allow the Team to represent enough “states” (Design, Coding, Code Complete, Testing, Test Complete, Bug Fix, etc.). This is the perfect chance to educate the Team about the true purpose of the Board as an Information Radiator to non-Team members. It is there to reflect what the Team knows about a card. It is not a communication tool between Team members, so any states that are meaningless to external observers are not appropriate on the board.

I choose the location of the Scrum Board unilaterally and use it as the focus of the Daily Stand-Up Meeting. When the team is first formed, I let them focus on the interaction with their teammates (the three Achievement questions, plus my Fourth Question described in Scrum Metrics for Hyper Productive Teams paper from Agile 2010) and I move their cards across the Radiator's surface myself. Within a couple of weeks, they start moving cards themselves without having been asked. This is usually my first indication that I can begin slowly stepping back and relaxing my demands.

Sprint Planning Meetings will be four hours, once per week.
The first complaint of most Engineers is that they perceive Scrum imposing a highly disruptive schedule on them, with more meetings than they somehow think they have ever had before. To minimize this common concern, I consolidate everything but the Daily Stand-Up meetings into a single, four-hour meeting. Within a few weeks, most Teams only need a couple of hours to achieve it all. And by the end of about eight Sprints together, the meetings are becoming ninety minutes or less in duration for a one week Sprint.

My initial agenda is as follows:

Demonstrations, where the Team shows the Product Owner the work they achieved and receives Story Point awards based on their accuracy.

The Retrospective comes next, aided by a host of metrics that I track. I only track whole-team metrics, never individual metrics. Initially, though I publish many metrics, I only focus on Velocity, Burndown, Work Capacity and Commitment Accuracy.

Product Backlog Presentation follows, during which the Product Owner discusses the content of the Backlog at that point in time. The Team is free to question motives, suggest alternatives and add requirements at this point. I reject any improperly formed User Stories on behalf of the team but always strive to meet with the Product Owner ahead of this meeting, review their work and give them a chance to correct the mistakes before the meeting is called to order.

Estimation and Negotiation signals that the meeting is nearly complete. They happen in a single motion with my new teams, though more mature teams eventually choose to split these activities into unique meetings. The Product Owner participates in an advisory role only during this phase of the meeting but never votes or tries to influence the estimates. I spend most of my time in this phase trying to keep the teams from unnecessarily breaking Story Cards down into task sequences, which some tend to do. The INVEST mnemonic is really handy here. As soon as a card passes all six INVEST checks, we stop breaking it down, estimate it and get to work.

Sprint Backlog Commitment is the final act of this Ubermeeting. In the first few Sprints, I literally read aloud what "Commit" does and does not mean so that there is no doubt in anyone's mind. Once the team commits to the work, the meeting adjourns.

During the Sprint, Multi-Tasking is Forbidden. Work must be in addressed and completed in Priority Order.

Some Engineers understand this right away. Others feel most productive or fulfilled when they have multiple projects in progress. They don't appreciate my pointing out that there is no value in incomplete work – but point it out, I do. Often. I insist and enforce that they work on cards without multi-tasking and in priority order. Sometimes this leads to petulant protests with people sitting idle but they’re doing less damage in that mode than with their hands in nine projects, none of which will be done.

I also have standard layouts that I use for their initial Sprint Planning Boards, User Stories, Story Cards, Burndown Charts and Velocity tracking.

As I said in the beginning, I do try to get all of this done with a friendly smile and a "please" but generally have to insist -- sometimes quite forcefully -- to get all of them moving. Although the beginning is rocky, we usually start laughing and having fun in the meetings within a week. And as they become more focused on and competent with Scrum, I quickly relax my grip on some of the rules and let them redesign their environment to their own liking – so long as they continue to respect the principles of Scrum. It is always my goal to step out of the spotlight, turn control back over to the Team and become an advisor whose participation is not required for the Team to succeed.

Three key reasons that I believe I am successful with this approach are:

I find the biggest, nastiest problem that the team has and solve in within a day or two of the first Planning meeting if at all possible. Some teams quickly volunteer this problem to me in their first Retrospective while others require observation, careful listening and behind-the-scenes reconnaissance to tease it out. Especially for those teams who haven't worked directly with me yet, having that very large problem go away underscores that they are important to me, that I take them seriously and that I am working hard to make their world a better place.

Since I am the head of Agile Practice for the entire company, I am never a new Team’s permanent Scrum Master. This gives me the freedom to create a bit (but only a very small amount) of "Us vs. Him" atmosphere at first. It causes the team to bond in what is often an entirely new way than they have before, and also sets up their permanent Scrum Master to be the "good cop" down the road. It allows me to be more firm about standing during Stand-Up, keeping your estimates private until the vote is called during estimation, etc. Keeping in mind that I generally have to bow out and move on to another team after just a few weeks, by which point they are functioning very well and are (on average) around the 500% mark, most teams tolerate this very well and learn good habits more quickly – even if it does leave me feeling a bit a schoolmarm.

I think Socrates was on to something. When I see something going wrong – say, someone sitting during the Daily Stand-Up – I don't always address the transgressor directly. Instead, sometimes I stop the meeting and ask the team, "Team, do any of you see something going wrong with our meeting right now?" Ironically, it is almost always the most skeptical or resistant person who is the first to correct the insolently perched teammate. Soon, they start calling one another on leaning or sitting long before I stop the meeting and ask what's going wrong. It helps them begin to police themselves so that I don't always have to be around to elicit good behavior.

This is roughly how I have driven teams into hyper-productivity in as few as four weeks, and why one of my co-workers calls me "The Scrum Whisperer." I have one team that has achieved 1,650% higher targeted value contribution per week after just four months (16 Sprints) together. We are pretty proud of those numbers. I've also noticed that teams using this immersive training approach tend to hit their Velocity elbow much sooner, giving Product Owners a greater and more stable view of the roadmap than teams who use longer Sprints or spend their inaugural period hashing out where they want their Scrum Board to be located.

It's a fairly large culture shock for most teams and doesn't yield a lot of friendly lunch invitations at first. But, per feedback from my VP of Engineering, they only “…hate [me] for about 2-3weeks. Then they're indifferent to [me] for another few weeks. Then they scream bloody murder if [he tries] to take [me] away from them." I do stay in touch with teams that I've kick-started like this and, with one notable exception, they have all continued their trend of improvements in my absence, which was always my goal.

I hope you'll find some of this helpful as you try to slingshot your teams into optimum Scrum performance.

Scott Downey
Owner, RapidScrum.com
Scott@RapidScrum.com

Scrum: Looks Like We Created an Industry!

2012-01-15T16:43:00.002-05:00

- 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?
- 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

2012-01-07T14:31:00.001-05:00

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

2011-12-29T23:38:00.012-05:00

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

2011-12-23T17:58:00.001-05:00

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

2011-12-22T14:43:00.002-05:00

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

2011-12-08T08:17:00.001-05:00

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

2011-11-20T06:35:00.007-05:00

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.

The Power of Scrum

2011-11-15T13:55:00.001-05:00

Book Description

Publication Date: November 10, 2011

The Power of Scrum tells the inspiring story of Mark Resting, CTO of a software company struggling with a major client and a project with more problems than solutions and a marriage in crisis. But, when he meets Jerry, a West-coast expert in Scrum, light at the end of the tunnel begins to appear, Mark begins to reluctantly hope things will work out. The road is bumpy, but Jerry skillfully brings Mark’s developers from a world of project crisis into a revolutionary approach that can save the day. Authors Jeff Sutherland, Rini van Solinger, and Eelco Rustenburg have written a fictional narrative that masterfully weaves a compelling human story around the teaching moments of a software, project management how-to, and in the process tell an engaging story of personal growth and triumph, while demonstrating the power of a revolutionary and mission-critical approach to project management. The Power of Scrum is a must read for project managers, software developers, and product developers, as well as for anyone who loves a great story well told. More ...

Give Thanks for Scrum Day 22 Nov 2011

2011-11-07T15:43:00.001-05:00

SCHEDULE- Give Thanks for Scrum, 11/22/2011

0930 AM Welcome Remarks- Dan Mezick
1000 Ken Schwaber on: 2011: WHAT A YEAR FOR SCRUM
1045 BREAK
1100 Jeff Sutherland on Why Teams are not Hyperproductive
1145 BREAK for LUNCH
1245 PM Welcome Remarks- Dan Mezick
0100 Dan LeFebvre – Self-Organization and Transparency: Team Freedom ? Or a Path to Micro-Management?
0145 BREAK
0200 Jeff Sutherland & Ken Schwaber : “Open Panel” Q&A on Scrum
0300 Honoring the Tribal Elders of Scrum
0310 Concluding Remarks and RAFFLE

Microsoft, Waltham, MA - sign up here

Agile Manifesto 10 Year Reunion: Full Video

2011-11-06T10:53:00.000-05:00

Zuckerberg would stay in Boston if he were starting up now

2011-11-05T13:14:00.001-04:00

TechCrunch, Leena Rao, 31 Oct 2011

Yesterday, Facebook founder and CEO Mark Zuckerberg took the stage at Y Combinator’s Startup School in a candid interview with Y Combinator Partner Jessica Livingston. You can watch the full interview here, and it starts around the 43 minute mark, and lasts for roughly 40 minutes. If you have some time to spare, it’s well worth a look.

Zuck revealed a number of fascinating things about entrepreneurship, founding Facebook, and product development, but one of the more interesting (and surprising points) came at the end of the interview when Livingston asked him what he would do different if he could go back in time. Zuck replied: If I were starting now I would do things very differently. I didn’t know anything. In Silicon Valley, you get this feeling that you have to be out here. But it’s not the only place to be. If I were starting now, I would have stayed in Boston. [Silicon Valley] is a little short-term focused and that bothers me.

Takeuchi and Nonaka: The Roots of Scrum

2011-10-22T04:16:00.002-04:00

Scrum for software was directly modeled after "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka published in the Harvard Business Review in 1986. During 2011, I had the good fortune to meet and work with Professor Nonaka in Tokyo. Some say Nonaka has replaced Peter Drucker as the leading management guru on the planet. Certainly, a number of the Harvard Business School professors view him as their teacher. Nonaka was hired by the Japanese government after World War II to help analyse why they lost the war. He thought it was interesting that we both had a military background. He does not use a computer and to him, Scrum is only indirectly related to software. It is directly related to leadership and running the top companies in the world. See the recent HBR paper on "Wise Leadership" by Takeuchi and Nonaka.

Nonaka told me Professor Takeuchi had recently moved back to the Harvard Business School (a mile from my home) and I should connect up with him right away. During this year I helped teach one of his business school classes. One of his teams set a world record for the paper airplane exercise we do in ScrumMaster training. I also helped him with a Harvard Business School summer executive program. Takeuchi teaches Scrum in his classes by reviewing the case studies taught at the business school and showing how success was always due to cross-functional teams working intensely together generating continuous improvement. This is Scrum to Takeuchi.

I felt we were lucky to choose their model for a software implementation of Scrum. Takeuchi is considered one of the top ten business school professors in the world and their formal model has led us down the path to an extraordinary implementation of their vision of Scrum project management. Both of these teachers are surprised and impressed with the wide-spread adoption of Scrum in software.

However, I was puzzled by the fact that Takeuchi and Nonaka have written many books and papers about Toyota, Honda, and other lean companies, yet they never talk about lean. They talk about Scrum, which means to them cross-functional teams engaging in the dynamic conflict of ideas that generates "ba," the energy flow that surfaces knowledge that forms new products. It's the innovation they are interested in and what westerner's call lean are a bunch of context dependent techniques that are side effects of knowledge generation. It seems that Scrum is at the root of lean to them.

So I dug into this puzzle a little deeper by carefully studying where this "lean" idea came from as it appears to be a western idea and not so much a Japanese idea. It all goes back to an MIT institute founded in the late 1980s to study why the Japanese automotive industry was starting to dominate world production. They focussed mainly on Toyota and its unique method of production.

Taiichi Ohno, the inventor of the Toyota Production System says everything he knows he first learned at Ford. Then all he did was go back to Japan and remove waste. The story of his work is summarized in “The Machine That Changed the World” where Womack discusses what Ohno did after he returned from studying mass production at Ford.

“Back at Toyota City, Ohno began experimenting. The first step was to group workers into teams with a team leader rather than a foreman. The teams were given a set of assembly steps, their piece of the line, and told to work together on how best to perform the necessary operations. The team leader would do assembly tasks as well as coordinate the team, and, in particular, would fill in for any absent worker—concepts unheard of in mass production plants… Ohno next gave the teams the job of housekeeping, minor tool repairs, and quality checking. Finally, as the last step when teams were running smoothly, he set time aside periodically for the team to suggest ways collectively to improve the process [1].”

Ford Motor company dominated the auto industry with mass production until Alfred Sloan introduced better management practices at General Motors. Toyota moved beyond General Motors with cross functional teams and continuous improvement. They consistently achieved four times the productivity and twelve times the quality of General Motors by the early 1990’s. By 1994 I was writing that General Motors would inevitably go bankrupt within 20 years and Cutter Consortium would not let me publish this statement. I had to take it out of a paper I was writing for them as they thought it was too controversial or maybe "unAmerican." Yet the truth is the truth and General Motors beat my prediction. It only took about 14 years.

This cross functional team process and continuous improvement was observed not only at Toyota, but in many of the best companies worldwide by Takeuchi and Nonaka while they taught at the Harvard Business School in the early 1980s. The teams at Toyota and elsewhere reminded them of the game of rugby and they called this style of project management “Scrum,” a short form of the term “scrummage” where the game is restarted when the ball has gone out of play.

What Takeuchi and Nonaka saw at Toyota, Honda, Canon, Fuji-Xerox, 3M, HP and other high performing organizations is Scrum project management, which means to them teams that are autonomous, motivated by trascendent purpose, and engaged in cross learning. Short iterations combined with these team dynamics facilitate a knowledge generation cycle that leads to innovation, faster time to market, and higher quality. The “lean techniques” touted by Western observers are side effects of what Takeuchi and Nonaka see as the root cause of performance. And the root cause is Scrum which is teams engaged in continuous improvement.

On the Street in Amsterdam

2011-10-11T12:14:00.001-04:00

2011-10-07T11:13:00.000-04:00

Jeff Sutherland’s interview to PC Week

What are the major trends you see in today’s software development world?

If you look at the recent survey done by VersionOne, you will see that today over a third of development is running under the Agile banner. That’s up from just a few percent ten years ago. Traditional project management is actually less than a third of development today, and shrinking rapidly. If you look within Agile development, 75 percent of the people will say that they are doing SCRUM. So SCRUM is expanding. With SCRUM groups you will see a good number, 14 percent, are doing extreme programming practices inside the SCRUM, and there is where we see the fastest teams: using the SCRUM management practice with the extreme programming engineering practices inside.

How are the traditional and extreme programming methods combined in practice?

It’s not traditional practice. SCRUM is a framework for teams using engineering practices outlined by the extreme programming. The first SCRUM team implemented all the extreme programming practices before extreme programming existed. In fact Kent Beck, who started extreme programming, asked me to send him all the information I had on SCRUM, and he had everything about SCRUM before he started working on extreme programming. So when I got together in 1995 with Ken Schwaber to talk about moving SCRUM out into the industry, Ken felt we should just present SCRUM as the team framework: the product order, the SCRUM master, the team, the scrum meetings (how they work together), and the SCRUM artifacts (how you track and manage a SCRUM project). And he felt that if we did that, SCRUM could be implemented very quickly in two days and over time, people could improve the engineering practices using the continuous improvement that is embedded in SCRUM. And when they looked at removing the impediments that were blocking their progress, many of them would be engineering problems and they could look to extreme programming practices to help them with that.

Are there any significant new ideas in this field in the last few years or are they just repetitions of previously known methods?

In one sense there is nothing new. SCRUM was a way to bring together everything we had learned in the last 50 or 60 years in software development and frame it in a way that people could use that knowledge and improve their teams rapidly. So the big changes over the last decade have been teams getting better at doing the basics.

What are the key ideas of the scrum methodology? How does it differ from other approaches?

Takeuchi and Nonaka observed in the paper that launched Scrum that great teams exhibit autonomy, transcendence, and cross-fertilization. The teams they studied had a goal that transcended themselves. They used the knowledge of the cross functional team to facilitate cross learning and building craftsmanship and mastery of their profession. This intense cross functional team working together reminded Takeuchi and Nonaka of the scrum formation in rugby. And so they called this style of management SCRUM project management. And they said that if you get this small team really working together, you generate a cycle of knowledge and improvement quickly—so your products are more innovative, they come to market faster, the users like them better, and the company is more successful. So this scrum idea is fundamentally what Takeuchi and Nonaka saw in the best companies in the world.

Now, it’s interesting that when Westerners looked at what Toyota, for example, was doing, they noticed all the lean techniques: just in time delivery, kanban boards for driving production, all of these things…and the Westerners thought that all of these techniques were what made things work well and the called that ‘Lean’ in the west. But Takeuchi and Nonaka don’t talk about that. They say those techniques are side effects of rapidly evolving SCRUM teams who are generating new knowledge. And part of that new knowledge are new ways to implement. So in recent years, when people have visited Toyota and they’ve talked to the management and said, “Well, we don’t see the same practices at Toyota City in manufacturing cars today that are written up in the Lean textbooks. You’ve changed a lot of them. How can that be?” And the Toyota management will say, “Well, the Toyota way is all about respect for people and the teams doing continuous improvement. So they are constantly changing their practices. In order to go faster, they threw away some of those things that you guys are using in the west and now they are using new techniques.” The core of the issue is the team and the people. That’s the genius of Takeuchi and Nonaka and that’s what we implemented with SCRUM, and we did it in software. They weren’t specifically looking at software, they were looking at everything—you know, all companies. What are the best teams in any company in the world? What are they doing? They’re doing SCRUM. That’s what Takeuchi and Nonaka say. They are doing that team process.

When should it be used in practice?

One of the interesting things about getting a small team together—getting them to work together, getting them to build a backlog like we do in SCRUM, getting them to execute it quickly—it turns out that that works for anything. I work with the Open View Venture Partners, a venture capital firm, and they realized that SCRUM is not the software, that’s what Takeuchi and Nonaka said. SCRUM is getting anything done fast. You can double the output of anything by implementing SCRUM. So Open View implemented SCRUM everywhere—in finance, in administration, in teams that support our investments, teams that search for investments, all of these things—and as a result, many of their companies (we have 14 companies around the world that we are invested in right now that are doing SCRUM, and we’re investing in new companies all the time and we want them all to be SCRUM) and we find that those companies start to implement SCRUM—we have CEOs who have SCRUM boards in their office, they’re running SCRUM for their senior management team, they’re running it in sales, they’re running it in finance, in marketing and support. SCRUM is a process that is useful if you want to integrate, if you want to deliver sooner, if you want to deliver a higher quality product, SCRUM will always make that happen better than traditional ways of approaching project management.

Why did you decide to participate in CEE-SECR 2011?

Richard Soley, the CEO of the Object Management Group (OMG), whom I have known for many years, asked me if I would come to Moscow. I have very little time to travel beyond my clients in Europe and the United States but he pointed out to me that an old colleague, Nick Puntikov, was the chairman of the conference. Now I had worked with Nick back when he was the head of the StarSoft development labs in St. Petersburg. I had done training there. He had some of the highest performing teams in the world doing extreme programming but also working around the world with U.S. companies and other companies doing SCRUM with extreme programming inside. So I started talking with Nick, and Nick convinced me to come to Moscow. So that’s why I’m coming to Moscow.

What are your personal expectations of the conference?

As I said, I’ve been working with SCRUM companies in St. Petersburg and elsewhere so I know that there are a lot of very good Russian software developers, and I think that many of them will be at that conference—Nick said it’s one of the best conferences in Russia—and so I am going to be doing some training there and also some talking and I think it will be similar to some of the other conferences that I attend around the world. People who want to build better software, work faster, build better teams who are in Russia, I think will be there and we should all have a good time talking about it.

Happiness Metric - The Wave of the Future

2011-09-24T09:24:00.000-04:00

Update: ScrumInc used the happiness metric to help increase velocity over 300% this year. Net revenue doubled. The way to do this is now a formal pattern at ScrumPlop.org call "Scrumming the Scrum."

Traveling around the world, the happiness metric keeps bubbling up as a topic of interest. Books are starting to hit the charts at Amazon by business leaders (Zappos CEO, Joie de Vivre CEO) and psychologists. Managers and consultants are telling me that people are getting fed up with being unhappy at work. Younger people in particular are refusing to work in command and control environments based on punishment and blame. Major change is emerging (see The Leaders Guide to Radical Management by Stephen Denning).

The Scrum Papers documents some of the early influences on Scrum and Nobel Laureate Professor Yunus at the Grameen Bank in Bangledesh provided key insights on how to bootstrap teams into a better life. Practical work on these issues on the President's Council at Accion helped me put these insights into practice just prior to the creation of Scrum in 1993. I saw how to bootstrap developers out of an environment where they were always late and under pressure into a team experience that could change their life.

One of the most innovative companies in the world of Scrum is a consultancy in Stockholm called Crisp. Henrik Kniberg is the founder and we have worked together on Scrum and Lean for many years. He recently introduced the "happiness index" as the primary metric to drive his company and found it works better than any other metric as a forward indicator of revenue.

Henrik outlines on his blog how he used the A3 process to set the direction for his company and how that led to measuring company performance by the "Happy Crisper Index."

---------
Now a days one our primary metric is "Nöjd Crispare Index" (in english: "Happy Crisper Index" or "Crisp happiness index"). Scale is 1-5. We measure this continuously through a live Google Spreadsheet. People update it approximately once per month.

Here are the columns:

Name

How happy are you with Crisp? (scale 1-5)

Last update of this row (timestamp)

What feels best right now?

What feels worst right now?

What would increase your happiness index?

Other comments

We chart the history and how it correlates to specific events and bring this data to our conference.

Whenever the average changes significantly we talk about why, and what we can do to make everybody happier. If we see a 1 or 2 on any row, that acts as an effective call for help. People go out of their way to find out how they can help that person, which often results in some kind of process improvement in the company. This happened last week, one person dropped to a 1 due to confusion and frustration with our internal invoicing routines. Within a week we did a workshop and figured out a better process. The company improved and the Crisp Happiness Index increased.

Crisp Happiness Index is more important than any financial metric, not only because it visualizes the aspect that matters most to us, but also because it is a leading indicator, which makes us agile. Most financial metrics are trailing indicators, making it hard to react to change in time.

---------

As Dan Pink points out in his RSA talk, people are motivated by autonomy, purpose, and mastery. Takeuchi and Nonaka observed in the paper that launched Scrum that great teams exhibit autonomy, transcendence, and cross-fertilization. The "happiness metric" along with some A3 thinking helped flush out these issues at Crisp and it can work for your company.

At the core of the creation of Scrum was a daily meditation based on 30 years of practice beginning as a fighter pilot during the Vietnamese war. It is a good practice for a warrior and for Scrum as changing the way of working in companies all over the world is a mighty struggle. May all your projects be early, may all your customers be happy, and may all your teams be free of impediments!

"May all beings be well, may all beings be happy, may all beings be free from suffering."
- Compassion Meditation for a Time of War

Breaking Departmental Silos: Scrum in Finance

2011-09-06T15:00:00.007-04:00

By Christine Hegarty, Scrum Inc.

“So-and-so does that, not me.”

Upon hiring our accountant this June, I gleefully handed off the company QuickBooks file, stacks of financial statements and an overview of the bookkeeping functions and relished in the relief of no longer having responsibility for anything finance-related. The prospect of ignorance was bliss.

Defining the Problem

As it happens, ignorance increases the likelihood of ambiguity, delays, competing priorities, and missed opportunities. Even Scrum Inc., a six-person company run by Scrum with a single backlog, faces the limitations of departmental functions.

Through Scrum we know that a bad system is reflected in the code. We also know that communication saturation and a well-formed backlog with stories that meet the INVEST criteria are critical to attaining gains in performance. Viewing our problem with this lens, I realized that a pass-off system hinders an accountant’s ability to be a great accountant and that the current system would be suboptimal for an organization using Scrum and working towards hyperproductivity. I wanted to get the company’s finance activity started on Scrum and began with a story map.

A story map isn’t defined by Scrum but is useful for showing how functions relate and what tasks are needed to get there. In our company, the major functions of accounting are invoicing, paying vendors, reconciling accounts, reporting, tax preparation, collections, expenses reports, and tracking foreign revenue. From this horizontal stream, I started filling in the tasks needed under each function area. The accountant then worked with me to fill in the missing tasks.

At the Sprint Review and Retrospective, I presented the story map to the team and told them that not having financial tasks in the backlog was a company impediment. The team decided our kaizen for the following sprint would be entering the financial tasks into the backlog and put this improvement at the top of the backlog.

Integrating Department Functions to Smooth Flow

Tackling this impediment first required evaluating the value of financial tasks being a part of the team’s backlog to create a sense of why we would migrate to this system. The goal: eliminate a hand-off approach. The value:

· Breaks down the departmental silo (between operations and finance)

· More visibility for each side

· Team and Product Owner can anticipate needs/resources from accounting

· Accounting anticipates needs from team and Product Owner

· Broadens awareness of the impact of team’s tasks have on financial tasks

· Turns managing accounting activity into supporting accounting activity

· Diverse teams solve complex problems better than a group of like-minded experts, and each employee can benefit from the experience of the others when facing a challenge

· Smooth flow of activity, anticipated rather than reactionary

Standardizing Processes

Following creation of the story map and definition of the value, I theorized that to best meet the requirements of the story, we should start with a schedule of financial activity. Much of the financial activity repeats and follows a certain cycle. Bank statements arrive every month. Taxes are submitted quarterly and yearly. This aspect of finance particularly lends itself to Scrum.

For financial activity required in response to an event or infrequent occurrence, the accountant and I created a Google calendar that showed scheduled engagements. Within each event, the accountant created a short cut and paste question form to be completed by a team member that would provide actionable information. For example, when the company delivers a workshop to a client, the team creates an event in the Finance Calendar titled “Workshop [Client]” and pastes the standard question form into the event:

1. “Bill to” Information

2. AP Contact and Email

3. Project Type

4. Description and Location of Engagement

5. Total

Although simple, the calendar informs the accountant, enables billing to be immediately actionable, and removes the step of needing to email a team member for information.

All financial tasks were added to a spreadsheet and defined, including a column describing frequency by week, month, quarter, year, or “as needed”. We organized the cyclical tasks into a schedule by week. “As needed” tasks were placed in an adjoining column for quick reference.

Week 1	As Needed
tasks	tasks

Week 2
tasks	Tax
	quarterly tasks
Week 3	annual tasks
tasks

Week 4
tasks

With this schedule and the calendar, our Product Owner can plan weekly sprints to include cyclical and as needed financial tasks. These tasks are sized by the accountant based on team estimates and count toward velocity.

Lessons Learned

The team will experiment with this model and continue to inspect and adapt. We have realized the gains of eliminating hand-offs and enabling communication saturation. Finance systems are now clearer and easier to improve and innovate. Standardizing processes creates an easier, faster flow of information in and out of accounting. Working from a single backlog, the team can help finance move faster with higher quality.

2011-08-24T08:20:00.001-04:00

Outmoded project management practices are much more damaging that most people realize. Here is a 5M IT project failure that turned into a 200M writeoff for the company. Board members take notice.

Why Your IT Project May Be Riskier Than You Think

by Bent Flyvbjerg and Alexander Budzier, Harvard Business Review, Sep 2011

To top managers at Levi Strauss, revamping the information technology system seemed like a good idea. The company had come a long way since its founding in the 19th century by a German-born dry-goods salesman: In 2003 it was a global corporation, with operations in more than 110 countries. But its IT network was antiquated, a balkanized mix of incompatible country-specific computer systems. So executives decided to migrate to a single SAP system and hired a team of Deloitte consultants to lead the effort. The risks seemed small: The proposed budget was less than $5 million. But very quickly all hell broke loose. One major customer, Walmart, required that the system interface with its supply chain management system, creating additional hurdles. Insufficient procedures for financial reporting and internal controls nearly forced Levi Strauss to restate quarterly and annual results. During the switchover, it was unable to fill orders and had to close its three U.S. distribution centers for a week. In the second quarter of 2008, the company took a $192.5 million charge against earnings to compensate for the botched project—and its chief information officer, David Bergen, was forced to resign. Read more ...

Forbes Blog: Steve Jobs on Get Rid of the Crappy Stuff!

2011-08-14T11:31:00.000-04:00

Image via Wikipedia

Carmin Gallo, Forbes, 5/16/2011

Apple recently passed Google as the most valuable brand in the world. It’s extraordinary to think that the world’s top brand has a product portfolio that could fit on a small table. Of course that’s part of the reason why Apple is so successful—its relentless focus on creating a small number of simple and elegant products. When I was conducting the research for my book, The Innovation Secrets of Steve Jobs, I came across one story that provides a glimpse into how Steve Jobs and the company he co-founded has achieved its stunning success. The story comes to us courtesy of Nike CEO, Mark Parker. He said shortly after becoming CEO, he talked to Steve Jobs on the phone.

“Do you have any advice?” Parker asked Jobs. “Well, just one thing,” said Jobs. “Nike makes some of the best products in the world. Products that you lust after. But you also make a lot of crap. Just get rid of the crappy stuff and focus on the good stuff.” Parker said Jobs paused and Parker filled the quiet with a chuckle. But Jobs didn’t laugh. He was serious. “He was absolutely right,” said Parker.

Click for more ...

-----

A ScrumInc. client recently had a problem. The Product Owner team could only produce enough backlog for 30% of the developers. The recommendation was to use the other 70% of developers to get rid of the crappy stuff. The release time was cut in half with more features than the previous release and was delivered by 30% of the developers. The stock price went up 400% during the implementation when the other 70% of the developers started getting rid of the crappy stuff.

2011-08-05T17:23:00.004-04:00

Bob Sarni

Part 1 - http://www.youtube.com/watch?v=2r1GYC04VHI&feature=youtu.be

Part 2 - http://www.youtube.com/watch?v=1QbMRew-Olk&feature=related

Part 3 - http://www.youtube.com/watch?v=6tCLxNPh3Ic&feature=related

Part 4 - http://www.youtube.com/watch?v=1-RBlli6W-I&feature=related

Part 5 - http://www.youtube.com/watch?v=Ww5l0-yMGdM&feature=related

Part 6 - http://www.youtube.com/watch?v=2LTjzptoGfs&feature=related

Part 7 - http://www.youtube.com/watch?v=OfkxQ7buOhE&feature=related

Part 8 - http://www.youtube.com/watch?v=8cLdl-W7eQI&feature=related

Openview: Scrum Inc. training on location

2011-08-02T14:55:00.002-04:00

VENTURE CAPITAL

Inside OpenView's corporate relocation program

Posted by Scott Kirsner August 2, 2011 11:01 AM Boston.com
By Scott Kirsner, Globe Columnist

Scott Maxwell grew up in Silicon Valley, but these days he is practically operating a shadow economic development agency in Massachusetts. As founder of OpenView Venture Partners, a Boston-based venture capital firm (and before that as the head of the Boston office of Insight Venture Partners), he has persuaded more than a half-dozen companies from around the world set up shop here.

OpenView targets software and Internet companies that have already created a product or service, and begun generating revenue. "We look for companies that have around $5 million in revenue when we invest," Maxwell says, "so it's really expansion investing, giving them the resources they need for growth." OpenView will invest in start-ups anywhere in the world, Maxwell adds, "but the company needs to have a North American strategy." Often, that entails setting up a new headquarters in the U.S. and hiring a CEO here. OpenView's current fund totals $233 million, Maxwell says, and typically the firm puts about $7 million or $8 million into a company as its initial investment.

While a partner at Insight (a Manhattan-based firm), Maxwell brought three companies — Astaro, Imceda Software, and Acronis — to Burlington from Germany, Australia and Russia, respectively. Intronis, a cloud-based back-up service that started life in New Jersey, is now operating out of OpenView's Fort Point Channel office, and Zmags, an online merchandising company founded in Denmark, is now headquartered in the same neighborhood. Two other companies, Exinda and Open-e, have established headquarters in Boston after raising money from OpenView.

Most of the companies are still relatively small; all told, they account for perhaps 250 jobs in the state, according to OpenView's figures. "Boston is just the best place to set these companies up," Maxwell says. Often, they start by using space in OpenView's offices.

"It's really difficult to grow a company in Silicon Valley," he continues. "There's too much competition for hiring, the costs are high, and people in Massachusetts work a lot harder. For business-to-business companies, the labor pool is incredible here, and there are plenty of salespeople. And I say all that as a California native."
______
Jeff Sutherland has been Senior Advisor to Openview Venture Partners since 2006 where he started up Scrum Inc. onsite and began working with portfolio companies to implement Scrum. He has recently moved to the Cambridge Innovation Center as the Scrum Inc. team has expanded.

Openview uses Scrum everywhere for venture group operations. About 14 portfolio companies implement Scrum in software development and many of them use Scrum in sales, marketing, finance, admin, and even for the senior management teams.

For the next Certified ScrumMaster training at Openview see scrumfoundation.com.

Can your new hire work on a Scrum team?

2011-07-12T08:13:00.001-04:00

New for Aspiring Doctors, the People Skills Test

By GARDINER HARRIS

Published: July 10, 2011, New York Times

ROANOKE, Va. — Doctors save lives, but they can sometimes be insufferable know-it-alls who bully nurses and do not listen to patients. Medical schools have traditionally done little to screen out such flawed applicants or to train them to behave better, but that is changing.

Enlarge This Image

Jeremy M. Lange for The New York Times

Applicants prepared for the first phase of the “multiple mini interview” at Virginia Tech Carilion.

At Virginia Tech Carilion, the nation’s newest medical school, administrators decided against relying solely on grades, test scores and hourlong interviews to determine who got in. Instead, the school invited candidates to the admissions equivalent of speed-dating: nine brief interviews that forced candidates to show they had the social skills to navigate a health care system in which good communication has become critical.

The new process has enormous consequences not only for the lives of the applicants but, its backers hope, also for the entire health care system. It is called the multiple mini interview, or M.M.I., and its use is spreading. At least eight medical schools in the United States — including those at Stanford, the University of California, Los Angeles, and the University of Cincinnati — and 13 in Canada are using it.

Grandfathers of Scrum on Leadership

2011-07-10T10:51:00.002-04:00

The Big Idea: The Wise Leader

by Ikujiro Nonaka and Hirotaka Takeuchi in Harvard Business Review, May 2011

In an era when discontinuity is the only constant, the ability to lead wisely has nearly vanished. All the knowledge in the world did not prevent the collapse of the global financial system three years ago or stop institutions like Lehman Brothers and Washington Mutual from failing.

No one could slow down the recession as it sped across the world, or ensure that market leaders like General Motors and Circuit City didn’t go bankrupt. No one realized that despite enormous government stimuli, the road to recovery would be torturous, with so few jobs created in the U.S. and Japan. Never did we expect more of leadership—and never have we been so disappointed.

It isn’t uncertainty alone that has paralyzed CEOs today. Many find it difficult to reinvent their corporations rapidly enough to cope with new technologies, demographic shifts, and consumption trends. They’re unable to develop truly global organizations that can operate effortlessly across borders. Above all, leaders find it tough to ensure that their people adhere to values and ethics. The prevailing principles in business make employees ask, “What’s in it for me?” Missing are those that would make them think, “What’s good, right, and just for everyone?” The purpose of business, executives still believe, is business, and greed is good so long as the SEC doesn’t find out.

The gulf between the theory and practice of ethics exists in business for several reasons: There is a big difference between what top management preaches and what frontline people do. There’s a philosophical tendency in the West, following Plato, to conclude that if a theory isn’t working, there must be something wrong with reality. People behave less ethically when they are part of organizations or groups. Individuals who may do the right thing in normal situations behave differently under stress. And common rationalizations, such as that you are acting in the company’s best interest, or justifications, such as that you will never be found out, lead to misconduct.

Hit by fraud, deceit, and greed, people are angry about the visible lack of values and ethics in business. There’s something wrong with the way B-schools, companies, and leaders are developing managers. As Bent Flyvbjerg pointed out in Making Social Science Matter (Cambridge, 2001), instead of trying to emulate the natural sciences, we should have ensured that management asked questions such as “Where are we going?” “Who gains, who loses, and by which mechanisms of power?” “Is this development desirable?” “What should we do about it?”

For leaders to cope with these myriad pressures, knowledge is more critical than ever before. Sixteen years ago we published The Knowledge-Creating Company. Since then executives have come to recognize that knowledge can yield sustainable competitive advantage. Companies have learned to capture, store, and distribute knowledge, so it continually catalyzes innovation. However, as we have seen, leading a knowledge-creating company is difficult.

Why doesn’t knowledge result in wise leadership? The problem, we find, is twofold. Many leaders use knowledge improperly, and most don’t cultivate the right kinds. The types of knowledge we discussed in our book are now well known: explicit and tacit. Managers tend to rely on explicit knowledge, because it can be codified, measured, and generalized. Wall Street firms thought they could manage greater risk by using numbers, data, and scientific formulas instead of making judgments about loans one at a time. The same holds for the U.S. automobile industry, which relies on offering financial incentives rather than understanding customer needs.

Reviewers needed for HICSS-45 Agile research papers

2011-06-26T16:03:00.004-04:00

HICSS is one of the top conferences in paper citation index rankings. This means papers will be seen and used by researchers worldwide more than papers from other conferences. All HICSS papers are published in the IEEE Digital Library and are FREE to download, so accepted papers are accessible to everyone at any time, even by your grandchildren. No other conference can give you the same distribution of your concepts and ideas.

HICSS-45 REVIEWERS NEEDED - reviews due by 1 Aug 2011

January 4-7, 2012

The Grand Hyatt Kauai Resort and Spa

Kaloa, Kauai, Hawaii

Contact jeff@scruminc.com if you would like to review one or more of the four papers below. Please create an account at https://precisionconference.com/~hicss before emailing me with the numbers of the papers you would like to review.

Improving Trust in Information Systems Development Using Agile and Formal Practices (411)

Abstract: This paper posits that implementing a balanced portfolio of Agile and formal project practices will strongly support the cognitive trust-building processes and promote good development and O&M decision making for information systems, programs, and projects. The mechanisms enhance decision making by moderating the potentially negative effects of executive, managerial, development team, and end user distrust. Research has shown that establishing and maintaining an environment of trust can be improved by using well regarded effective trust supporting and trust building practices in appropriate situations that avoid a “Cargo Cult” mentality.

This paper argues for employing a set of trust building practices and processes from both formal and Agile methodologies that vary depending upon three factors; the need to develop a new or full replacement system, the experience of the user/purchasing organization with the development team, and the O&M status/working capabilities of the solution in use by the target organization.

Evaluating and Improving Software Scalability (774)

Abstract: Scalability is an important but under-researched topic. Many organizations developing for the Web face the problem of measuring and predicting the scalability of the software systems they develop. Though the scalability problem seems quite prevalent, there is no widely accepted definition of software scalability in the current literature. There is also a lack of an accepted method to evaluate the scalability of a piece of software based on software bottlenecks. In this paper we first review the existing definitions of software scalability, analyse why they only partially match the scalability problem for software, and make an attempt to get at a definition of what is meant by software scalability. We use this definition of scalability to propose an approach to evaluate the software scalability of a Web application. We then test this evaluation approach in a case study of a software development organization.

Effect of Task Mental Models on Software Developer’s Performance: An Experimental Investigation (1195)

Abstract: This study provides some preliminary results on the efficacy of mental models in software development. Specifically, based on results from a controlled laboratory experiment, it shows that a software developer’s mental model quality is a determinant of software quality performance, regardless of whether the task is performed individually or in pairs. Further, this effect is found to be consistent across software tasks of varying complexity.

Investigating the Long-Term Acceptance of Agile Methodologies: An Empirical Study of Developer Perceptions in Scrum Projects (1327)

Abstract: Agile software development methodologies have gained huge interest in research and practice. However, since they set a polar opposite to traditional methodologies, their introduction hugely affects the working habits of developers. As agile methodologies postulate flat hierarchies and self-organizing teams, the long-term commitment of developers becomes a critical success factor. Yet, current studies primarily measure the success of agile methodologies in the short-term. In order to evaluate the use of agile methodologies in the long-term, we conducted a study at a world-leading insurance company which introduced Scrum back in 2007. Using qualitative research methods and the Diffusion of Innovations Theory as an analytical lens, we gained in-depth insights into the long-term use of Scrum. In particular, we were able to identify numerous factors which developers perceived as relative advantages or more compatible to their working processes. However, we also found factors regarding the complexity of Scrum which were perceived as drawbacks by developers.

Background on HICSS:

Now in its 45th year, the Hawaii International Conference on System Sciences (HICSS) is one of the longest-standing continuously running scientific conferences. This conference brings together researchers in an aloha-friendly atmosphere conducive to free exchange of scientific ideas. Unique characteristics of the conference include:

A matrix structure of tracks and themes that enables research on a rich mixture of computer-based applications and technologies.
Three days of research paper presentations and discussions in a workshop setting that promotes interaction leading to additional research.
A full day of Symposia, Workshops, and Tutorials. See Program Components for additional detail.
A truly international experience with participants usually from over 40 countries, (approximately 50% non-US).
Papers published in the Proceedings by the IEEE Computer Society Press and carried in the IEEE digital library Xplore. Access to HICSS papers is in the top 2% of IEEE Conferences.
Paper presentations and discussions which frequently lead to revised and extended papers that are published in journals, books, and special issues.
A keynote address and distinguished lecture which explore particularly relevant topics and concepts.
Best Paper Awards in each track which recognize superior research performance.

Recent research that shows HICSS ranked second in citation ranking among 18 Information Systems (IS) conferences[1], ranked third in value to the MIS field among 13 Management Information Systems (MIS) conferences[2], and ranked second in conference rating among 11 IS conferences[3]. See References.

The Australian Government's Excellence in Research project (ERA) has given HICSS an "A" rating, one of 32 Information Systems conferences so honored out of 241 (46-B and 146-C ratings). Data supplied by the Australian Research Council, December 2009. See http://lamp.infosys.deakin.edu.au/era/?page=cfordet&selfor=0806

Back to the Future: Agile Manifesto Reunion

2011-06-15T15:44:00.007-04:00

Click here for reunion info ...