Scrum frees teams from the tyranny of the urgent:

A key goal of the Scrum transformation is breaking the parent-child relationship between “business” and “development”.  Technical planning, implementation, commitment, and delivery is in the hands of the team while the Product Owner provides a single priority-order backlog of consolidated items from stakeholders, users, and the developers, for the team to plan around.  Once a well-formed-team finds the right mix of XP and Lean practices (especially continuous integration and frequent releases) the pressure of “we have to do this now” is easy to manage.  If major items frequently pop up mid-week on a “release train” that deploys weekly:

• The team leaves room in their commitment for these items
• The Product Owner sets realistic expectations with stakeholders on which release will include the request

This is part of the power of Lean planning for making strategic product and release decisions – once the Minimum Viable Product is in the open market, data from the users can determine urgency of backlog items.  Frequently, this is a point where a pivot is desirable.  Through frequent releases, the users, stakeholders, and the team can relax and look at the big picture, free from the fear arbitrary deadlines and urgent scope “creep”.

Scrum frees teams from the fear of making mistakes:

While the extreme co-dependency that drives the tyranny of the urgent is overcome by putting an end to arbitrary deadlines and poor scope decisions, the fear of making mistakes is overcome through the key roles defined by Scrum.  Note, these are roles and this label is intentional – these are NOT by necessity positions or titles.  As I describe in Why Product Owners? a role is the confluence of empowerment, responsibility, and accountability for One Big Thing that rests on the shoulders of a single person.  Teams are free to voice ideas because the Scrum framework encourages collaborative implementation planning, cross-functional brainstorming, and constant discovery of best practices.  With XP Pair Programming, this becomes even easier as a single screen and keyboard gets two minds and four eyes that can converse on best practices, mitigate against knowledge silos, and build team relationships.  In the end, all of these adults acting brilliant and mature, huddled around a problem still have the Product Owner as the proxy to the users and stakeholders.  The team is free to determine one small solution at a time, just-in-time, and just-enough – then iterate or pivot.  When tough decisions need to be made, the Product Owner makes the call, relying on the expertise of the team, sets expectations, and maintains accountability.  Moreover, the user story – as the building block of incremental product delivery – isolates risk of mistakes to the smallest valuable user interaction and continuous integration ensures that when a new increment is not “potentially shippable” it can be easily taken out until additional iteration is completed.

Scrum frees organizations from business as usual:

When things go wrong in a large Waterfall project, multiple helpless Project Managers ask for updates but are unable to check boxes, development teams are powerless to drive the direction of the product, and stakeholders become progressively frustrated by the unfinished pit into which money is being thrown.  Then they cancel the project!  What is missing here?  JOY!  Menlo Innovation’s Richard Sheridan and author Joy, Inc. describes the importance of team joy in an interview with InfoQ:

There is in fact tangible business value to joy. But understand this: our focus is external to the organization. What we want more than anything else is that the work of our hearts, our hands, and our minds gets out into the world and delights people. That’s our definition of joy. We want somebody to stop us on the sidewalk and say, “That thing you built, I love it. Thank you. You made my life better.”

When I build a new Scrum team, guiding them with the help of my Scrum Master through the process of forming, storming, norming, this is the number one fear I must guide them through:  I say “Yes, the requirements will change.  Yes, what you build today will be modified tomorrow.  What matters is that you are a creator, people will actually use what emerges, and it will make a difference to them.”

The move from cancelled projects to meaningful user feedback has an incredible impact on an organization.  The drive to constantly improve, tighten feedback loops, and evolve through empirical process control will make disruption the norm and remove the fear of inevitable change and new ideas.

Scrum frees organizations from process rigidity:

There are three overarching goals driven by the roles, ceremonies, and artifacts in Scrum:

1. Notice ineffective processes, workflows, or behaviors quickly and cease them.
2. Notice effective processes, workflows, or behaviors communicate this knowledge
3. Recommending new processes or practices that can be tested for the length of a sprint

At the organization level, the same process should occur.  While the empirical methodology monitoring “the process” – a mix of lean, XP, and other function-specific practices – is held constant, the practices that are monitored within “the process” are under constant review at the team and organization levels.

At this year’s ScrumAlliance Global Scrum Gathering in Phoenix, Arizona, I attended a terrific session  “Scrum at Scale – Free yourself from the myth of one-size-fits-all scaling“ led by Scrum Inc.’s Alexander Brown.  Look for an upcoming post on his argument that Scrum is by definition modular and object-oriented, such that organizations scaling Agile, Scrum, Lean, and XP can utilize empirical process control and a mix-and-match approach to the various frameworks most appropriate to the unique needs of each team.