managing agile....: InfoQ: Manager 2.0: The Role of the Manager in Scrum

Manager 2.0: The Role of the Manager in Scrum

Posted by Pete Deemer on Jul 23, 2010

Community

Agile

Topics

Agile in the Enterprise ,

Teamwork ,

Adopting Agile

Tags

Scrum Master ,

Self-organizing Team ,

Management ,

Scrum

Share
|

When an organization starts to explore Scrum, there’s often an uncomfortable moment early on when someone points out that the role of “manager” seems to be missing entirely. “Well I guess we’ll have to just get rid of ‘em all!” wisecracks one of the developers, and all the managers in the room shift uncomfortably in their seats.

RelatedVendorContent

Scrum Tutorial Series

ScrumCore Training. Certified ScrumMaster and Certified Product Owner public and private courses

A ScrumMaster’s Checklist: Product Owner, Team, Dev Practices, Organizational

Agile Transformation Strategy

Learning to be a Good Product Owner: Foundation Skills

Related Sponsor

ScrumWorks Pro is the only Scrum project management tool designed for the enterprise. Sign up for a free 35-day trial.

Scrum defines just three roles – Product Owner, Team, and ScrumMaster – and the basic direction given to others in the organization is to “support them, or get out of their way”. This is not very detailed advice, especially if you’re a manager expected by senior management to ensure everything goes well.

The traditional role of the manager in the corporate world is based on a model known as “command and control”. Here, the job of the manager is to identify what needs to be done, to issue detailed instructions to the employee, and then to ensure the employee completes the work according to the instructions. The role of the employee in this model is simply to follow the directions as given, trusting the judgment and wisdom of the manager to ensure that the right work is being done in the right way.

In complex, dynamic environments such as software development, this approach tends to break down. First, it is difficult and time-consuming for a manager to understand every requirement in full detail and issue precise instructions to guide the work of every employee. Within a software development Team, the work is highly interconnected, with intricate dependencies, and frequent change and surprise. To expect a single manager to do all the basic thinking for his or her team is unrealistic, and it often constrains the team’s productivity to the manager’s ability to give instructions. In addition, this approach tends to be demoralizing for employees; their role is simply that of “order follower”, and they often feel little sense of ownership of their work. Accountability is limited to answering the simple question, “did I complete the orders I was given?” If the answer is “yes”, the job has been done – regardless of whether the right thing was built, built well, or built to satisfy the business goals of the customer.

Scrum is based on a different approach: The Self-Organizing Team. The difference is apparent from the first steps the Team takes. In Scrum, the Team decides how much work to commit to in a Sprint. Experience has shown that when Teams themselves decide how much to commit to – and when this commitment is realistic and achievable – the Team’s focus, motivation, and drive is significantly higher, and they produce better results. When managers first learn of this practice, they often voice the concern, “What if the Team under-commits?” This is typically not a problem, since the process of deciding the commitment is very transparent and open. Indeed, it’s much more common in the early Sprints for Teams to significantly overcommit; most Teams have very little experience doing their own estimation, and it takes a number of Sprints before their optimism is tempered by experience. Moreover, in the event the Team does wind up under-committing, they will either finish the Sprint early, or they will start work on the next item on the Product Backlog. No harm, no foul.

Team Tango had just completed their first Sprint Planning Meeting, for a two-week Sprint. They brought in their manager, Jason, and walked him through the work they’d decided to commit to in the Sprint.

Finally, they asked Jason, “Is this a good amount to commit to?”

Jason turned the question around to the Team:

“Do you truly believe you can finish this work, at a high level of quality, by the end of the Sprint? Do you really feel committed?”

The Team members all nodded to him, looking quite convinced.

“Then it’s a good amount to commit to.” Jason replied. “And if it turns out to be too much or too little, you’ll know two weeks from now, and you’ll have learned something about how much you should commit to in the following Sprint”.

The next aspect of self-organization happens during the Sprint, when the Team works together closely to decide who will perform which tasks, and to make sure all the work is completed. When the Team is responsible for this decision-making, they remain focused on the fact that they own the commitment – and if the commitment is to be completed, they are the ones who must do it. When someone outside the Team is responsible for deciding what needs to be done and by whom – for example, a manager – the Team receives a subtle but real signal that they are not responsible: it’s the manager’s job to worry about how to meet the commitment, not the Team’s. This does not mean that managers are not providing support during the Sprint – on the contrary – but managers are careful not to send any signal to the Team that would reduce their sense of ownership of the goal, or responsibility for managing themselves during the Sprint.

On the first day of their first Sprint, the Team called their manager Sanjay over to join them for their Daily Scrum Meeting. Sanjay, wanting to be helpful, agreed to the request. He stood just outside the circle as the Team gave their reports to each other. Sanjay noticed that people seemed to be emphasizing how much they got done the day before, and weren’t spending very much time reporting the blocks they were hitting. And after each person gave their short report, they looked over to Sanjay expectantly, hoping to catch a glance of approval. By the end of the Daily Scrum, Sanjay noticed that the entire circle of people had shifted, so they were now facing him.

After the last report was given, a Team member raised his hand, and asked “Sanjay, do you have any feedback or guidance for us?”

Sanjay knew that he had to take action.

“Guys, I’m really concerned. I feel like this meeting was for my benefit. I feel like you’re still looking to me to make sure everyone’s doing the right thing. Here’s the deal: I’ll give you any help you need, at any point in the Sprint. If you hit a block and you’re not able to resolve it, I’m here to provide any assistance I can. But at the end of the day,