Knocking Down Silos: Transitioning the Enterprise to Agile

In this article, the structure of the misaligned IT organization is revealed as process-centric silos which have created an ever-widening chasm with business clients that the enterprise organization is supposed to serve.

In a previous article addressing the challenges of Enterprise Requirements Management , it was suggested that the legacy enterprise organization requires restructuring so that productivity gains promised by Agile methods can take root and grow. At the same time, there is a growing chorus of IT skeptics who are singing about the ineffectiveness of the CIO.  Legacy enterprise organizations struggle to stay coupled with business drivers, with the most collaborative relationship occurring at the CIO-to-peer level.

In this article, the structure of the misaligned IT organization is revealed as process-centric silos which have created an ever-widening chasm with business clients that the enterprise organization is supposed to serve.This chasm is best bridged using Lean and Agile methods. Enterprise agility begins with building trust by rapidly creating business value using cross-functional teams that can be scaled upward. Agile barriers and enablers are presented to allow CIOs to assess their organization's potential for restructuring and adapting to Agile.


The legacy IT enterprise organization is a structure consisting of silos of technologists that rarely collaborate with business units (see Figure 1). This organization pattern of silos has been called the "Technology Organization" by Kirk Knoernschild in an excellent article on the Agile Matrix. These silos come about from good intentions as well-meaning process experts attempt to decompose software development into repeatable sub-processes. Once specialized process (such as requirements management or object model analysis) becomes the focus of an organization, time-to-market begins to slow, and survival becomes management's highest priority within the silo. Project teams become matrix units where specialists from each area participate in virtual project teams and, in the truly dysfunctional case, are assigned to multiple projects at the same time. The management role becomes a specialization in maximizing the project load for each resource in the silo. Organizations with this structure can manage waterfall projects successfully, but speed and change-tolerance suffers. Symptoms of such organizations are manifest as well-formed change control structures emerge to protect the already over-burdened resources from unplanned and unexpected work. Managers of these resources focus on protecting their resources from "the business," and are seen as good managers if they can "manage their business clients."


Figure 1: The legacy enterprise organization structure. Note that as the organization grows, project managers are added to each silo to manage resource tasking activities as resources are spread across multiple projects. Silos in this organization tend to line up with different phases and activities of the waterfall life-cycle, creating a focus on process and not product.

The Legacy Enterprise Organization: Yearly Planning and the Origination of the Death March
Sometime in the middle of the summer, the enterprise project cycle typically begins. Struggling project managers are asked to review and "SWAG" project briefs for next year's project list.[3] This up-front planning effort is clearly a Lean anti-pattern, and violates the principle of eliminating waste, since up-front specification is wasteful in software development. Even worse, this activity is a clear distraction from current project work at best, and at worst, it commits an entire organization's resources to next year's activities with no information other than short summaries of capabilities and business cases. The yearly planning cycle fixes scope, resources, and delivery date. Experienced Agile practitioners will attest to the variation in estimates for just 10-day cycles. With this basic truth of technical product development established, it borders on absurd to commit millions of dollars of resource capacity to long range software development projects with fixed scope and no opportunity to allow discoveries to feedback into the original plan. Instead "discoveries" are treated as planning errors.

The enterprise project planning


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.