Scrum Teams and “The” Management
September 22, 2010
The relationship between a company’s Scrum teams and its management can be adversarial at times. At almost every conference or workshop I’ve attended on product management process, product development, Agile, and Scrum, an attendee inevitably asks a question about how to deal with their senior management team.
Typically, the attendee is a software developer, product manager, Scrum Master, or project manager and they refer to their company’s management as “them” and “they,” casting those managers in a negative light.
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.
Those unproductive management-Scrum team interactions are one of many operational support issues I have encountered in working with OpenView’s portfolio companies.
Jeff Sutherland, co-creator of Scrum (http://www.jeffsutherland.com/) and a Senior Advisor to OpenView, brings some clarity to the debate. He says that Management should provide a compelling vision, have a business plan in place, provide the necessary resources, remove impediments the team cannot remove themselves, and challenge the team to move beyond mediocrity.
Seems simple enough. Yet Management and Scrum teams seem to lack shared vision and communication at times. And, typically, it’s the fault of both parties. Sometimes Management doesn’t follow through on the simple principles Sutherland lays out above, while Scrum teams can respond unproductively.
The end result is that both groups get stuck in a cycle of poor performance, failed sprints, and lackluster products.
Below is a partial list of senior management missteps that I’ve found hurts Scrum team performance with suggestions on how to function differently. The Scrum teams don’t get off scot-free, though. After I discuss management behaviors and how to fix them, I’ll do the same for the Scrum teams.
No Compelling Vision
Senior management needs to know where they want to take the company and inspire their Scrum teams with that vision. OpenView Venture Partners hosted an Extraordinary Execution Workshop in May of 2009 that focused on helping senior teams document and communicate their company vision and other aspirations. Earlier that year, Luke Hohmann, CEO of Enthiosys and a Senior Advisor to OpenView, spent half a day improving our portfolio companies’ visions at a Product Management Forum.
The goals of both workshops were simple. We were trying to engage our portfolio companies’ management in a discussion that ultimately provided them with a clear and compelling vision. From there, they could easily communicate it to their Scrum teams.
When Management asks Scrum teams to commit to unrealistic deadlines 6 to 12 months in advance without understanding the team’s actual capability to commit to those deadlines, it’s a recipe for disaster.
Instead, senior management should drive the team to do more in less time. The best way to do that is with an aggressive, inspiring vision and associated goals. If the Scrum team is not comfortable committing to something, management should surface the impediments and work with the team to remove them.
Arbitrary Metrics and Subjective Goals
Whether it’s velocity, lines of code, number of features, or other creative metrics, pushing the Scrum teams to do more on arbitrary metrics with highly subjective goals is not productive.
The easiest way to mitigate this misstep is to avoid using team performance metrics in a way that the team might perceive the deck being stacked against them. Instead, recognize the strengths and weaknesses of team performance metrics and understand that pushing any metric in an overbearing way is the quickest way to counterproductive behavior and unhappy teams. You should use metrics for informational purposes and challenge teams to tell you what they need to perform better and identify the impediments that might slow them down.
More With Less
If senior management asks its Scrum teams to do more with less resources — failing to consider the impact of that action or offer proper support — a breakdown in the relationship is sure to result.
Instead, management should rely on the Scrum team to indicate their resource needs for certain commitments rather than force them into unworkable situations. Management should make sure the team is pushing themselves are far as they’re reasonably capable of going. But the goal should be to establish a level of trust in the team to make the right decision.
Failure to Remove Impediments
As I discussed above, it’s one of senior management’s responsibilities to ensure that any impediment that will keep the Scrum team from executing its goals on deadline is removed from its path.
When a team surfaces an impediment that they are unable to remove themselves, senior management should work with them to remove it or explain to the Scrum team why it can’t, proceeding to then help them work around it. It boils down to collaboration and developing a sense of teamwork and trust that will only strengthen the Scrum team’s efficiency and resolve.
Of course, it’s not a one-way street. Senior management can do all of the right things and if they aren’t reciprocated by equally productive Scrum team actions, it’s all for naught.
Here are a few unproductive Scrum team behaviors and how to mitigate them.
Agreeing to Everything
The Scrum team should understand what it needs and what a realistic timeline is for a particular project or initiative. So, if that team agrees to everything management requests, even if those requests are beyond its capabilities, the team is only setting itself up for failure.
Scrum teams should instead carefully consider what is being asked, estimate it, and determine if they can realistically commit to those requests. The team should provide supporting data for its capabilities so that management can learn and make better informed decisions the next time around.
Pushing Back the Wrong Way
It’s not incorrect for Scrum teams to push back on management when the situation dictates it. But pushing back in a non-constructive fashion without good explanation, supporting data, or alternative options is not the way to go.
If the management team requests something the Scrum team can’t deliver, they should respond with a few reasons why the request isn’t feasible and suggest what they are able to deliver. In other words, answer management with options and useful information, not with a simple “No.”
It’s the Scrum team’s responsibility to communicate their issues and impediments to management. How else would senior managers know how to resolve or help with those issues?
The Scrum team needs to openly discuss its impediments, especially those that the team cannot resolve itself. The team should, however, refrain from over-communicating small impediments that can and should be resolved without management’s interjection.
Asking For More Without a Reason
When there is a gap between what product management wants and what the development Scrum team thinks it can deliver, the natural impulse is to ask management for more resources.
Asking management for more resources without having proper supporting analysis or first utilizing existing resources is an inefficient way to operate. Scrum teams should first determine the business value of what management needs to build, determine if it really needs all of it in the targeted time frame, and then decide if the Scrum team can do more. Once those options have been exhausted, the Scrum team and product management should request more resources, offering appropriate supporting analysis to buoy the request.