Scrum Log Jeff Sutherland

Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto.

Tuesday, June 30, 2009

nlscrum - Hilversum, Netherlands 24 June 2009

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.

Sunday, June 28, 2009

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

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?

Tuesday, June 23, 2009

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

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.


Sunday, June 21, 2009

HICSS 2010 Papers: Need Reviewers!

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.


1. You must have or create an account on the review site at:

2. Then send an email to jeff at 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
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
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.

Thursday, June 11, 2009

HICSS 43 Call for Papers - submissions due 15 June 2009

It's time for you to get your most scintillating Agile theories
together, write a kick-ass paper that could get published in the IEEE
library and spend a week in beautiful Hawaii next January. Sound good?
Then get writing!

HICSS-43 CALL FOR PAPERS - submissions due 15 June 2009
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.

Track: Software Technology
Minitrack: Agile Software Development: Lean, Distributed, and Scalable
Co-Chairs: Jeff Sutherland and Gabrielle Benefield

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.

The track is 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. Topic areas identified as most needing further research by participants in HICSS 2009 were:

* The Product owner
* UX design
* Distributed teams
* How to effectively do self management
* Example driven development

Papers of interest include these topics:

* 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 processes are shown to produce quantitative and qualitative benefits across multiple implementations.

To submit papers and read more about the conference please go to the Agile Software Development HICSS43 web page.

Jeff Sutherland
Scrum, Inc. powered by OpenView Labs
332 Congress St., 3rd Floor
Boston, MA 02210
+1 617 606-3652

Gabrielle Benefield
Scrum Training Institute
London, UK


Saturday, June 06, 2009

Scrum in Church

We presented this paper at Agile 2009. Our reviewers think this will become one of the great Agile papers.

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

From 2005-2009 the author led Scrum teams in churches in Massachusetts, Connecticut, Florida, and Delaware. Scrum was designed to increase productivity and improve quality through teamwork. This experience report shows how Scrum was implemented in non-profit organizations to break down silos of knowledge and activity, encourage communication and collaboration, improve the working environment and personal relationships, and drive higher velocity and quality throughout the organization. Nonprofits have impediments that are difficult to overcome – parttime and volunteer workers, narrow specialization, little to no experience with project teams, and political problems whose roots can go back as far as 1692. Scrum as an institutional change agent is invaluable to a church.