1200

By Michael Mariani, Scott Likens, Imran Ilyas and Chris Curran

When it comes to Agile methodology, many organizations have resisted it because of a belief that they have to implement it across the entire organization or not at all.  Furthermore, there is a fear that Agile isn’t proven for large, complex, enterprise-class projects.  However, we have found that using an approach driven by architecture best practices, the benefits of Agile can be applied individually to any development project when it makes sense. The approach balances architecture, release planning, and organizational structure, a “triangle offense” of sorts we call Architecture-Driven Agile.  The key to realizing the value of Agile is to implement enough structure to connect with the rest of organization while enabling Agile teams to actually be agile.

The Agile Triangle

In our work with an airline, we applied the principles of Architecture-Driven Agile to accelerate the delivery of a new e-commerce platform and new online marketing capabilities. The results were compelling. By weaving architecture blueprints, patterns, and people throughout the Agile process, we were able to utilize progressively more detailed planning to provide greater visibility to stakeholders.  Building an organizational structure that linked the Agile teams to rest of the enterprise, we helped the airline deliver on-time, on-budget, and three times faster than teams using waterfall methodologies.

These are the three pillars of the Architecture-Driven Agile triangle offense:

1. Architecture

Architecture should play a central role throughout all phases of planning and execution. With the typical web of technical dependencies most organizations have, strong architecture direction is necessary so that the Agile solution fits the environment and doesn’t hamper the speed of the development team. Rigorously applying architecture isn’t common in Agile methodologies, but doing so can align technologies and help developers move more quickly by working through complex technical and integration challenges.

2. Release Planning

An iterative planning approach will provide better visibility into delivery objectives. Using the architecture as a guide, IT leadership can develop a release plan that sets functionality, schedules, and budget costs. Further estimation of functional complexity, technical dependencies, and development capacity, can help leadership iterate and evolve the roadmap.  Progressive, balanced planning provides better visibility into investment and return and creates a linkage between the Agile teams and the organization’s strategic direction.

3. Organizational Structure

A critical component of effective Agile delivery is an organizational structure that maintains alignment with the broader enterprise and preserves agility among the delivery teams. This structure should provide roles to manage the Agile team and communication with other programs, systems, and shared services not in Agile mode.  Ideally, the development process will remain somewhat insulated from enterprise complexities and constraints.

So when you think about the “triangle offense” of Architecture-Driven Agile, each of the corners is working toward the same goal of effective delivery. This really nullifies the “all or nothing” mentality because each corner opens up opportunities for the others, allowing the organization to pursue the path of least resistance (as Phil Jackson or Tex Winter might say).  In doing so, the technology organization will also unlock the benefits of agile for the enterprise, creating the direction, visibility, and structure to allow the speed of agile development teams to thrive in large organization.

In a later post, we’ll explore some of the key challenges inherent in Agile methodologies and some tips for mitigating the risks.

1200