{ 2007 11 19 }

Effective small teams need coordination to make an effective large organization

Bernie Thompson

Print This Post Print This Post

Email This Post Email This Post

Permalink

This is part 2 of 10 of the 10 Pitfalls of Agility on Large Projects. In part 1, we talked about how planning a month or less ahead is not enough on a very large project, and what to do about it.

Here’s some of why people say that long-term, full-detail plans are essential:

  1. You need the detailed work breakdown structure through the end of the project to produce estimates.
  2. And you need estimates to schedule handoffs, deliverables, and other dependences between teams.
  3. And as things do change, you need a plan through which to communicate those changes.

How can we satisfy these needs while still allowing small teams latitude to adapt and be agile?

Concern #1 is a red herring of sorts. Estimates constructed from a detailed WBS are not the most accurate, if you’re in a domain with significant unknowns (like most new product development). In these domains, you’ll get much better estimates from other methods like an experienced expert or group of experts using a technique like Wideband Delphi. For more, see a book like McConnell’s Software Estimation: Demystifying the Black Art

#2 is a dominant concern for organizations with long internal lead times. The motivation and techniques for attacking this problem in other ways is what lean thinking is all about. In short, agile/lean teams are much better equipped to handle changes in other teams’ plans, so they don’t need those plans to be as firm. It’s a self-reinforcing benefit of shorter cycles that pays off in spades.  The trick is keeping the peace during the (often long) transition period where an organization has a mix of long-cycle and short-cycle teams. These solutions to #3 can help during this transition.

Concern #3 speaks to allowing your high and low level plans to evolve as you progress and learn. But how do you keep them in sync?

Top Down and Bottom Up

  • Have top-down goals and priorities that are clear about the customer and business need, but that don’t over-anticipate the technology to best fulfill that need.
  • Be prepared to take top-down input and provide bottom-up feedback as part of your regular planning cycle (e.g. Scrum’s monthly sprint planning).
    • For inputs, the Scrum Product Backlog and processes around it are an effective way to turn top-down priorities into actionable technical workitems.
    • For feedback, provide actuals. In order to keep the trust of the organization, some kind of actuals in terms of feature throughput, earned value, or time data, etc. are essential. If agile teams “go dark” on a large organization, it becomes harder maintain trust when things go bad (as they invariably will from time to time on a large project).
    • For feedback, provide new estimates on the larger goals, based on this last cycle’s progress on specific workitems. To make this feasible, use a fast group estimation method like planning poker or its elder kin, wideband delphi.
  • As the size of the team goes up and dependencies between teams get more tangled, coordination on just a monthly basis isn’t enough. Getting information more frequently than your usual planning cycle (or getting your planning cycle down to one or two week sprints) may become essential. The diagram above says weekly (which might match an org with more than 6-8 Scrum teams).

    This might also be the threshold where project management specialists are called for — don’t distract your project leads with sub-sprint communication and coordination between teams. But also don’t lose Scrum’s designed benefit of protecting teams from constant interrupts — the team controls whether their plan changes within a sprint. Project Managers can help make sure status and communication flow between teams even during a sprint, but they (like all stakeholders) should be prepared to hold new work and priority changes until teams plan their next sprint.

If you’re adopting short-cycle methods in a (long-cycle) large organization — what are your pain points that weren’t covered here. And how have you adapted?

Posted by Bernie Thompson on Monday, November 19th, 2007, at 2:00 am, and filed under agile, lean, management, project.

Follow any responses to this entry with the RSS 2.0 feed.

You can post a comment, or trackback from your site.