Software development has its share of problems. Here are a few of the most nefarious:

• Missed deadlines and cost overruns
• Inadequate testing and poor user experience design
• Lack of customer involvement and feedback
• Long release cycles and complex upgrade procedures
• Declining team productivity and software quality over time

Agile approaches to software development appear simpler than the traditional waterfall approaches and easier to master. If the team and the company are small, agile development can be simpler, faster and cheaper. If the team and the company are large, new challenges will complicate agile development.

The problems begin before the agile development process even starts. Agile approaches are often viewed as processes pertaining to software engineering or product development. They are deemed technical processes used by technical people to build technology products. That's all true, yet in the end, businesses need to be agile not just the software developers.

Some of the major benefits of agile development become impediments as teams grow ever larger.

1. Agile development generally works best when teams are less than 10 people. Try building a major enterprise application with 10 people. It will take years. Enterprise teams are often over a hundred people. Imagine a daily standup with 100 people!
2. Agile teams often track progress using sticky notes on a wall or whiteboard. For an enterprise software project, one side of the building might have to be dedicated to the status board. Not very practical.
3. Agile teams rely heavily on personal interactions rather than documents and electronic exchanges. It's hard to get to know 100 people and personally share information with them regularly.

Clearly, enterprise teams have to be divided into smaller sub-teams or workgroups. The rule of thumb that says an agile team should be no more than 9 people makes some sense. If the entire project is 100 people, there will be at least 11 workgroups and possibly 14 or 15 if the average group size is around 7 people.

Of course, 9 is not an absolute upper limit on team size. An experienced team that's been together for a few projects or releases might be comfortable with 12-18 people because they know each other well and everyone knows his/her role. A less experienced team will struggle with such a large group simply because communication becomes complex.

Each of these workgroups will hold a daily standup covering their commitments and responsibilities. The standups are effective in handling internal communications but they don't address external communications. One of the major challenges of enterprise agile development is inter-group communication and information sharing.

Issues that span workgroups will not be easy to manage.

For teams using Scrum, the "Scrum of Scrums" has been offered as a way to split up the daily reporting into a hierarchical structure. Teams meet daily and they send representatives to inter-group daily meetings. The approach is cumbersome at best and regressive at worst as it serves to isolate people and information while maintaining a command-and-control structure. We can do better.

Creating many small workgroups assumes that the system architecture is such that software components or modules can be developed independently. While this may sound simple, it requires experienced system architects and great discipline. The object-oriented guidance to define systems that are "loosely coupled and highly cohesive" strongly applies to large agile teams.

Similarly, the workgroups will not be able to test the complete system. They will be focused on their component(s). If the final system is complex, a separate workgroup whose sole function is the test the complete system will be needed. While this may seem contradictory to the agile manifesto, it is the reality of complex, enterprise systems.

What follows are a few suggestions for adopting enterprise agile development successfully.

1. The traditional functionally-organized engineering group won't work. Splitting up software development into program management, user experience, product management, development, quality engineering, and documentation is too restrictive. Instead, establish Centers of Excellence. Each Center should focus on a core function such as team leadership (e.g. Scrum Masters), product ownership, user experience, system architecture, information management, quality, publications, etc.
2. Form Special Interest Groups driven by the CoEs to define, implement and monitor new guidelines. Keep the guidelines minimalist and simple. Guide the teams. Don't legislate them.
3. Establish team-based metrics to track team (and workgroup) performance, not individual productivity. Be clear about individual roles and responsibilities.
4. Establish a common vocabulary and standard rules (such as the 'definition of done') to be used by every workgroup.
5. Automate as much as you can. a) Workgroups should have the option of using physical or electronic boards. However, those boards will have to be rolled-up into an overall project status board. The rollups will have to be electronic to promote transparency. b) Automated regression testing is a critical success factor. Don't skimp on it. c) Consider an internal social networking tool for information sharing such as Yammer or Salesforce.com's Chatter.
6. Conduct retrospectives at the workgroup level and among workgroups. Inter-group communication and software handoffs will likely need improvement.
7. Get professional help. Good training and coaching are invaluable. Don't try to do this alone. Select a few staff members to become internal coaches/mentors (a kind of train the trainer approach).
8. Focus attention on 2-3 workgroups and get them to high levels of excellence in advance of everyone else so they can be role models. You'll be tempted to treat all workgroups the same and attempt to synchronize them at the same competency level. That's unlikely to be successful. Workgroups will perform at different levels. Embrace it.
9. Expect and encourage mistakes, that's right, encourage mistakes. Being truly agile means making mistakes and learning from them.
10. Set target delivery dates and hold them firmly. Everyone needs to recognize that the company is serious about meeting dates. Just be sure to give the workgroups the flexibility they need to determine what to deliver by the due dates.

None of this is simple. Companies that make the commitment at the executive level and invest in their people will succeed. Those looking for a quick fix will fail. Which type of enterprise is yours?