Scrum Log Jeff Sutherland

From the Command Post

2012-05-08T17:27:00.001-04:00

HICSS-46 CALL FOR PAPERS

2012-05-07T04:27:00.000-04:00

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

2012-05-06T16:17:00.001-04:00

Google Automation of my QA Strategy

2012-05-06T11:07:00.002-04:00

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

2012-05-05T10:15:00.000-04:00

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!

2012-05-01T13:54:00.000-04:00

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?

2012-04-26T15:56:00.001-04:00

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

2012-04-20T09:56:00.000-04:00

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.

Moving toward these types of behavior is more difficult than it might appear. Most teams avoid truth, transparency, and trust because of cultural norms or past negative experiences from conflict that was generated by honest communications. To combat these tendencies, leadership and team members must facilitate positive conflict. Doing so not only helps create productive behavior but also has several other benefits:

Process improvement depends on the team to generate a list of impediments or problems in the organization, to face them squarely, and then to systematically eliminate them in priority order.
Innovation occurs only with the free interchange of conflicting ideas, a phenomenon that was studied and documented by Takeuchi and Nonaka, the godfathers of Scrum.
Aligning the team toward a common goal requires the team to surface and resolve conflicting agendas.
Commitment to work together happens only when people agree on common goals and then struggle to improve both personally and as a team.

This last bullet, about commitment, is especially important. It is only when individuals and teams are committed that they feel accountable for delivering high value, which is the bottom line for software development teams. Agile methodologies facilitate commitment by encouraging teams to pull from a prioritized work list, manage their own work, and focus on improving their work practices. This practice is the basis of self-organization, which is the driving force for achieving results in an agile team.

To create high-performing teams, agile methodologies value individuals and interactions over processes and tools. Practically speaking, all of the agile methodologies seek to increase communication and collaboration through frequent inspect-and-adapt cycles. However, these cycles work only when agile leaders encourage the positive conflict that is needed to build a solid foundation of truth, transparency, trust, respect, and commitment on their agile teams.

You can go to Microsoft's site to read the whole thing.

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

2012-04-19T08:36:00.001-04:00

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

2012-04-17T06:33:00.000-04:00

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

2012-04-13T02:43:00.000-04:00

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

2012-04-01T09:37:00.005-04:00

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

2012-03-27T10:13:00.001-04:00

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

2012-03-20T15:00:00.001-04:00

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:

They set meaningful and challenging, but achievable, goals to help focus the teams’ effort on activities that create the most business value.
They work with teams to identify and eliminate impediments that are beyond the team’s ability to remove directly.
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.

The transition from traditional manager to Agile leader can be difficult…often the Scrum terminology is new and unfamiliar, many of the traditional tools and activities no longer apply, and managers wonder how they should be spending their time if they aren’t busy telling people what to do. Not every manager can make the transition, and without a clear sense of their new role even the best-intentioned leaders will subconsciously revert to old habits and may become an impediment to increasing team velocity.

So how can Scrum teams help their managers become better Agile leaders?

First, keep leadership “in the loop” both by educating them on Scrum terms and what they mean, and providing transparency into the team’s velocity, backlog points, impediments and other key metrics. Company leadership needs visibility into team progress…after all, they have to communicate the company’s status to internal and external stakeholders. A clear sense of where the team stands also allows leaders to have productive discussions about how best to support the team.

In exchange for that visibility, Agile leaders MUST make three commitments to the team: 1) to use their visibility to solve problems rather than assign blame; 2) to work quickly to remove impediments identified by the team; and 3) to minimize any additional work needed to share data…all metrics should be pulled and calculated from existing tools with no manual team work to convert them back into “traditional” reports.

Second, help your managers understand the role you want them to play rather than expecting them to figure it out on their own. Even a quick candid conversation about how they can help the team will go a long way. If you need more help, give us a call. The new workshop I mentioned earlier is designed specifically to help executives learn how to lead an Agile company. It focuses on getting leaders comfortable with shaping corporate vision, ensuring visibility, and supporting motivation in a Scrum environment. It also explains what leaders should and should not expect from their high-performing Scrum teams, and how to establish a more collaborative working dynamic.

So if it feels like your management “just doesn’t get it” and is perpetually in conflict with the team, take a moment to step back and think about how you can help your management team to become better Agile leaders.

Alex Brown

COO, Scrum Inc.

Happiness Metric - The Wave of the Future

2012-03-15T03:02:00.000-04:00

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

Answering Some Questions

2012-03-12T13:51:00.000-04:00

Jeff had a great webinar hosted by SmartBear last Thursday. If you missed it, here's the link to the archived webinar and the slides. We got hundreds of questions from the audience, and SmartBear sent fifteen of them on, they'll be posting all of them on their site soon, but we thought we'd give you a sample of a couple. If you watched the webinar and want to get the full scope of Jeff's thinking on Scrum, you can sign up for our March or April Certified Scum Master courses that are coming up.

What size team is "too small" for scrum?

Zero is the quick answer. We’ve seen Scrums of three of two and even one person. But for most teams the rule of 7 plus or minus two is the way to go. This usually has enough team members to allow for cross functionality, but not too many to make communication and sharing difficult. The more common problem I see is that teams are too large. If you have a team over 9 people, your team is just too big. And the research shows a team of 5 will go faster than a team of 7.

How do you deal with product ownership and customers on the team with shrink wrap software where there are a wide range of different types of customers with differing needs?

We coach all of our venture company on developing “personas” which are user archetypes for the product. Product Owners should take our Certified Product Owner course to dive into detail on this.

There needs to be one “vision” for a product. Now, there may be different types of customers (personas) that will be buying your product for different needs, but there needs to be one person who is prioritizing all of the differing customers’ needs. Is it more important to implement X feature for a certain type of customer, or Y feature for another? These can’t be of equal priority. If the product is large enough that you have multiple teams and multiple product owners, there still needs to be a Chief Product Owner who can settle questions of priority among the product owner team. I strongly recommend that even in large projects there is ultimately only one backlog that is organized in priority order. The reason for this is that the whole group should be focused on the top priority items, rather than diffusing their efforts on whatever features they think are important, rather than what the product owner and the customers think is important. Read the Citrix Online case study to see how to prioritize releases of a portfolio of products at the enterprise level. This is another topic covered in detail in our Product Owner course.

That Product Owner course will be held in Boston on May 31-June 1.

How The C-Suite Hurts America

2012-03-01T14:53:00.003-05:00

Steve Denning, one of the smartest guys today thinking about management and how companies are run, just pointed out a new Harvard Business Review article which should be required reading:

If some progressive journal were to write about overpaid CEOs, it wouldn’t be news. It would be just another “dog bites man” story.

But when Harvard Business Review, the pillar of the business establishment, writes that the C-Suite is so grossly overcompensated that US competitiveness is being systematically undermined, it’s big news. It’s a “man bites a pack of dogs” story.

Throughout HBR’s 90 year history, it has been a cheerleader for the C-Suite. Issue after issue, year after year, HBR has tirelessly nurtured the C-suite, tended it, encouraged it, cared for it, defended it, and celebrated it, as well as providing guidance for those aspirants who would like to gain access to the hallowed citadel.

So HBR can hardly be accused of any anti-business bias when it publishes an incisive article detailing how and why the C-Suite of US business is so grossly overcompensated that the practices are inexorably pushing the US economy into decline. In effect, the article describes in detail what the various Occupy movements have long suspected but never knew how the rip-off was executed.

You can read more on Denning's blog here, where he does wonder why the thing was published on page 124, and has a few other issues with HBR's thinking. Steve is the author of Radical Management, and is teaching a course on the thought and practice of it in D.C. on March 19-20.

Force Yourself To Be Better: Strengthen Your Sprint Retrospective

2012-02-28T15:15:00.001-05:00

Here at Scrum Inc. we've been thinking a lot about two things: impediments and the Sprint Retrospective. These are really where the rubber meets the road in terms of improving productivity. We'll have a later post on impediments, but I wanted to share this excerpt from Jeff's and Ken Schwaber's forthcoming book "Software in 30 Days," which comes out May 1st. We emailed it around our team yesterday after our retrospective just didn't feel strong enough. It is a good reminder that the Sprint Retrospective can be one of the more difficult things to do in Scrum, but also one of the most powerful.

Every member of the Scrum team strives to improve, Sprint by Sprint. The Sprint Retrospective is where the improvements are formulated. This meeting should be a natural break between Sprints, the Sprint Retrospective is when the Scrum team sits back, reviews what happened during the last prior Sprint, and formulates ways to improve their work and the way the work is conducted. The discussion might include:

Whether or not the team members worked together well or not and why.
Whether the team did more or less than it forecast and why.
Whether the team has all the skills and facilities it needs to do the job.
Whether or not the developers understood the requirements and why.
Whether the team was able to complete the Sprint in line with the requirements, and, if not, why not?
What could be improved or dropped in the next increment of functionality.

Next, the team identifies several things to do differently in the upcoming Sprint that will increase creativity, effectiveness, and productivity. In general, Scrum Teams continually improve. This is the Scrum Team’s chance to make its work and life better. New requirements often arise during the Sprint; new opportunities and challenges also arise. Often, just seeing the increment of functionality evokes new ideas.

Jeff will be talking about this at length at his next Scrum Master course in Boston on March 29-30.

The Dangers of Not Being Done, Or Ready For That Matter

2012-02-24T09:21:00.001-05:00

On March 8, Jeff will be giving a webinar hosted by SmartBear software. As we put together the presentation, one of the re-current themes of good Scrum came up. Getting stories ready, and getting things done. We've also been working on a new book we're calling "The Scrum Handbook: Everything You Need To Know To Get Started With Scrum," and we thought we'd share a bit of Chapter 4 that focuses on being ready, and getting to done.

Ready, Ready to Done, Done

I want to re-iterate is the importance of being ready and getting to done. When stories are developed and groomed they need to be ready to implement before the Sprint begins. The Product Owner should work with the team ahead of time to make sure that the stories are ready to be implemented by the team. They should be clear, concise, and most importantly actionable. A good Product Owner should have enough stories in that state to fill up the next two sprints. Both the Team and the Product Owner should spend 5-10% of their time in preparing stories for future Sprints.

Here’s what happens if stories aren’t ready. The Team is estimating and forecasting that they can finish vague and incomplete stories. They waste time and energy trying to get clarity from the Product Owner on exactly what the story means. People get frustrated and annoyed and run around in circles rather than getting down to work. Or that one vague story actually turns out to be five real stories once the work is actually begun. Or they work on the wrong thing, or the right thing in the wrong way, forcing the work to be re-done. The stories at the top of the ordered Product Backlog, the stories the Team will be pulling into the next Sprint, have to be ready. Some companies actually require a detailed checklist to determine whether a story is “ready ready” not just kind of ready, or sort of ready. Simply getting your stories ready will have immediate, dramatic impact on the Team’s productivity. But notice, while the Product Owner is responsible for putting the features and stories in the backlog, the Team must work with the Product Owner to help him or her to get the stories into actionable shape. Because only then will the Team be able to estimate how much work any one story will take, and how many stories they can take into a Sprint.

The Dangers of Not Being Done

And that leads me to what done is. I wrote extensively in the last chapter about the importance of a definition of done. I want to re-emphasize it here. If some people think the work is done at the end of the Sprint, but it really isn’t done, people are going to have to go back and re-do that work. We know that if you have to do the re-work it will take you at least twice as long to do it, and we’ve seen it take as much as twenty-four times as long. This type of waste is called technical debt in the software business. It’s the stuff that isn’t done that has to be done before you can ship your product. If you don’t get it done in the first place, when you were working on it to begin with, it will pile up and pile up, until there is no way the team can get that amount of work done before the planned release date. Managers force people to go on death marches, the quality of the software slips, people get sick and depressed from the pressure, the date slips, the product that is eventually released is bad, and the customers are irate. This leads to the company failing and you losing your job, your children going hungry and a destructive spiral into the darkest depths of the human condition. Don’t do it, get stuff done.

Remember Jeff's latest book, "The Power of Scrum," is available in hardcover and electronically at Amazon.com.

The Maxwell Curve: Getting more production by working less!

2012-02-14T05:15:00.000-05:00

Recently I was coaching teams at OpenView Venture Partners and Scott Maxwell, the founding partner, jumped up and said, “Jeff, I want to show you the Maxwell Curve! Here is what we have learned by running Scrum internally with teams of venture capitalists making investments.”

“As venture capitalists we used to want people to work harder and harder to get more productivity, certainly more than 40 hours a week. We would push them and push them until they started to burn out, get demoralized, and threaten to quit.”

“Now it is different with Scrum. In order to double our productivity we need to work less, certainly no more than 40 hours a week. Scrum is intense and you cannot work extra hours at that pace without losing productivity.”

The VCs proved to themselves that sustainable pace works. The maximum productivity point is no more than 40 hours a week with Scrum.

The head of OpenView Labs that supports our investment portfolio companies recently told me he was concerned. Productivity had stayed about the same when they cut their 60 hour weeks to 40 hour weeks. He felt guilty they hadn’t doubled productivity although he was happy with a major improvement in lifestyle for him and his team.

He asked me to do a retrospective with his team to see what they could do to improve. I found out that the number of story points was up 20% by moving the work week to a sustainable pace. However, 25-35% of the stories they used to work on were eliminated by prioritizing the Scrum Product Backlog (they were considered “junk” stories). This meant that they used to have to do about 160 story points to achieve the 120 story points per week they do today.

So their velocity is 160% higher by working a shorter work week. The big question for them is, “Would velocity increase if they worked less?”

Enabling Specifications: The Key to Building Agile Systems

2012-02-11T13:18:00.000-05:00

Previously, I discussed the notion of "Agile Requirements" and this concept is embedded in the Nokia Test. There is not a definition of Agile Requirements that is commonly agreed upon, so I now use a standard concept that is better terminology for what is needed. I've been thinking about this a lot recently and will be stressing it at my Scrum Master course in Boston Mar. 29-30.

For many applications, particularly web applications, a story only needs notes and acceptance tests on a card or sticky note. For some applications, like mobile applications for physicians, unless a fully formed prototype is acceptable to a carefully selected group of test physicians, end users will refuse to use the application when it is installed in the hospital setting. Therefore, a fully formed enabling specification, with a fully working prototype, needs to be agreed upon before cutting a line of code.

Apple uses this routinely which is "Why You Can't Innovate Like Apple." PatientKeeper used this strategy during 2003-2008 which is one of the reasons they were the fastest company-wide set of Scrum teams I have ever seen. I called them "The Future of Scrum" at Agile 2005. Some people said PatientKeeper looked more like Kanban than Scrum so they were also the fastest Kanban teams ever seen. I have always run Kanban inside of Scrum since 1993 since Scrum is Takeuchi and Nonaka's view of lean teams. However, we tried to minimize the Kanban, just as Taiichi Ono did and as Toyota does today.

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

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

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

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

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

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

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

A user story contains a template, notes, acceptance tests, and implies a conversation with the Product Owner. So the conversation may be part of the enabling specification if the conversation is clear before the beginning of a sprint. This can be on a card for a simple application and will be on the order of no more than 3-5 pages even for a complicated mission-critical and life-threatening application like the PatientKeeper Platform.

As the lawyers pointed out, an enabling specification for a major feature needs to be no more than five pages. So all of the documentation needed, including transcribing all the conversations, should be on the order of 3-5 pages for a moderately large feature. This is what I mean by "Agile Specification." I now think "Enabling Specification" is better terminology.

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

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

Be sure to sign up for Jeff Sutherland's Certified Scrum Master course in Boston Mar. 29-30. Jeff will be talking more about specifications and some of his other latest thinking on implementing and practicing Scrum.

Scrum Assessment Checklist

2012-02-10T06:19:00.001-05:00

Several people have asked me for the Scrum Checklist we have used for years, created by Henrik Kniberg at Crisp in Stockholm. The earlier version was a mindmap. The current version is a checklist.

I've used it for assessment in OpenView Venture Partners portfolio companies by asking teams to evaluate themselves on each item on a scale of 1 to 10. I've found that our teams are very honest about their current capabilities and the results very useful.

We will be talking about this at the Certified ScrumMaster course in Los Angeles.

Release Duration and Enterprise Agility

2012-02-03T12:57:00.000-05:00

You ever wonder why your cellphone Apps seem like they have a new version every day or two? Dan Greening doesn't have to wonder, he knows why, they make better products, faster. - jj

Short release duration—the time from starting development on a feature set until it is tested for value, for example when customers pay for an upgrade—is an implied goal of agile methods and lean product management. Short release durations help companies test market theories to maximize profit, identify and mitigate deployment and usability problems, exercise the entire value chain of internal processes, and diagnose accumulating technical debt.

Attempting to reduce release duration may help drive agile behavior through a company. Shorter release durations motivate automated testing, high-availability architectures and streamlined configuration and deployment.

As an added bonus, release duration can be easy to compute: Finance departments often collect relevant data to satisfy capitalization and depreciation rules.

Citrix Online release duration history

After Citrix Online adopted Scrum [suth2011] and Enterprise Scrum [gree2010], release duration dropped from an average of over 35 months to less than 4 months, better than what it had as a small startup. Its market share rose during the same period. Data from another company, PatientKeeper, also seems to indicate that short release durations correlate with more profitable outcomes.

On February 7, 2012 at 11:00am EST, Scrum.org will host a webcast where I will explain how to measure release duration, how different forms of technical debt cause release duration to increase, and how limiting release duration can motivate paying down technical debt. Click here to register for the webcast.

On February 27 and 28th, 2012 in Los Angeles, Jeff Sutherland, Scott Downey and I will be teaching techniques to help you achieve similar outcomes, at our Certified ScrumMaster course in Los Angeles, . Click here to register for the Certified ScrumMaster course.

Dan Greening is an agile management consultant, specializing in enterprise-level agility, lean product management and finance. Dan joined Citrix Online in 2007, and became its Director of Engineering Productivity and User Experience from 2008 to 2011. He developed an agile portfolio management process. Dan co-founded several startups. He has been Principal Investigator on three National Science Foundation SBIR grants. He holds a Ph.D. in computer science from UCLA. Dan can be reached at dan@greening.org.

References

[gree2010]: Daniel Greening, “Enterprise Scrum: Scaling Scrum to the Enterprise Level,” 2010 43rd Hawaii International Conference on System Sciences (HICSS), Koloa, Kauai, Hawaii January 5-8, ISBN: 978-0-7695-3869-3 (10 pages)
[suth2011]: Jeffrey V Sutherland, D. M. van Solingen and Eelco Rustenberg, The Power of Scrum, CreateSpace (2011), ISBN 978-1463578060.

The Importance of the Product Owner

2012-02-03T09:33:00.000-05:00

Scrum Inc.'s Christine Hegarty wrote this today, just before she went on vacation, of course, so I'm posting it for her - jj

Here at Scrum Inc. we've been thinking a lot about the role of Product Owner recently. It's something that we see a lot of companies struggle with. It’s common knowledge in the Scrum world that a good Product Owner will increase revenue by keeping the backlog ordered so that we are producing the higher value sooner. But just how they accomplish that isn't always clear. So we decided to offer the definitive Product Owner classes to help educate Product Owners on how they can increase business value and revenue. I've been working with Catherine Louis, CST, to launch our first Boston-area CSPO this month. At the beginning of March, Jeff will be teaching the Product Owner course he has developed in Los Angeles.

In building the class, Catherine and I have spent a lot of time discussing the importance of the role to a great Scrum implementation. The following passages reflect some of our conversations about the role of the Product Owner and I thought they would be interesting for the community to talk about.

Q: What is it that makes the Product Owner (PO) role particularly challenging?

A: The PO is the person who can answer this question: "Is this the right thing to do for the customer?" That's a tough job! The PO is someone who is market facing: he's able to craft and relay a vision. The PO is someone very close to the customer; the PO is the owner of a Product Backlog and focused on bringing value (and "delight!") back to the customer. He is also responsible for keeping a Product Backlog ordered such that the items at the top of the backlog are sized appropriately for the team to begin working on, and are ready to be taken in for the first Sprint.

This is a role that can't be done alone: the PO is considered part of the team, and may need to have many stakeholders assisting in ordering the backlog, making sure we're taking into consideration the Pareto factor: i.e., the top 20% of the backlog should contain the highest value.

Q: What are some of the key pitfalls?

A: Typically we meet new POs moving from a culture of traditional batch/phased development, dealing with larger and specialized teams, with a goal of upfront perfection and "requirements sign-off".

In traditional/waterfall development, the churn of requirements is discouraged, and there is a perfect plan and associated goal to deliver value at the end of a Release. We cannot discount the massive cultural change needed to manage a Product Backlog that is emergent. We want to see a flow of value, customer collaboration, self-organized smaller and integrated teams, with value driven incrementally.

The cultural shift is one that moves us from crafting a fail-safe plan we want to execute and deliver at the end of a release, to a "safe to fail" framework where we learn and improve each iteration. Making this cultural shift allows us to turn this expected requirements churn into our competitive advantage.

Q: So this cultural shift involves a lot more people than just the Scrum Team, including the Product Owner...

A: The PO is key to the transition to Agile, but because it is a change of mindset for the whole organization, and a lot of players need to be involved from the beginning, roles not normally thought of as Scrum roles. Supporting roles in particular, should not be forgotten.

Take HR for example. We're now formed in self-organizing, self-motivated and self-managed teams, and the reward structure needs to be updated to acknowledge and reward team performance. Imagine what might happen if that doesn't change. Take Project Management: We're now formed in these same teams, yet there is a Project Manager who is acting accountable for results asking for daily status reports in weekly meetings.

In making a decision to move from traditional/waterfall product development to Lean/Agile/Scrum, I recommend looking at everyone who is involved from initial decision, to delivery of value to the customer. Do not forget the cadre of supporting roles who need to be there as Servant Leaders to remove impediments, clear the path, and support the flow of value (the deliverables) to the customer. Everyone needs to be on this page: For every decision you make, every day, ask yourselves "Is this the right thing to do for the customer?" If the answer is "no", then don't do it. If the answer is "yes", say "hell yes!" and do it right away. If the answer is "I don't know", take the decision to the Product Owner.

Catherine's Boston Product Owner Course will be held on Feb. 14-15 in Boston. Jeff Sutherland's Product Owner Course, for those of you on the West Coast, will be in Los Angeles Mar. 1-2.

The Power of Scrum

2012-02-02T14:46:00.000-05:00

Please read before ScrumMaster and Product Owner courses in Los Angeles and Boston in February.

Book Description

The Power of Scrum tells the inspiring story of Mark Resting, CTO of a software company struggling with a major client and a project with more problems than solutions and a marriage in crisis. But, when he meets Jerry, a West-coast expert in Scrum, light at the end of the tunnel begins to appear, Mark begins to reluctantly hope things will work out. The road is bumpy, but Jerry skillfully brings Mark’s developers from a world of project crisis into a revolutionary approach that can save the day. Authors Jeff Sutherland, Rini van Solinger, and Eelco Rustenburg have written a fictional narrative that masterfully weaves a compelling human story around the teaching moments of a software, project management how-to, and in the process tell an engaging story of personal growth and triumph, while demonstrating the power of a revolutionary and mission-critical approach to project management. The Power of Scrum is a must read for project managers, software developers, and product developers, as well as for anyone who loves a great story well told. More ...