Having spent the past 3 years working with clients who are going through the transition to Agile, I have observed some of the associated challenges and pain and developed a few opinions along the way. The biggest barrier that I’ve observed to successful Agile is the organization’s overall structure and processes – what I once heard described as ‘scar tissue’ that prevents the flexibility that Agile demands.

Many companies start down the Agile path by converting a team or group of teams to Agile. There is some success, and slowly other teams are converted. This sounds sane and logical. The problem is, Agile isn’t just a software development methodology, so if Agile is limited to only the IT department, very quickly those Agile teams are bumping their heads painfully against the ceiling.

Some of the biggest challenges that Agile teams in large organizations face:

External dependencies – The idea behind Agile is that teams are cross-functional, dedicated, and co-located so that they have everything they need within the team to manage their work and deliver value. In large organizations, Agile teams almost always have multiple external dependencies, other teams (which may or may not also be Agile) that they must work with in order to complete almost any feature in the backlog. This results in a lot of time spent managing the coordination between teams: synching up backlogs, sprint planning, and testing activities to ensure that dependent work is done in the correct sequence and with the correct technical design.

IT/Business wall of separation – For Agile to succeed, there has to be regular engagement of the business stakeholders with the feature team. If the product owner is a part of IT, then she builds a bridge to the business stakeholders but she shouldn’t be the only member of the team who interacts with the business. Without open communication with users and stakeholders, the feature team members are just performing tasks defined by the product owner and don’t really own the delivery of value. Agile doesn’t work well if you seal your programmers up in an ivory tower.

Budgeting – I’ve seen this scenario more than once: the organization chooses a high priority program, gives all teams a high level overview, and then demands an estimate for a year or more of work in three weeks. Teams drop everything they’re working on and hold dozens of cross-functional meetings, trying to build a year’s worth of backlog with enough detail that it can be sized. Three weeks later estimates are duly sent to the program office, which then cuts them in half and tells the teams to start work. Fairly predictable budget and schedule overruns ensue.

So how can organizations overcome these problems and really take advantage of the benefits of Agile? Is true Agile really possible in a large enterprise, or does it only work in a small, start-up environment? Is Agile in a large company doomed to become ‘Watergile’ in spite of the best intentions?

In Total Agile – Part 2, I will channel my inner Agile guru and write a few common sense ideas about doing Agile better in large organizations.