Over the past year, I’ve been reading more and more about the “death” of Agile, particularly as it relates to large enterprises that undertake Agile transformations but do not give the projects enough of a chance to succeed. I worry that failed projects will damage the industry’s perception of Agile.

Having worked on dozens of Agile projects, I can tell you definitively that iterative development, with its fast feedback cycles, continuous integration, and ongoing team improvement, will never be an incorrect approach to software development. As always, the trick is in the execution.

Intelliware recently posted a presentation regarding the Challenges of Agile Adoption, where we discussed how adopting Agile in any organization is challenging in many ways. We found it to be especially difficult in larger organizations, due to their complex infrastructures, numerous legacy systems and mature organizational cultures. It seems that larger organizations often underestimate the difficulty to get Agile right.

The fundamental problem seems to be the way larger organizations attempt Agile transformations. They often select isolated development teams to follow an “Agile” methodology, provide coaching on basic Agile practices, and hope for the best. Some attempt is made to involve surrounding teams, and management is coached about Agile benefits and what’s needed to make sure Agile processes and behaviours take hold, but generally the focus is on the project teams directly involved and not the wider “ecosystem” in which those teams operate.

We think the idea that teams can just “go Agile” in isolation, without implementing complementary changes in the wider organization, is short-sighted and often leads to failure. Any team adjusting to a different working model will have trouble normalizing to the new standards, and this is especially true if their support structures are not changing their own behaviours, including their approach to delivery. Teams that provide project support, such as PMO, infrastructure, and change/release management, must align their priorities with Agile processes and delivery requirements, especially in established enterprises.

The main issue that must be managed is the interface between Agile teams and non-Agile teams.

How should we manage the requirements of non-Agile partner teams while still allowing Agile processes and behaviours to take root?

A good start is embedding specific enterprise roles within the project team. For instance, if an Agile team includes either a member of the release management team or at least someone whose role it is to oversee release management issues at an enterprise level, this allows the team to maintain their internal rhythm and still work in sync with established enterprise protocols. Release candidates can be developed, tested, verified by business partners, and prepared for release at a team level, while management of actual deployments rolls up to the enterprise level. In addition, this structure ties release management directly to the team’s delivery objectives, which at the end of the day should be the fundamental mission.

Another example is project management reporting. The rhythms of Agile teams may not correspond to established patterns of enterprise reporting, but if these discrepancies are managed properly, teams can still operate for maximum output without having to change their processes simply for the sake of meeting existing reporting cycles.

Properly managing this blended approach to project delivery is the key to successful Agile roll-outs in larger, more traditional organizations. If Agile teams are set up without considering the types of interfaces described above, they will very likely wither and die. But if Agile transformation efforts are given enterprise-level commitment and enterprise-level consideration, they will successfully demonstrate their enormous advantages in managing risk, and delivering software projects on-time and on-budget.