Flexibility Scales
Once you get beyond all of the myths and recognize that it's not a black-and-white world, it soon becomes obvious that there is no one single agile strategy that is right for all situations. This is true even in the most simple of situations, let alone in the complex situations that we usually find ourselves in—teams are made up of individuals, people who have their own unique experiences, skills and preferences. The implication is that we need to be flexible in the way that we approach software process—that a single "repeatable" approach isn't going to work in all situations.
This is particularly true when you scale agile software development approaches, and that to do so effectively you need to recognize that there are many factors to consider. Each team finds itself in different situations, and depending on where it finds itself with respect to these various factors will determine which agile strategies to apply and how to do so. The critical complexity factors are:
1. Geographical distribution. Is your team colocated (working in the same room), near located (working in the same building or city), or dispersed to various locations around the world? Your communication strategy will vary; in particular, the more dispersed your team, the greater the need for coordination and interim documentation.
2. Regulatory compliance. Regulations such as the Sarbanes-Oxley Act and the Food and Drug Administration (FDA) statutes will increase the documentation and process burden on your projects.
3. Entrenched policies, people, and processes. The organization in which your agile team works may be very agile, it may be very traditional, or somewhere in between. Development teams will need to be flexible in the way that they work with enterprise support teams, and similarly these support teams will need to vary their strategy depending on the working styles of the various teams that they support.
4. Legacy assets. Does your system have to integrate with existing assets such as legacy databases, shared services, or legacy systems? Not only will your technical strategy change to reuse these assets, you may discover that you need to refactor them to bring their quality in line with what your team is creating.
5. Organizational distribution. Do you have people on your team from different work groups, divisions, countries, or even companies? This will impact the way that you organize your team, how you organize the work, and how you share information.
6. Degree of governance. If you have one or more IT projects underway, then you have a development governance program in place. How formal is it? Does it enable or hinder agile work practices? Does it add additional overhead or does it help to streamline your work?
7. Team size. The way that you organize, manage, and support a team of 5 people is very different than the way you do so for a team of 50 or 500.
8. System complexity. The more complex the system, the greater the need for a viable architectural strategy, although that doesn't necessarily imply the need for onerous documentation. Many agile teams adopt the Rational Unified Process (RUP)'s strategy of envisioning the architecture early in the lifecycle and then immediately proving that it works via the creation of an end-to-end, working skeleton of the system.
The values contained in the Agile Alliance's Agile Manifesto (www.agilemanifesto.org) implicitly promote the concept that agile is relative, yet it seems to me that we often forget this in practice. More and more we're applying agile approaches at scale and we're finding that we need to be flexible in our approach. We're also finding that at scale, we need to move towards the right-hand side of the agile values more than some agile zealots would prefer. The agile strategies that worked for small, colocated teams developing straightforward systems won't work very well for large, dispersed teams working in regulatory environments on very complex software. Different situations require different strategies, and the best advice that I can give is to embrace change.
