I’ve wrestled with some hairy large scale agile problems.  I’ve found that the coordination, temporal synchronization, and management overhead represented dramatic waste.  While many argue that this is part of the nature of scaling up, I have a hypothesis.  I believe that a shift from a team oriented organizational structure to a community oriented organizational paradigm will result significant efficiently improvements over highly synchronized, coordinated, and regimented teams.  One of the many problems that large scale organizations face in this regard is release planning.  

Let’s unpack this practice to understand the challenges it represents, in practice, for most organizations.

Coordination: As the number of teams increase, it becomes challenging to coordinate work allocation between groups.  Historically, I have created elaborate structures, tools, and rituals to try to make this more efficient.  Traditional release planning activities creates an unhealthy cycle of “point in time” moments of clarity and focus that then degrade over time until the tactical decisions made on a daily basis by the teams drop to a sufficiently low quality as to act as a forcing function for replanning.  The productivity and budgetary cost implications of large scale release planning act as a counter balancing force that actively encourages extending the use of poor information longer.  This leads most organizations to reach equilibrium with quarterly (or annual!!) release planning.  

Because even a quarterly planning function is challenging to coordinate at large scale, most organizations will further compromise on other axes to work around the budgetary and logistical constraints.  Typical suspects are:

Time boxing of the event, regardless of actual time required for the complexity and scope of the organization’s mandate

Participant constraints, where delegates, meant to represent all the knowledge and experience of a team or stakeholder, are selected to participate which creates another source of imperfect information into the planning process (further eroding the half life of the plan’s usefulness) or leads to significant time delays, cutting into the already limited time allotted to the planning process.

Scope constraints, where topics discussed are unnaturally limited to a list of predefined priorities or “strategic” initiatives, which often flies in the face of the organic interdependencies between otherwise tactical concerns and the topics of import.  This leads to polite fictions where planning for significant work gets deferred under the banner of dependancies (or high brow euphemisms like Architectural Runway and Technical Debt reduction).  This directly and proportionally builds inaccuracies into the plan which further reduces the useful tenure of the plan.

What should be done?

Organizations need to rearchitect their planning processes.  Two key focus areas of a more organic and natural process are:

Align planning to areas of focus.  Any product has a natural set of key drivers for change.  Sometimes this is the implementation of a single business model (think Lean Startup MVP).  Other times it has a natural set of key constituents that can be effectively segmented into a portfolio. Additionally, there are a set of concerns such as technical debt levels relative to the expected longevity and activity of the code base or operational and support concerns.  By segmenting planning, the activities can be aligned to more natural events and cadences in the business (such as industry cycles and events, line of business calendars, etc).  Planning can then be smoothed out into a finer grain process that more closely resembles a continual planning model (with budgetary alignment based on priority).

Move to a more fluid and fungible resource model.  One of the biggest sources of impedance between stakeholder priorities and development capacity is over specialization of resources and teams.  

There is a natural tendency for organization stakeholders to want to codify priorities and portfolio allocation into the organizational structure.  While it makes sense on the surface and it is easy to align budget and consensus around the practice, it immediately cements a point in time set of priorities and organizational concerns into an org chart.  This makes it incredibly hard to react to changes in stakeholder priories and react to changes in the business.  It also creates an unnecessary and destructive tendency to shrink and grow teams not based on the merits of the personnel but on team alignment to priorities.  

There is a natural tendency for technical leaders and contributors to want to codify technology decisions and code bases into organizational structures.  ”This is the RoR team.”  ”This is the platform team.”  ”This is the blue widget team.”  All of these represent technologists natural desire for efficiency.  Because a team (or location) has a history with a particular code base or technology, most technologists will want to funnel all requirements involving a the specialization through that team.  This creates significant bottlenecks that are not well appreciated by stakeholders.  Being told that they cannot have the thing that will deliver the most business value because it requires a specific team that is working on something else is not easy to swallow.  Organizations should create development communities that transcend team affiliation so that work can more efficiently align to business value return instead of technical resource availability.  While strengths and weaknesses will always exist, codifying cross training into process and ensuring the model promotes wide geographic exposure maximizes return on development cost centers.