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.

by Henry Hwangbo, Guest Author

Agility is a term that is applied to everything from sports to dog shows, and everything in between.  More recently, agility has been used to describe engineering methods, including software.  In the mid-1990s, “lightweight” software methods gained some traction, aided in part to the growth of object oriented analysis and design.  Finally in 2001, the term agile was ratified as a software development approach and described in the Agile Manifesto (and Dilbert).

During the last 18 months, I have talked with several companies who are looking to become more cost efficient in building software.  Many IT leaders are asking if an agile approach is a possible avenue.

In my experience, the types of resources available and the system environment should have more impact on your choice of methodology over the type of project.  For example, I find agile great in concept, but tough in implementation, unless you have most of the following:

1. Little or No Mainframe Development – has anyone tried to do agile with COBOL batch programs and 3270 screens or no UI at all?  How do you get the business folks to validate the business rules?
2. Rock Star Developers – not all developers are created equal and it’s very difficult to find good developers, much less get them all on one project
3. Small Teams (both technical and business) – if you need to coordinate 80-100 people (and get them to agree to a direction) because of the systems/business involved you can call it agile, but it’s not agile
4. Business Folks Who “Get It” – business analysts that come from the waterfall world will try and define every single requirement to the tenth degree
5. Green-field Development – it’s much easier to do agile if you do not have to worry about integrating with existing systems; the less dependencies, the better
6. Project Managers Who “Get It” – planning, dependencies, and issue/risk prioritization are different depending on the SDLC methodology; “status updaters” and “process bots” need not apply.

From a purely theoretical standpoint, agile (and other) iterative methodologies will win.  The better question to ask and answer is:

“Is an agile method realistically feasible
given our current set of IT capabilities?”

That means understanding the people, technology, and processes and either selecting the methodology to fit those factors or changing the factors (e.g. hire agile developers – don’t use in-house developers)  and project (e.g. remove dependencies on mainframe systems, reduce scope to a single business unit) so it’s easier to build in an iterative/agile fashion.