done. This helps to identify waste but also helps in scheduling and prioritizing work. A common concern from organizations new to agile development, especially offshore, is the issue of not having all the requirements. Even though requirements are never complete, having the safety net that they are declared to be complete seems to allow people to proceed. By scheduling work based on the biggest problems facing the business that have yet to be solved, the greatest amount of value is delivered to the business more rapidly. Not only that, but due to their importance, these requirements are more often than not front and central and therefore more complete.
Early Risk Mitigation
Early risk mitigation means continuously addressing the hardest issues. In many cases, the most important business priorities are also the most architecturally significant but this is not always the case. So risk must be a constant consideration. Risk shouldn't be postponed because it only gets worse.
Stepping back from the details, the Agile Manifesto
Recognizing the principles previously outlined is valuable, but applying them to an environment that crosses ten-and-one-half time zones, cultures and possibly languages is quite a different task. To tackle this task the first step is to pull back from the details and investigate the source.
The Agile Manifesto investigated
From The Agile Alliance ( http://www.agilealliance.org/) the Agile Manifesto states:
- People and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile Manifesto has typically been interpreted as favoring the left hand side (people and interactions, working software, collaboration and responding to change) so dramatically so that it paints a dark picture of the right hand side. Rather, the maximum value that fits an environment is going to exist somewhere along the continuum of each statement in the manifesto, similar to the way an equalizer is adjusted for ideal sound. The focus on left versus right should be adjusted to fit your environment, as illustrated in Figure 1.
Practices and Techniques of distributed Agile Development
Accepting that a somewhat higher level of formality may be required to address the issues inherent to distributed development, we have found that basing our Agile development processes on the phases of the Unified Process to be the most effective. This allows for the inheritance of phase gate criteria, giving useful internal milestones to the teams as well as serving as a source of artifacts that could be used. Furthermore, we have found that the practices of Scrum fit nicely with the distributed nature of our teams, although some adaptations have had to have been made. With these two high-level guiding lights the following 11 practices have emerged as useful tools to consider:
- Communicate The Contract. It is crucial to provide as much information as possible to the offshore team to ensure they are aware of contract details and restrictions as early as possible. Without this information decisions can not be made. If a team is to self-manage it needs the tools to make informed decisions.
- Release Information Early. When asked, the majority of offshore teams will say they receive information too late and most likely they will also say they don't receive enough. It is extremely important to open communications channels early and keep them open. It is essential that when issues and changes arise they are immediately imparted to the offshore team.
- Onsite/Local Facilitator. An onsite presence typically acts as a conduit between the client and the remotely located development team. The problem is that when