Taking Agile to the Next Level
One of the biggest challenges facing agile development techniques is how to scale them to enterprise and global level initiatives that often have distributed teams, long delivery cycles, complex integrations and massive testing and training needs. While this can be challenging there are some approaches that can effectively scale agile techniques across the enterprise.
Agile projects advocate small co-located teams working closely with customers to build software in short, iterative and incremental pieces. A large number of projects are very good fits for this type of development and, in general, keeping projects small and focused dramatically increases their liklihood of success. However, not all projects can be approached this way, some systems can have multiple customers, multi-year development lifecycles and global distribution requirements, others have heavy regulatory and testing requirements, all of them though can leverage some of the benefits of agile development.
When an agile project has more than two teams that are remotely distributed you need a different development model for managing and coordinating work. One approach is to implement a Feature Team approach which emphasizes small, co-located development teams working on well defined features which can be demonstrated in consistent iterations. To make this work you need a Program Team to manage consistency, quality and reporting between the Feature Teams and you also need an Architecture Team responsible for building components and frameworks that the Features Teams can use and to ensure a common, scalable architecture. An example framework can be seen below:
This model implies several things. Agile techniques are emphasized at the Feature Team level while classic PMI project management knowledge areas (such as Scope/Risk/Change/Communication/Resource Management etc.) are managed at the Program level. It also implies that the agile concept of a single 'product owner' is broadened to reflect that most large organizations have a collection of individuals with different responsibilities in assessing features and their priorities. The program team would work across the different stakeholder groups to define and prioritize features which implies that on larger agile programs/projects, the Feature teams are formed after the Program team has had an opportunity to lay the groundwork of high level requirements, architecture and overall resources. Although this might sound 'waterfall-ish' it actually reflects more of the tenets found in the Unified Process for the Inception phase which basically advocates a solid understanding of the scope, requirements and risks of a project at level just sufficient that you can begin building software against these attributes.
Obviously, there's a lot to this model and there are some good other sources you can turn to learn how to scale your agile projects. I presented a powerpoint on this topic last month called Scaling Agile and Philippe Krutchen has an excellent piece that explores this topic in more detail: Scaling Down Large Projects to meet the agile sweet spot.