From the Command Post

HICSS-46 CALL FOR PAPERS

Get your papers ready for the January 2013 HICSS conference (in Maui)!  The Agile and Lean Organizations track will be one half day during the 4-day conference. HICSS is a conference with a wide-variety of researchers (not just software) interested in system-science—how things get invented, organized and completed. You'll have many opportunities to socialize with other speakers (barbecues, beaches and good food).  The papers are IEEE published so it's a good opportunity to get your work out to the world.  I hope you can join us.

Location

Grand Wailea Maui
January 7-10, 2013 (Monday-Thursday)

Agile and Lean Organizations Mini-Track

Agile and lean approaches promote iterative product releases and pull risk-reduction earlier in product development. Characteristics include: cross-functional teams, rapid outcome testing (such as automated testing in software), continuous quality monitoring and deployment, pairing (for software, pair-programming), bias-avoiding estimation, process improvement and short feedback loops. Advocates claim agile development produces greater staff resiliency, better release forecasting, fewer product failures and more sustainable work pace.
Lean product management methods test market hypotheses and rapidly adapt to discoveries.  Characteristics include: set-based design, A-B testing, unmoderated user-experience testing, direct market experimentation, customer validation and pivoting. Advocates claim lean product management produces greater market satisfaction, deeper customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient resource utilization.
Advocates believe that sustainably agile/lean organizations must demand technical excellence everywhere (not just in software), promote individual and organizational change, organize knowledge, train employees in agile and lean philosophies, and optimize the whole value chain from concept to cash.
We seek research papers and experience reports that describe how agile development and lean product management affect organizational systems and outcomes. How do agile development and lean product management interact? How do organizations restructure to support these philosophies? When they do not restructure, what happens? How do markets respond to rapid iterations and end-user experimentation?
HICSS conferences are devoted to the most relevant advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Accepted papers may be theoretical, conceptual, tutorial or descriptive in nature. Those selected for presentation will be included in the Conference Proceedings published by the IEEE Computer Society and maintained in the IEEE Digital Library.

How to Submit a Paper

Follow Author Instructions posted on the conference web site: http://www.hicss.hawaii.edu/hicss_46/apahome46.htm.

• Select the correct track: “Agile and Lean Organizations” or “Agile/Lean Startup Organizations”
• HICSS papers must contain original material. They may not have been previously published, nor currently submitted elsewhere.  All submissions undergo a double-blind peer review process.
• Abstracts are optional, but strongly recommended. You may contact the Minitrack Chair(s) for guidance or verification of content.
• Submit a paper to only one Minitrack.  If a paper is submitted to more than one minitrack, then either paper may be rejected by either minitrack without consultation with author or other chairs. If you are not sure of the appropriate Minitrack, submit an abstract to the Track Chair(s) – see names and contact information below. for determination, and/or seek informal opinion(s) of Minitrack Chair(s) before submitting.
• Do not author or co-author more than 5 papers.  This means that an individual may be listed as author or co-author on no more than 5 submitted papers.  Track Chairs must approve any names added after submission or acceptance on August 15.

Important 2012 Deadlines for Authors

Date	Description
June 15	Submit full manuscripts for review as instructed. The review is double-blind; therefore, this initial submission must be without author names.
Aug 15	Review System emails Acceptance Notices to authors. It is very important that at least one author of each accepted paper attend the conference. Therefore, all travel guarantees – including visa or your organization’s fiscal funding procedures – should begin immediately. Make sure your server accepts the review system address https://precisionconference.com/~hicss.
Sept 15	SUBMIT FINAL PAPER. Add author names to your paper, and submit your Final Paper for Publication to the site provided in your Acceptance Notice.  (This URL is not public  knowledge.)
Oct 1	Early Registration fee deadline. At least one author of each paper should register by this date in order secure publication in the Proceedings. Fees will increase on Oct 2 and Dec 2.
Oct 15	Papers without at least one paid-in-full registered author may be deleted from the Proceedings and not scheduled for presentation; authors will be so notified by the Conference Office.

Cancellation and Refund Policy   All conference cancellation requests must be in writing.  A fee will be charged for cancellation of registration after Oct 15, at which time the paper is subject to withdrawal from the Proceedings.  There is no registration refund after Dec 1.  Cancellations for accommodations must be handled directly with the hotel.

HICSS-46 TRACK CHAIRS

Software Technology
Gul Agha  agha@cs.uiuc.edu
Rick Kazman  kazman@hawaii.edu

Agile and Lean minitrack co-chairs

Gabrielle Benefield
Evolve Beyond Limited
gbenefield@evolvebeyond.com

Dan R. Greening
Evolve Beyond LLC
dgreening@evolvebeyond.com

ScrumPlop has Begun

Google Automation of my QA Strategy

I have consistently found in my own companies and Openview Venture Partners companies that I coach that carefully prioritized implementation of acceptance tests produces higher quality faster than anything I have seen.

An Open-E in Poland they implemented continuous integration and immediately increased the velocity of over 50 developers by 20%. The next step was to improve the quality of their open source network storage server software so it could be released faster with fewer support problems. The software had to run on 80 different hardware platforms and needed thorough acceptance testing by a quality assurance team after development had completed a release. This acceptance test phase took 4-6 weeks per release.

I told them to proritize the problems encountered by the quality assurance team and implement tests in the build process to prevent these problems from ever appearing again. After 3 weeks of work by one developer there were 130 tests were running in the build process. The next release cycle cut quality assurance to 2 weeks and reduced support calls from the field by 50% saving millions of euros of development time and generating millions of euros in increased sales. Nothing I have seen works better than this.

Google has developed a brilliant automated strategy called "Bug Prediction" which does essentially the same thing. Seems like every team should be doing something like this.

Bug Prediction at Google

What's the problem?

Here at Google, we have thousands of engineers working on our code base every day. In fact, as previously noted, 50% of the Google code base changes every month. That’s a lot of code and a lot of people. In order to ensure that our code base stays healthy, Google primarily employs unit testing and code review for all new check-ins. When a piece of code is ready for submission, not only should all the current tests pass, but new tests should also be written for any new functionality. Once the tests are green, the code reviewer swoops in to make sure that the code is doing what it is supposed to, and stamps the legendary “LGTM” (Looks Good To Me) on the submission, and the code can be checked in.

However, Googlers work every day on increasingly more complex problems, providing the features and availability that our users depend on. Some of these problems are necessarily difficult to grapple with, leading to code that is unavoidably difficult. Sometimes, that code works very well, and is deployed without incident. Other times, the code creates issues again and again, as developers try to wrestle with the problem. For the sake of this article, we'll call this second class of code “hot spots”. Perhaps a hot spot is resistant to unit testing, or maybe a very specific set of conditions can lead the code to fail. Usually, our diligent, experienced, and fearless code reviewers are able to spot any issues and resolve them. That said, we're all human, and sneaky bugs are still able to creep in. We found that it can be difficult to realize when someone is changing a hot spot versus generally harmless code. Additionally, as Google's code base and teams increase in size, it becomes more unlikely that the submitter and reviewer will even be aware that they're changing a hot spot.

In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range. Source-based metrics that could be used for prediction are how many lines of code, how many dependencies are required and whether those dependencies are cyclic. These can work well, but these metrics are going to flag our necessarily difficult, but otherwise innocuous code, as well as our hot spots. We're only worried about our hot spots, so how do we only find them? Well, we actually have a great, authoritative record of where code has been requiring fixes: our bug tracker and our source control commit log! The research (for example, FixCache) indicates that predicting bugs from the source history works very well, so we decided to deploy it at Google.


For details click here ...

Agile Planning - Fighter Pilot Meets Solo Sailor

Recently I visited Hank de Velde on his boat that he uses to sail solo around the world with Rini van Solingen, original author of "The Power of Scrum." Hank and I had similar ideas on planning for high risk adventures.

Software in 30 Days is Out!

The official publication of "Software in 30 Days" is May 1. The book is a collaboration between the two creators of Scrum, Jeff Sutherland and Ken Schwaber. The goal of Scrum is to actually have working software at then end of each Sprint, which should be 30 days or less. Working software means tested, integrated, and ready to ship if necessary! This book shows you how it's done. It shows you how you can implement Scrum in your company, and how to improve the Agile practices you are already using. From the introduction:

We, Jeff and Ken, have been in the software industry, collectively, for seventy years. We have been software developers, managers in IT organizations and software product companies, and owners of both product companies and service organizations. More than twenty years ago, we created a process that lets organizations deliver software better. Since then we have helped hundreds of organizations do the same. Our work has spread farther than we have ever imagined possible, being put to use by millions of people. We are humbled by the extent of its adoption, and we are awed by the feats people have used it to accomplish. 

This is not the first book we have written on the topic of building software. It is, however, the first book we have written for people who do not themselves build software. This book is instead for leaders within organizations that depend on software for their survival and competitiveness. It is for leaders within organizations that can benefit from developing software rapidly, incrementally, and with the best return on investment possible. It is for leaders who face business and technological complexity that has made the delivery of software difficult. We have written this book so that these leaders can help their organizations achieve these goals, enhance their internal capabilities, improve their product offerings, and more. 

This book is for CEOs, executives, and senior managers who need their organizations to deliver better software in less time, with lower cost, with greater predictability, and with lower risk. For this audience, we have a message: You may have had negative experiences with software development in the past, but the industry has turned a corner. The software profession has radically improved its methods and its results. The uncertainty, risk, and waste to which you are accustomed are no longer par for the course. We have worked with many software organizations
that have already turned the corner; we want to help you do so, too. 

The book is available at Amazon and Barnes and Noble, in print and e-book versions. The print version is also available at Powell's.

Update: Can't believe I forgot it, if you're in the Netherlands, here's the bol.com link. Also available on Amazon.co.uk and Amazon.co.de. Thanks @scrumnl!

Scrum: The Future for Education?

When we first heard about teachers using Scrum in a classroom we had to know more and got in touch with those teachers through Ilja Heitlager at Schuberg Philis in the Netherlands. Here's what they sent in. It's translated into English from the original Dutch.


eduScrum in Dutch education

How it began …

Imagine: you are a chemistry teacher at a school for secondary education. Your students work in groups on complex assignments, but you are not completely satisfied about the results of that teamwork. And then your son-in-law becomes a Scrum Master and you hear his enthusiastic stories… That is how it began.

How it continued …

Willy Wijnands and Jan van Rossum, chemistry teachers at Ashram College (secondary education in Alphen aan den Rijn, the Netherlands) have been using an educational version of scrum since October 2011: eduScrum. They incorporate scrum into their lessons, to give students the opportunity to study more energetic and more effective. Using eduScrum also stimulates students to develop their strength as a team player.

Team work starts in their lessons with an introduction about confidence and an activity in which students talk about their personal capabilities and soft skills like punctuality, leadership capabilities, planning skills etc. After that, they form groups of four, set up to have additional capabilities. In this way, individual strengths in a team make individual weaknesses less relevant. Subsequently, they work in groups on the assignments of the context-rich chemistry module from a detailed sprint schedule.

Teacher: ‘I have indicated the number of time points per assignment (one point equals 10 minutes) and requested them to make an individual schedule. They have discussed those schedules and processed them into a group schedule. When I pointed out that I also wanted to do some whole-class teaching, they told me there was no time for it and that I should have announced it earlier. Wonderful, that much ownership. But they have to be in for it, because they have to learn to cope with unexpected events in their schedule.’

Group of four students, almost simultaneously: ‘This work is more pleasant in a group rather than individually. It is possible to ask each other questions and divide the tasks, which saves time. We have divided the experiments, because they are a good deal of work. But today we are going to work in groups of four during the entire lesson, because these assignments are very important and everyone should understand them. That is why we work together, it is something we have thought about during planning.’

Every group starts the lesson with a short scrum. This way they know what they have to do and where they stand to each other. A subsequent step is for them to learn to call each other to account, in case a group does not function optimally. The first step in doing this is a short but effective evaluation, executed by the groups themselves. Confidence in each other is the key theme in this evaluation.

Boy: ‘Our group consist of two boys and two girls. A group is useful when the group members co-operate. We’re fine in our group. Everyone takes his or her responsibility.’

Girl from the same group: ‘Everybody is contributing in our group. We have committed ourselves to do the work and we all are living up to it. We do our own tasks, and also work together. We do not study alone, if one of us does not understand, we explain to each other instead of asking the teacher. The information we have found we share with our group.’

From a Scrum perspective this might be trivial, but from a traditional educational perspective (focusing on the individual cognitive training) this is very special.

The plans for the future …

Willy Wijnands and Jan van Rossum are working with with Ellen Reehorst, an education designer and trainer, to further develop eduScrum and to hand it over to other teachers later. Use these addresses to find out more:


www.eduscrum.nl
info@eduscrum.nl
@eduscrum on twitter

The Agile Manifesto, Elaborated

The Agile Manifesto is one of those documents that at one level is simple, but actually holds a lot of meaning:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Recently Microsoft asked Jeff to write about the principles and values behind the Agile Manifesto, and how they can be translated into real action.

Here's the section on Individuals and Interactions:

Signers of the Agile Manifesto

Individuals and interactions are essential to high-performing teams. Studies of "communication saturation" during one project showed that, when no communication problems exist, teams can perform 50 times better than the industry average. To facilitate communication, agile methods rely on frequent inspect-and-adapt cycles. These cycles can range from every few minutes with pair programming, to every few hours with continuous integration, to every day with a daily standup meeting, to every iteration with a review and retrospective.

Just increasing the frequency of feedback and communication, however, is not enough to eliminate communication problems. These inspect-and-adapt cycles work well only when team members exhibit several key behaviors:

• respect for the worth of every person
• truth in every communication
• transparency of all data, actions, and decisions
• trust that each person will support the team
• commitment to the team and to the team’s goals

To foster these types of behavior, agile management must provide a supportive environment, team coaches must facilitate their inclusion, and team members must exhibit them. Only then can teams achieve their full 
potential.

In the end, resistance is futile. Change or die.

Steve Denning has written a great post over at Forbes addressing some of the traditional management arguments against Scrum. His key point, I think.

"What’s wrong here is the corporate culture, not Agile. Surviving in today’s marketplace requires individual and team freedom. It translates into cross-functional work that is constantly adapting, with roles switching as needed. It also means adjusting processes continuously to reflect the current situation.

In Agile, processes are secondary to the requirements of the work. Bureaucracy is the opposite: the requirements of the work—and the customer—are secondary to the bureaucracy. Not surprisingly, firms in this mode do a poor job of meeting customers’ needs.

When the culture doesn’t fit Agile, the solution is not to reject Agile. The solution is to change the organizational culture. One doesn’t even have to look at the business results of firms using hierarchical bureaucracy to know that they are fatally ill. In today’s marketplace, they will need to change their culture or they will die. They need to become Agile."

Steve has a lot more to say, go read the whole thing. More and more we're finding that traditional managers have to make the transition to Agile and Scrum...if they don't they'll be left behind. At Scrum Inc. we're addressing it in two ways. First, Jeff has completely re-invented the Certified Scrum Product Owner course, this one is based on legendary fighter pilot John Boyd's OODA loop. He's teaching it for just the second time in Boston at the end of May. And we've developed leadership workshops that focus directly on executive teams.


What's become really clear is that management no longer has the luxury of saying that Agile is for others. The science speaks pretty loudly, waterfall projects fail at such a greater rate than agile products, over and over again, that if businesses that don't make that switch aren't going to be around in the end. As Steve puts it, companies have to "change their culture, or they will die."

Scrum Metrics for Hyperproductive Teams

 

Yesterday, OpenView Venture Partners videotaped the Scrum metrics presentation that Scott Downey and I presented at Agile 2010. It consists of an animated slide presentation and an Excel spreadsheet that supports RoboCoach, the automated tool for generating a retrospective on your Scrum.

In the presentation, we fine tune the backlog and the Scrum meetings to help create a culture of hyperproductivity. It turns out that high performing teams are constantly removing impediments. As they go faster and faster the impediments become smaller and smaller, yet constant attention to removing them is critical. Failure to do this is similar to failure of the flight control computer in a high performance jet aircraft. It is always making slight adjustments to keep the aircraft stable. If the computer fails, the plane will spin out of control.

The metrics here are simple to collect and detailed in their capability to assess the stability of a team. For the first time we have comparable metrics across Scrum teams which are useful for identifying opportunities for coaching and improvement.

Videos of the Agile 2010 presentation can be found here. The latest RoboCoach spreadsheet can always be found on rapidscrum.com. The version of the presentation prepared for Openview can be downloaded here.

DoD Goes Agile

With waterfall failure after failure, even the government has decided to make Agile development a priority. Some people have a hard time believing this but I just want to take you through what happened in one department, the biggest one there is, the Department of Defense. Back in 2009 someone inserted this section into the 2010 Defense Acquisition Bill. These are the rules that the Department must follow when purchasing anything. Here’s the relevant section 804: IMPLEMENTATION OF NEW ACQUISITION PROCESS FOR INFORMATION TECHNOLOGY SYSTEMS.

The key language is this:

(2) be designed to include—

(A) early and continual involvement of the user;

(B) multiple, rapidly executed increments or releases of capability;

(C) early, successive prototyping to support an evolutionary approach; and

(D) a modular, open-systems approach.

Basically, for the DoD at least, Agile became the law. Here's the report the DoD returned to congress on how they would go about it:

The language here certainly sounds Agile to me:

•    Deliver Early and Often: This principle is aimed at changing the culture from one that is focused typically on a single delivery to a new model that comprises multiple deliveries to establish an environment that supports deployed capabilities every 12 to 18 months.

•    Incremental and Iterative Development and Testing: This principle embraces the concept that incremental and iterative development and testing, including the use of prototyping, yield better outcomes than trying to deploy large complex IT network systems in one "Big Bang."

•    Rationalized Requirements: User involvement is critical to the ultimate success of any IT  implementation, and user needs must be met. However, this principle also recognizes the need for users and requirements developers to embrace an enterprise focus across a portfolio of capabilities with established standards and open modular platforms vice customized solutions to ensure interoperability and seamless integration.

•    Flexible/Tailored Processes: The Department's IT needs range from modernizing nuclear command and control systems to updating word processing systems on office computers. This principle acknowledges  unique types of IT acquisition and embraces flexible and tailored-and risk-appropriate-IT paths based on the characteristics of the proposed IT acquisition.

And while I don’t know exactly how Agile the DOD has become, this is the language their CIO is using on their modernization plans.

The DoD CIO's 10 Point Plan for IT Modernization targets the most pressing, near-term challenges and presents approaches to efficiently and effectively deliver agile, secure, integrated, and responsive IT capabilities. This plan will enable the DoD to reduce costs and deliver faster, more responsive capabilities, while improving interoperability, user satisfaction, cyber security, and, ultimately, mission success. The primary goal is to enable agile, secure, efficient and effective IT for DoD.

And if that doesn't convince you, here's an interesting bullet from a slide deck by the White House CIO, Steven VanRoekel on the administrations 2013 IT budget priorities:

Entrepreneurs in Residence
– Introduce and cultivate innovative best practices and technologies into
the Government
– Assemble agile teams to solve problems using rapid cycle, lean engineering principles

There are other government agencies that have used Scrum to great effect, I know the FBI used it to rescue their Sentinel program from a complete waterfall failure, and I’m sure there are more. Anyone else know of any?

Also, if anyone knows of anybody who wants to take the next step in their career and get trained as a Scrum Master, there are still a few seats left for my Apr. 26-27 course in Boston.

Yet Another Waterfall Project Failure

California Scraps Massive Courts Software Project

By Chris Kanaracus, IDG News

California's Judicial Council has put the brakes on a long-running, massive software project that was supposed to modernize the state's trial courts case-management systems, saying the software is viable but that there's simply no money to continue installing it.

An independent audit found that it would cost US$343 million to deploy and support CCMS version four to 11 courts through fiscal year 2020-2021, according to the Judicial Council. Some $333.3 million has been spent so far on the third and fourth versions of CCMS, it said."What we do best in the judicial branch is to weigh the evidence and make reasoned and deliberate decisions," Chief Justice Tani G. Cantil-Sakauye said in a statement. "The council's decision to stop deployment of CCMS was responsible and prudent in view of our budget situation and the facts we gathered on the actual costs of deployment. CCMS works. Unfortunately, we don't have the resources to deploy it."

Earlier versions of CCMS are already implemented at a number of trial courts. But they aren't as advanced as version four, which can "handle all case types, provide for data exchange, and provide public access to cases across the state," according to a statement. The Judicial Council voted on Tuesday to continue supporting those earlier implementations.

Now, the CCMS Internal Committee will make recommendations to the council for "other ways" to use the CCMS technology and the state's investment in it "as well as develop new strategies to assist courts with failing case management systems," according to a statement.

The system's total cost had been estimated to be roughly $2 billion. More ...

---------

Gartner is now recommending that waterfall be abandoned. You need to be a subscriber to get:

Gartner - Technical Professional Advice

2012 Planning Guide: Application Delivery Strategies

Key points:

• Business users are losing patience with old-school IT culture. Relationships are tense and resentful. Legacy systems and practices impede agility. Bottom line - GET AGILE
• Adopt a product perspective.
• Say goodbye to waterfall.
• Improve cross-competency collaboration.
• Launch a deep usability discipline.
• Start a technical debt management program.

Sustainable Pace - why it's important

Why We Have to Go Back to a 40-Hour Work Week to Keep Our Sanity - Alternet by Sara Robinson

One hundred fifty years of research proves that shorter work hours actually raise productivity and profits -- and overtime destroys them. So why do we still do this?

March 13, 2012  |  

Photo Credit: gfpeck 

If you’re lucky enough to have a job right now, you’re probably doing everything possible to hold onto it. If the boss asks you to work 50 hours, you work 55. If she asks for 60, you give up weeknights and Saturdays, and work 65.  

Odds are that you’ve been doing this for months, if not years, probably at the expense of your family life, your exercise routine, your diet, your stress levels, and your sanity. You’re burned out, tired, achy, and utterly forgotten by your spouse, kids and dog. But you push on anyway, because everybody knows that working crazy hours is what it takes to prove that you’re “passionate” and “productive” and “a team player” — the kind of person who might just have a chance to survive the next round of layoffs. Read more ...

Leading vs. Managing in a Scrum Environment

Alex Brown, Scrum Inc.'s Product Owner and COO, had some thoughts on the role of management in Scrum, as he's been working on a workshop for executives for the past month or so. - jj

It’s odd. A number of people have told us recently they don’t think management has a role in a successful Scrum implementation.  The comments have been things like team members saying that the role of management in Scrum is to “keep the heck out of the way,” or teams complaints about management requests for updates and delivery forecasts. On the flip side, some business leaders have told us they feel Scrum is “hostile to management.” 

photo by Eoin Gardiner (cc)

We couldn’t disagree more, as we think management support is critical for Scrum to work at its best. In fact, we’ve actually spent a lot of time recently developing a Scrum Inc. workshop just for leadership to show them how important their role is and how to make the most of it.

From our point of view, comments like these say more about the specific organizations than Scrum. They are all classic symptoms of a breakdown in communication between an organization’s leadership and the teams actually doing the work. But it’s a common enough misperception that I thought I should address it here.

A core Scrum principle is that the team should be able to determine how to work best, free from micro-management.  The team should also push back on management requests that threaten to interrupt the Sprint, since that gives leadership a better picture of how their actions impact the actual work.

However, that doesn’t mean that business leadership doesn’t have a vital role to play; it does, and it is far more active than just “staying out of the way.”  Teams that exclude management entirely miss an enormous opportunity for productivity growth.  Our research shows this quite clearly: effective collaboration with leadership accelerates velocity more than twice as rapidly as “Guerilla Scrum” run in isolation from corporate management.

More importantly, and I can’t stress this enough, conflict with or lack of support from management is the biggest and most often cited challenge to implementing Scrum successfully.

The key difference is Agile companies look to their executives for leadership rather than management.  This is a real change in mindset, both by Team members and also in how managers view themselves and their role. A traditional management team spends much of its time focused on telling teams what to do. An Agile leadership team is a positive force that works with teams in three important ways:

1. They set meaningful and challenging, but achievable, goals to help focus the teams’ effort on activities that create the most business value.
2.  They work with teams to identify and eliminate impediments that are beyond the team’s ability to remove directly.
3. They establish and maintain a system of incentives that reward teams not individuals. If everyone focuses on teamwork rather than personal benefit, more work gets done faster and better…and that needs to be encouraged.  

Happiness Metric - The Wave of the Future

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


Traveling around the world, the happiness metric keeps bubbling up as a topic of interest. Books are starting to hit the charts at Amazon by business leaders (Zappos CEO, Joie de Vivre CEO) and psychologists. Managers and consultants are telling me that people are getting fed up with being unhappy at work. Younger people in particular are refusing to work in command and control environments based on punishment and blame. Major change is emerging (see The Leaders Guide to Radical Management by Stephen Denning). The Harvard Business Review devoted a recent issue to Happiness because happy employees lead to happy customers and better business. However, never underestimate the human capacity for screwing things up. See HBR blog on "Happiness is Overrated." You might need to "Pop the Happy Bubble," a pattern designed to straighten things out when your team is oblivious to impediments.

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

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

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

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



 Here are the columns:

• Name
• How happy are you with Crisp? (scale 1-5)
• Last update of this row (timestamp)
• What feels best right now?
• What feels worst right now?
• What would increase your happiness index?
• Other comments

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

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

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

---------

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

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

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