Scrum Log Jeff Sutherland

Managing Offshore Software Projects

2008-04-25T11:23:00.003-04:00

Verma, Vikas (2008) Managing Offshore Software Projects. Icfai University Press.

A new book republished the Scrum case study on the highest performing large project ever recorded.

Sutherland, J, Viktorov, A., and Blount, J. (2006) Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams. In Proceedings of the International Conference on Complex Systems, Boston, MA, 25-30 June.

This project distributed Scrum teams so that half of each team was in the United States at SirsiDynix and the other half of each team was at Exigen Services in St. Petersburg, Russia. It showed how to set up distributed/outsourced teams to achieve both linear scalability of teams on a large project and distributed velocity of each team the same as the velocity of a small colocated team.

This project is still generating controversy in the Agile community by showing that you can run distributed high performance Scrums. There were quality problems on this project that caused some in the Agile community to discount the remarkable results and argue that it could not be repeated successfully.

However, Xebia in the Netherlands has now repeated the fully distributed model on a seried of projects using Scrum with a complete implementation of XP practices inside each Scrum team. Half of each team on all large projects is based in the Netherlands and the other half of each team is based in India. They achieve the same performance as the SirsiDynix project with extremely low defect rates. Their definition of done at the end of each Sprint is that the software has been successfully acceptance tested by the end user.

A paper on the Xebia experience has successfully passed the first phase of the review process for publication at Agile 2008 in Toronto.

Fully Distributed Scrum: The Secret Sauce for Hyperproductive Outsourced Development Teams. Jeff Sutherland, Ph.D., Guido Schoonheim, Eelco Rustenburg, Maurits Rijk.

ScrumMaster Certification in Los Angeles

2008-04-23T07:53:00.000-04:00

20-21 May 2008, Beverly Hills, CA

Get certified by Jeff Sutherland, Co-Creator of Scrum and Scott Downey from MySpace. This course will be led by Jeff Sutherland, Co-Creator of Scrum in downtown Beverly Hills near Rodeo Drive at The Tower - Beverly Hills Hotel, Beverwil Drive. Beverly Hills, CA 90025. Jeff has been a consultant to MySpace and Scott Downey, MySpace Scrum Evanglist will assist him with this training.

The course will start promptly at 9am each day and run until 5pm. Please arrive at 8:30 the first day for a continental breakfast. Participants should read Ken Schwaber's book, Agile Project Management with Scrum, or Jeff Sutherland's draft of The Scrum Papers before the class as we will assume you know the basics of Scrum.

Jeff Sutherland started the first Scrum at Easel Corporation in 1993. He worked with Ken Schwaber to emerge Scrum as a formal process at OOPSLA �95. Together, they extended and enhanced Scrum at many software companies and IT organizations and helped write the Agile Manifesto.

Jeff is the CEO of Scrum, Inc. powered by OpenView Venture Partners and is Agile coach to over 20 portfolio companies and to the OpenView venture group staff which runs all its operations with Scrum. As Senior Advisor to OpenView and CTO of PatientKeeper he focuses on using Scrum to transform companies as well as empower software developers. PatientKeeper quadrupled revenue in 2007 and the OpenView venture capital group is using it to create similar high performance portfolio companies. Jeff will share the secret sauce that helps development teams radically improve productivity and quality while providing a more rewarding and fun working environment for developers.

You can learn from Jeff's experience as a consultant to the world's leading software companies. Their experience can help make your Scrum implementation world class. There has been lot's of learning with Jeff at Google, Yahoo, Microsoft, IBM, Oracle, MySpace, Adobe, GE, Siemens, BellSouth, GSI Commerce, Ulticom, Palm, St. Jude Medical, DigiChart, RosettaStone, Healthwise, Sony/Ericson, Accenture, Trifork, Systematic Software Engineering, Exigen Services, SirsiDynix, Softhouse, Philips Medical, Barclays Global Investors, Constant Contact, Wellogic, Inova Solutions, Medco, Saxo Bank, Xebia, Insight.com, SolutionsIQ, Crisp, Johns Hopkins Applie Physics Laboratory, Motley Fool, Planon, OpenView Venture Partners, Juske Bank, BEC, Camp Scrum, DotWay AB, Ultimate Software, Danube, Rally Development, Version One, and many other companies.

Jeff is an expert on distributed/outsourced Scrum (see Agile 2008) and on implementing Scrum in a CMMI Level 5 company. He has has scaled and distributed Scrum using his last five companies as laboratories. His entire current company at PatientKeeper is run by a MetaScrum, and is one of the most advance implementions of Scrum worldwide. Mary Poppendieck, in her latest book on Lean Software Development, comments: Five years ago a killer application emerged in the health care industry: Give doctors access to patient information on a PDA. Today there is no question which company won the race to dominate this exploding market; PatientKeeper has overwhelmed its competition with its capability to bring new products and features to market just about every week. The sixty or so technical people produce more software than many organizations several times larger, and they do not show any sign that the size of their code base is slowing them down.

A key strategy that has kept PatientKeeper at the front of the pack is an emphasis on unprecedented speed in delivering new features. It will not surprise anyone who understands Lean that PatientKeeper has to maintain superb quality in order to support its rapid delivery. CTO Jeff Sutherland explains it this way:

�Rapid cycle time:

* Increases learning tremendously
* Eliminates buggy software because you die if you don't fix this.
* Fixes the install process because you die if you have to install 45 releases this year and install is not easy.
* Improves the upgrade process because there is a constant flow of upgrades that are mandatory. Makes upgrades easy.
* Forces quick standardization of software via new features rather than customization and one off.
* Forces implementation of sustainable pace. You die a death of attrition without it.
* Allows waiting to build new functionality until there are 4-5 customers who pay for it. This is counterintuitive, and caused by the fact everything is ready within 90 days.�

"I find that the vast majority of organizations are still trying to do too much stuff, and thus find themselves thrashing. The only organization I know of which has really solved this is PatientKeeper." Mary Poppendieck

In this course, participants will learn how to stop thrashing and start executing along with everything necessary for getting started with Scrum. There are very few rules to Scrum so it is important to learn its fundamental principles by experiencing them directly from those who have implemented the best Scrums in the software industry. Participants gain hands-on practice with the release backlog, sprint backlog, the daily Scrum meeting, tracking progress with a burndown chart, and more. Participants experience the Scrum process through a �59-minute Scrum� and the "XP Game� which simulate Scrum projects through non-technical group exercises.

The course will run from 9am-5pm each day.

Following the course, each participant is enrolled as a Certified ScrumMaster, which includes a one-year membership in the Scrum Alliance, where additional Certified ScrumMaster-only material and information are available.

PMPs:
You can receive 16 Professional Development Units (PDUs) for this course.
Course Material:

Participants will receive course materials for review upon registration. Click here for course syllabus.

The CSM course was formulated to train and certify ScrumMasters and is used worldwide for ScrumMaster training. The book, Agile Project Management with Scrum, by Ken Schwaber is required reading for the course and the course is based on the primary Scrum book, Agile Development with Scrum.

What to do when Sales guys are Waterholics ...

2008-04-22T01:12:00.003-04:00

Here is today's best question in my long list of emails. The Sales guys don't want Scrum in a company because they think they can't commit to the customer to close deals.

"We need to sign the contract first. The customer does not sign the contract, if finish date, price and features list are not in the contract. When using waterfall, the customer has all of that. That's how sales works. That's what we offer to them. With SCRUM either end date or features list is not defined. And end price is also not defined! We can't sell anything that way!"

Here is my answer ...

Your sales guy's are clueless about Scrum. They should take the Certified ScrumMaster class so they know what they are talking about. First they might start applying Scrum to their work in Sales. Then they could understand what the developers should be doing.

Our venture capital group runs company acquisitions using Scrum. The most junior guy on our team is the former SVP of Global Sales for Oracle. He could probably give a good answer for your sales force and maybe help them start using Scrum.

Basically, a sales plan calls for closing deals. This is the product backlog. The locity of closing should be known by the sales guys. They have a list of tasks that need to happen to close the deal as the opportunity moves through the sales funnel. This can all be mapped out on the Scrum board. They should have a burndown chart that shows deal closing for a Sprint. They can burn down revenue achieved.

The immediate deals are locked and loaded for closing. The ones further out are in the planning stage for closing. Further out the deals are forecast just like software features. You know you will achieve a closing velocity but don't know exactly which deals will close.

So for Scrum, whether for sales or software development you need a plan (product backlog). The product backlog needs to be prioritized. The closing velocity needs to be estimated by the individual teams, the revenue needs to be committed to in the plan based on closing velocity, and the projects need to be DONE (whether they are closing sales plans or finishing software development contracts). There is always a roadmap owned by the product owner from which commitments are made.

This is exactly the opposite of what your sales guy is saying. We have a lot of teams that say they are doing Scrum but do not have product backlog, estimates, velocity, and burndown. Your sales guy must have seen some of these dysfunctional teams and completely misinterpreted Scrum.

Trifork in Denmark runs their sales with Scrum. All their sales people are Certified ScrumMasters. Every time they stop updating the Scrum Board they start losing track of deals and revenue and need to refocus on getting the Scrum Board updated. The VP of Sales runs the board as most of the people are on the road all the time.

When they close a software development contract, a sales person is sometimes the ScrumMaster leading the software development team. In this way the sales guys make money for the company while selling instead of wasting a lot of money on their expenses and driving up cost of sales. Once inside the company as a ScrumMaster they can sell even more stuff.

As for development, some of the leading companies in the world are doing fixed price contracts in Scrum. They know all the features, they estimate them all, and they commit a date to deliver. They then work an Agile process to finish the contract early and save money for the customer while driving up margins for themselves. It may be your Scrum teams are in the very early stage of maturity and are not able to make the committments that the sales people need. Or they have not educated the sales people properly. This is the responsibility of your Chief Product Owner. Do you have one?

PatientKeeper HIMSS08: Scrum @work

2008-03-02T16:55:00.001-05:00

PatientKeeper runs a Type C Scrum and quadrupled revenue in 2007. HIMSS is the biggest IT show in healthcare and PatientKeeper was one of the hottest companies there.

"I'm such a PK groupee now! I'll be sure to get that contract signed in the next 2 weeks."

"Everything you're doing is amazing. I need to call my account manager to talk about adding some of these web integrations."

"When we get back, can you call me so we can add Charge Capture?"

"PK is THE scariest vendor here. Everyone on the convention floor is intimidated by you."

"I have this physician portal, Medseek. No one likes it. We need to replace it with PK so the docs will be happy AND we'll have downtime. Call me next week."

"I stopped by the Thompson booth. It's clear they don"t have the same capabilities as you - UI or integration"

"I saw the Medseek demo. Anyone satisfied with that physician portal has their sights set way too low."

"You're booth is amazing. The mobility wall is way cool!"

"I told a couple of colleagues from other hospitals to come find you. That you guys were the answer to their meditech and physician sat issues."

"And everyone wants to be a PK partner. They all want to associated with the hottest company in HCIT.'

Scrum and Organizational Patterns

2008-02-02T15:24:00.003-05:00

In the early days of what we now know as Agile processes, Mike Beedle was influenced by the online description of Scrum, implemented the process in his own company, and led the effort to drive Scrum through the Pattern Languages of Programming Design conferences. This made Scrum the first (and only) formal organizational pattern that describes a complete Agile process. One of the patterns books contains the Scrum pattern:

M. Beedle, M. Devos, Y. Sharon, K. Schwaber, and J. Sutherland, "Scrum: A Pattern Language for Hyperproductive Software Development," in Pattern Languages of Program Design. vol. 4, N. Harrison, Ed. Boston: Addison-Wesley, 1999, pp. 637-651.

Recent work by Jim Coplien shows that Scrum is deceptively simply while compressing a complex array of organizational patterns in his book, "Organizational Patterns in Agile Software Development." Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes. It takes over 60 pages of rather dense text to describe these patterns. Click here for details of Jim's presentation on Scrum and patterns.

One of Scrum's design goals was to encapsulate best practices from 40 years of software development into a process that was simple enough for the average IT worker to use for development in less than 2 days of startup time. Jim's research shows that we did a good job of accomplishing that goal. You can download a copy of the complete Scrum pattern as it is part of a draft of "The Scrum Papers."

High Moon Studios: A Portrait - Scrum

2008-01-28T08:00:00.001-05:00

Planning Poker Cards: Faster, Better, Cooler!

2008-01-27T02:09:00.000-05:00

Photo of old verison of cards. New improved version photo coming soon!

I'm leaving Stockholm today after working with Crisp on Scrum training this week. In my bag are the new, upgraded, Crisp planning poker cards. Developers have been asking for more colors. We really need seven to support the typical Scrum team so each person has a different color. And the Planning Poker cards need numbers on the corners of the cards so you can seen the numbers when you hold a deck in your hand. The new cards solve these problems and Crisp has the only good web site for ordering Planning Poker cards so get them here!

Crisp needs to update it's web site. The photo is of the old cards. I'll post a photo of the new new improved version when I finish traveling today.

There are three best practices that have emerged for both Scrum and XP - User Stories, Planning Poker, and Scrum Boards. Lots of people have asked where to get Poker Planning cards. Many companies make these cards and none of them are as easy to sort as the color coded cards from Crisp in Sweden.

Estimating is one of the core activities in Scrum and other agile processes. This means the process of assessing the size of a story, i.e. how long it will take, how much work it is to implement, or how expensive it is.

In Scrum, estimating is a team activity. For each story, the whole team participates in the estimation process.

Planning poker is a simple but powerful tool that makes team-estimating faster, more accurate, and more fun. Some companies have eliminated 80% of their planning costs and are able to get better estimates using Planning Poker! Even if you are stuck in the mire of Waterfall planning these cards can help you avoid missed dates and death marches. Recommended for all developers.

HICSS 2008: Schedule of Agile Papers

2007-12-09T01:00:00.000-05:00

Wild man Evan Campbell demonstrates Type C Scrum at HICSS 2007

Agile Software Development: Lean, Distributed, and Scalable
Co-Chairs: Jeff Sutherland and Hubert Smits
HICSS 41, January 7-10, 2008 - Hilton Waikoloa Village Resort
Waikoloa, Big Island, Hawaii

ST 1 Thursday; Kona 3; 8:00 � 9:30
Bridge Methods: Complementary Steps Integrating Agile Development Tools and Methods with Formal Process Methodologies
Stephen J. Cohen and William H. Money
Rolling Out Agile in a Large Enterprise
Gabrielle Benefield
Great Scrums Need Great Product Owners: Unbounded Collaboration and Collective Product Ownership (in competition for best paper)
Ken H. Judy and Ilio Krumins-Beens

ST 2 Thursday; Kona 3; 10:00 � 11:30
Effects of Agile Methods on Website Quality for Electronic Commerce
David F. Rico
A Case Study: Introducing eXtreme Programming in a US Government System Development Project
Ann Fruhling, Patrick McDonald, and Christopher Dunbar
Retrofitting Cyber Physical Systems for Survivability through External Coordination
Kun Xiao, Shangping Ren, and Kevin Kwiat
Scrum and CMMI Level 5: The Magic Potion for Code Warriors
Jeff Sutherland, Carsten Ruseng Jakobsen, and Kent Johnson

Is it Scrum or Lean?

2007-11-30T14:33:00.001-05:00

Today I got a question in email about Scrum and Lean, fallout from the recent workshop I did with Mary Poppendieck at MIT. Is Scrum related to Lean? Are we finding out new things about Scrum or Lean? Are customers asking for Lean?

After thinking about the early days of Scrum I think the root of both Scrum and Lean is complex adaptive systems theory. When we created Scrum we did not talk about Lean, we talked about complex adaptive systems. I think Scrum and Lean are complementary implementations of ways to deal with physical reality where things are often not linear, not simple, and not predictable.

After the first Scrum started at Easel in 1993, I began talking about the process in the internet newsgroups in 1994, particularly comp.object, and by 1995 we had a well documented thread of my discussions on Scrum on comp.object, interlaced with comments from Bob Martin, Kent Beck, and others.
http://jeffsutherland.com/scrum/scrum.txt

So the origins of Scrum are well documented and can be researched in Google groups by searching in the archives. My original Scrum web page started in 1994 and was widely viewed on the web throughout 1995 and updated regularly until the Agile Manifesto meeting in 2001.
http://jeffsutherland.com/scrum/history.html

During 1995, I invited Ken Schwaber to take a look at the first Scrum team which led to collaborating on the first formal paper on Scrum presented in the fall of that year at the OOPSLA. We did not discuss Lean at all but did discuss complex adaptive systems.

Mike Beedle was influenced by the online description of Scrum, implemented the process in his own company, and led the effort to drive Scrum through the Pattern Languages of Programming Design conferences. This made Scrum the first (and only) formal organizational pattern that describes a complete Agile process. Recent work by Jim Coplien shows that Scrum is deceptively simply while compressing a complex array of organizational patterns in his book, "Organizational Patterns in Agile Software Development."

Looking at "scrum.txt" you will see that Scrum derives directly from best practices in new product development documented by Takeuchi and Nonaka in their 1986 HBR paper. The leading example in the paper was Honda (Toyota was not so well know at the time). Takeuchi does not specifically address Lean as we know it today.

In 1995, I commented in the comp.object newsgroup:

Usability studies ... have convinced us that only one paper in the literature describes the rapid application development environment achieved with Object Studio (the combination of Enfin Smalltalk and Synchronicity Business Object Modeling and Persistent Object Mapping).

Takeuchi, Hirotaka and Nonaka, Ikujiro. The New Product Development Game.
Harvard Business Review, Jan/Feb 1986, pp. 137-146.

Takeuchi and Nonaka describe the Scrum methodology (a Rugby term) which we use internally. It is significantly different than anything you have seen because there is no project management schedule, only a committed delivery time for a release. The Japanese auto and electronic companies are using it to clean our clocks in the global economy. Did you notice that U.S. auto companies had a banner year and still lost
market share in 1994?

Small teams are given objectives to meet in a fixed time frame. They take the existing software (you never build anything from scratch) and small projects (2 days to 2 weeks per person) are assigned as SynchSteps. SynchSteps are dynamic pulses generated against the existing code structure that causes mutations (as in a biologic organism).

A project team is typically 3 developers, 3 QA people, 3 doc people, and one or two users. They meet daily and all agree on steps completed and next steps. For large projects, small teams of this size build components and a SCRUM of SCRUMs meets less frequently to work out interfaces between components. Developers must be outnumbered on the team by QA and documentation people or they generate too much code too fast (malignant functionality).

The code evolves like a biological system via punctuated equilibrium. You can read about this process as modeled by Denny Hillis on a Connection Machine in the book "Artificial Life." When enough mutations occur in multiple parts of the organism, the system shifts to a

higher plateau of functionality. We say at this time that a "package" is emitted. This will be a new piece of the software system we are building. For example, we are adding Use Cases to the Synchronicity product at this time and when the package appears, an objective for the release cycle is met.

A release cycle, typically six months, is built of packages which are loosely defined as objectives at the start of the release cycle.

Management must release control of the team and let it function as a self-organizing entity that grows a system like a plant. We have found that we get dramatically more functionality in less time and a much cooler product with this approach. This approach rationalizes the comments that Fred Brooks made in 1987 in his paper "There is No Silver Bullet". There, he stated that the only way to speed up development was to grow a prototype like a plant.

We track the process by the velocity of SynchStep (Sprint Backlog item) assignments versus the velocity of SynchStep completion. This gives estimate of package time completion, kind of like launching a rocket, watching its trajectory, and predicting impact point. We can adjust the impact point by lowing the arc (less functionality) or adding rocket fuel (more resources) to hit the time frame committed to management.

We monitor progress regularly via demonstrations. Nothing counts with management except delivered code that works. Packages are regularly shipped out as alpha components that people can drop into the current release of Synchronicity. Synchronicity dynamically changes, menus and all, so that people can try out the new functionality and see if they like it.

With SCRUM schedules are obsolete (developers love it) and delivery dates never slip (management loves it). If this sounds too good to be true, I suppose it is, but management will agree there is more functionality and less slippage with this process than anything they have ever seen. Our users are asking us to lengthen the product delivery schedule because we are delivering too many new releases with major upgrades
too fast. (This still doesn't stop them from complaining about not getting everything on their wish list.)

We find that the paridigm shift required for optimum utilization of the SCRUM process is significant. The object-oriented paridigm requires a shift in thinking, but Scrum requires a shift in the organization and the way people work and relate to one another.
------------------------------------------

Scrum was strongly influenced by complex adaptive systems theory - the work of Peter Senge at MIT, Christopher Langdon at the Sante Fe Institute, and many others. Also by Goldratt's constraint theory and by Rodney Brooks subsumption architecture, the basis of the company iRobot which I helped to get started shortly before Scrum began. Starting at the bottom of my original Scrum web page I commented:

"SCRUM is based on complexity theory and artificial life experiments at Thinking Machines using highly parallel simulation of systems evolution. It induces the phenomenon known as "punctuated equilibrium" seen in the evolution of biological species."

The reason the first Scrum team called Sprint Backlog items SyncSteps was that developers executed the Sprint Backlog in a carefully chosen order - that order which produced the fastest path to appearance of the next feature from the users point of view. Just as proper ordering of the Product Backlog optimizes revenue, proper ordering of the Sprint Backlog optimizes production of value. It accelerates software evolution and can produce effects seen in biological systems.

The "punctuated equilibrium" effect is achieved at Toyota using set-based concurrent engineering. As an example, Toyota does not build one radiator for a new car. They build six, and wait to the last possible moment to choose the best radiator to deploy in production. This is similar to competition between biological species in an ecosystem and the species that adapts best to the environment wins. The Scrum
community has yet to implement set based concurrent engineering strategies that were used by the first Scrum team.

However, test first development drives the software creation process in the right direction as early testing shows immediately what does not work and allows rapid deployment of alternative strategies. The key is evolution of software like a biological system based on competing implementation constructs and survival of the fittest.

A thoughtful analysis of the relationship between complex adaptive systems and Lean will show that both Scrum and Lean are instantiations of complex adaptive systems theory. A subset of complex adaptive systems theory is artificial life, a term invented by Christopher Langdon at the Sante Fe Institute in the 1980's. His seminal paper showing that organisms similated on a computer evolve faster as they approach chaotic regions strongly influence Scrum. In Scrum, we introduce chaos into the development process and then use an empirical control harness to inspect and adapt a rapidly involving system.

In trying to describe Scrum at JAOO in 2005, I used Lean to show why Scrum works. Scrum is a way to implement lean in building software. In fact, it has the advantage that if you follow it closely and implement well, you will be doing Lean as articulated by Mary and Tom Poppendieck sithout even understanding Lean. It is hard for people to understand complex systems theory so it is difficult to use that as a motivator. It is hard for people to understand Lean as well, but Toyota has become such a dominant force in industry that fear, uncertainty, and doubt wakes people up from their sleep.

In 1995, I worked with Hubert Smits and Jean Tabaka at Rally to develop a course for people who want to take their Scrum implementation to the next level all based on Lean as the easiest way to articulate what you need to focus on to optimize Scrum.
Ken Schwaber argues that by simply

focusing on the Scrum framework and the impediment list you will achieve this. This is absolutely correct. Lean is just an extra teaching tool.

There is also my paper on Scrum and CMMI Level 5 on the implementation of Scrum by Systematic Software Engineering, an implementation entirely driven by Lean. In Denmark, it is national policy to lean out all industries. As a result, it is easy to sell Scrum as a way to implement Lean in software.

Scrum is an inspect and adapt framework which is extremely simple by design to allow the average developer at Ford Motor company to get started in a couple of days. However, it is hard to implement. Less than 10% of the Scrum teams worldwide can pass the Nokia test, primarily because they cannot deliver potentially shippable (fully tested) software at the end of a Sprint. Talking to people about complex adaptive systems doesn't seem to help them as well as talking to them about Toyota to show them how their implementation of Scrum is broken, how it is riddled with disruptions in flow (muri), stressed everywhere (mura), and waste (mudah). Using Toyota as an example of a successful company who systematically elimiates muri, mura, and mudah shows them how they might best go about fixing their process.

So Lean is helpful as a teaching tool because it derives from the basic laws of the universe which are articulated at a theoretical level by complex adaptive systems research. Scrum derives from the same fundamental principles. Lean has practical ways to deal with process mapping, the cost of delays, queuing problems, reset times, and so forth. These are all useful in dealing with constraints, global system throughput, and other factors which were a primary concern for Scrum in dealing with the complex adaptive system called software development.

Lean derives from Edward Deming and the work of others teaching the Japanese that local optimization caused by traditional management by objectives was self-destructive. Deming, after consulting with the leadership in many American corporations, concluded that management is totally broken in the U.S. causing incalculable and inconceivable damage (such as the destruction of the auto industry). The global optimization promoted by Deming and his statistical quality control practices are rooted in complex adaptive systems theory, constraint theory being a specialized area that focuses on global optimization. Professor Senge's work on systems theory at MIT is the most readable resource for these early influences Scrum.

So the bottom line is that:

1. Scrum is not a direct descendant of Lean. It derives from complex adaptive systems with an indirect linkage to Lean through Takeuchi and Nonaka.

2. Management is interested in Lean, partcularly in Europe. Building on that interest and any knowledge they have about Toyota makes it easier to describe why Scrum works.

3. Lean is a good teaching tool to show Scrum teams why their implementations are broken. For example, if you do not have fully tested code and cannot create potentially shippable code in a Sprint, you have 100% work in progress going into the next Sprint. This would be viewed as a horrible and intolerable blunder in a Lean operation, yet software development teams and management seem to have difficulty understanding why this doubles your defects and cuts your velocity in half. And even when they understand it they often lack the political will to fix it. Teaching Kaizen mind and stopping the line is useful medicine for this disfunction.

Why Time Sheets are Lame!

2007-10-07T13:39:00.000-04:00

Programmer time vs. Quality Software Score. Totally uncorrelated!

Actually time sheets are worse than lame:
* they demotivate developers
* 10-15% loss of productivity is the minimum
* developers have to fake the time to fill them out properly
* erroneous data is used for reporting and management makes bad decisions
* customers are deceived
* they have nothing to do with quality code production
* they focus the whole organization on phony data instead of production

Nevertheless, this is not enough for many managers to give up time sheets. Just like the waterfall process, there is a psychological dependency so strong, it is as if they are on drugs.

However, the situation is even worse. Most management has completely wrong information in their head and thus continually make bad decisions. One of my students recently said to me, "You mean everything my manager told me is wrong!"

Yes, Jose, everything your manager ever told you is wrong:
* there is no correlation between developer time and software production
* there is no correlation between time spent and quality of code
* there is no relationship between "quality people" and code production

The only correlation between developer time and quality production code is the quality story points measured as a deliverable for a specific team.

Research over many years at Yale University provides some of the best data on this topic - see Joel on Software:
* for a single project worst/best coding times are 1/10
* across many projects worst/best coding times are 1/25
* the ratios above are the same for the worst and best Yale students
* the quality of the code produced is completely independent of time spent

For some reason, many development managers makes decisions without any data at all on this issue and their assumptions are completely out of reality.

Tom Poppendieck told me recently a competent manager actually did some research on his XP teams to see what number of hours per week produced the maximum amount of quality production code. After trying shorter weeks and overtime weeks, the best number of hours for teams to produce the most quality code was a 16 hour work week!

Trust me, you need to dump those lame time sheets and get focused on real software production before an Agile competitor puts you out of business!

Scrum and CMMI Level 5: A Magic Potion for Code Warriors

2007-09-04T16:34:00.000-04:00

An earlier blog item commented on the dramatic advantages of using Scrum with CMMI, particularly with a CMMI Level 5 company. See Scrum supports CMMI Level 5.

At the Agile 2007 Conference in Washington, D.C., an experience report was presented on the results of introducing Scrum into a CMMI Level 5 environment to replace waterfall projects for large defense and healthcare contracts. See Scrum and CMMI Level 5: A Magic Potion for Code Warriors. The paper was written by:

Jeff Sutherland, Ph.D. - Co-Creator of Scrum
Carsten Jakobsen - Systematic Software Engineering Process Leader
Kent Johnson - CMMI Level 5 Auditor

Systematic Software Engineering is a company which executes the waterfall process better than almost all companies in the world, with an ontime, on budget delivery rate of over 95% with estimates within 10% of actuals. The Scrum results were extraordinary, similar to introducing a team of Toyota consultants into a manufacturing plant. This was the result of driving the Scrum implemenation by lean principles which assured a disciplined and measured introduction of Agile practice.

- Productivity doubled in less than six months reducing total project costs by 50%.
- Defects were reduced by 40% in all Scrum projects (despite the fact this company already had one of the lowest defect rates in the world.)
- Planning costs were reduced by about 80%.
- User satisfaction and developer satifaction were much higher than comparable waterfall implementations.
- Projects were linearly scalable, something never seen before. The productivity of individual developers remains the same as the project increases in size.

The data in this study is some of the best in the industry and puts to rest the argument about whether the waterfall is preferable in some cases. The waterfall will always be less productive with higher defects on any project compared to a well executed Scrum.

Systematic Software engineering has revised its standard processes to use Scrum everywhere. See Scrum and CMMI Level 5: A Magic Potion for Code Warriors.

Agile 2007 Video Contest 2nd Place: Being Agile is our favourite thing

2007-08-21T16:11:00.001-04:00

More light hearted than "Developer Abuse" the video "Being Agile is Our Favorite Thing" won 2nd place at Agile 2007.

Agile 2007 Video Contest 1st Place: Developer Abuse

2007-08-20T19:24:00.001-04:00

At the Google party at Agile 2007 we all voted (screamed) for the best Agile video advertisement. Developer Abuse won easily.

ScrumMaster Certification: New York

2007-08-17T14:54:00.000-04:00

5-6 September 2007, New York

Get certified by Jeff Sutherland, Co-Creator of Scrum and Joe Little, Certified Scrum Practitioner, with lots of experience in introducing Scrum to the financial industry. Click here to sign up.

Jeff started the first Scrum at Easel Corporation in 1993 and worked with Ken Schwaber to emerge Scrum as a formal process at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and IT organizations and helped write the Agile Manifesto.

Participants will learn everything necessary for getting started with Scrum. There are very few rules to Scrum so it is important to learn its fundamental principles by experiencing them.

In this course, participants gain hands-on practice with the release backlog, sprint backlog, the daily Scrum meeting, tracking progress with a burndown chart, and more. Participants experience the Scrum process through a "59-minute Scrum" and the "XP Game" which simulate Scrum projects through a non-technical group exercises.

This course is equally suited for managers, programmers, testers, analysts, product managers, and others who are interested in working on or with a Scrum team. You will leave with solid knowledge of how and why Scrum works. Through practical, hands-on exercises and small-group discussion you will be prepared to plan your first sprint immediately after this class.

The course will run from 9am-5pm each day. A continental breakfast and lunch will be provided.

Following the course, each participant is enrolled as a Certified ScrumMaster, which includes a one-year membership in the Scrum Alliance, where additional ScrumMaster-only material and information are available.

Who Should Attend

Whether you're a manager, programmer, tester, analyst, product manager, or someone interested in working on or with a Scrum team, this course is suited for you. You will leave with solid knowledge of how and why Scrum works. Through practical, hands-on exercises and small-group discussion you will be prepared to plan your first sprint immediately after this class.

PMPs: You can receive 16 Professional Development Units (PDUs) for this course.

Course Material:

Click here for course syllabus.

Participants will receive course materials for review upon registration. The CSM course was formulated to train and certify ScrumMasters and is used worldwide for ScrumMaster training. The book, Agile Project Management with Scrum, by Ken Schwaber is required reading for the course and the course is based on the primary Scrum book, Agile Development with Scrum.

Camp Scrum: A Powerful New Concept to Accelerate your Agile Program

2007-08-10T01:27:00.000-04:00

Looking for a powerful way forward into the world of Agile development? Whether you're just getting started or looking for ideas that can improve your current Agile implementation, you don't want to miss this opportunity to learn from the world's top experts in Scrum and Agile software development.

Imagine having a whole week together with four of the most authoritative personalities in Agile software development today... Not only a week of seminars, but a week of living with the experts, and of informal discussions of everyday practical problems of project management... Imagine gaining deep insights into the fundamentals of Scrum and Agile that could make all the difference in the world on your current project... Imagine being able to discuss these issues with others like you who bring their experiences to this event... Then imagine it all taking place in a beautiful rural Swedish setting, surrounded by nature...

If you can imagine this, you can imagine Camp Scrum.

Agile Video Contest - post yours before Agile 2007

2007-07-29T20:00:00.001-04:00

There is an Agile You Tube video contest going on sponsored by VersionOne, Google, and InfoQ. The best video will be selected (and rewarded) at the Agile 2007 conference in Washington, D.C. next month.

Check out current video submissions and submit your entry now!

ScrumMaster Certification: Silicon Valley

2007-07-12T07:30:00.000-04:00

1-2 August Sunnyvale, CA

Get certified by Jeff Sutherland, Co-Creator of Scrum and Gabrielle Benefield, Agile leader at Yahoo. Click here to sign up.

Jeff started the first Scrum at Easel Corporation in 1993 and worked with Ken Schwaber to emerge Scrum as a formal process at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and IT organizations and helped write the Agile Manifesto.

Participants will learn everything necessary for getting started with Scrum. There are very few rules to Scrum so it is important to learn its fundamental principles by experiencing them.

The course will run from 9am-5pm each day. A continental breakfast and lunch will be provided.

Who Should Attend

PMPs: You can receive 16 Professional Development Units (PDUs) for this course.

Course Material:

Click here for course syllabus.

Origins of Scrum

2007-07-05T10:53:00.000-04:00

Scrum derives directly from the Takeuchi and Nonaka paper in the Harvard Business Review, "The New New Product Development Game." The best example in this paper is Honda and their style of product development. I gave this paper to Kent Beck at his request in 1995 when he was putting together eXtreme Programming.

The Scrum daily meeting derives directly from the Borland Quattro Pro paper by Jim Coplien.

Complex adaptive systems theory, particularly as implemented by iRobot using Prof. Rodney Brooks subsumption architecture, was used to implement simple rules to allow an average team to boot up into a hyperproductive state.

All of this occurred in 1993. The great results delivered by Scrum with new products in 1994 and 1995 got Mike Beedle and Ken Schwaber interested in the process. Ken clarified the process for global consumption beginning in 1995 and Mike Beedle led the effort to write the PLoP patterns paper on Scrum pointing out that it is an organizational pattern to allow teams to achieve a hyperproductive state.

The first Scrum team starting in 1993 rapidly achieved a hyperproductive state by implementing all of the engineering practices now known as XP, along with some that are not in XP. In particular, it used strategies for choosing Sprint backlog items that generated the most rapid appearance of new features. This forced not only test first development (and document first as well) but created a strategy similar to Toyota's concurrent engineering.

Few implementations of Scrum achieve the hyperproductive state for which Scrum was designed (5-10 times normal performance). Those that do all implement variations on XP engineering practices and many, like the CMMI Level 5 implementation of Scrum (which has not achieved the hyperproductive state yet) drive the whole implementation from a lean perspective.

Takeuchi and Nonaka are the godfathers of Scrum and gave it the name. Their latest Hitosubashi book clarifies and extends their work in the original Harvard Business Review paper and it useful for those trying to achieve a hyperproductive state. There is a lot of lean in there.

The first Scrum was influenced by concepts from Goldratt's constraint theory and focus on muri, mura, and mudah. Elimination of disruptions in flow was initiated after the first few Sprints to eliminate reset times between Sprints, now accepted as a best practice in Scrum. Mura, or avoidance of stress on an person, system, or process yielded hyperproductive states combined with zero attrition in several of the Scrum companies where I led engineering. This is now known as sustainable pace in Agile development. Finally, Mudah, or radical reduction in waste has always been a primary driver in all the companies where I implemented Scrum. You cannot achieve a hyperproductive state without it.

Jim Coplien has pointed out repeatedly over the years that there are down sides to constraint theory and some XP practices which should be avoided. I've done my best to sidestep the potholes he has pointed out.

Scrum was specifically designed to deal with:

Ziv's law - specifications will never be fully understood.
Humphrey's law - the user will never know what they want until after the system is in production (maybe not even then)
Wegner's lemma - an interactive system can never be fully specified nor can it ever be fully tested. This is the software analogy to Godel's theorem.
Langdon's lemma - software evolves more rapidly as it approaches chaotic regions (taking care not to spill over into chaos)

Thus any association of predictive or defined processes with Scrum is an exercise in futility.

That said, I am entirely in agreement with Ken Schwaber, that all of this should be driven by "inspect and adapt" and building a prioritized impediment list. Working off the impediment list in priority order will streamline flow, reduce stress, and eliminate waste in the correct sequence and failing to do so will, ironically, result in violation of lean principles.

"There is a spectrum of work in which Langdon is at one end and Brooks can be thought of at the other. At Langdon's end, the goal is to create virtual simulations (nothing physical) that exhibit characteristics such as evolutionary change and emergent complexity. Much of this work was done in conjunction with the Santa Fe Institute, and was big a decade ago. Much of the excitement around it has died down. At Brooks' end, roboticists use models from real organisms to organize their structure. Early works in this vein included an artificial cockroach, and it has been a feature of Brooks' MIT research for the last 15 years or so. Although both are biologically inspired, the goals and methods are quite different."
http://hci.stanford.edu/academics/cs378/wiki/Main/ArtificialLife

XP Game: Know your team's velocity!

2007-06-29T16:01:00.000-04:00

I'm using the XP Game in Certified ScrumMaster classes and many people want to know the orgins of the game and how to obtain materials. The full game can be downloaded from the site below. We use a short version of the XP Game to show how Scrum teams can improve estimation, determine the velocity of their teams, and generate "ba" which is the team spirit seen at Toyota on the Prius project.

XP.BE - The XP Game

Want to learn about...

* the planning game?
* velocity?
* story estimation?
* short releases?
* making predictable plans?
* how to explain these things in your company?

Want to...

* play the planning game? (...but maybe in another role)
* feel the velocity of your team?
* see it work?
* let both business people and developers experience it?
* have fun?

The XP Game is a playful way to familiarize the players with some of the more difficult concepts of the XP Planning Game, like velocity, story estimation, yesterday�s weather and the cycle of life. Anyone can participate. The goal is to make development and business people work together, they both play both roles. It�s especially useful when a company starts adopting XP.

Want to know more?

Then you're ready to go to the detailed description. Or, if you want to, you can go immediately to the download center. Did you already play it? Enter all your feedback in the evaluation form. Read testimonials of people who played it.

The XP Game is developed by Vera Peeters (Tryx) and Pascal Van Cauwenberghe (Nayima).

Hawaii International Conference on Software Systems 2008: Call for Papers - due 15 June 2007

2007-06-09T02:57:00.000-04:00

Get your papers in by 15 June 2007 - don't miss Hawaii in January 2008!

Agile Software Development: Lean, Distributed, and Scalable
(Jeff Sutherland and Hubert Smits)

Agile software development processes have been influenced by best practices in Japanese industry, particularly by lean product development principles implemented at companies like Honda and Toyota, and knowledge management strategies developed by Takeuchi and Nonaka, now at the Hitotsubashi Business School in Japan, and Peter Senge at MIT. This Minitrack will focus on advancing the state of the art or presenting innovative ideas related to agile methods, individual practices and tools. Accepted papers will potentially enrich the body of knowledge and influence the framework of thought in the field by investigating Agile methods in a rigorous fashion.

We are open to research papers on multiple aspects of agile methods, particularly those that bring best practices in knowledge management and lean development to scalable, distributed, and outsourced Scrum, eXtreme Programming (XP), and other agile practices. Topics include:

Research on existing or new methodologies and approaches: informal modeling techniques and practices, adapting/trimming existing methods, and new product/project planning techniques

Research on existing or new techniques or practices: pairing, war-rooms, test-first design, paper-based prototyping, early acceptance test driven development, exploratory testing, refactoring, or others.

Research on special topics or tools: configuration and resource management, testing, project steering, user involvement, design for agility, virtual teams or others.

Research on integrating ideas from other fields, e.g. interaction design, requirements engineering, cognitive science, organizational psychology, usability testing, software security, into agile processes.

Research studies of development teams using ethnographic or social research techniques.

Research on agile software engineering economics.

Quantitative and qualitative studies of agile methods, practices, and tools.

Research on agile compliance and cost benefits within CMMI, ISO 9000, and FDA certified development projects.

Papers are particularly relevant when agile process implementations are shown to produce quantitative and qualitative benefits on distributed, outsourced, large, or standards compliant software development projects which have been previously been viewed (erroneously) as unsuited for agile development.

Jeff Sutherland, Ph.D.
Chief Technology Officer and Worldwide Scrum Consulting Practice Manager
PatientKeeper Inc.
275 Washington St., 2nd Floor
Newton MA 02458
Tel: (617) 987-0394
Email: jeff.sutherland@computer.org

Hubert Smits
Services Dept
Rally Software Development
3333 Walnut Street
Boulder, CO 80301
Email: Hubert.Smits@rallydev.com

Scrum World Tour T-Shirt

2007-05-23T09:46:00.000-04:00

Thanks to �rjan Hillbom CPG we now have a Scrum World Tour T-Shirt produced by Trifork in Denmark. �rjan is a rock group/motorcycle gang video expert who attended a Certified ScrumMaster training by me and Jens Ostergaard in Copenhagen recently. He said Scrum really "rocks" and it is definitely "faster, better, cooler" and must have a world class T-shirt which he designed for free.

A Type C Scrum Danish company produces really nice T-shirts so I asked them to produce this one. It costs about $30 plus a few dollars for shipping. Get your Scrum World Tour T-Shirt at Trifork.

Scrum Podcast: Andy Latham's conversations with thought leaders

2007-04-17T10:01:00.000-04:00

Listen to conversations with thought-leaders at the interface between Web 2.0, Libraries, and the Semantic Web... by Andy Latham

Jeff Sutherland talks with Talis about SCRUM

In our latest Talking with Talis podcast, I talk with Jeff Sutherland about SCRUM. Jeff is one of the co-creators of SCRUM and is also the Chief Technology Officer of PatientKeeper.

During our conversation, we discuss the SCRUM process, examining the theory and the history behind it and we explore the benefits of adopting SCRUM in software development.

During the conversation, we refer to the following:

* Jeff's SCRUM blog

* Agile Software Development

* Ken Schwaber

* Scrum Alliance

* Kent Beck

* Extreme Programming

* Yahoo!

* Google AdWords

This conversation was conducted by telephone on Friday 13th April 2007 and edited in Audacity.

Oursourcing Strategy: Only Work with Scrum Teams

2007-04-16T09:14:00.000-04:00

I had an exciting week in the Amsterdam area at the beginning of April working with Xebia, a consulting company that has set up a subsidiary in India that uses a SirsiDynix style Scrum where geographic transparency rules and teams are made up of people from multiple locations that meet daily. Aggressive, well functioning Scrums can use this style of organization to radically force teams across geographies to function as one entity. If you want to outsource to India, work through the Xebia India team. You have to try this to see how it works. Set up a test case. Outsource one project to an India waterfall team. Outsource another through Xebia to an India Scrum team and see what happens. You will be surprised by the results.

There are only a few hours time difference between Amsterdam and India so their daily working relationship is excellent with overlapped schedules. I spent some time with the leader of the Indian organization who worked for Xebia in Amsterdam for many years and took the opportunity to return to India and build Agile teams. He and his Indian teams have a tight working relationship with the Amsterdam consulting group.

For information on Xebia, check out Serge Beaumont's blog item on the manager's role in Scrum. We were discussing this over a few beers at an outstanding Dutch restaurant and Serge asked me about the PatientKeeper MetaScrum which meets on a weekly basis. It is led by the Chief Product Owner. However, the CEO is almost always there and aggressively removes company impediments. This led Serge to a brilliant insight. The PatientKeeper CEO is the ScrumMaster of our MetaScrum! That's one of the reasons it works so well.

Deep Agile: A Dialogue Between Scrum and XP

2007-04-13T13:35:00.000-04:00

Photo from cover of Crosstalk, Apr 2007

Spend two days with two signatories of the Agile Manifesto - Jeff Sutherland, Co-Creator of Scrum, and Ron Jeffries, XP author and consultant.

You wouldn't want to miss a two day deep dive into Agile: Scrum, Extreme Programming(XP) and Lean steps to software development success. Not to mention how to get Scrum and XP working together ...

When: April 28 and 29th, 2007
Where: MIT Tang Center/E51-345, Cambridge, MA

Register here. All proceeds go to the Boston chapter of the ACM.

ScrumMaster Certification Boston

2007-03-25T18:47:00.000-04:00

18-19 April 2007 Boston
17-18 May 2007 Boston
8-9 Nov 2007 Boston

Get certified by Jeff Sutherland, Co-Creator of Scrum. Signup using Google or PayPal checkout buttons on left. Or email Purchase Orders or fax to 617-812-8527.

Jeff started the first Scrum at Easel Corporation in 1993 and worked with Ken Schwaber to emerge Scrum as a formal process at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and IT organizations and helped write the Agile Manifesto.

Springtime is a wonderful time of year in Boston and the course will be given at PatientKeeper, home of the first All-At-Once Scrum driving the whole company to market leadership in their product space. Jeff is the PatientKeeper CTO and Worldwide Scrum Consulting Practice Manager. He will be assisted in leading the course by the PatientKeeper Product Owner who will review Product Backlog management for the company's product portfolio. They will describe how to automate and manage Sprint Backlogs for multiple teams developing a wide variety of integrated and interoperable products.

The PatientKeeper Chief Product Owner leads the weekly MetaScrum which resources, starts, stops, and changes all Sprints to deliver dozens of production releases a year to large enterprise healthcare systems. Mary Poppendieck, in her latest book on Lean Software Development comments:

Five years ago a killer application emerged in the health care industry: Give doctors access to patient information on a PDA. Today there is no question which company won the race to dominate this exploding market; PatientKeeper has overwhelmed its competition with its capability to bring new products and features to market just about every week. The sixty or so technical people produce more software than many organizations several times larger, and they do not show any sign that the size of their code base is slowing them down.

A key strategy that has kept PatientKeeper at the front of the pack is an emphasis on unprecedented speed in delivering new features. It will not surprise anyone who understands Lean that PatientKeeper has to maintain superb quality in order to support its rapid delivery. CTO Jeff Sutherland explains it this way:

"Rapid cycle time: * Increases learning tremendously * Eliminates buggy software because you die if you don't fix this. * Fixes the install process because you die if you have to install 45 releases this year and install is not easy. * Improves the upgrade process because there is a constant flow of upgrades that are mandatory. Makes upgrades easy. * Forces quick standardization of software via new features rather than customization and one off. * Forces implementation of sustainable pace.. You die a death of attrition without it. * Allows waiting to build new functionality until there are 4-5 customers who pay for it. This is counterintuitive, and caused by the fact everything is ready within 90 days."

As part of the unique opportunity to work for two days within a Scrum company, there is a large open space Atrium which is ideal for group exercises. Participants will learn everything necessary for getting started with Scrum. There are very few rules to Scrum so it is important to learn its fundamental principles by experiencing them.

The course will run from 9am-5pm each day. A continental breakfast and lunch will be provided.

Who Should Attend

PMPs: You can receive 16 Professional Development Units (PDUs) for this course.

Course Material:

Click here for course syllabus.

Of course, there will be updated material and training exercises in the course which you cannot get from books. The entire syllabus will be made available upon registering for the course so you can look it over and bring it with you to the sessions. You may get to see our Product Backlog presented by the PatientKeeper Chief Product Owner or attend our Daily Scrum of Scrums!

Logistics Information

http://maps.google.com/maps?q=275+Washington+St,+Newton,+MA&ie=UTF8&amp;amp;amp;amp;amp;amp;z=15&om=1&iwloc=addr

Boston CSM Trainings are held in the PatientKeeper Board Room on the second floor of 275 Washington Street in Newton, MA. This is directly off the Mass. Pike and across the street from the Sheraton Hotel, only about a 10-15 minute drive from Logan Airport or from Harvard Square.

PatientKeeper, Inc.
275 Washington Street - Second Floor
Newton, MA 02458
+1 617 987-0394
+1 617 812-8527 fax

PatientKeeper has a special rate of $179 at the Newton Marriott. Click on
http://cwp.marriott.com/bosnt/patientkeeper/ to get this rate which also includes "Wired for Business" (unlimited high speed, unlimited local telephone calls and unlimited domestic long distance).

The Newton Marriott is approximately 6 miles (and about 10-12 minutes) from the corporate office. http://marriott.com/hotels/travel/bosnt-boston-marriott-newton/
You can call the hotel directly at (617) 969-1000 or the Marriott Worldwide Reservations line at (800) 228-9290. Just be sure to mention the PatientKeeper "P1K" rate!

Airport Shuttle Reservations:
The Boston Marriott Newton Hotel has a contracted rate for airport transfers with Knights for $28.00 per way with direct service from Logan International to The Boston Marriott Newton Hotel. Advanced Reservations are required by booking online at http://www.knightslimo.com or calling Knights at (800) 822-5456.

Shuttle to PatientKeeper:
For service to and from the Boston Marriott Newton Hotel to PatientKeeper's Newton office, we have negotiated rates with US Limo and each traveler will pay own expenses with US Car Service with your own credit card. To make shuttle reservations, please contact US Limo at 508-494-1015. The rates are outlined as follows:

$18/way for a Sedan which accommodates up to 3 passengers
$35/way for an SUV which accommodates 4 � 6 passengers
$50/way for a Van which accommodates 7-14 passengers

Remember there are many other good hotels in the Harvard area near PatientKeeper. Check www.hotels.com or your favorite travel site for hotels in Cambridge, MA, and pick one that fits your price.

The fee for Certified ScrumMaster Training is $1200. You can register in three ways:

1. Fax a Purchase Order to PatientKeeper at 617-812-8527.
2. Send a check to Jeff Sutherland, PatientKeeper, Inc., 20 Guest Street, Suite 500, Brighton, MA 02135.
3. Use the Google Buy Now button on the upper left side of this page.

Refund policy: Rescheduling to another date for the same course is free at any time. 90% of the course fee will be refunded for cancellations more that 7 days in advance of the course. No refunds will be provided for cancellations within a week of the course.