Scrum Log Jeff Sutherland

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.

HICSS 43 Call for Papers - submissions due 15 June 2009

2009-06-11T12:54:00.000-04:00

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
http://www.hicss.hawaii.edu/hicss_43/minitracks/st-asd.htm
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
jeff@scruminc.com
+1 617 606-3652

Gabrielle Benefield
Scrum Training Institute
London, UK
gbenefield@gmail.com

Scrum in Church

2009-06-06T05:08:00.002-04:00

We are working on this paper for 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. (click here for latest draft)

Ken Schwaber on "Flaccid Scrum - A New Pandemic?"

2009-05-30T17:34:00.001-04:00

Agile Bazaar June Meeting

Date: Thursday June 18
Time: 6:00 - 9:00pm
Place: To be announced (A Burlington location was planned but we are looking for a larger space and will announce it soon)
RSVP: Go to http://agilebazaar.org/ to register. We expect to fill all the seats, so sign up early!

Food: Will be provided
Cost: Voluntary contribution to offset food expenses is welcome

Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.

Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn�t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.

The primary habits that hinder us are flaccid developers and flaccid customers who believe in magic, as in:

Unskilled developers - most developers working in a team are unable to build an increment of product within an iteration. They are unfamiliar with modern engineering and quality practices, and they don�t have an infrastructure supportive of these practices.

Ignorant customer - most customers are still used to throwing a book of requirements over the wall to development and wait for the slips to start occurring, all the time adding the inevitable and unavoidable changes.

Belief in magic - most customers and managers still believe that if they want something badly enough and pressure developers enough to do it, that it will happen. They don�t understand that the pressure valve is quality and long term product sustainability and viability.

Have you seen these problems? Is your company "tailoring" Scrum to death? Let Ken respond to your issues and questions!

Ken will describe how Scrum addresses these problems and will give us a preview of plans for the future of the Scrum certification efforts.

Evidence-based Advocacy of Scrum and Agile

2009-05-23T04:24:00.000-04:00

Bob Marshall, Transformational Leadership Specialist & Co-founder of the UK Rightshifting Network

I attended a great talk by Jeff Sutherland (one of the founders of Scrum) in London last night, courtesy of JP Morgan and the ACCU.

For all those folks who missed it � you really would have learned some useful things by being there, I think.

For me, the undoubted highlight of Jeff�s talk was the copious amount of evidential data for the remarkable improvements in productivity (effectiveness) brought about by effective adoption of Agile methods, and Scrum in particular.

Another pleasure of attending such events is the opportunity to pick up some little nuggets of information not otherwise generally appreciated. Last night I learned that Scrum was expressly designed in part at least, on lessons learned from cellular biology and cancer research, and the Scrum team model is based on the way Toyota put their Prius product development team together. (Happy to explain further if anyone�s interested).

I would urge anyone interested in software development effectiveness to seek Jeff out and learn from his extensive practical experience.

Click here for slides - Agile Development in the Enterprise

- Bob

-----------------

Note: The first Scrum team at Easel Corporation in 1993 was based directly on:

Takeuchi, Hirotaka; Nonaka, Ikujiro (January-February 1986). "The New New Product Development Game" (PDF). Harvard Business Review. At that time, the Prius team was not formed and the example used by Takeuchi and Nonaka for automobile production was Honda. Later work by Takeuchi describes Prius development based on the same model of team formation. See Hitotsubashi on Knowledge Management.

Scrum Video

2009-05-12T14:49:00.000-04:00

Scrum methodology from Soul' on Vimeo.

SmartBear: A better way to do code review ...

2009-04-25T15:42:00.001-04:00

At OpenView Venture Partners we encourage portfolio companies to do code reviews - online, not face to face. Contrary to most agile practices where face to face communication is preferable, there are some distinct advantages to online review - no posturing, no haranguing, complete documentation of the problem, leisurely review and followup.

SmartBear Code Reviewer 5.0 has some nice features and we have some reference sites for OpenView companies.

An interesting discussion on whether code review should be done before or after committing to the build can be found on the SmartBear blog.

Shock Therapy: British Telecom Presentation

2009-04-13T11:20:00.000-04:00

Photo by twhume

On 2 April, I presented the latest version of "Shock Therapy: Self-Organization in Scrum" at British Telecom in London.

An earlier version of this presentation was presented at Google in the summer of 2008. The Google presentation is now on YouTube and several people have asked for slides so here is the latest version of "Shock Therapy: Self Organization in Scrum."

After the Google presentation, a group of went to dinner and they pressured me until late in the evening to describe exactly how and why the first Scrum team went into a hyperproductive state. The results of this discussion will be pressented at:

Travelocity
325 Hudson St.
New York, NY 10013 US
View Map
When: Tuesday, April 14, 6:00PM Add to my iCal Calendar
Phone: 917-887-1669

Topic: "Agile Architecture: Should I take the Red Pill or the Blue Pill?"

An analysis of hyperproductive Scrums at Google last summer showed that high performance of a team is dependent on architecture, the quality of the implementation and the understanding of the team. Most teams have either poor common understanding of system components or lack of ability to work together across components. This cripples velocity. With the right understanding of architecture teams can achieve not only high velocity, they can craft the product to fit end user needs in extraordinary ways. Thus the fundamental principles of the Agile Manifesto can be achieved at a much higher level with the approach described in this presentation.

We will need your name on a list at the door and bring your photo ID.

Location: Travelocity, 325 Hudson (see above; many thanks to them!) Entrance is on Vandam St. (just around the corner). Conference Room is on the 10th Floor.

We will have networking and food starting at 6:00pm. The talk will start at 6:30pm. And we will stop at 8:00pm.

Self-Organization: The Secret Sauce for Improving your Scrum team

2009-04-12T20:38:00.001-04:00

Google asked for an advanced Scrum presentation for those already doing Scrum. So we talked about "Shock Therapy" and how to bootstrap a hyperproductive team.

Scrum and the A3 Process: Game Over for Waterfall Companies

2009-04-10T15:29:00.001-04:00

The best teams I work with are using lean tools to identify waste, particularly value stream mapping. They then use Scrum to eliminate waste by working the Scrum impediments list. This has the benefit of pushing Scrum out of development into the rest of the organization as they see how they contribute to waste (or they feel so much pressure from development velocity they have to change).

This week I spent several days with the second company in the world that is implementing Scrum everywhere. It starts with the Senior Management Scrum Board in the CEO's office and translates into every department in the organization. The last company that did this immediately generated a hockey stick in their revenue curve, acquired two companies and went public in less than a year. We are eager to see what happens with this company.

As we have focused on surfacing waste and clarifying the ScrumMasters impediment lists, we find that ScrumMasters need better tools to eliminate impediments. They need a plan the whole company can understand and support. Using the A3 Process developed at Toyota we find that it gives ScrumMasters a powerful tool that they need to eliminate impediments.

Google on A3 Process and you will get hundreds of links and dozens of books, so this is a huge resource available to ScrumMasters everywhere.

A key component of the single sheet A3 paper which documents the problem, context, root cause, proposed solution, next steps, and issue is the 5 Whys. For every problem ask why, they ask why to the answer. Do this five times and you will get down to the root of the issue which is often surprising to management and developers alike. See:
Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System

These aggressive strategies will turn a Scrum company into a Toyota that will crush a waterfall company like GM. We are beginning to see an acceleration of waterfall software companies going out of business in some parts of the world because they are either unable or unwilling to change.

TableNinja: Poker Consultant expert advice to Agile developers

2009-04-06T10:11:00.001-04:00

Alex Sutherland graduated from Cal Tech a few years ago and continued into the doctoral program in math and econometrics. However, his online poker hobby was generating all the cash he needed and he noticed that the PokerStars user interface was not suitable for serious players with multiple simultaneous games running concurrently.

Teaming up with a partner in a Los Angeles software company doing Scrum, they decided to implement the best front end for experienced poker players in the business. TableNinja shipped their first Scrum product release a few months later.

Alex is a Certified ScrumMaster from a recent course in Beverly Hills and says Scrum has definitely helped him and his partner double productivity and that it works better remotely than it does colocated. When they are colocated they drift off focus. When they work via Skype video they stay focused. As a result they say their next hires will probably be outside the United States.

This observation is the same as the CTO of Xebia made in our paper at Agile 2008 last year. Teams half in the Netherlands and half in India work better in their environment than colocated teams so they do all their projects that way. Of course, you need to do really good Scrum to get this effect.

TableNinja does consulting for serious poker players all over the world and some of Alex's best students are in places like Tokyo outside the United States. He says his recommendations to wannabe Poker champions are the same that he makes to software developers.

Your game falls roughly into three categories:

A Game - all the big money is made in your A game. The typical player/developer is running at this level less than 10% of the time.

B Game - this is where you make small amounts of money, probably 40% of your time.

C Game - this is where you lose small (or perhaps big) amounts of money about 40% of the time.

Alex's goal as a coach is to increase your A game to 20% of your time and make your B game good enough to pay off your losses on your C game. If you do this, you can make as much money as you need (and maybe more) playing Poker.

The problem for Poker players and software developers is that they do not stay focused when in their A game and stop playing when they realize they are playing their C game. They are like a taxi driver that has a target of $300 a day. During a conference when they can cycle back and forth to the airport they make $300 in a hour and quit. The rest of the time they cruise for 12 hours a day until they get their $300 dollars. They don't get it that they should only work the day of the conference that week!

Alex's recommendation is to code like crazy when you are in the zone and quit immediately when you are tired or bored. I noticed this recommendation fit nicely with Tom Poppendieck's observation of an XP company that did an experiment with different hourly work weeks to see when XP teams that did intensive pair programming hit their maximum production of shippable software. In that company, 16 hour weeks delivered the most production ready software.

Tune in, turn on, and drop out of the rat race might be good advice for Agile developers. You can start by playing a little TableNinja to get a feel for it. Better yet, join us at Beverly Hills Scrum Certification training later this month and learn how to do this in software development.

Sprint Burndown: by hours or by story points?

2009-04-05T17:56:00.001-04:00

The best teams I work with burn down story points. They only burn down when a story is done.

To do this, the team needs to have small stories. They will need to work with the product owner to make this happen. In disciplined teams this saves a lot of overhead and makes them go faster.

For new teams, breaking down the Sprint Backlog into tasks and estimating in hours is normally recommended as the teams need to learn to manage resource loading. However, Intronis, one of my venture group portfolio companies, started their first Scrum with burning down story points and has never looked back. They tripled their velocity in a few months and have one of the best implementations of Scrum in our 12 portfolio companies.

This strategy is recommended only for teams that can deliver working software at the end of each Sprint. This means tested at the feature level, i.e. potentially shippable code.

French Scrum Meetup: Should you take the Red Pill or the Blue Pill?

2009-03-23T13:28:00.003-04:00

The first French Scrum User Group meeting was a great success and we had more people than the room could hold. I reported on the Scrum Gathering in Orlando and reviewed some of the highlights of that meeting. The major focus was on the architecture presentation that Jim Coplien and I delivered in Orlando. It was great fun to talk about the dramatic difference between those teams that take the red pill (that Morpheus offered Neo in the Matrix), and the blue pill that most people take. This creates two radically different Agile worlds out there.

Selling Scrum: How to persuade people to change!

2009-02-18T11:45:00.005-05:00

Taichi Ohno. Workplace Management. Gemba Press 2007

People constantly ask me how to sell Scrum either to management or to developers. The real question has nothing to do with Scrum. It has to do with leadership and how do you persuade people to change from an old way of doing things to a new way.

Taichi Ohno, the father of the Toyota Production System, was constantly asked this question. His book on Workplace Management is from talks he gave to management and workers and the first talk is on the art of persuasion.

His comments reflect real genius. They articulate what artificial intelligence programmers found out when trying to build robots in the 1980s. Half of what people think is wrong. The challenge is to inspect and adapt to find out what opinions, thoughts, or ideas are wrong. They found that robots would not work unless they programmed this into the robots.

I've found that this is one of the core principles essential to innovation and one of the most important ideas that any person can incorporate into their being. Without it you will fail half the time. With it you will still fail half the time, but inspect and adapt, see problems quickly and recover. People will say you are a "wise" man or woman and that you know more than the rest of us. They will follow such an "expert" because they trust them to navigate through a world of increasing uncertainty.

The Wise Mend Their Ways - Taichi Ohno

I don't think the gemba (workplace) changes easily. If the gemba changed easily [management of work] would be very easy but the gemba is not such a place. It is important for people to understand and agree, and it is important for us to persuade them.

In order to explain and gain the agreement of many people, you need to have some basis for your arguments. When I give talks I am often asked about how to develop one's powers of persuasion. But if you are in a position to give instructions or give orders, you cannot do this unless you have a lot of confidence about what you are saying. However, people's ideas are unreliable things and I would be impressed if we were right half the time.

There is a proverb "even a thief is right three times out of ten." If it's true that even a thief will say three right things, then I think a normal person is right half the time but wrong the other half of the time.

When I was a middle school student in the old system, we studied the Chinese classics, and ruing this class we learned from the Analects of Confucius. In these writings Confucius says "the wise will mend their ways" and "the wise should not hesitate to correct themselves."

... We are all human and we are wrong half of the time. You may give the wrong orders to your subordinates. Since we are all human, half of what your subordinates have to say may be right. Unless managers first take this attitude, people will turn away from us.

So in the end, having a sense of humility is one of the conditions for developing strong powers of persuasion.

Hawaii Agile Papers - HICSS 2009

2009-02-10T05:31:00.001-05:00

HICSS presentation on distributed Scrum is posted at link below.

Software Technology Track
Co-chairs: Gul Agha and Rick Kazman

Agile Software Development: Lean, Distributed, and Scalable
Co-chairs: Jeff Sutherland and Gabrielle Benefield

ST1 Tuesday
Queen�s 4; 8:00 � 9:30

All-Out Organizational Scrum as an Innovation Value Chain
Brent Barton

The Impact of Organizational Culture on Agile Method Use
Diane Strode, Sid Huff, and Alexei Tretiakov

Automated Acceptance Testing Using Fit
Geir Hanssen and B�rge Haugset

Agile Deployment: Lean Service Management and Deployment Strategies for the SaaS Enterprise
Robert Benefield

ST2 Tuesday
Queen�s 4; 10:00 � 11:30

A Model of Agile Evolution and Maintenance Process
Mira Kajko-Mattsson and Jaana Nyfjord

Understanding Shared Leadership in Agile Development: A Case Study
Torgeir Dings�yr, Nils Brede Moe, and �yvind Kvangardsnes

Fully Distributed Scrum: Replicating Local Productivity and Quality with Offshore Teams
Jeffrey Sutherland, Guido Schoonheim, and Mauritz Rijk
HICSS slide presentation

Bridge Methods: Using a Balanced Project Practice Portfolio to Integrate Agile and Formal Process Methodologies
Stephen Cohen and William Money

See HICSS42 for latest details on the conference.

Roots of Scrum: Takeuchi and Self-Organizing Teams

2009-01-10T10:12:00.008-05:00

Click on image above for Nonaka and Takeuchi SECI process

The first Scrum team was created directly from a paper which is required reading for any Scrum practitioner. It explains how to set up self-organizing teams and clearly outlines management's role in the process.

Takeuchi and Nonaka. The New New Product Development Game. Harvard Business Review, 1986

A longer paper from a book which is out of print goes into more depth. Some may find this easier reading.

Ken-ichi Imai, Ikujiro Nonaka, and Hirotaka Takeuchi. Managing the New Product Development Process: How Japanese Companies Learn and Unlearn.

It clearly explains the fundamental concepts so often missed by management and teams new to Scrum. The discussion of self-organizing teams is a good example:

A new product development team, consisting of members with diverse backgrounds and temperaments is hand picked by top management and is given a free hand to create something new. Given unconditional backing from the top, the team begins to operate like a corporate entrepreneur and engage in strategic initiatives that go beyond the current corporate domain. Members of this team often risk their reputation and sometimes their career to carry out their role as change agents for the organization at large.

Within the context of evolutionary theory, such a group is said to possess a self-reproductive capability. Several evolutionary theorists use the word "self-organization" to refer to a group capable of creating its own dynamic orderliness. A recent study by Burgelman found that a new venture group within a diversified firm in the United States takes on a self-organizing character. Another study by Nonaka has shown that Japanese companies with a self-organizing characteristic tend to have higher performance records than others.

The creation and, more importantly, the propagation of this kind of self-organizing product development team within Japanese companies represents a rare opportunity for the organization at large to break away from the built-in rigidity and hierarchy of day-to-day operations. It is quite difficult for a highly structured and seniority-based organization to mobilize itself for change, especially under noncrisis conditions. The effort collapses somewhere in the hierarchy. A new product development team is better suited to serve as a mote for corporate change because of its visibility ("we've been hand picked"), its legitimate power ("we have the unconditional support from the top to create something new"), and its sense of mission ("we're working to solve a crisis situtation").

An alternative view of a parallel approach is outlined in:

Chet Richards. Certain to Win. XLibris Corp, 2004.

Richards outlines the strategy of fighter pilot John Boyd. He uses German concepts to illustrate key ideas.

* Enheit -mutual trust, unity, and cohesion
* Fingerspitzengefuhl - intuitive feel, especially for complex and potentially chaotic situations
* Auftragstaktik - mission, generally considered a contract between superior and subordinate
* Schwerpunkt - Any concept that provides focus and direction to the operation

He takes these concepts down to second order interactions. Trust builds by training in the field and by mission driven challenges that a self-organization team accepts or does not accept. It they accept, they can be counted on to do it or die in whatever way they see fit without intervention by the superior. This level of trust depends on the team trusting the rightness of their leader. If superiors do anything to disrupt the team, trust breaks immediately.

With trust based on real unity and cohesion, Boyd's Observe, Orient, Decide, Act feedback loop goes into an implicit state where there is Observe, Orient, and Decisions becomes implicit. The team goes into motion before the leader can give a command. Like in martial arts the Sensei is moving before he even sees the motion of the attacher using a sixtth sense. This is the kind of trust a Dream Team has. You know it when you see it and how come so few software teams have that level of trust?

French Scrum User Group Meetup

2009-01-08T18:45:00.003-05:00

The new French Scrum User Group now has over 100 members. We will meetup at La Defense in Paris the evening of 19 March. Click here for details.

Scrum in Seattle: Last Week to Sign Up

2009-01-04T13:22:00.000-05:00

Civica Office Commons
225 108th Ave NE
Bellevue, WA 98004

Scrum Certification Seattle
12-13 Jan 2009

This course will be led by Jeff Sutherland, Co-Creator of Scrum and Mitch Lacey, former Agile coach at Microsoft. Jeff will discuss his latest papers being submitted to Agile 2009 and papers presented early in January at his Agile track at the Hawaii International Conference on Software Systems. These will provide real world experience on how new ScrumMasters can implement world class teams.

Going from Good to Great: How a CMMI 5 Company Quadruples Productivity with Scrum

Take No Prisoners: How a Venture Capital Group Does Scrum

Distributed Scrum: The Secret Sauce for Hyperproductive Distributed Outsource Teams

Scrum In Church: Saving the World One Team at a Time

Shock Therapy: A Strategy for Consistently Generating Hyperproductive Teams

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.

Scrum Makes You Feel Better

2009-01-03T08:11:00.003-05:00

"The types of activities which people all over the world consistently report as most rewarding - that is, which make them feel best - involve a clear objective, a need for concentration so intense that no attention is left over, a lack of interruptions and distractions, clear and immediate feedback on progress toward the objective, and a sense of challenge - the perception that one's skills are adequate, but just adequate, to cope with the task at hand."
________________________________________________________________________

An interesting psychological finding
Posted by: "Nancy Van Schooenderwoert" vanschoo@acm.org nancyvanschooenderwoert
Date: Thu Dec 11, 2008 8:54 pm ((PST))

I was searching in my copy of "Lean Thinking" by Womack and Jones, and noticed this interesting passage in the chapter on 'Flow'. The authors mention a psychological researcher named Mihaly Csikszentmihalyi. (Someone's got a tougher last name than me!)

Here is the passage I thought might interest you:

"He has spent the last twenty-five years reversing the usual focus of psychology. Instead of asking what makes people feel bad (and how to change it) he has explored what makes people feel good, so that positive attributes of experience can be built into daily life."

"His method has been to attach beepers, which sound at random intervals, to his research subjects. When the beeper sounds the subject is asked to record in a notebook what she or he was doing and how they were feeling. After sifting decades of notebook data from thousands of subjects around the world, he has reached some very simple conclusions."

"The types of activities which people all over the world consistently report as most rewarding - that is, which make them feel best - involve a clear objective, a need for concentration so intense that no attention is left over, a lack of interruptions and distractions, clear and immediate feedback on progress toward the objective, and a sense of challenge - the perception that one's skills are adequate, but just adequate, to cope with the task at hand."

"When people find themselves in these conditions they lose their self-consciousness and sense of time. They report that the task itself becomes the end rather than a means to something more satisfying, like money or prestige. Indeed, and very conveniently for us, Csikszentmihalyi reports that people experiencing these conditions are in a highly satisfying psychological state of flow."

This gives an indication of why test driven development is so compelling for people once they know the basic technique. It also applies to sports and the arts. There the whole point is to do something that's just at the limit of your ability and keep pushing the edge.

It reminds me of a recent interesting post over on Jeff Sutherland's website. It's called "Scrum Makes You Smarter." It reports on a study that suggests voluntary pressure in the form of audacious goals taken on by high performance teams makes them produce more neuron stem cells.
............................................
Nancy Van Schooenderwoert, Lean-Agile Partners Inc.
www.leanagilepartners.com

Christmas Cheer: The Little Scrummer Boy

2008-12-20T12:39:00.001-05:00

Frank Fortner, SVP of Application Development at Iatric Systems, sent me this note recently and at the request of a Scrum Trainer who I shared it with, agreed to contribute his good cheer to the larger Scrum community.
-------------
Hi Jeff,

We've recently implemented Scrum at my company and it has been going very well so far. As a small/medium company that always operated in a lesser structured agile type of process, the added structure and accountability of Scrum has been a Christmas gift in itself. At this point, we haven't been at it very long (few months) but folks are picking it up and embracing it. Maybe too much�

As the father of Scrum, I thought you of all people might appreciate what one of our product managers put together over a sleepless night with too much time on her hands. It was obviously inspired by the Christmas carols she was listening to. Is it corny? Probably, but folks have clearly picked up the basic concepts!

The Little Scrummer Boy
Written by Michelle Schneider, RN
(For the most joyous experience, you must sing this aloud)

Scrum, they told me � Scu-rumpa-pum-pum

A new release to see - Scu-rumpa-pum-pum

Our great ideas we bring - Scu-rumpa-pum-pum

Followed by programming - Scu-rumpa-pum-pum, Scrumpa-pum-pum, Scrumpa-pum-pum

So to en-hance it - Scu-rumpa-pum-pum, When we Scrum

Product Backlog's huge, Scu-rumpa-pum-pum

How will we get it done, Scu-rumpa-pum-pum

Time for our Sprint Planning, Scu-rumpa-pum-pum

Then Daily Scrum meetings, Scu-rumpa-pum-pum, Scrumpa-pum-pum, Scrumpa-pum-pum

So to en-hance it - Scu-rumpa-pum-pum, When we Scrum

Are you done QC'ing, Scu-rumpa-pum-pum

It's time for debugging, Scu-rumpa-pum-pum

Today we demo it, Scu-rumpa-pum-pum

Awesome I must admit, Scu-rumpa-pum-pum, Scrumpa-pum-pum, Scrumpa-pum-pum

So to en-hance it - Scu-rumpa-pum-pum, When we Scrum

Merry Christmas and Happy Holidays!

ScrumButt Test: aka the Nokia Test

2008-12-10T05:37:00.004-05:00

The "Nokia Test" for Scrum teams was developed orginally by Bas Vodde at Nokia Siemens Networks in Finland. It has been updated several times and appears in it latest incarnation in Jeff Sutherland's Scrum Certification classes where he demonstrates that attending the class yields an average return on investment of 1033% for participants.

Links to all previous versions of the Nokia Test, the current scoring of the ScrumButt test, and the 1033% ROI calculations can be found in the attached presentation, "The ScrumButt Test: aka The Nokia Test."