Scrum "Shock Therapy" How To Change Teams FAST

While he was updating his paper for Scrum "Shock Therapy," Scott Downey of Rapid Scrum found one of the original emails he wrote about how he boosted dozens of teams into hyper productivity. He comments below and the full paper was published as:


J. Sutherland, S. Downey, and B. Granvik, "Shock Therapy: A Bootstrap for a Hyper-Productive Scrum" in Agile 2009, Chicago, 2009.


Jeff will be at Agile 2012 in Dallas and talking about hyperproductivity at 9:30 on Thursday, 16 August.

The Framework of Scrum provides many options for customization and interpretation for each Team. In my experience, most teams just starting out are so overwhelmed with choices and potential that they can't find a constructive way to start. I have known of teams that spent so much time designing their Scrum Board, for example, that Management lost patience with them and the Scrum Framework because a Scrum Board was all they ever produced.

It occurred to me one day that Scrum Teams are the customers of the Scrum Master. If we don’t already know it, Scrum teaches us that customers of our enterprise don't really know what they want until they have seen it, or at least something to define what they don’t want. So why would we expect Scrum Teams to know how to set up, for example, their Sprint Planning Meetings if they haven't seen a working prototype?

This approach was documented in the Agile 2009 presentation titled “Shock Therapy” (available at http://www.rapidscrum.com/resources.php), coauthored by Jeff Sutherland and Bjorn Granvik.
When I join a team as their Scrum Master, I issue a few non-negotiable rules (gently if possible, firmly if necessary). These rules remain in effect until the team has met three criteria:

1. A minimum of 240% increase in Velocity
2. They have completed three consecutively successful Sprints
3. They have identified a good business reason to begin changing rules

My initial rules are roughly these:

Everyone on the team will attend a Scrum Training session.
I conduct an extremely condensed Introduction to Scrum course and the entire team comes together for a single session. Until everyone has been trained, we won't begin our first Sprint.

Sprints will be one week long.
I justify this by pointing out that there is a reason geneticists study mutations in Fruit Flies instead of Elephants – they want to see the mutations quickly and adapt their studies accordingly. So do I. Teams generally hate this part as much or more than anything else I require of them but I have been able to coax every team into giving me at least four, one-week Sprints as a trial. Here's a favorite exchange of mine that almost always comes up:
Engineer: "But I can't do anything in one week!"
Scott: "Then simple math suggests that you can only do four nothings in a month."
Interestingly, by the time the teams have met the three criteria for changing this rule, only one so far has ever elected to change it.

White House Issues New IT Contracting Guidance

Greater Accountability and Faster Delivery Through Modular Contracting

Posted by Joe Jordan, Steven VanRoekel on June 14, 2012 at 03:29 PM EDT

Last week, we highlighted a number of ways in which reform of Federal Information Technology Management is giving taxpayers more for their IT investments and improving the overall function and efficiency of government. Today, we mark yet another milestone in our march to improved fiscal and contractor accountability as we roll out Contracting Guidance to Support Modular IT Development. 

For too long, Federal IT was marked by runaway information technology (IT) projects in Federal agencies that wasted billions of dollars and were years behind schedule. By the time some of these projects launched, if they launched at all, they were often over budget, late and/or obsolete.  In many cases, these failures can be traced back to lengthy acquisition and IT development efforts that aimed to deliver massive new systems over years, rather than providing new functionality in an incremental manner – as the private sector does...

Today, we are releasing a new document, Contracting Guidance to Support Modular IT Development, which encourages agencies to shift away from the bloated, multi-year projects so common in the past to a more nimble approach. The guidance provides our IT, acquisition, finance, and program officials practices for how they can, working together as part of an integrated program management team, break investments into more manageable chunks; eliminate the costly lag between when the government defines its requirements and delivers solutions; and begin delivering workable solutions shortly after contract award. By requiring frequent deliverables, agencies will also be better able to hold contractors accountable for keeping projects on track and delivering solutions that truly meet agency needs. And by breaking investments into smaller chunks, agencies may be able to drive more competition – including small businesses that might not have been equipped to compete for the massive, multi-year projects of the past. And more competition means a better value for the American people.

Building on policies established in the Clinger-Cohen Act 15 years ago, the guidance lays out key investment principles to facilitate modular IT development. It then discusses acquisition strategies that are best suited to support the high level of responsiveness that agencies need for modular development. This includes the smart use of contracts where orders are placed as needs arise with short time periods to fulfill specific project development needs within 6 month intervals, as well as rapid response activities in 90 day periods.  Equally important, the guidance highlights several case studies from agencies that already are achieving success with modular development and modular contracting.  

For full article click here ...

Happiness Metric: The Effect of a Bad Boss

Bad bosses are one of most damaging factors in companies leading to unhappy employees which directly affects customer satisfaction and lowers revenue. One of the the primary effects of Scrum is to eliminate the bad boss. Any leader who wants to be better should take a look at Scrum. And those who are doing Scrum will notice that a bad ScrumMaster will have the same effect. We have never seen a hyperproductive Scrum team without a good ScrumMaster. 

As Takeuchi and Nonaka point out, a leader implementing Scrum would be a "Wise Leader." Join us in Kendall Square where we will discuss this in Scrum training on 26-27 July.

How Damaging Is a Bad Boss, Exactly?

by Jack Zenger and Joseph Folkman  |   9:00 AM July 16, 2012 | Harvard Business Review

What's the one factor that most affects how satisfied, engaged, and committed you are at work? All of our research over the years points to one answer — and that's the answer to the question: "Who is your immediate supervisor?"

Quite simply, the better the leader, the more engaged the staff. Take, for example, results from a recent study we did on the effectiveness of 2,865 leaders in a large financial services company. You can see a straight-line correlation here between levels of employee engagement and our measure of the overall effectiveness of their supervisors (as judged not just by the employees themselves but by their bosses, colleagues, and other associates on 360 assessments). So, as you can see at the low end, the satisfaction, engagement, and commitment levels of employees toiling under the worst leaders (those at or below the 10th percentile) reached only the 4th percentile. (That means 96% of the company's employees were more committed than those mumbling, grumbling, unhappy souls.) At the other end, the best leaders (those in the 90th percentile) were supervising the happiest, most engaged, most committed employees — those happier than more than 92% of their colleagues.

This study is by no means unusual. We've seen the same pattern in the U.S., the U.K., the Netherlands, Spain, United Arab Emirates, and India. We've seen it in financial services, manufacturing, high-tech, government, universities, hospitals, food service, oil, and every other industry we've studied. We've seen it in organizations employing 225,000 people and 250.

And we're not the only ones who've seen it: In a recent article, Jim Clifton, the CEO of the Gallup organization, found that 60% of employees working for the U.S. federal government are miserable — not because of low pay, poor workplace benefits, or insufficient vacation days — but because they have bad bosses. He goes so far as to report a silver-bullet fix to this situation: "Just name the right manager. No amount of pay and benefits will solve the problems created by a manager who has no talent for the task at hand." Read more ...

DoD Goes Agile

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

The key language is this:

(2) be designed to include—

(A) early and continual involvement of the user;

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

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

(D) a modular, open-systems approach.

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

The language here certainly sounds Agile to me:

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

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

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

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

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

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

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

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

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

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

Don't Wait. Just Begin.

Sometimes when I talk with people about starting up a Scrum team, or transforming their organization to Scrum, they get paralyzed. They think there are just so many things to do before they can start Scrum. They’ve got to get the right tool, the right space, the right this, the right that. So they waste time thinking about how they want to do something rather than just doing it.

Even if you’ve just started and there are a thousand things to do, don’t wait, just start. Scrum was designed to start a team in 2 days or less. Put everything that you feel you have to get done into stories and put them in the backlog. Even the task of making the backlog itself can be a backlog item! You only need enough stories to fill one Sprint, then while that one is going on, you develop more stories, and more, and you’re off and running.

One of the basic ideas of Scrum and Agile and Lean is to have the absolute minimum you need to enable the work to get done. If  your set up is too complicated, you’ll have introduced waste into the system at the very beginning. Instead of thinking you have to have everything all set up and planned, just begin. Think of it like a worker on a line at a lean manufacturing plant. The guy who installs the spark plugs only needs eight sparkplugs in his work area at any one time, more is just waste. So how do you set it up with only the parts you need? Just build one Sprint of stories and begin.

If you want to learn how to begin, there are still some seats left for my Certified Scrum Master Course on July 26-27 in Boston.

Happiness Metric Webinar

All the questions and growing excitement surrounding the Happiness Metric have made us decide to host a webinar on what it is, how it can be used, and how powerful it can be. Jeff's time is incredibly booked, and we know not everyone can make it to one of his classes, so we thought we'd try a webinar to offer his insight into how you can push teams into hyperproductivity just by asking how happy people are. The one-hour seminar will be on Wednesday, June 27 and you will have a chance to ask Jeff questions in a Q&A session.

From the course description:

Happiness is the key to success. Measuring it is the key to improvement. This one-hour webinar with the co-creator of Scrum, Dr. Jeff Sutherland, will show you how to do it. Everyone knows it instinctively, happy people do better work, make customers happy, and make the workplace a better place to be. People are simply fed up with working in an unhappy company. More and more talented people simply won’t work in command and control environments based on punishment and blame, they’d rather be happy. 

But how do you make people happy? Or more precisely, how do help people make themselves happy? And most importantly how do you make yourself happy? 

Scrum was designed by Dr. Sutherland to bootstrap developers out of an environment where they were always late and under pressure into a team experience that could change their lives. He now studies the Happiness Metric for the companies he works with as closely as he does the balance sheet. Unlike financial metrics, which just tell you how much money was made in the past, Happiness taps into employees feelings about the future.

The webinar is archive here ...