Introducing Scrum for a product development team in the enterprise environment creates a new bargain between management and the team. A clear understanding of this bargain helps each party take full advantage and maximize the win-win outcomes.
The team uses a visible backlog, information radiators, and frequent product reviews to provide transparency into their operations, including to management. That’s scary for team members, who often fear that scrutiny will lead to repercussions that typically plague traditional project-management: micromanagement, nagging about development pace, heavy status reporting requirements, etc.
Management leaves the team alone during their development timebox and waits for the end of the sprint for the team to adopt new priorities or change focus. And they engage in servant leadership, making it a priority to remove obstacles from the team’s path rather than formulating specific plans for the team to execute. That’s scary for management, who must give up their sense of control over team productivity, trust teams to manage their own performance optimization, and respect sprint boundaries in introducing new priorities and product vision changes.
The combination of short iterations, a protected development timebox, clear ownership of product backlog, and focus on servant leadership gives both the team and management bright-line rules of engagement that accommodate good rhythms for development, reprioritization, and stakeholder engagement. Establishing these rhythms allows all parties to make the necessary trade-offs and maximize the benefit from ongoing development activities.
The best Scrum adopters use these simple clear rules to raise the level of team/stakeholder trust and engagement. They come to view their old ways as forms of hiding and illusory control. And in doing so they achieve superior alignment up and down the development organization, radically improving the effective delivery of customer value, the ultimate measure of success.