Coordinated agility

 I’ve been using Scrum for seven years and writing about it for the last six. Scrum’s concept is fantastic—multidiscipline, self-directed teams, iterating on short scenarios (stories), in small batches from start to finish, within short, fixed-length, continuous-improvement cycles. Given the success many Microsoft® teams have had with Scrum, it’s stunning that such a strong disconnect still exists between org-level project managers and team-level Scrum engineers.

Many org-level project managers and middle managers believe Scrum is chaotic, haphazard, dangerous nonsense that discourages planning. Many Scrum aficionados believe project planning is wasteful, disruptive, unnecessary horse manure that serves only to placate out-of-touch upper management with fantastical schedules. Well guess what? You are both wrong, and far too smart to be so stupid as to assume the other is ignorant. And yet, you are both so very ignorant.

Scrum is loaded with planning, and efficiently tracks more data in more detail than any other project management method I’ve seen at Microsoft (except for TSP, used by a few teams). Likewise, high-level project planning is critical to successfully scoping, coordinating, and delivering any large-scale initiative. If you have limited vision, then Scrum alone is fine. If you want to deliver lower quality and less customer value in more time than your competitors, or if you want to micromanage every aspect of your limited scope, then project planning alone is fine. If you have a bold vision with broad scope that you want delivered efficiently with high quality and copious customer value, then you need a balance of both high-level project planning and Scrum.

I respect your right to disagree with me

Why is there a disconnect between many org-level project managers and Scrum aficionados? I talked about the cause a few years ago in my introduction to project mismanagement:

“Project management happens differently at different levels of scale and abstraction. There is the team or feature level (around 10 people), the project level (between 50 and 5,000 people working on a specific release), and the product level (multiple releases led by executives). Agile methods work beautifully at the team level; formal methods work beautifully at the project level; and long-term strategic planning methods work beautifully at the product level. However, people rarely work at multiple levels at once; in fact, years typically separate those experiences for individuals. So people think effective methods at one level should be applied to others, which is how tragedies are often born. The moral is: small tight groups work differently than large disjointed organizations. Choose your methods accordingly.”

You can’t expect process-heavy, formal methods to work well for small teams, any more than you can expect dynamic, emergent planning to work well for large organizations. To bridge the gap between the two, you must understand the goals of each and what they need from each other. Let’s break it down.

Plans are nothing; planning is everything

The goals of high-level project planning (vision, architecture, schedule, and risk management) are to:

§  Set a compelling shared vision that aligns a large organization. Without a compelling shared vision, your long-term success is left to chance. Sure, iterating with customers can provide greatly appreciated incremental value, and even hint at long-term value. But major advances are born of compelling shared visions.

§  Establish interfaces between teams that enable the vision. A compelling vision gives an organization a shared destination. Establishing interfaces between teams and components provides an architectural roadmap to that destination. Sure, you could drive from Seattle to New York without a map or highways—but it would take you a long time to get there.

§  Meet commitments to business partners. Big, established, successful companies get that way through partnerships. If you are delivering a compelling vision with real value, you’ll want to involve your partners. That means commitments on both sides. Real money is on the line.

§  Reveal and resolve issues that could jeopardize those commitments. Any large project with partnerships involves dependencies, risks, and coordination. There are numerous ways the project could stall or fail, including greater than anticipated success after launch. You must plan for success and failure. It’s hard work to reveal and resolve issues before they sabotage a project.

Project planners, architects, and middle managers need Scrum teams to align to the shared vision, abide by their interfaces (or update them collaboratively), meet their commitments (or update them collaboratively), and surface and mitigate issues as they arise.

I can take care of myself

Okay, we have a shared vision, interfaces, commitments, and a risk-mitigation plan. Now we just need to follow them, right? What universe do you come from? In my universe, change is the only constant, and progress happens one step at a time.

At a high level of abstraction, the plan may come together and make perfect sense, but at a low level, details intercede. Variation and complexity surface as the details emerge. Project planners, architects, and middle managers could try to micromanage these changes themselves through endless status and design meetings, adding tons of overhead, creating bottlenecks, and grinding progress to a crawl. Or maybe they could trust the engineers closest to the details to work through the problems.

Agile methods, like Scrum, adjust to emergent details and changing situations quickly and effectively. They minimize work-in-progress and overhead in favor of working, customer-focused solutions that meet project requirements. That doesn’t mean Scrum teams don’t plan—it means they approach planning in an iterative manner as they take each step toward the shared vision.

Scrum teams need project planners to set the vision, interfaces, and prioritized requirements, and then get out of the way. So long as the vision is reached, the interfaces respected, and the requirements met, project planners should be very happy. That self-directed Scrum teams quickly resolve most of the issues themselves is something project planners and middle managers must learn, accept, and in time, embrace.

So happy together

Project planners and Scrum engineers should embrace each other. (Group hug!) They complement each other’s work. Project planners give Scrum teams direction. Scrum teams allow project planners to focus on the broad picture, while the Scrum teams provide detailed information on their rapid, flexible, iterative progress toward high-quality, functioning, customer scenarios.

Project planners and Scrum engineers both play critical roles on a project with a bold vision and broad scope. Ignorance is no excuse for fear or rejection of each other’s work. The better we understand each other’s roles and goals, the better we are able to deliver delightful and innovative experiences to our customers.