Scrum Teams and the Management

At almost every conference or workshop that I attend on the topics of product management process, product development, Agile, and Scrum, an attendee (typically a software developer, a product manager, a ScrumMaster, or project manager) inevitably asks a question about how to deal with their senior management team.

This question typically kicks off a discussion that refers to management as “them” and “they”, often in a negative light as spoiled children, overbearing parents, or the not-too-bright boss from Dilbert.

Advice ranges from pushing back on management, to demanding more resources, to quitting and finding a new job. Attendees generally find none of this helpful…after all, they live in the real world.

While providing operational support to the expansion stage software companies in our venture capital portfolio, I encounter many unproductive instances of management-Scrum team interactions.

To get us moving in the right direction, Jeff Sutherland, co-creator of Scrum (http://www.jeffsutherland.com/) and Senior Adviser to OpenView Venture Partners, says that Management plays the following role:

• Provide a compelling vision
• Have a business plan
• Provide the necessary resources
• Remove impediments the team cannot remove themselves
• Challenge the team to move beyond mediocrity

Seems simple enough, and yet again and again I see management teams not fulfill this core role.

I also see Scrum teams respond to this unproductively, and instead of collaborating with management to get to a better level of performance, show a stiff upper lip and complain about management at the next Agile therapy session…and both get stuck in a cycle of poor performance, failed sprints, and lackluster products.

Here I provide a partial list of senior management behavior that I find hurts Scrum team performance, with suggestions on what to do instead.

In my next blog post, I’ll discuss unproductive behaviors of the Scrum team and how they can help management, and themselves, do better.

Counterproductive management behavior and what they can do to improve:

• Have no compelling vision 
  • To mitigate: Senior management needs to know where they want to take the company, and inspire their Scrum teams with this vision. OpenView Venture Partners hosted an Extraordinary Execution Workshop earlier this year focused on helping senior teams document and communicate their company vision, and other aspirations (http://openviewpartners.com/events/extra09.html), and a Product Management Forum where Luke Hohmann, CEO of Enthiosys (www.enthiosys.com) and Senior Adviser to OpenView, spent half a day improving our companies’ product visions (http://openviewpartners.com/events/prdmang09.html).
•  Ask Scrum teams to commit to unrealistic deadlines 6 to 12 months in advance, without regard of what the Scrum team is actually capable of committing to, or regard to the value of such commitment.
  • To mitigate: Senior management should drive the team to do more in less time with an aggressive, inspiring vision and associated goals, but if the Scrum team is not comfortable committing to something, management should surface the impediments to such commitments and work with the team to remove them. They should ask the questions: “What do I really need to know today?”, “What do you need to be able to commit to this?” and “To what can you commit today?”
• Push the Scrum teams to “do more” on arbitrary metrics with highly subjective goals, whether velocity, or lines of code, number of features, or other creative metrics.
  • To mitigate: Do not use team performance metrics in a way that the team will perceive as against them, and certainly do not use metrics that do not measure team performance as indicators of it. Do not use them as a tool for evaluation. Recognize the strengths and weaknesses of team performance metrics, what they measure and don’t measure (very few metrics really measure the performance of a Scrum team), and consider that pushing on any set of metrics in an overbearing way will likely lead to counterproductive behavior and unhappy teams. Use metrics for informational purposes, to directionally guide decisions, and encourage teams to use those metrics themselves to get better. (Much more on this topic in future blogs). To push the teams to do better, challenge them to tell you what they need to do better. Challenge them to surface impediments, ask for more resources, better backlogs, and so on.
• Ask the team to do more with less without proper support or consideration.
  • To mitigate: Rely on the Scrum team to indicate to you their resource needs for certain commitments, and/or commitment levels for their current resources, rather than force them into unworkable situations. Either ask them what resources they need to achieve certain commitments, or ask them what commitments they can make with their level of resources. This doesn’t mean you shouldn’t poke at their views and arguments and make sure they’re pushing themselves as far as they should…it just means the team has the final say on what they need to achieve a set commitment. If you do not trust your team to make this decision, you’ve got bigger issues.
• Not remove impediments surfaced by the Scrum team
  • To mitigate: When a team surfaces an impediment they cannot remove themselves, either work on removing it, or explain to the Scrum team why you can’t, and help them work around it. Give them an estimate and when you may be able to remove the impediment in the future.

And that’s just a start…in my next week, I’ll discuss unproductive behaviors of the Scrum team, and how they can help management and themselves do better.