Scrum Log Jeff Sutherland

Excel Spreadsheet for Hyperproductive Scrum Teams - very cool!

2010-01-30T12:43:00.000-05:00

Scrum Metrics for Hyperproductive Teams: How They Fly Like Fighter Aircraft

Jeff Sutherland and Scott Downey

Agile 2010 Submission

Scrum teams use lightweight metrics like story points, the burndown chart, and team velocity. The inventor of Scrum was a fighter pilot and used the burndown chart to help teams land a sprint properly. Recent work with hyperproductive teams shows they are like modern jet fighters in two ways. They have engines that produce velocity�alignment of the team, and team spirit. And they carefully measures aspects of performance to make slight adjustments in flight. Failing to constantly adjust the flight of the team can result in a hyperproductive crash into waterfall performance.

One hour discussion of a comprehensive, yet minimal set of team metrics used in an environment where hyperproductive teams are the norm, along with an Excel spreadsheet that can be used by any Scrum team to improve performance. Velocity, story completion by priority, work in progress, story acceptance rate by product owner, unplanned work, and trending accuracy of estimates all appear to be essential to determine the altitude, velocity, angle of attack, and attitude of a hyperproductive team. Slight adjustment of these parameters on a daily basis keeps the team on target. Half hour questions and discussion on using the Excel spreadsheet to improve team performance.

How you can download Scott Downey's extremely cool Excel Spreadsheet for your Scrum team:

Go to the Agile 2010 speaker web site:

http://agile2010.agilealliance.org/speaker.html

Click on login and sign up for a free account. You can then login and access:

http://agile2010.agilealliance.org/node/5217

Please give us a few positive comments in a review so Agile 2010 will get this submission on the agenda for the conference. You can download the spreadsheet at the link above.

Role of the Manager in Scrum

2010-01-24T07:45:00.000-05:00

Pete Deemer, our Business Manager at the Scrum Training Institute, has written an excellent article on the role of the manager in Scrum.

---------

Like me, you probably get asked the following question quite often: "What's the role of a manager in Scrum? I'm a manager, and since I'm not mentioned in the definition of the Scrum roles, and the team is self-organizing, does that mean I'm supposed to just... disappear?"

http://scrumti.com/home/stream_download/%23%3CUUID:0xb747aba0%3E-71972

Pete Deemer

Agile 2010 Abstract Posted: Hitting the Wall!

2010-01-24T06:48:00.000-05:00

Hitting the Wall: What to Do When High Performing Scrum Overwhelms Operations

ll-at-once Scrum implementations require total commitment to change, high level management participation and aggressive removal of impediments. In July of 2009, Pegasystems (NASDAQ:PEGA) deployed 27 Scrum teams in the U.S. and India in less than two months and global continuous integration became a top priority impediment. To avoid �hitting the wall� before the first major Scrum release of their enterprise software applications, a Scrum SWAT team engineered a continuous integration environment for hundreds of software developers on two continents within a few weeks.

* Understand strategy for widespread deployment of Scrum in an enterprise
* See impact of Scrum team productivity on operations and infrastructure
* Learn how to identify top priority engineering impediments
* Be able to rapidly deploy continuous integration in a complex enterprise software environment

Create a free account at http://agile2010.agilealliance.org/speaker.html and you can download and review a draft of this paper.

Iterative vs. Incremental Development

2010-01-13T13:51:00.001-05:00

Drawing by Jeff Patton

What is iterative and what is incremental development? Even the experts are confusing themselves when describing it. Perhaps our language is an inadequate reflection of reality.

Jeff Patton thinks software should be built the way an artist works. The artist "iterates" on the whole thing and the potential of the whole picture is visible in every iteration from the initial sketch to the final painting. The complete work comes gradually into focus. Patton calls this "iterative" development.

However, this is exactly what Mills and Brooks call "incremental" development. They advocate growing software like a plant. This is a similar metaphor to the way an artist's sketch "grows."

Harlan Mills of IBM first published this concept in �Debugging Techniques in Large Systems� Prentice Hall, 1971. (Any software system should be grown by incremental development.)

Fred Brooks popularized the concept in �No Silver Bullet: Essence and Accidents of Software Engineering� first published in IEEE Computer, April 1987 with the final version published in the anniversary edition of �The Mythical Man Month.�

So Patton has the right idea, but his use of the term iterative development is wrong. Incremental development is iterating on the whole thing (each iteration is a minimal useable feature set that is potentially shippable).

Patton slams the common practice of building one feature completely in an iteration, then a second feature in a subsequent iteration. He calls this incremental development (wrong!). He is out of step with the terminology used by computer scientists over many decades.

Key to the Mills/Brooks concept of incremental development is the idea that every iteration is usable in some way (potentially shippable software). The first Scrum shipped all increments at the end of each iteration and they were used by internal consultants �in anger� to execute on revenue generating customer projects. It was only �potentially shippable� because the Product Owner (Don Roedner) was not ready to release it to the general market.

Patton is not clear on what we meant by potentially shippable software which is that every iteration is useable. �Potentially shippable� was first described by Ken Schwaber in his OOPSLA 1995 paper on Scrum after observing the first Scrum team. This first paper on Scrum is republished in �The Scrum Papers.� Perhaps Ken and I could have been clearer on what �potential shippable software� means.

So Scrum is both interative and incremental development when done properly. Each iteration delivers a fully functional increment, just as a plant works at every stage of growth. If it does this every iteration is �potentially shippable" and in the ideal case is shipped to a set of end users who use it to get real work done and provide feedback.

HICSS 2010: Schedule of Agile Papers

2009-12-31T03:19:00.000-05:00

Free download of IEEE library of HICSS papers from previous years!
HICSS has an agreement with IEEE for free download of all published papers. Click on link above.

HICSS-43 Agile Papers Schedule
Track: Software Technology
Minitrack: Agile Software Development: Lean, Distributed, and Scalable
Co-Chairs: Jeff Sutherland and Gabrielle Benefield
January 5-8, 2010
The Grand Hyatt Kauai Resort & Spa, Kaloa, Kauai, Hawaii

HICSS-43 offers a unique, highly interactive and professionally challenging environment that attendees find "very helpful -- lots of different perspectives and ideas as a result of discussion." HICSS sessions are comprised primarily of refereed paper presentations; the conference does not host vendor presentations. All papers are peer reviewed and accepted papers are published in the IEEE Digital Library.

ST 1 Wednesday / Kauai Ballroom 6 / 8:00 � 9:30

Enterprise Scrum: Scaling Scrum to the Executive Level
Daniel R. Greening
Exploring the Transient Nature of Agile Project Management Practices
Lech Krzanik, Pilar Rodriguez, Jouni Similia,
and Anne Rohunen
Rigorous Support for Flexible Planning of Product Releases � A Stakeholder-Centric Approach and its Initial Evaluation
Ville Heikkil�, Anas Jadallah, Kristian Rautiainen,
and Guenther Ruhe

ST 2 Wednesday / Kauai Ballroom 6 / 10:00 � 11:30

Seven Dimensions of Agile Maturity in the Global Enterprise: A Case Study
Robert Benefield
Software Entropy in Agile Product Evolution
Geir Hanssen, Aiko Yamashita, Reidar Conradi,
and Leon Moonen
Organizational Transformation with Scrum: How a Venture Capital Group Gets Twice as Much Done with Half the Work
Jeff Sutherland and Igor Altman

Mentoring Candidates for CST

2009-12-22T10:24:00.001-05:00

Many people ask about how to become a Certified Scrum Trainer. A series of recommendations has been discussed within the Scrum Trainer community and published at the link below. While not mandatory, they are certainly recommended guidelines. Click on the link for complete documentation.

Mentoring for candidates for CST
This page describes the best practice guidelines already in use by many senior CSTs. Reviewers of CSTs have been requested to consider this in their reviews. These best practices were later also agreed by the CSTs interested in this topic at the ScrumGathering in Orlando in 2008.

Mentoring serves two purposes.

* Enable the mentor (and others) to make an informed recommendation or decision.
* Enable the candidate to learn more about being a CST, so that, if approved, he or she can be more successful.

Scrum is important and very strong CSTs are critical to its continuing success. Thus, mentoring is important. It is in the best interest of the customers who ultimately benefit from Scrum that the CST community be improved.

Jeff Sutherland @ Google, Dec 14 2009

2009-12-16T12:43:00.001-05:00

Interesting discussion at Google on Monday evening this week. Slides are available at the link below. Available also is the Systematic Ready Ready Checklist for Product Backlog discussed during the presentation. The talk was based on the Agile 2009 experience report:
C. Jakobsen and J. Sutherland, "Scrum and CMMI � Going from Good to Great: are you ready-ready to be done-done?," in Agile 2009, Chicago, 2009.

A Practical Roadmap to Great Scrum: A Systematic Guide to Hyperproductivity

In the field of Large-scale application of Agile, the best data set comes from a CMMI Level 5 company that is providing data collected from over 100 highly disciplined Scrum teams. Based on the lessons found in this data, Jeff will describe how a new team can follow the path of Systematic Software Engineering and double productivity by focusing on "product DONE," then double it again by focusing on "product backlog READY." Current research shows that any team can achieve hyper-productivity in a few sprints, even in a dysfunctional company. This presentation will show the audience how to do it and how easy it can be, if they work to remove impediments.

The talk is free, but due to space constraints, attendance is limited and RSVP is required.

Registration, socializing, and light refreshment from 5:15 - 6:00.
Doors close at 5:45
Talk and Q&A from 6:00 - 7:30

Location:
Google
111 Eighth Ave - 10th Floor
New York, NY 10011
http://maps.google.com/maps?q=111+Eighth+Ave+10011
(use the doors by the Chase Manhattan Bank near 15th Street)

Give Thanks for Scrum Day

2009-11-27T15:04:00.002-05:00

GiveThanksforScrum_23, originally uploaded by IT Event Photography Boston.

Ken Schwaber and I had a spirited discussion answering questions from the audience at the Agile Boston conference on 25 November.

I started off the day with "Practical Roadmap to Great Scrum: Systematically Achieving Hyperproductivity." Several people have asked for data on story process efficiency which typically is about 20%, i.e. if a story takes one ideal day to implement it takes five calendar days to deliver on average. When you raise your story process efficiency to over 50% you will double your velocity. Systematic Software Engineering in Denmark, a CMMI Maturity Level 5 company, has provided extensive data in this presentation which will be useful to anyone interested in high performing Scrum teams.

Enabling Specifications: The Key to Building Agile Systems

2009-11-25T10:29:00.000-05:00

Previously, I discussed the notion of "Agile Requirements" and this concept is embedded in the Nokia Test. There is not a definition of Agile Requirements that is commonly agreed upon. However, I have found a standard concept that is better terminology for what is needed.

A couple of years ago, I visited PatientKeepers patent attorneys as our CEO wanted to get a patent on a discovery of a reporting strategy for analyzing physician fee payments that would raise hospital revenue by 30% during the first month of use. I asked the Product Owner to bring along what documentation she had for review by the lawyers. There was a three page Agile Specification. This is a document that Product Owners at PatientKeeper use to describe the global concept of a feature. User stories are developed from this document.

Our goal was to work with the lawyers to understand how much documentation was needed for a patent application. The lawyers pointed out that a patent application is an "enabling specification." This is a legal term that describes a document that allows the average person knowledgeable in the domain to create the feature without having any discussion with the originators of the enabling specification.

The lawyers determined that our Agile Specification of three pages was not an enabling specification. To produce a document that would be approved by the U.S. patent office we would need five pages.

It turns out that an enabling specification is exactly what is needed to maximize the process efficiency of executing a user story. The average process efficiency of teams executing user stories is about 20%. This means a story that takes one ideal day of work takes five calendar days to delivery. Systematic Software Engineering, a CMMI Maturity Level 5 company, has extensive data showing that teams that drive story process efficiency to over 50% will double their velocity systematically for every team.

The definition of an "enabling specification" is part of U.S. patent law which has been adjudicated extensive by the courts so it is not only a commonly agreed upon concept, you can take your requirements to court and the judge will tell you whether or not they are enabling specifications.

In general, requirements are NOT enabling specifications. On a recent project at a large global company we discovered that hundreds of pages of requirements were not enabling specifications. On the average 60% of what was in the documents was useless to developers. It caused estimates to double in size. Even worse, 10% of what was needed by developers to implement the software was not in the requirements.

A user story must be an enabling specification for agile teams to operate at peak performance. If it is not, there will be the need for continued dialogue with the Product Owner during the sprint to figure out what the story means. This will reduce story process efficiency and cripple velocity.

A user story contains a template, notes, acceptance tests, and implies a conversation with the Product Owner. So the conversation may be part of the enabling specification if the conversation is clear before the beginning of a sprint. As the lawyers pointed out, an enabling specification for a major feature needs to be no more than five pages. So all of the documentation needed, including transcribing all the conversations, should be on the order of 3-5 pages for a moderately large feature. This is what I mean by "Agile Specification." I now think "Enabling Specification" is better terminology.

2-231 Obtaining Patent Rights � 2.07[6]
"A patent specification is enabling if it allows a person of ordinary skill in the art to practice the invention without undue experimentation."

See Jay Dratler. Intellectual Property Law: Commerical, Creative, and Industrial Property, Volume 1 for citations.

Le Ph�nom�ne Chabal

2009-11-21T19:41:00.001-05:00

Sebastien Chabal sacks the All Black ...

Agile Boston User Group Event: Give Thanks for Scrum 25 Nov

2009-11-15T15:25:00.003-05:00

Join the Agile Boston user group as we GIVE THANKS FOR SCRUM on the day before Thanksgiving, 11/25, at the Microsoft facility in Waltham Massachusetts from 12:30 - 5:30 pm.

This is your fun, informative, convenient, content-rich, no-empty-calories, 100% Scrum-centric Boston agile community event. We put it together for your enjoyment, in one great afternoon.

This festive event includes great speakers, great food, great socializing, and great Scrum authorities-- including Jeff Sutherland, Ken Schwaber, Amr Esslamadisy, Sanjiv Augustine, Dan Mezick and more.
Turkey from Georgetown Texas Public Library

Our Sessions and Speakers: Click here to view all sessions

JEFF SUTHERLAND on Scrum applied (session details)

KEN SCHWABER (confirmed!) on: Outrageous Assessments (*NEW* session details)

SANJIV AUGUSTINE on: Working towards true mastery of Scrum (session details)

AMR ELSSAMADISY on successfully adopting Scrum in YOUR organization. (session details)

DAN MEZICK on deconstructing Scrum via BART (Boundary, Authority, Role and Task) analysis (session details)

SCRUM AUTHORITY PANEL: JEFF and KEN SCHWABER (confirmed!) (session details)

LIVE MUSIC with DAN HERMES (biography and links)

Register and directions here ...

AgilePalooza Slides and Papers, Charlotte, NC, 13-14 Aug 2009

2009-11-13T09:21:00.003-05:00

The presentations below make a good introductory workshop on Scrum. All slides and reference papers are provided.

AgilePalooza, Charlotte, NC, 13-14 Aug 2009

Day 1 � Wells Fargo KEYNOTE 8:45 � 9:45 am

Agile Software Development in the Enterprise
Jeff Sutherland, Ph.D.

Scrum started in small companies and achieved dramatic results with hyperperforming teams. This presentation will show how several companies have used hyperproductivity to generate extraordinary financial returns. It will also describe how Scrum scales up for large companies and outsourced, distributed teams and how venture capitalists are using Scrum to improve returns in their investiment portfolios. Scrum is used in large financial organizations like Vanguard, Wachovia, Fidelity, Standard and Poors, and many others. Some strategies for getting started with Scrum are described.

Beginner Track 10:00-11:15 am

Introduction to Scrum: How they did it at Yahoo

Jeff Sutherland, Ph.D.

Scrum Training Institute co-founders deployed 250 Scrum teams at Yahoo during 2005-2008. Teams that were well coached achieved 300-400% gains in productivity. Teams not properly coached were audited at 35% improvement. The overview of the basic training for new Yahoo teams will be covered in this session by the Chairman of the Scrum Training Institute. IEEE paper on Yahoo Scrum implementation can be found in "The Scrum Papers."

Advanced Track 1:15 � 2:30 pm

Practical Roadmap to Great Scrum: How one of the world�s best companies systematically improves Scrum performanceJeff Sutherland, Ph.D.

The ACM Agile chapter in Boston was sold out at the Microsoft Research and Development Lab in Cambridge last week for a presentation on how to systematically take Scrum development teams to a hyperproductive state based on extensive data collected on hundreds of teams at Systematic Software Engineering in Denmark during 2006-2009. As a CMMI Level 5 company, Systematic institutionalizes standard processes across their entire organization and does large fixed-price defense, healthcare, and financial systems under contract. In 2006, they systematically doubled the productivity of every team in the company through Scrum with a lean approach to Acceptance Test Driven Development. In 2009, they began the second doubling of productivity by focusing on the Product Owner and process efficiency of stories. Their lean, systematic, and well documented approach to deploying Scrum will help everyone achieve similar levels of performance. Click here for latest IEEE paper on Systematic Scrum implementation.

Fishbowl Panel 4-5:30 pm

Day 2 � Public Day at Crowne Plaza Hotel

Learning Agility Track 11-12:15

Introduction to Scrum: Shock Therapy

How new teams in California and Sweden systematically achieve hyperproductivity in a few sprints
Jeff Sutherland, Scott Downey, Bj�rn Granvik

New teams need to learn how to do Scrum well starting the first day. This talk will describe how expert coaches at MySpace in California and Jayway in Sweden bootstrap new teams in a few short sprints into a hyperproductive state. This requires new teams to do eight things well in a systematic way. Good ScrumMasters with make sure their teams understand these basics for high performance and great ScrumMasters will make sure the teams execute all of them well. This session will review the critical success factors for new Scrum team formation. Click here for Shock Therapy IEEE paper.

Advancing Agility with Non-Software Scrum � Open Space 12:15-1pm

Discussion of:

Scrum in Church: Saving the World One Team at a Time
Rev. Arline Conan Sutherland, Jeff Sutherland, Christine Hegarty

Take no Prisoners: How a Venture Capital Group Does Scrum
Jeff Sutherland, igor Altman

Scrum Everywhere: Wiredrive Implements Scrum for Sales and Support

2009-10-22T06:00:00.001-04:00

Bill Sewell, Scott Downey, Jeff Sutherland

At a recent Digital LA Scrum event, Scott Downey and I talked with Bill Sewell, CEO of Wiredrive a company that manages creative advertising. Bill has an innovative approach to using Scrum for his sales team.

Scott and I were doing a Certified ScrumMaster course in Beverly Hills at the time and will do another on 11-12 January 2009. See link on left side of the page.

Can Scrum Help Facilitate Creative Process?

Scrum is a nicely refined way of managing people and tasks. It helps project teams assess priorities and work together. Some of the scrum methodology came from Toyota, which figured out that teams work more efficiently when they can self organize, work in shorter bursts (two week cycles), and understand their purpose clearly. Most people who use scrum are in the Web 2.0 space, but the Church of Sweden and many local governments are finding it to be a useful process, as well.

We�ve been using scrum for our development process for a while now. We use it not only in production, but in sales, customer care and support. In the advertising space, companies like the Barbarian Group are making good use of scrum in their daily operations. We would love to see other companies learning about this new process and getting on board. It might be constructive to share information and explain what we�ve learned, what works for us, and what we�ve had to modify.

Scrum principles behind creativity

At Wiredrive, we are huge fans of TED conferences. There are two TED videos that echo the sentiments of the scrum process. The first is called the Surprising Science of Motivation by Dan Pink and the second is called, Do Schools Kill Creativity? by Ken Robinson. If you are trying to solve difficult, imperceptible problems, then you need to be in a creative mindset. Most of our institutions are really good at killing creativity and instituting a factory like environment.

Not surprisingly, most motivation incentives that worked great for easy tasks actually slow people down when they are trying to solve imperceptible problems. What works best is intrinsic motivation, focusing on autonomy, mastery and purpose. This is what scrum does really well; allowing team members to self prioritize, utilize their strengths and work with a sense of purpose to achieve hyper productivity.

Jeff Sutherland has an interesting metaphor he calls �red pill, blue pill� based on the movie The Matrix. He warns people learning scrum that it�s the equivalent of Neo choosing the red pill and waking up in the bowels of a nasty spaceship, realizing that his whole existence had been an illusion. Once you have learned how to work as a self organized team, you never want to go back to being plugged in to the machine.

Scrum Gathering Munich Keynote: Practical Roadmap to Great Scrum

2009-10-20T04:24:00.002-04:00

A Practical Roadmap to Great Scrum: A Systematic Guide to Hyperproductivity
Jeff Sutherland, Ph.D - Chairman, Scrum Training Institute

The best data in the world on Scrum comes from a CMMI Maturity Level 5 company that is migrating all data collection to function points to provide research data on over 100 highly disciplined teams. I will describe how a new Scrum team can follow the path of Systematic Software Engineering to double productivity by focusing on DONE and then doubling it again by focusing on product backlog READY. Current research shows that every team can achieve hyperproductivity in a few sprints, even in a dysfunctional company. This presentation will show you exactly how to do it and how easy it is if you remove impediments.

Click here for slides...

Scrum Day Keynote South Africa: Take No Prisoners

2009-09-13T08:36:00.001-04:00

I gave the keynote address for Scrum Day in South Africa, filling in for Ken Schwaber who had a bicycle accident the previous week. The group asked me to talk about the paper we presented at Agile 2009 called "Take No Prisoners: How a Venture Capital Group Does Scrum."

A good time was had by all even though I did it remotely using Acrobat Connect and Skype video. Click here for the slide presentation. For the paper, click on "Jeff Sutherland's Papers" on the left side of the page. The paper is being expanded and upgraded for the Hawaii International Conference on Systems Sciences and will be uploaded shortly.

Pivotal Tracker: Now with a Burndown Chart!

2009-09-01T13:07:00.000-04:00

Pivotal Tracker is a great lightweight tool for running distributed Scrum. It's free and I use it for my company and my wife has used it for Scrum in Church. Ward Cunningham says it is the only tool that is as good as cards. Well, maybe not as good as a Scrum Board but close. OpenView Venture Partners recommends it for portfolio companies not ready to move up to Version One, a tool provided by one of our portfolio companies.

I met Dan Podsedly for the second time at Agile 2009 to discuss how new features are supporting Scrum. Key issues are the Burndown Chart and handling large stories (Epics) that need to be broken into smaller stories without losing the relationships.

The Burndown Chart is here and it is a nice one that shows the flow of stories from state to state.
-----

New Pivotal Tracker feature: Points Breakdown Chart
Posted by Dan Podsedly on Sunday August 23, 2009 at 08:32PM

We've added a new report feature to Pivotal Tracker, to help you analyze how smoothly your project is progressing. It's based on this popular idea, shared in our Get Satisfaction powered support community.

These new Points Breakdown charts help you visualize the progress of your project as stories move through different stages of completion. Stories start out as "Unstarted", then move on to "Started", "Finished", "Delivered", and then "Accepted" (unless they get rejected). The different colored bars show the point totals of the stories that are in each state at the end of each day. As days pass, you would expect the number of unstarted to go down, and the number of accepted to go up. If any of the other groups are especially big, the chart may help you identify bottlenecks in your workflow.

Agile Richmond: Agile Software Development in the Enterprise

2009-08-31T14:39:00.000-04:00

A large crowd showed up in Richmond on 23 July to hear my latest talk on Scrum in the enterprise. Click here for slides on Agile Development in the Enterprise V8.

-------------
Agile Richmond, in partnership with CCPace and Staff Focus, are please to offer an opportunity to meet with Jeff Sutherland, one of the founders of Agile & Scrum. This event will be held at the Dominion Innsbrook Technical Center, 5001 Dominion Blvd, Richmond, VA 23060 on July 23rd at 6pm. Dr. Sutherland will speak on the topic of "Agile Software Development in the Enterprise". We will explore how companies large, small and enormous have used the hyper productivity of Agile to generate extraordinary financial returns. We will also discuss how Scrum scales up as companies grow, and the usage of Scrum for outsourced, distributed teams. And, perhaps most appropriate to these times, hear how venture capitalists are using Scrum to improve returns in their investment portfolios.

Nokia Test: Where did it come from?

2009-08-25T17:42:00.001-04:00

www.slashphone.com

In 2005, Certified Scrum Trainer Bas Vodde was coaching teams at Nokia Networks in Finland and developed the first Nokia test focused on Agile practices. He had hundreds of teams and wanted a simple way to determine if each team was doing the basics.

The Nokia test is a similar to a maintenance check on your car. It looks at whether your tires have air, your tank has gas, all cylinders are firing, and makes sure there are no critical missing pieces to your car. You should perform it before you go out for a drive with your Scrum team.

It does not provide the secret sauce for hyperperforming teams. However, it is the first line of the recipe for high performance. We give this test to Scrum teams at OpenView Venture Partners and to their portfolio companies as the venture group does not expect good performance from Scrum teams without passing the Nokia test. They are also very interested in predictability of release dates which is impossible without passing grades on the test.

On 19 June 2006, announced a joint venture with Nokia Networks to form Nokia Siemens Networks. Full operations started on 1 Apr 2007 . Combined 2005 revenues were estimate at 15 billion Euro. Bas Vodde moved to China to train Nokia Siemens Networks staff on Scrum and updated the Nokia Test to include Scrum practices.

In 2007, Jeff Sutherland tuned the Nokia Test for Scrum Certification and in 2008 developed a Nokia Test scoring system. In 2009, a team question was added to the Nokia test. Click here for the lastest version.

Each person on the team takes a sheet of paper and prepares to score questions on a scale of 1-10. Teams average their score and team scores are averaged across a training class or a company to determine the Nokia test score.

Scrum training classes average a score of 4 to 5 during the first morning of the course. At the end of the course, they feel they can bring their teams up to a 6 by the end of their next Sprint using what they learned in the course.

Microsoft NE R&D Center 6 Aug: Practical Roadmap to a Great Scrum

2009-08-08T09:56:00.002-04:00

Here are the slides for the presentation on "Practical Roadmap to a Great Scrum" given at Microsoft on 6 Aug 2009.

Date: Thursday, August 6th
Time: 6 - 9pm
Where: Microsoft New England R&D Center, 1 memorial Drive, Cambridge, MA
RSVP: Register at agilebazaar.org
Cost: Free! Food will be provided thanks to our sponsors

Sponsored by:
Version One http://www.versionone.com/
Rally http://www.rallydev.com/
Microsoft http://research.microsoft.com/en-us/labs/newengland/

Practical Roadmap to a Great Scrum: How Every Team Can Systematically Achieve Hyperproductivity

Purpose: Share the experience and practical steps from projects that Systematic Software Engineering has used to ensure hyperproductive scrum teams. Systematic is a CMMI Maturity Level 5 company in Denmark that has "systematically" institutionalized Scrum.

Focus: Provide specific tips and tricks to other agile projects on best practices and pitfalls, as Systematic has uncovered them.
Perspective: Jeff Sutherland will - based on his extensive experience and insight - put the above experiences into the perspective of what best practices constitutes a �mature Scrum� and how every team, without exception, can achieve the same level of performance as Systematic.

The overall theme will be presentation of specific experiences from Systematic and suggestions on best practices based upon them as confirmed by other companies who have achieved the same goals as Systematic - more than 4 times the production and quality of equivalent waterfall teams.

Learning outcomes

* You will learn the specific practices to bring a ScrumBut into a Great Scrum, what the typical pitfalls are, and what others have done to address them.
*The focus will be on practices for higher performing teams and less on typical initial problems of adopting agile practices.
*You will also learn which practices are valued by investors whose goal is maximizing revenue through hyperproductive agile teams.

References

J. Sutherland, C. Jacobson, and K. Johnson, "Scrum and CMMI Level 5: A Magic Potion for Code Warriors!," in Agile 2007, Washington, D.C., 2007.

C. Jakobsen and J. Sutherland, "Scrum and CMMI � Going from Good to Great: are you ready-ready to be done-done?," in Agile 2009, Chicago, 2009.

Ready: The Dynamic Model of Scrum

2009-07-04T18:58:00.000-04:00

The Definition of Ready by Serge Beaumont

I give CSM trainings with Jeff Sutherland, and about half a year ago he had put something in his material called "the dynamic model of Scrum". The essential feature was the addition of a READY state opposite the DONE state. The idea here is that a team needs to be in a stable, known situation to be able to perform well. It immediately struck a chord with me: I had seen so many teams thrash because the Product Owner could not give them a clear objective, the READY state was exactly the goal to work to. But what was it really, and how do you get there? By now I think I've got some good answers to these questions.

Here's a picture from my Scrum course material to illustrate the concept...

What does the READY state do?

In a self-organizing team setting a clear destination it very important: self-organization does not exist if you have nothing to organize TO. The READY state prevents team thrashing by ensuring that the preconditions for a good Sprint execution have been met. More ...

For a description of how to systematically quadruple velocity of a Scrum team by focusing on ready and done states see:

C. Jakobsen and J. Sutherland, "Scrum and CMMI � Going from Good to Great: are you ready-ready to be done-done?," in Agile 2009, Chicago, 2009.

Nokia Test: Online

2009-07-01T04:55:00.001-04:00

The latest version of the Nokia test is now ready for online scoring in French and English thanks to Antoine Vernois. We are finding that for teams that can establish a baseline velocity, raising the score two points will typically double velocity and quality. Raising to over 9 out of 10 will triple velocity.

nlscrum - Hilversum, Netherlands 24 June 2009

2009-06-30T01:05:00.001-04:00

I spent the month of June in Europe and one of the highlights was the nlscrum meeting held at Xebia in the Netherlands. We had a full house that wanted to talk about taking the Red Pill instead of the Blue Pill. See "Agile Architecture: Red Pill or Blue Pill." Good fun was had by all. Unlimited ice cream was available.

In the movie, "Matrix," Neo is offered a choice of a Red Pill or Blue Pill. Normally only those 18 and younger can stand the shock of taking the Red Pill, but Neo is 30 years old and Morpheus thinks he might be able to cope with reality.

In the world of Scrum, those who take the Blue Pill wake up and everything is the same. Developers choose anything they want to work on, architecture will just emerge without thought, the code will do the talking even when you are deaf to the signals, testing is never completed in a sprint, you don't know your velocity, management is unhappy, and customers are upset. This is "normal" in the world of software development.

For those who take the Red Pill, waking up is a shock. They see that everything is broken! Quality sucks, software does not fit users needs, deverlopers are agonizingly slow, process efficiency for everything they look at is 10% or less, impediments are everywhere and noone sees them. If you bring up a problem, there are men in black ready to shut you up and put you out of commission. Management is the enforcer of dysfunction, rather than helping the teams to be great! The world is an illusion, people are mesmerized, never experiencing the exhileration of what it means to be fully functional.

Everyone introduced to Scrum is offered a choice. You can remain slow, dysfunctional, and unhappy or you can wake up and see impediments are everywhere and men in black are trying to make sure noone removes them and destroys the illusion. Everything is broken and noone else notices. You don't want to fix it, but you have no choice. Your only options are the thrill of victory or the agony of defeat.

If other members of your team take the Red Pill, they will see the underlying architecture of the code base. They will notice which story will create the fastest path to a new and tested feature. They will challenge you to take the right story to help make the team a winning team. When you go to implement the story they will say don't do it that way, pair with me and we will get the task done in an hour. Otherwise it will take two days the way you are thinking about it. Your team will go hyperproductive in three sprints and stay that way until or unless the men in black take you down.

Velocity: Why don't people know how much Scrum teams can get done?

2009-06-28T14:21:00.000-04:00

The velocity of the Scrum team is the number of story points they can turn into working code at the end of a sprint. This is used by the Product Owner to create a release plan with a realistic date. The investors at OpenView Venture Partners released that all the GANTT charts they were seeing at board meetings were wrong because the senior management did not know the velocity of their teams.

The image above shows a blue ball with a lower position than the red ball. However, the blue ball velocity is going up and the red ball is stable. Scott Young makes a profound argument that you would be a better person if you based your life on a velocity based paradigm. See his comments on "Balancing Today and Tomorrow."

All great Scrum teams triple their velocity by removing impediments and the best teams do it in three sprints. If they continue to improve engineering practices they will stabilize at 5 times the velocity of a waterfall team. We see this consistently in case study after case study. And this is at less than 40 hours a week because if they work more they slow down.

So why are teams uncomfortable with velocity? Some teams have dysfunctional management that will use it against them. So root case analysis will reveal that management is destroying the Scrum. Go work for another company!

Some companies say they have stopped using the burndown chart because it depresses the developers as they fail all the time. Hire new developers!

50% of the companies who say they are doing Scrum can't get working software at the end of a Sprint so their velocity is zero. So that might be a reason for not calculating velocity.

Of the remaining 50%, over half of them can't pass the Nokia test so they would have very low velocity (if they knew it).

At OpenView Partners we invest in teams that know their velocity and we look at a plan presented by management who doesn't know the velocity of the teams as complete fiction. Competent managers have plans supported by real velocity data.

Maybe there are other reasons people don't know their velocity?

Ritual Roasters: Is this the world's best cappucino?

2009-06-23T09:27:00.000-04:00

In my travels, I'm always hunting for a better cappucino. In general, Norway has the best coffee. There are two locations where I can get an extraordinary cappucino in Oslo.

However, the best cappucino I've had is roasted and prepared in San Francisco at Ritual Roasters.

They have a location in Napa and two in San Francisco, in the Mission and Bayview. This cup was brewed at Flora Grubb Gardens 1634 Jerrold Ave MAP San Francisco, CA 94124. You get to drink it in the middle of a nursery garden. On a sunny morning it is a little bit of heaven.

HICSS 2010 Papers: Need Reviewers!

2009-06-21T12:52:00.004-04:00

HICSS-43 PAPER SUBMISSIONS - Need reviewers with review deadline 14 Aug
Track: Software Technology
Minitrack: Agile Software Development: Lean, Distributed, and Scalable
Co-Chairs: Jeff Sutherland and Gabrielle Benefield
January 5-8, 2010
The Grand Hyatt Kauai Resort & Spa, Kaloa, Kauai, Hawaii

HICSS-43 offers a unique, highly interactive and professionally challenging environment that attendees find "very helpful -- lots of different perspectives and ideas as a result of discussion." HICSS sessions are comprised primarily of refereed paper presentations; the conference does not host vendor presentations. All papers are peer reviewed and accepted papers are published in the IEEE Digital Library.

Reviewers

1. You must have or create an account on the review site at: https://precisionconference.com/~hicss43

2. Then send an email to jeff at scruminc.com with the numbers of the papers below that you would like to review.

3. Reviews are easy and short using the form at the HICSS review site.

4. We like to get as many reviewers as possible for each paper to determine its usefulness to the agile community as well as its technical excellence.

Submitted Papers

Paper 468
Software Entropy in Agile Product Evolution
Abstract: As agile software development principles and methods are being adopted by large software product organizations it is extremely important to understand the role of software entropy. That is, how the maintainability of a system may degrade over time due to continuous change. It is important to understand how this, on one side affects the ability to act agile in planning and development, and how agile processes, on the other side, may affect growth of entropy. We report from a case study of a successful software product organization that has adopted the agile development method Evo. We explain how the agile process is negatively affected by a serious case of software entropy and, on the other hand how the agile process actually enforces this problem. Based on a thorough overview of relevant research we discuss how this situation can be resolved to release the full potential of agile software product evolution.

Paper 696
Embodied Scrum
Abstract: In the same way it is not necessary for an ant to understand complex system theory to be a good ant, a
scrum master need only understand the rules of being a scrum �agent.� But unlike the ant, the scrum team member has an emergent sense of free will and agency that can make it difficult to embrace the simple and seemingly arbitrary rules of the scrum process. One approach to fostering an embrace of the bottom-up nature of scrum is to teach scrum masters the basic principles of complex systems theory, illustrating the power and ubiquity of self-organization, emergence, and adaptation. This paper represents one possible presentation of complex systems theory in accessible language, targeted to scrum masters. Additionally, a case is made for the relevance of first-person embodied practices for developing high quality sensory signal interpretation, i.e. radical empiricism.

Paper 465
Enterprise Scrum: Scaling Scrum to the Executive Level
Abstract: Our company manages 25 teams across 6 products using a single top-down Enterprise Scrum. We know of no other company doing this, yet it provides extreme visibility and control at the CXO level. It promotes agile thinking enterprise-wide, driving non-engineering departments to adopt Scrum. We believe it is making us more profitable. We estimate effort in team months, run quarterly Sprints, assign whole teams to stories, meet in weekly stand-ups, etc. We start, postpone or cancel whole projects. When priorities compete, we often decide by comparing project profit margins, e.g., net-present-value over effort. Our President is the ultimate product owner. On the individual project level, we still use 2-4 week Sprints and all the trappings of the classic Scrum process. New challenges arise: Moving teams between projects requires rapid build environment setup. Architects must justify infrastructure projects with net-present-value. Our process became more �lean� to adapt mid-quarter.

Paper 849
Managing Breakdowns in Constructive Research: Method Re-configuration in Agile Systems Development
Abstract: A different set of skills and practices is needed in constructive research than in many other types of research. Often the actual construction and refinement of a certain IT-artifact often lies outside the scope of the core competency of the researcher(s). In order to realize constructive research involving the study of the construction of, as well as the use of, new artifacts need to be constituted by collaboration between diverse actors having different interests. In this paper the need for an increased understanding of how system developers should work in order to contribute successfully in constructive research is addressed. Due to the fact that such research aims to develop knowledge by creating something that does not exist, the need for flexibility and taking incremental steps in such development processes become essential. Based on a project involving researchers and system developers, ways to overcome breakdowns in such collaborative processes are developed.

Paper 959
Seven Dimensions of Agile Maturity in the Global Enterprise: A Case Study
Abstract: Agile rollouts often struggle to succeed in large complex organizations. This is often due to a misunderstanding of the complexity of interdependencies of vast disparate teams that often exist, resulting in limited local optimizations. Understanding and mapping the maturity of practices for interdependent teams and units provides a method to discover and remove bottlenecks between groups that enable the organization to continuously improve. Maturity mapped to a superset of XP-style technical and Agile program management practices appears to provide a powerful model for improving efficiency and alignment of cross-organizational engineering teams. This is a case study of the model developed by BT Design, the IT division of the telecommunications provider BT, which has been implemented across development streams comprising of hundreds of teams and components to improve organizational agility.

Paper 971
CAKE: A Knowledge Management Solution for Agile Teams
Abstract: Agile software development is based on a culture of abundance that does not always describe the organizations into which it is introduced. This paper addresses information paucity by describing a recent project to map data across tiers, systems, and organizational domains by developing a wiki-based tool and its supporting social processes. The entire system of people, tools, and information was named CAKE for �Community Authored Knowledge Exchange� and was built on principles of stabilization by weak links. These principles valued sustainability over optimization, participation over control, and openness over closure, but never lost sight of the contribution each side made to the final solution. Because these principles underlie the same weak links that stabilize agile teams, I believe the CAKE package of social processes, tools, and information can add real value to agile organizations.

Paper 1278
Rigorous Support for Flexible Planning of Product Releases � A Stakeholder-Centric Approach and its Initial Evaluation
Abstract: This paper addresses the problem of product release planning in iterative product development. We propose a method which combines decision, process, and tool support. The method, which is called SCERP, facilitates the active involvement of stakeholders in the different stages of the planning process. SCERP is flexible in the number of stakeholders involved, in the planning horizon, in the number and definition of planning criteria, and in the selection of the best plan out of a set of optimized alternatives. A proof-of-concept of the method is given by a case study of release planning for a tool called Agilefant, which is developed with a process partially based on Scrum. The benefits of the method as demonstrated by the case study are: (i) better decisions by the product owner by relying on more objective information, (ii) more transparency of release decisions, and (iii) efficient tool support accompanying the whole process.

Paper 1277
Towards Lightweight Requirements Documentation
Abstract: Most existing requirements management processes and associated tools are designed for document-driven software development and, thus, are unlikely to be adopted for the needs of an agile software development team. In this paper we discuss how and what can make traditional requirements documentation a lightweight and less heavy process, suitable for users requirements elicitation and feedback. Further, we propose a reference model for the requirements documentation phase and analyze what kind of requirements documentation tools are needed to support an agile software development process. We also present Vixtory, a tool derived and used for the documentation of lightweight requirements in agile web application development projects.

Paper 1397
Exploring the Transient Nature of Agile Project Management Practices
Abstract: Two large software projects provided background to this research. One investigated agile processes for development of innovative smart urban services targeting usability and user feedback, in a dozen of geographically dispersed city organizations (mostly in Europe) of various expertise and size, to be sharing a considerable part of the product and process technology. The other looked for agile management practices for big distributed projects with very short time to market. In both cases it was obvious that choosing project management practices should depend on context and system properties such as usability, time to market, feedback. The emergent practices were not final. The paper reports on our exploration of the transient nature of agile project management practices.