Scrum Log Jeff Sutherland

Scaling Scrum - What People Are Not Talking About!

2014-08-05T10:42:00.002-04:00

Me and Dean Leffingwell with a copy of my new book

There was a lot of talk about scaling Scrum at Agile 2014. Here's a photo of Dean Leffingwell, creator of the Scaling Agile Framework aka SAFe, and me. People have a lot of opinions about scaling frameworks. Some love them. Some hate them. Alex Brown and I presented a way to think about scaling that would apply to any framework (or lack thereof).

The interest in scaling shows that Scrum is not just about pilot projects any more. It is implemented widely across companies and managers need to start dealing with it as their major responsibility - making their company agile. So they want to know all the details about what they need to do. And they keep on wanting to add things to Scrum to make it more agile. When I ask them "How is that working for you?" they tell me how hard it is to implement Scrum.

What is most interesting to me is what they don't talk about. Scaling Scrum means getting rid of stuff because everything in Scrum is just in time and just enough. Here are a few things that companies are getting rid of.

1. Microsoft is getting rid of test teams

Scrum means you deliver working software in short intervals. That means all testing is completed as part of development so you have shippable code. If testing slides out of a sprint and is done later we have found in the U.S. and Europe that for complex products it takes 24 times as long to test outside a sprint as inside a sprint. And the best companies today are doing continuous deployment, something we started at PatientKeeper a decade ago. Ancestry.com delivers 220 releases to production every two week sprint. Hubspot does 170 live production updates on a slow day. Google has 15,000 developers working on one code branch and runs 75 million automated tests a day. Even Microsoft has a 3000 person Scrum that delivers a production release of all development tool products at the end of every three-week sprint. Testing is core Scrum in these companies.

2. Spotify got rid of DevOps and dependencies between teams

Operations was slowing deployment so Spotify decided to have the teams do all deployment. All teams upgrade their component of the live system at the end of every sprint. And now they are moving to continuous deployment. They still have agile operations teams that provide tools and advice while staying out of the way.

In order to deploy faster, Spotify got rid of dependencies between teams so that they could be as autonomous as possible. Remaining dependencies they identify and manage carefully.

3. Systematic got rid of management meetings

A CMMI 5 company, Systematic delivers Scrum projects at half the cost of their waterfall projects. Customers have a choice. But Systematic is Scrum top to bottom with almost 2000 people, including the senior management team. At the beginning of last year, their senior management Scrum did a cost benefit analysis of all their meetings, which showed that only the standard Scrum meetings had a value which exceeded the cost. So they banned all meetings that were not Scrum meetings.

--

This is just the beginning of stuff to get rid of because any extra weight slows you down and increases cost. That's why, as a former fighter pilot, I really like the Saab Gripen. Every six months they use Scrum to build a new release of the jet aircraft operating system with new hardware that makes it faster, cheaper, lighter, more efficient, more powerful, with better electronics and more sophisticated targeting. Aviation week calls it the best aircraft in the world and Janes Defense Weekly calls it the cheapest aircraft in the world.

Getting lean is always the hard part. To get there, the best book I've read for agile managers is Musashi's Book of Five Rings - how the world's best swordsman won every fight he ever fought. A close second is Certain to Win: The Strategy of John Boyd, Applied to Business. Boyd was the world's greatest fighter pilot who won every battle in under 40 seconds. Scrum Inc.'s Alex Brown also has an in-depth workshop on Agile leadership.

Agile means faster, better, cheaper, cooler. So throw that old ballast off the boat when scaling and turn Scrum from slow, hard, and painful into fast, easy, and fun!

-- Jeff Sutherland

Agile Means Get Rid of Test Teams!

2014-07-22T21:07:00.001-04:00

Microsoft got agile years ago in tools development. You can read about that in Agile Software Development with Visual Studio where they describe how 3000 developers cut their bugs from 30,000 down to 3,000. They now deliver a new release of all development tools every three week sprint and bugs are down 90% because they got rid of test teams. Testing becomes part of the development process. It is not something you do at the end with a separate team. Both Ken Schwaber and I were consultants on that project.

The next problem is Windows. At Agile 2013 last summer, Microsoft reported on a companywide initiative to get agile. 85% of every development dollar was spent on fixing bugs in the nonagile groups of over 20,000 developers. To fix that requires a major reorganization at Microsoft. And the Wall Street Journal is reporting on how it is going down.
---

Microsoft Plots ‘Agile’ Development Course as Talk on Job Cuts Loom

By
CLINT BOULTON

Reporter, Wall Street Journal

Microsoft Corp. CEO Satya Nadella is preaching a more nimble approach to building software as part of the company’s transformation to “reinvent productivity” in a “mobile-first and cloud-first world.” The effort, known as agile software development, is designed to lower costs and hone operations as the company focuses on building cloud and mobile software, say analysts. Microsoft’s new approach may also make redundant certain app development positions, a result that could prove beneficial should reports on upcoming job cuts, which could top 5,800 positions and be the largest in the software giant’s history, prove to be true.

: Jin Lee/Bloomberg; Satya Nadella, chief executive officer of Microsoft Corp.

Following a July 10 memo in which he promised to “develop leaner business processes,” Mr. Nadella told Bloomberg Thursday that it makes more sense to have developers test and fix bugs instead of a separate team of testers to build cloud software. Such an approach, a departure from the company’s traditional practice of dividing engineering teams comprised of program managers, developers and testers, would make Microsoft more efficient, enabling it to cut costs while building software faster, experts say. Read more ...

Key Books on Innovation - Updating My Library

2014-06-25T10:43:00.001-04:00

Before starting Scrum in 1993, I was involved in multiple technology companies, as well as a non-profit in California led by successful founders of start-ups. We studied carefully several editions of Everett Rogers, "Diffusion of Innovations," and I just downloaded the fifth edition on my Kindle to read again. I was a fan of Joseph Schumpeter's, "Capitalism, Socialism, and Democracy," and even wrote a paper competing for the Schumpeter Prize during my time working with artificial intelligence in MIT Technology Square, the home of the original "Hackers." When I proposed the paper for publication in the Harvard Business Review at a Beacon Hill cocktail party, the editor of this illustrious journal was so offended he refused to talk with me. But those were the days before the internet and even HBR changed after publication of Clayton Christensen's, "The Innovator's Dilemma."

Recently, I watched a fascinating interview with Marc Andreesen at Stanford Business School where he mentioned a book he felt was equally important with Christensen's work. Carlota Perez's "Technological Revolutions and Financial Capital" is basic reading for any technology investor and updates Schumpeter's ideas to the internet era. The book holds that the sequence technological revolution-financial bubble-collapse-golden age-political unrest recurs about every half century.

We are in the golden age of the information technology era with political unrest starting to bubble up. And in my latest book "Scrum: The Art of Doing Twice the Work in Half the Time" we describe how Scrum was used by National Public Radio for their award winning work on the Egyptian Revolution. One of my colleagues sent me a note last week suggesting that some of the Arabs he trained in Scrum might have used it to engineer the Arab Spring. But I digress ... My work on the Schumpeter paper illustrates how innovations take about 20 years to mature, whether it is eyeglasses in the 11th century or TV in the 20th century. So we knew it would take about 20 years for Scrum to revolutionize our way of working. We thought it was for software but now, everything is becoming software. See the Wall Street Journal interview with Marc Andreesen where he describes how "software is eating the world!" (subscription required)

We are even going mainstream in HBO's hilarious new TV series, "Silicon Valley," where the Googles of the world are competing with little start-ups (and losing) each using Scrum as a competitive weapon. It will be interesting to ride the wave as this 50 year technology cycle unfolds.

Recording the Audio Version of the New Book

2014-06-22T21:39:00.004-04:00

The last page of Scrum: The Art of Doing Twice the Work in Half the Time read for the audio version. It took three days of reading to get here:

Pre order now! Available 9/30 from Crown Business.

amazon | bn | itunes

How Management Can Help Team Performance

2014-06-17T02:45:00.002-04:00

Withdrawal of Team Autonomy During Concurrent Engineering

Donald Gerwin
School of Business and Department of Systems and Computer Engineering, Carleton University, Ottawa, Ontario, Canada K1S 5B6,

Linda Moffat
School of Business and Department of Systems and Computer Engineering, Carleton University, Ottawa, Ontario, Canada K1S 5B6,

Permalink: http://dx.doi.org/10.1287/mnsc.43.9.1275

Published Online: September 1, 1997

Page Range: 1275 - 1287

Abstract

Team autonomy is an essential characteristic of cross-functional teams engaged in concurrent engineering. At the same time it is a characteristic that North American firms have considerable difficulty in successfully implementing. Delegating a good deal of decision making to teams is often counteracted by processes that during a new product program withdraw some of a team's autonomy or discretion. Data from 53 cross-functional product development teams in 14 firms indicated that withdrawing autonomy is negatively correlated with both task and process aspects of team performance. The determinants of withdrawing discretion include lack of a shared understanding of the development process, environmental change, and lack of managerial “buy-in” to team autonomy. Consequently, successful implementation of team autonomy, through mitigating withdrawal of discretion, requires a clear well-communicated model of the development process, a freezing of design revisions, and policies that encourage managers to support the team rather than interfere in its decision making.

Latest News on DOD Goes Agile

2014-04-21T10:18:00.000-04:00

Since I briefed the Coordinating Task Force at the Pentagon on how to report back to the Congress on progess, we've talked a lot about how the US Department of Defense (DoD) is going Agile. We've also shared some ideas on how to do it from SEI. Here is some real concrete guidance about how to do it from the DoD.

We've also been corresponding with four-star General Barry McCaffrey, my former classmate at West Point. He was very clear in his comments on our new book, Scrum: The Art of Doing Twice the Work in Half the Time.

“Scrum is mandatory reading for any leader, whether they’re leading troops on the battlefield or in the marketplace. The challenges of today’s world don’t permit the luxury of slow, inefficient work. Success requires tremendous speed, enormous productivity, and an unwavering commitment to achieving results. In other words success requires Scrum.”

In the process of writing our online course Agile Defense we read with great interest the Interim DoD Instruction 5000.02. This document shows at least one way the DoD is thinking about doing, Agile development in software.

Here are their two models of software acquisition. The first reflects a certain amount of waterfall thinking:

"Figure 4 is a model of a program that is dominated by the need to develop a complex, usually defense unique, software program that will not be deployed until several software builds have been completed. The central feature of this model is the planned software builds – a series of testable, integrated subsets of the overall capability – which together with clearly defined decision criteria, ensure adequate progress is being made before fully committing to subsequent builds."

Here's a new, more Agile model of deployment:

"This model is distinguished from the previous model by the rapid delivery of capability through several limited fieldings in lieu of single Milestones B and C and a single full deployment. Each limited fielding results from a specific build, and provides the user with mature and tested sub-elements of the overall capability. Several builds and fieldings will typically be necessary to satisfy approved requirements for an increment of capability. The identification and development of technical solutions necessary for follow-on capabilities have some degree of concurrency, allowing subsequent increments to be initiated and executed more rapidly."

The new model moves the DOD closer to the second value in the Agile Manifesto - working product over comprehensive documentation. They may not meet the Agile Manifesto principle of delivering product increments in a few weeks to a few months. Yet it is a definite step forward.

At the Pentagon I emphasized that DOD purchasing should require "Change for Free" in all their contracts as it could save them hundreds of billions of dollar a year. The F-35 contract alone is $143B dollars over budget mainly due to software testing!

Sign up for our online course next Wednesday from 11-12 for more on how Scrum, Agile, and the military work together.

Leadership Dashboards: Post 2

2014-04-17T14:39:00.000-04:00

This is the second post in a series about creating effective leadership dashboards. You can catch the first post in the series on the goals of an effective agile dashboard here.

This post focuses on how to organize the creation of a great dashboard. How the dashboard is created is often overlooked in favor of diving directly into what metrics to include, and the look and feel of a complete dashboard; but being deliberate in the process can dramatically improve the finished product and prevent the alarmingly frequent incidents of total failure. For example, a client I am currently supporting in dashboard creation had previously worked with a large accounting firm to create an executive dashboard for their development group…six months and hundreds of thousands of dollars later, the project was cancelled without the leaders ever having seen a single working metric!

There are three main pillars for how to create a successful leadership dashboard:

Use Scrum to develop the dashboard
Develop a prioritized backlog of metrics and deliver incrementally
Leverage an “interactive” interface and drill down hierarchy

Use Scrum

It should come as no surprise that I recommend using a Scrum team to develop and deploy the leadership dashboard. (After all, we use it for everything here at Scrum Inc.) But interestingly enough, when most companies embark on developing a dashboard, they tend to treat it like an internal side project and not give it the full focus, attention and agile discipline that they apply to their customer-facing work. With unclear roles and objectives, and competing with a dozen other projects for employee attention these informal efforts often go nowhere.

If you are serious about developing a useful dashboard, designate a dedicated and cross-functional team to build it. Maintain the discipline of working off a backlog of metrics to deploy and identify a product owner to incorporate user feedback. Leverage the structure provided by a regular sprint cadence with demo and retrospective meetings. It may feel like a lot of overhead, but you will be glad you made the investment when enjoying your completed dashboard.

Deliver Incrementally

What caused the failed dashboard effort mentioned above, and countless others before it, was the attempt to deliver a working dashboard in a single “big bang.” The hallmarks of this approach are to “mock up” the look and feel of all of the metrics in a dashboard, get buy in from leadership on that design, then build the dashboard. Unfortunately, this waterfall approach is no more effective for dashboard creation than it is for software development, and for exactly the same reasons: 1) leadership doesn’t really know what they need to see to make effective decisions until they see it, leading to a “moving target” that can consume years of back and forth mock-up revision; 2) too often, teams agree on a mock-up only to discover that it is impossible to pull the data required to make it a reality; and 3) company data and systems are complex and interdependent…small changes to one element of the dashboard have ripple effects throughout the tool, making after the fact changes a nightmare.

Fortunately, dashboards lend themselves extremely well to iterative and incremental delivery. Each combination of metric and business unit within the company is a useful feature that can be delivered and refined independent of the other metrics. Integration, summary views and second-order metrics can then be layered on. A savvy product owner in dialogue with the dashboard’s end users can easily prioritize which metrics and which business units are of greatest concern and prioritize the backlog of metrics appropriately to deliver the greatest value as early as possible. Ensuring that there is an easy way for users to provide feedback within the first iteration of the dashboard makes this process even more straightforward.

The biggest challenge here is to set appropriate expectations with leaders in advance about what incremental development looks like and get a commitment to providing feedback. They might be resistant at first to a partially completed product or the effort of feedback, but it is imperative that they provide actionable guidance to produce an effective dashboard. “It isn’t good enough yet” is a common response, but not sufficiently engaged and actionable to help the team.

In the past, I have positioned the value proposition for incremental delivery as, “The initial version will be rough, and I can almost guarantee that you won’t like it; however: you will have something in your hands within x days, it will be REAL data that will improve your visibility over what you have now, and we will implement any actionable feedback you have over the subsequent iterations to make the dashboard exactly what you want it to be.” This usually works, though it is worth getting agreement in writing for the inevitable retrenchment later.

Leverage an Interactive Tool

The default expectation in the business world is that a dashboard is a single page or PowerPoint file that contains summary metrics and can be transported around for easy reference. While this is fine in practice, the advent of cloud computing and ubiquity of mobile devices have opened up significant new possibilities for interactive metrics reporting. Here again, a little up front expectation setting is essential to leveraging this potential.

A single flat dashboard can only show top-level metrics and tends to get very cluttered as more information is added. By contrast, an interactive data visualization tool like Tableau or Domo can have a clean and simple top-level design, but allow the decision-maker to click-down into disaggregated views as needed (stay tuned for more detail on tools in a future post). It provides more data, but gives the user control over how much detail to show. The data can be updated at different cadences or even in real time, rather than a single monthly update to a PowerPoint slide. Finally, with dashboards fed to mobile apps, the information is even more readily available than the printed dashboard page.

That said, remember that the dashboard’s ultimate purpose is to help leaders make decisions, so particularly in the early iterations it may be helpful to build a dashboard that looks familiar and comfortable to leadership. Having built credibility in the process and team, you can then flex your interactive muscles and deliver value-adding capabilities.

In the next post, we will cover what information leaders typically want updates on a regular basis, and how to achieve those objective with compelling agile metrics. If you want a sneak peek at some of these metrics, they are covered in our online course on The Scrum Leader’s Dashboard.

AlexBrown is Scrum Inc’s Chief Product Owner and Chief Operating Officer. He set up the company’s internal metrics dashboard to automatically consolidate and share agile metrics and support better decision-making. He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.

Yet Another $163B Waterfall Disaster

2014-04-10T09:28:00.003-04:00

The F-35 Is Worse Than HealthCare.gov

Vocative.com - Eric Markowitz, 25 Mar 2014

The $400 billion jet project is the most expensive weapon the Pentagon has ever purchased. It's also seven years behind schedule and $163 billion over budget ...

And here’s the kicker: According to a 41-page Government Accountability Office (GAO) report released yesterday, the F-35, which has yet to fly a single official mission, will stay grounded for at least another 13 months because of “problems completing software testing.”

What GAO Found

Delays in developmental flight testing of the F-35’s critical software may hinder delivery of the warfighting capabilities the military services expect. F-35 developmental flight testing comprises two key areas: mission systems and flight sciences. Mission systems testing verifies that the software-intensive systems that provide critical warfighting capabilities function properly and meet requirements, while flight sciences testing verifies the aircraft’s basic flying capabilities. Challenges in development and testing of mission systems software continued through 2013, due largely to delays in software delivery, limited capability in the software when delivered, and the need to fix problems and retest multiple software versions. The Director of Operational Test and Evaluation (DOT&E) predicts delivery of warfighting capabilities could be delayed by as much as 13 months.

Happiness Metric - The Wave of the Future

2014-04-08T10:27:00.000-04:00

The Happiness Online Course archive is available.

... any investor should be able to measure its return, and now a group of U.K. researchers say they've provided the first scientifically-controlled evidence of the link between human happiness and productivity: Happier people are about 12% more productive, the study found.

The results, to be published in the Journal of Labor Economics, are based on four different experiments that employed a variety of tactics on a total of 713 subjects at an elite British university. See article ...

_________

ScrumInc used the happiness metric to help increase velocity over 500% in 2011. Net revenue doubled. The way to do this is now part of a formal pattern at ScrumPlop.org called "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

Six Signs your Team’s Acceleration is Too Good to be True

2014-04-08T05:00:00.000-04:00

Let me say right from the beginning that I am a huge fan of tracking velocity in Scrum…it is an amazingly powerful concept.

The ability to measure team output from sprint to sprint allows a team to systematically experiment with different process improvements and consistently get better over time.
A clear sense of how much output the team actually produces within a sprint also drives better decision-making about when to expect project completion without slave-driving the team developing it.
As an agile leader, I like to know whether my teams are accelerating, decelerating or staying stable over time. If they are accelerating, it gives me confidence that our projected completion dates are relatively safe; whereas if they are stable or decelerating, it implies greater risk in current projections.

But metrics are only as good as the integrity of the data that feed them. The traits that makes estimating velocity in points so powerful (speed, ease for the teams, intuitive accuracy of estimation) also mean that, in the wrong conditions, velocity can be manipulated to produce misleading conclusions. To be clear, this is not the terrible scourge that proponents of measuring in hours often claim it is…a few simple guidelines such as “NEVER tie incentives to velocity” and “don’t use declining velocity as a reason to beat up your teams” generally suffice to eliminate any deliberate gaming of the system.

However, seeing velocity increase over time just feels good and teams often thrive on the sense of accomplishment that comes from getting more done in less time. Even without overt pressure to increase velocity, the collective will to go faster can create upward velocity drift that isn’t necessarily driven by increases in underlying output. Since only the team suffering from velocity drift is impacted, this need not be a major problem. But for Scrum Masters, Product Owners and teams concerned with maintaining the integrity of their velocity metric, I humbly offer…

The 6 signs that your beautiful velocity growth trajectory may just be bad data:

Velocity always increases – Even the highest-performing Scrum teams suffer setbacks or encounter new impediments. In general, scrum teams that set challenging goals should expect to fail about 20% of their sprints, meaning that velocity should decline from the previous sprint about the same percent of time (if you are using “yesterday’s weather” to pull stories into the sprint). If your team has been through a dozen sprints without a single backslide in velocity, it suggests that stately upward trend is being managed more deliberately than it should.
Inexplicable Acceleration – Velocity can go up in short bursts for no particular reason, but it is difficult to sustain structural velocity improvement without systematically removing team impediments. So if a team’s velocity has been increasing consistently but they can’t point to specific impediments that they have removed, that is a red flag that the acceleration may not be real. At best, the team is not conducting healthy process experiments to deliver repeatable and sustainable acceleration. At worst, they may be undermining the meaningfulness of their velocity.
The same story now receives a higher point estimation than it used to – This is the definition of “point inflation” that opponents of measuring velocity in points are always pointing to. In practice, we rarely see egregious cases of point inflation where the exact same story that was 3 points in a previous sprint is now 5 points in the current one. Instead, we typically encounter more nuanced forms of inflation, such as when an additional quality check is added to correct for past issues and points are added to complete this additional work. The amount of effort needed to complete the work may have increased, but the amount of output has not, so these added points represent a subtle form of point inflation.
Backlog stuffing with “filler stories” – Teams that are striving to increase velocity often become obsessed with ensuring that everything they do is reflected in the backlog. In general, you don’t want to do tons of off-backlog work and do want to stay focused on completing the goals of the sprint. However, some level of housekeeping and team hygiene work is a natural part of the group process. If including these items in the backlog was always a team norm…that is fine. If that wasn’t always the norm, then including these filler stories with associated points gives the false impression that the team is accelerating when it is not actually producing more output.
Lots of separate minimum-sized stories – We often say that smaller user stories are better, and that ultimately teams should strive to work with uniformly small stories in the sprint. This is a great goal, but it can be taken too far. If work is broken into many stories that are smaller than the smallest sizing increment used by the team (“xs”, “1-point”, “Chihuahua”, etc.) then the rounding error of adding all these fractional stories together starts to exert a strong upward influence on velocity. If these precisely divided stories are still good user stories reflecting incremental functionality, then it is time to reset your reference story to accommodate smaller divisions. More often than not, however, these tiny stories are really tasks and are hurting the team’s ability to work together to produce quality product.
Excessive “normalization” of velocity – Tracking team strength in each sprint is helpful for knowing the context the team is operating within. There are a number of compelling reasons to apply a lightweight level of normalization to a team’s raw velocity number to get a better predictor of actual team output: it provides a more stable measure of output in the face of major illness, vacations, family leave and other significant shifts in team capacity. However, it also introduces one more lever that can artificially increase apparent velocity, so teams need to be careful to only reserve normalization adjustments for major capacity impacts, and not try to adjust for every perceived shift in team strength. If you notice that the team has not been at full capacity for a long time, it is time to questioning if over-normalization may be occurring.

I Feel free to share your own experiences with velocity in the comments section below, or check out other musings on the value of good metrics in Scrum, including a thread on leadership dashboards here.

-Alex

Alex Brown is Scrum Inc’s Chief Product Owner and Chief Operating Officer. He set up the company’s internal metrics dashboard to automatically consolidate & share agile metrics and support better decision-making. He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.

Agile Progamming for Families

2014-04-06T04:17:00.000-04:00

New York Times columnist and author Bruce Feiler has just published a new book titled: The Secrets of Happy Families: Improve Your Mornings, Rethink Family Dinner, Fight Smarter, Go Out and Play, and Much More. The secret it turns out is applying agile development to your household.

Every week starts with a family meeting. Kids and parents self-organize and self-manage (kids even help decide on their own incentives and punishments) and every week they have a retrospective to determine what they can do better next Sprint. Turns out that kids think their parent’s stress levels can improve.

Scrum: savior of the modern American family? Watch and decide for yourself.

You can listen to an NPR review and an interview with Bruce Feiler here and here.

Wanna learn more about Agile and childhood? Click here for Scrum in schools.

-- Joel Riddle

#ScalingScrum: How Do You Manage a Backlog Across Multiple Teams?

2014-03-26T04:30:00.000-04:00

Scrum is being used for everything from massive software implementations, to cars, to rocket ships to industrial machinery. Scrum Inc.'s Chief Product Owner, Alex Brown, is in the midst of putting together a presentation on a modular way to scale scrum.

He has noticed that when projects scale-up, one of the first issues organizations must confront is how to manage a Product Backlog across multiple teams.

Some organizations work from one master backlog managed by a Chief Product Owner or a Product Owner Team. Multiple teams then pull stories from that backlog.

Other organizations have teams with individual product owners who create their own backlogs and release their own modules into a loosely coupled framework. Spotify has set up their entire organization to enable this. (They also carefully manage dependencies across teams.)

There is a whole spectrum of options between these two examples. The right answer for any company lies in their own context. If you're building something where all the modules are intimately integrated, a single, tightly managed, master backlog may work well. In a different environment, it might be faster for individual teams to continuously release improvements on their own module. There is coordination on the epic level, but Sprint-to-Sprint, their backlogs are independent from each other.

These models work for different Scrum implementations and we know there are even more ways of doing it. We would love to hear your story so we are extending an open invitation to the Agile community:

How do you manage your backlog across teams?

We want to learn how your context shapes your practice. Why do you do it that way? What kind of product are you building? How many teams do you have? And how is your method working for you?

Please post your answers in the comment section or on Jeff's Facebook page, or on Twitter if you are that concise (@jeffsutherland #ScalingScrum).

As the conversation winds down, we'll write a blog and compile the most interesting and effective techniques so we can learn from each other.

In the coming months, look forward to a Scrum Inc. online course in which Alex and Jeff present a framework for scaling Scrum. They will also share this framework at Agile 2014 in Orlando.

--Joel Riddle

Agile Leadership Dashboards: Post 1

2014-03-20T16:00:00.000-04:00

I am having lots of conversations these days about executive dashboards for Scrum…what does a leadership team really need to know in order to do their job well, and how can teams provide that information without wasting valuable of time preparing reports? Within these discussions, there are also nuances such as: what agile metrics might actually be dangerous to share with management because they can drive unintended consequences? And what metrics should or shouldn’t be linked to incentives?

With these debates as a background, I am embarking on a regular series of posts to explore the subject of agile metrics and leadership dashboards further. For this, I will be drawing specifically on experiences setting up our own dashboard at Scrum Inc. and working with a large tech client (who shall remain anonymous) to set up an agile executive reporting tool for their C-suite leadership. I welcome everyone to join in the conversation and share your own experiences, both positive and negative, in the blog comments. I will try to weave these into future posts.

To start, what are the goals of a leadership dashboard? Like a good user story, it is important to have a clear vision of the desired outcome, and a set of acceptance criteria so that you recognize success when you see it. Particularly if you are using agile to develop the dashboard incrementally, you need to know when your latest increment is “good enough.”

At the most basic level, leaders need to accomplish three objectives:

They need to establish and maintain a compelling vision that aligns the organization around a shared sense of purpose.
They need to maintain visibility of how the organization is progressing toward the realization of that vision, and make course adjustments as needed to ensure progress.
They need to support motivation and accountability within the organization.

An effective leadership dashboard directly supports the second objective, but its can also help deliver the third objective, and should be informed by the first.

To my mind, a successful dashboard should provide leaders with the relevant context and metrics they need to make informed decisions. It should be updated on a frequency that meets or exceeds the required decision-making cadence. Finally to the extent possible, the dashboard should be assembled from data that teams are already collecting to inform their own process and pulled automatically to minimize distraction from producing valuable new product.

Relevant Content

I will definitely revisit the topic of potential metrics to include in a dashboard in much more detail in future posts. For this discussion, suffice it to say that top-level metrics should answer the key questions of:

1) Are we producing the right product(s) for the customers we are trying to serve;

2) Are we prioritizing our efforts and applying our resources correctly given what we think we know about the market and our competitors;

3) Are we making consistent progress towards our strategic goals; and

4) Are we doing all of the above in a way that we can sustain for the long run?

Metrics that answer or inform these questions help leaders make better strategic decisions. Extraneous metrics are at best a distraction, and at worst cause leaders to make bad decisions.

Update Cadence

Some decisions only need to be made once a year, such as “should we renew our annual contract with…?” Others need to be made monthly, daily, or in response to real-time events, such as “how do we restore service given an outage that just occurred?” A truly great dashboard provides the current snapshot of key metrics with the most relevant data being shown. Real-time decisions need data from a few moments ago, whereas monthly financial decisions are better made with the recent month’s complete data rather than a partial view of the current month’s results. Deliberately matching update frequency to decision cadence brings the most powerful data to the right place with the least amount of effort.

Automation

We speak with far too many teams that complain about the onerous reports they are asked to produce for senior leadership. The typical complaint is that leadership wants updates on a number of metrics the team never uses for its own purposes, so this data must be gathered, calculated, and presented manually. The team sees this as a huge waste of time to produce metrics that don’t even reflect reality on the ground.

The Scrum process throws off enormous amounts of high quality data, such as velocity, team happiness, planned backlog, defect and impediment lists, and business value. Most teams already collect this data in software tools with API interfaces. Other than the first few iterations of a new dashboard where the metrics and presentation are still being refined in coordination with leadership stakeholders, there is no good reason dashboard data can’t be pulled, calculated, and presented automatically.

As I mentioned, this is just the first of many posts on this topic. If you want to dig deeper, feel free to check out our past online course on "The Agile Leader's Dashboard".

-Alex Brown

How Waterfall Led Healthcare.gov Off a Cliff

2014-03-14T15:41:00.000-04:00

....And no one noticed until it was too late. Steven Brill's recent piece cover story in Time about how a handful of Silicon

Valley engineers and experts resurrected HealthCare.gov from technical and political disaster should be a warning to politicians and policy experts everywhere: No longer can the government continue to use traditional development and contracting methods without looking incompetent. Citizens use software everyday that delights them. They now expect websites to be intuitive, well-designed and reliable.

Here are three takeaways from Time:

Make work visible!

One of the things that shocked [the rescue] team most–”among many jaw-dropping aspects of what we found,” as one put it–was that the people running HealthCare.gov had no “dashboard,” no quick way for engineers to measure what was going on at the website, such as how many people were using it, what the response times were for various click-throughs and where traffic was getting tied up. So late into the night of Oct. 18, [the team] spent about five hours coding and putting up a dashboard.

Stand-ups Work

It was in . . . a nondescript office park in Columbia, Md.–lined with giant Samsung TV monitors showing the various dashboard readings and graphs–that Barack Obama’s health care website was saved. What saved it were stand-ups.. . . The stand-up culture–identify problem, solve problem, try again–was typical of the rescue squad’s ethic.

Government contracting is broken:

But one lesson of the fall and rise of HealthCare.gov has to be that the practice of awarding high-tech, high-stakes contracts to companies whose primary skill seems to be getting those contracts rather than delivering on them has to change. “It was only when they were desperate that they turned to us,” says [team member] Mickey Dickerson. “I have no history in government contracting and no future in it … I don’t wear a suit and tie … They have no use for someone who looks and dresses like me. Maybe this will be a lesson for them. Maybe that will change.”

Things are changing at least at the Department of Defense. It is now the law that all DoD software contracts must be Agile. Many in Washington are still trying to figure out what exactly that means but it is a start. Scrum Inc. is also seeing a rush of training requests from big government defense contractors looking to get their teams certified in Scrum.

In April we're giving an on-line course that focuses on Scrum, Agile, and the DoD. We'll be talking about the latest on how the Department is changing its rules to take advantage of Scrum's ability to deliver products faster, better, and more responsive to change. Which if you're providing tools to someone in combat, is critical.

-- Joel Riddle

Call for Papers - HICSS 48

2014-03-02T11:05:00.000-05:00

HICSS is one of the top conferences in paper citation index rankings. This means papers will be seen and used by researchers worldwide more than papers from other conferences. All HICSS papers are published in the IEEE Digital Library and are FREE to download, so accepted papers are accessible to everyone for the rest of time. No other conference can give you the same distribution of your concepts and ideas. Plus it is held on the island of Kauai in January. Write, publish, vacation!

We invite you to submit abstracts and manuscripts for the Agile and Lean Organizations: Management, Metrics and Products mini-track, to be held at HICSS-48 on January 5–8, 2015 at Kauai, Hawaii. Mini-track co-chairs are Jeff Sutherland (Scrum, Inc.) and Dan Greening (Senex Rex). HICSS is an IEEE Computer Society sponsored conference. Abstract and manuscript submissions received before May 1, 2014 will receive early guidance to improve the likelihood of acceptance. Final manuscripts are due June 15, 2014.

The Hawaii International Conference on System Science provides a great mix of academics, industrialists and consultants looking at many system science applications. HICSS attendees gain inspiration from innovators in a variety of fields.

Topics
Deadlines
May 15, 2014. Early Review Deadline
June 15, 2014. Submission Deadline

Background

We seek research papers and experience reports that describe how agile development and lean product management interact with organizations, their structures, cultures and products. What evidence-based guidance can we provide to leaders to help motivate, create and sustain agile/lean organizations? How do agile development and lean product management interact and support product groups, departments and companies? How do organizations restructure to support these philosophies and when they do not restructure, what happens? What cultural requirements and/or training are needed for companies to maintain agile behavior? How do organizations implement, monitor and improve coaching, training, mentoring and Scrum Mastering? What are the important metrics, and how do companies measure and improve? How do markets respond to rapid iterations and end-user experimentation?

Submit abstracts or full manuscripts for early review and guidance to improve likelihood of acceptance, to agilelean2015@senexrex.com. Earlier submissions will gain greater attention.

Submit full manuscripts for review. Review is double blind; therefore this submission must be without author names. Follow author instructions found on http://www.hicss.hawaii.edu/hicss_48/apahome48.htm, select “Software Technology” track and “Agile and Lean Organizations” mini-track.

Agile managers structure product development as rhythmic experiments to improve production. Agile is most often applied to software development, and we expect most papers in this mini-track to discuss software development. However, we also welcome papers that describe different types of organizational “production”, such as management initiatives, manufacturing, marketing, sales and finance.

Lean product management continually seeks to reduce waste, including waste due to producing unprofitable products (recently popularized as “Lean Startup” or “Lean Entrepreneurship”). 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 and customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient use of development staff.

These approaches claim superiority in new product development over traditional approaches (such as “waterfall management”) that make early development and market assumptions in long-range plans and rarely test those assumptions prior to release.

Experimentation lies at the heart of both agile development and lean product management: they identify leading indicators of progress (velocity, reach, engagement, loyalty, revenue, etc.), consider changes to process or product, construct hypotheses, and incorporate feedback loops to confirm or invalidate the hypotheses, perform production or market experiments, and rapidly adapt to discoveries.

Agile and lean approaches challenge organizations large and small. People typically conflate small failures (learning) with large failures (organizational threats), assume that innovation means taking long-range untested risk, and establish and protect budgets with many baked-in production and market assumptions. These cultural realities interfere with agility and real innovation.

As a result, companies invest enormous amounts of money in agile transformations that can succeed, but sometimes fail. What can organizations do to improve agile uptake? How do we know that the organization is improving? How can organizations diagnose problems without motivating gaming? What types of people are more likely to thrive in agile and lean organizations, and what roles should they take? What hiring practices result in better candidates? What training programs produce better results? What coaching structures work? How do we measure these activities?

There are two agile/lean mini-tracks in HICSS-48. This mini-track focuses on organizations and product management. The other mini-track focuses on software development practices. The mini-track chairs may redirect submissions that seem more appropriately hosted in the other mini-track.

We’re looking forward to seeing your submission, and seeing you at HICSS 2015 on Kauai!

Guidance on Agile Acquisition in DOD

2014-02-25T16:09:00.000-05:00

Just got a heads up from Will Hayes who took one of our regular Certified Scrum Product Owner courses a few weeks ago. He works at the Software Engineering Institute at CMU and is the lead author of a technical note that gives guidance to acquisition professionals at the Department of Defense on how they need to change their practices to take advantage of Scrum. The note is titled: Agile Metrics- Progress Monitoring of Agile Contractors:

As the prevalence of suppliers using Agile methods grows, these professionals supporting the acquisition and maintenance of software-reliant systems are witnessing large portions of the industry moving away from so-called “traditional waterfall” life cycle processes. The existing infrastructure supporting the work of acquisition professionals has been shaped by the experience of the industry—which up until recently has tended to follow a waterfall process. The industry is finding that the methods geared toward legacy life cycle processes need to be realigned with new ways of doing business.

There is some pretty interesting stuff in the paper, one of the things that leapt out at me was this:

If the Project Management Office (PMO) is doing a request for proposal (RFP), no matter which phase, ensure that the RFP contains language that allows the use of Agile. In many instances, the traditional RFP language makes it difficult, if not impossible, to propose an Agile based solution. (emph. added)

I highlighted that line because it is critical that government acquisitions professionals change some of the ways they think about RFPs. Often, the very contract language requires waterfall. This despite other DoD rules that require Agile methods. If you are spending taxpayer dollars, you need to encourage Scrum, otherwise you're just requiring projects to cost more, take longer, and not do what you actually want them to do.

-- JJ Sutherland

Breaking News: Systematic Video After 7 Years of Scrum

2014-02-09T08:15:00.000-05:00

In 2006, I trained the first 30 Scrum Masters at Systematic in Aarhus, Denmark. As a CMMI Level 5 organization, they wanted to go lean by testing Scrum as a process improvement. Within six months Scrum cut project costs in half and reduced defects by 40% plus or minus 3% for all projects. They then introduced Scrum as their standard process and created the only Scrum CMMI Level 5 company.

In the past seven years, Scrum has improved the Systematic project success rate to 98%. This is extraordinary in a world where over 50% of agile teams cannot deliver a project on time.

Recently, I visited Systematic and we videotaped a discussion on their progress using Scrum.

For the original paper which documented Systematic transitioning to Scrum see:

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

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

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

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

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

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

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

War and Organizational Change

2014-02-06T12:31:00.000-05:00

In yet another odd intersection of the two worlds I've worked in, covering war and Agile transformation, I recently came across the Michael Horowitz book, The Diffusion of Military Power (via Tom Ricks’ excellent blog at Foreign Policy The Best Defense). Horowitz theorizes that relative military power and dominance are driven by a state’s ability to incorporate innovation. He says "adoption capacity, the combination of financial intensity and organizational capital possessed by a state, influences the way states respond to major military innovations."

Here's something that leapt out at me. Great powers are willing to spend inordinate amounts of money on innovations that don't require them to re-think what they do. But, "innovations requiring disruptive organizational transformations but relatively reasonable financial investments, like blitzkrieg...will spread haltingly.” Basically, if an innovation challenges the status quo power dynamic within an army it won’t be adopted. Even if it means the Nazi’s take Paris. Status and prestige are far more important than actually winning wars. Until you start losing them

Sound like Scrum? Here's the kicker: "New powers that master the necessary organizational changes can gain advantage over the potentially bigger though less nimble major power opponents."

That could describe Silicon Valley.

Horowitz also points out: "Information technology has generally been employed in a sustaining rather than a disruptive fashion. It has not yet led to large-scale organizational changes or major shifts in thinking about the situations in which force deployments are possible." In other words, they've adopted the tools, but not the organizational change needed to use them to their fullest potential. The forces that do so may make a modern military force as relevant as one of DEC’s minicomputers. Which is exactly the comparison he uses for the American military.

-- JJ Sutherland

#idefineagile Winner

2014-01-24T12:26:00.000-05:00

Agility, by its very nature, is hard to pin down. In many ways it shouldn’t be codified and corralled by a restrictive and reductive definition. Agile is about adaptation to a changing landscape, so really the best description is laid out in the values and principles of the Agile Manifesto.

But it’s kind of fun to try to define the undefinable. Well over a hundred people took part in the contest #idefineagile last week. Those brave souls tried to come up with a definition of Agile at tweet length, 100 characters or less.

And the entries really did reflect Agile values. The recurring ideas were words like: continuous learning, trust, respect, transparency, fun, embracing change etc.

And there were some truly great ones. Even Martin Fowler, the guy that wrote the Agile Manifesto on the white board at its creation joined in:

@jeffsutherland (People-first > process-first) + (Adaptive planning > predictive planning) #Idefineagile
— Martin Fowler (@martinfowler) January 17, 2014

Not surprisingly, that’s a pretty good one.

My favorite tweets used AGILE as an acronym. The reason I like the technique is that when I was at West Point I used a similar definition as a tool in the midst of constant demands for extreme performance along with yelling and screaming when you never measured up. Every morning at breakfast as 3000 cadets bowed their heads in moment of silence I asked only one thing. “May I do better today than I did yesterday.” That mantra helped make my Corps of Cadets company the best on the parade field and eventually produced Scrum as we know it today.

Among all the great entries, I thought Francesco Attanasio of Salerno, Italy, who goes by the twitter handle @LeanScrumMaster, slightly edged out the rest. Here is his entry:

#idefineagile A: Actively G: Gain I: Improvements L: Learning E: Everyday @jeffsutherland
— Francesco Attanasio (@LeanScrumMaster) January 21, 2014

Congratulations Francesco, you have won a three-month subscription to ScrumLab.

-- Jeff Sutherland

Can You Define Agility?

2014-01-16T15:57:00.000-05:00

Most years, just after the first of January, I fly to Hawaii and while escaping the New England winter is a bonus, my real reason is to attend the Hawaii International Conference on Systems Sciences (HICSS.) The conference is pretty broad, but one of the tracks focuses on research into Agile practices. Most years I present a paper, this year I shared some of the latest research I’ve been doing on how teams that finish early accelerate faster. Conference attendees voted it the best paper in the Agile track and nominated it for best paper overall.

A paper that grabbed my attention with its title alone is: State-of-the-Art: A Systematic Literature Review on Agile Information Systems Development. (Sorry no link yet, I’ll post it when it is made available online.) In it, Markus Hummel of Goethe University in Frankfurt takes a broad look at the entire state of play in Agile research over the past year. He delves into how many papers were published, who authored them, what subjects were covered, what research methods were used, etc. His conclusions were inconclusive, mainly because he points out a lack of academic rigor in many papers. Hummel calls the field “nascent” and concludes, “Findings of the literature are mostly based on experiences which lack empirical and theoretical support.”

But what really jumped out at me was this comment:

The definition of agility remains one of the most salient problems of agile [Information Systems Development]. A universal understanding of what constitutes ‘agility’ is not observable. Attempts of research-based taxonomies for pinpointing the concept of agility build the basis for a common definition, but most papers still rely on the Agile Manifesto that consists of unverified principles and practices of practitioners, which are not suitable as a solid theoretical grounding. The use of research-based definitions of agility should be extended in order to enable a better comparison of studies and to increase the value of research on agile ISD.

Basically, he’s saying it’s hard to assess the state of Agile development methods because what it means to be Agile has never been defined! Only 45% of the papers even referred to a definition of Agile, most often the Agile Manifesto.

(Scrum was developed totally by a data driven approach and benchmarked by productivity analysis tooling at Capers Jones company, Software Productivity Research in 1993. Only when it performed 10 times better than waterfall was it released. Then we were certain that even a reasonable implementation of Scrum would double performance. It looks like I need to write a paper on this so the academics will understand better why Scrum based experience influenced the writing of the Agile Manifesto.)

Agility by its very nature is best expressed in a series of values and principles. Anything too prescriptive would defeat the purpose of being Agile in the first place. That’s the genius of the Agile Manifesto. Scrum is a way of putting those values and principals into practice. It’s the most popular way and the best way I’ve come up with. In fact, the values are based primarily on an agreement of what Scrum and XP had in common with help from thought leaders and authors of books on software technologies.

But maybe a succinct definition of Agile could help communicate its value more clearly to the rest of the world.

I have a pretty good idea of how I would define it but I’m interested in hearing what you have to say. So here’s what I propose. Either tweet to @jeffsutherland or post below in the comments section your definition of Agile. In a twitter bound world, let’s limit it to around 100 characters (leaving some room for a # and re-tweeting) and incorporate as much of the spirit of the Agile Manifesto as necessary. It should also make sense to someone who is unfamiliar with Agile practices. The person who writes the best definition will receive three months of ScrumLab Premium for free ($150 value.)

Next week on this blog I will announce the winner and offer my definition. Tweet to @jeffsutherland and use the hashtag #IdefineAgility.

-- Jeff Sutherland

Update: DoD Goes Agile

2013-11-28T10:25:00.000-05:00

Update November 2013: SEI has posted a report analysing the legal documents that require Department of Defense to use agile practices. Defense contractors that Scrum Inc. is working with propose Scrum for most new projects. See also DoD CIO comments on agile development.

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:

Based on my Scrum briefing at the Pentagon in 2011, DoD introduced this language into their requirements for vendors:

• 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 many DOD departments have not yet come to terms with Agile, 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.

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 July 26-27 course in Boston.

Give Thanks for Scrum 2013

2013-11-27T17:26:00.002-05:00

Every year just before Thanksgiving Agile Boston hosts Give Thanks for Scrum. It is the only time that the two co-creators of Scrum, Jeff Sutherland and Ken Schwaber, speak together, and answer questions.

Jeff gave the latest iteration of his talk, Scrum: The Future of Work, laying out where Scrum came from, the state of the art, and where he sees it going.

People asked for the slides and some of the patterns he discussed. They can be found on this page. You can also find some papers on Distributed Scrum, Scaling Scrum, and Scrum in Church. We hope to have the video up there soon as well.

Happy Thanksgiving!

Pioneering Multitasking Researcher Has Died

2013-11-08T11:56:00.000-05:00

One of the things we emphasize in Scrum is the toll that multi-tasking can take on productivity. Study after study shows switching from one project to another in quick succession can seriously hurt your velocity. In many companies teams are often assigned more than one project at a time. This forces them to switch between projects rather than focusing on just one, moving it to done and then starting the next.

Clifford Nass, who died at a far too young age of 55 last week, was a Stanford professor whose research showed just how counter-productive multitasking is.
From the NYT Obit:

One of his most publicized research projects was a 2009 study on multitasking. He and his colleagues presumed that people who frequently juggle computer, phone or television screens, or just different applications, would display some special skill at ignoring irrelevant information, or efficiently switching between tasks, or that they would prove to have a particularly orderly memory.

“We all bet high multitaskers were going to be stars at something,” he said in an interview with the PBS program “Frontline” after the paper he and his colleagues wrote, “Cognitive Control in Media Multitaskers,” was published in 2009.

“We were absolutely shocked,” he said. “We all lost our bets. It turns out multitaskers are terrible at every aspect of multitasking. They’re terrible at ignoring irrelevant information; they’re terrible at keeping information in their head nicely and neatly organized; and they’re terrible at switching from one task to another.”

He added, “One would think that if people were bad at multitasking, they would stop. However, when we talk with the multitaskers, they seem to think they’re great at it and seem totally unfazed and totally able to do more and more and more.”

Professor Hass' research into how people actually do things, rather than how they say do things, was a great contribution in helping us understand ourselves and the way we work.

-- JJ Sutherland

When is an Engineer Worth $10M a Year?

2013-10-19T13:52:00.000-04:00

Salesforce.com Agile Transformation - Agile 2007 Conference from Steve Greene

Chris Fry just got $10M in stock options as Twitter prepares for public stock offering. He previously drove an all-at-once transformation of SalesForce.com to Scrum which helped make it the company with the highest return on investment year-to-year for most of the last decade (see Steve Denning's article for Forbes). Guess he is probably worth the money.

I was involved in a similar transformation at Pegasystems a few years ago. 27 teams in two months vs. 30 teams in 3 months at SalesForce.com. Pegasystems stock price quadrupled during the transformation so all-at-once Scrum can be worth a bundle of cash. We wrote about the Pegasystems effort in this paper:

J. Sutherland and R. Frohman, "Hitting the Wall: What to Do When High Performing Scrum Teams Overwhelm Operations and Infrastructure," in Hawaii International Conference on Software Systems, Kauai, Hawaii, 2011.

There is a lot of talk about scaling Scrum recently. Before you adopt any approach, ask them to "show you the money!"

What the Heck is Business Value Anyways?

2013-10-18T10:38:00.001-04:00

If you use Scrum, you probably hear the term “business value” tossed around a lot. At Scrum Inc., we get asked about it all the time. Here are some of the more common questions:

“Business value seems so vague, what does it mean exactly?”
“Does lowering costs have more business value than increasing revenue?”
“What has more business value, something important or something urgent?”
“Should business value be realized only when it increases the customer’s experience?”

Simply put, business value is the lens the product owner uses to order the product backlog. It can be derived by lowering costs, increasing revenue, growing customer satisfaction, reducing risk or enhancing capability.

However, knowing the definition of business value doesn't necessary inform product owners about how it should be assigned. Assigning business value is a subjective task that includes a lot of variables. A good product owner needs to have strong business acumen, a complete understanding of the product’s vision and a good relationship with the customer and team.

Even with these elements in place, product owners struggle to get the most value out of the backlog. Why? Because it’s extremely difficult. Assigning business value requires balancing a lot of information based on a variety of changing priorities.

Jeff Sutherland and Scrum Inc. have a lot of experience helping product owners clarify some of the trade-offs involved. We have been offering Certified Product Owner Classes for a while now and do to a whole lot of demand have recently increased the number of classes we offer. Catch the next one at the end of the month. Sign up here.

And, in an effort to make some of Jeff’s experience more accessible, next week we are offering an on-line course that specifically address how to calculate business value. The class will be taught by Jeff and hosted by Scrum Inc.’s Chief Product Owner AlexBrown. Learn how we quantify the value of potential projects; calculate cost per story point and revenue per story point and how we use an array of management metrics to get the most out of our backlog.