content top

Do You Need a Transition Team?

Do You Need a Transition Team?

We recently assessed a young Scrum implementation and our observations led to a lot of discussion around the office. We saw excited teams, a stable cadence of meetings, and leadership eager to support the implementation — in other words, a very promising start. Yet the teams had hit a wall and the organization was struggling to understand why. Our answer: You need a transition team.

As we dug deeper to find the root cause of what was stalling the implementation, it became clear that the teams were all struggling with the same organizational impediments. (We use the term “organization impediment” to refer to impediments beyond a team’s sphere of influence.) Yet there was no one in the organization accountable for, or empowered to, address those impediments.

Why a Transition Team?

Scrum fundamentally changes the way teams interact with the organization. This change uncovers many impediments that, if not addressed at the enterprise level, often limit teams to a fraction of their potential. A transition team is tasked with coordinating between the teams and the enterprise in order to identify and remove organizational impediments.

A well-run transition team will own the process of moving to Scrum and be held accountable for supporting its success. To do this it must be empowered to resolve impediments that cannot be addressed at the team level.

How it works:

Ideally this will be one of the first Scrum teams your organization launches, so that it can support the implementation from day one. Who should be on the transition team depends largely on context. The team’s success requires it to be cross-functional and empowered — meaning it possess the diversity and authority to lead the organizational change necessary. The team’s roster may evolve as the Scrum implementation matures and the organizational impediments begin to change in nature.

The transition team works closely with the Scrum teams to discover common impediments that are slowing them down, but that are beyond the teams’ sphere of influence. These impediments come in many forms such as the need for more training, a more agile approach to product planning, better testing infrastructure, more agile tooling, etc. The transition team adds these impediments as stories to an organizational impediment backlog, which it prioritizes in true Scrum fashion. The team paves the way for agile success by working in sprints to tackle the impediment backlog at the top of the backlog. Just as importantly the transition team makes these impediments and their velocity against them visible, serving as the key success metric for the agile transformation.

The ultimate goal of a transition team is to instill a culture of continuous improvement not just within the teams, but also from top to bottom. When the transition team has achieved a relatively mature Scrum, it should not be disbanded but rather repurposed with a charter to support the organization’s continued agility. At this stage the team becomes the go-to support center for teams that need coaching, training for a new member, or ideas on tackling an impediment.

Looking for more ways to work better? Contact us to speak about your goals. 

 

Read More

New Book Launch Party

New Book Launch Party

Today:

I began a month’s worth of events in the U.S. and Europe this week promoting my new book Scrum: The Art of Doing Twice the Work in Half the Time. The first event was a Reddit IAMA. One question I liked:

jf200399:  Hi Jeff, we know about the mechanics and the productivity of scrum. But do you like to tell something about the culture in scrum teams?

The culture of Scrum teams will evolve if people work on it to something like a high performance sports team. We liked Rugby videos on the first Scrum team and kept on showing our favorite All Blacks scrum video. We asked what is the difference between us and them. They were totally focused. They had all arms linked. Their mental attitude was they would crush anything that got in the way. When one individual broke through the line the whole team was ecstatic. The first Scrum team said to a person, this culture changed their lives and they would be looking for the same experience again and again for the rest of their life. There were a lot of tears when the team was acquired by another company and had to split up.

“This book cuts through the jargon and pedagogy and gets to the essence of what makes it work.”

–Adam Messinger, CTO, Twitter

Tomorrow:

On Saturday, I fly to Silicon Valley to meet with most of the leading companies there. I’ve already had pre-meetings with leadership teams from Ericsson, Workday, Cisco, Salesforce.com, Walmart, Visa, Symantec, Adobe, and Intuit, among others. A highlight will be the Disruptive Leadership presentation at the Silicon Valley Agile Leadership public meeting at PayPal on Tuesday, 10/7. Stacey and Mary Louie have done an awesome job with their team in organizing four events every day for a week.

“Senior leaders should not just read the book—they should do what Sutherland recommends.” –Jeffrey Pfeffer, Professor, Stanford Graduate School of Business, co-author of The Knowing-Doing Gap

The Next Week:
VersionOne has invited me to Atlanta for a community event on Monday 10/13: Disruptive Leadership: The Power of Scrum with Jeff Sutherland. I’m really excited to meet the Scrum community in Atlanta, which is growing by leaps and bounds.

“Jeff Sutherland succeeds brilliantly.”

–Eric Ries, New York Times bestselling author of The Lean Startup

 

Read More

The Origins of the Daily Standup

Jeff’s new book Scrum: The Art of Doing Twice the Work in Half the Time is coming out on September 30, 2014. I thought I’d share an excerpt from it on how the Daily Standup came to be. Pre-order the book from AmazonBNiTunes, or Indiebound.

With the first Scrum team at Easel Corporation in 1993, I regularly showed them a video of the All Blacks rugby team getting ready for a game. The All Blacks, a legendary team from the small country of New Zealand, are a transcendent team. Before every game they perform the Maori warrior ceremony of the haka. The haka is a warrior dance that charges up people about to go into battle. While watching it, you can almost see the energy come out of each player and coalesce into a greater whole. With synchronized stomping and clapping and chanting—ritualized movements of cutting an enemy’s throat—you can see ordinary men transform themselves into something bigger, something greater. They’re invoking a warrior spirit that does not accept defeat or dismay.

It took a few viewings of the video, but my team of slightly-out-of-shape computer programmers eventually started to talk about how they could be that way.

So they went into the literature to find out how the best teams did it. One of the great things about software development is that the situation early on was so bad, and so much money was being wasted—billions and billions each year—that people spent a lot of time studying why, and there was data on everything.

One paper we found was an examination of a Borland Software Corporation project called Quattro Pro for Windows. For the project one million lines of software code had been created. They took thirty-one months to produce and were the output of eight people. That means each team member produced one thousand lines of code each week. That’s the fastest of any team on record. (see Jim Coplien’s paper on it for details)

One of the elements of Borland team’s “secret sauce” was that they would have everyone on the team meet every single day to discuss how they were performing. Getting everyone together in a room was key, because it gave the team the opportunity to self-organize around challenges. If someone was stuck with a problem—if the accelerometer wasn’t talking to the altimeter—everyone saw that the impediment could block the whole Sprint, and they swarmed on it, making sure it got fixed pronto.

At Borland the daily meeting was an hour at least. That struck me as too long, so I looked at the core things that need to be communicated in that huddle and came up with the three questions.

And that’s how the daily meeting came to operate. We had certain rules. The meeting was held at the same time every day, and everyone had to be there. If the entire team wasn’t present, communication simply didn’t happen. And it didn’t matter what time of day the meeting took place, as long as it was at the same time every day. The point was to give the team a regular heartbeat.

The second rule was that the meeting couldn’t last more than fifteen minutes. We wanted it to be crisp, direct, and to the point. If something required further discussion, we noted it and met further after the daily meeting. The idea was to get the most actionable and valuable information in the least amount of time.

The third rule was that everyone had to actively participate. To help this happen, I said that everyone had to stand up. That way there’d be active talking and listening going on. It also would keep the meetings short.

This is the reason such a meeting is often called the Daily Standup or Daily Scrum. It doesn’t really matter what you call it. It has to be at the same time every day, with the same three questions, with everyone standing up, and last no more than fifteen minutes.

The problem that I frequently see crop up is that people have a tendency to treat the Daily Standup as simply individual reporting. “I did this . . . I’ll do that”—then on to the next person. The more optimum approach is closer to a football huddle. A wide receiver might say, “I’m having a problem with that defensive lineman,” to which an offensive blocker might respond, “I’ll take care of that. I’ll open that line.” Or the quarterback might say, “Our running game is hitting a wall; let’s surprise them with a pass to the left.” The idea is for the team to quickly confer on how to move toward victory—i.e., complete the Sprint. Passivity is not only lazy, it actively hurts the rest of the team’s performance. Once spotted, it needs to be eliminated immediately.

I want aggressive teams—ones that come out of the daily meeting knowing the most important thing they need to accomplish that day. One person will hear another say that a task will take them a day, but another team member might know how to do it in an hour if they work together. I want teams emerging from that meeting saying things like, “Let’s nail this. Let’s do this.” The team needs to want to be great.

My standard speech to teams large and small is: “Do you really want to suck forever? Is that what your motivation is in life? Because it’s a choice, you know—you don’t have to be that way.” A team has to demand greatness from itself.

At Easel, with the first Scrum team, we implemented the Daily Standup during the third Sprint. We’d planned out four weeks of work for that Sprint—pretty much the same workload as the previous month. We finished it all in a week. A 400-percent improvement. That first Friday the whole team just looked around at one another and said, “Wow.” That’s when I knew I might be on to something.

Pre-order Scrum:The Art of Doing Twice the Work in Half the Time from AmazonBNiTunes, or Indiebound.

Read More

Scrum Alliance, Scrum Inc., Scrum.org Endorse The Scrum Guide

Ken Schwaber and Jeff Sutherland the co-Creators of Scrum and authors of the Scrum Guide

Ken Schwaber and Jeff Sutherland the co-Creators of Scrum

Scrum Inc. is pleased to join Scrum Alliance and Scrum.org in announcing a new website ScrumGuides.org that will be the new home of the Scrum Guide.

From the Press Release:

Scrum Alliance, Scrum.org, and Scrum Inc. announce the release and joint endorsement of a new community website, ScrumGuides.org. The new website is the official source of “The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game.”

Dr. Jeff Sutherland and Ken Schwaber created Scrum and authored “The Scrum Guide” to ensure Scrum remains true to its core principles and values.

“The Scrum Guide is the canonical definition of Scrum. Ken and I have worked closely together for decades to keep it simple, clear, and, in the true spirit of Scrum, to include only what is absolutely necessary,” says Sutherland CEO of Scrum Inc. “Scrum is a powerful tool to radically increase productivity. Every implementation of Scrum is different, as teams and organizations apply it within their context, but the fundamental framework always remains the same. For Scrum Alliance, Scrum.org, and Scrum Inc. to come together to recognize the central place the Scrum Guide holds will provide clarity to the hundreds of thousands of Scrum practitioners across the planet.”

The explosive growth of people and organizations using Scrum in recent years has led to some market confusion as to the precise definition of Scrum. The preeminent certifying bodies, Scrum Alliance and Scrum.org, coming together in support of a common definition of Scrum is a win for Scrum practitioners around the world.

“The pieces of Scrum are carefully fit to each other to yield the best possible results. This has taken years for Jeff and myself to achieve. Watch for new versions as we continue to refine,” said Ken Schwaber, founder of Scrum.org.

“It’s time for convergence in the Scrum community,” said Scrum.org’s operations chief David Starr.  “Giving this clear explanation of Scrum clarifies the framework for the entire industry. We are pleased to support a shared and unambiguous source of truth defined by Scrum’s creators.”

Carol McEwan, Scrum Alliance Managing Director said, “This makes the most sense for the Scrum community.  The Scrum Guide is based on the principles of which Scrum was founded. It offers Scrum practitioners worldwide a common standard and understanding of the foundations of Scrum. This collaboration adds real value and can only benefit everyone practicing, or considering practicing Scrum.”

Read More
content top