State of the art descriptions of Agile best practices generally focus on process enhancement within a single, co-located team. And certainly there are enough new concepts to stay busy within that simple team layout. But in reality, EIS development in single team, single location team configuration are rare. Most enterprise development today involves multiple teams, distributed across multiple locations and time zones, with dependency on one or more vendors. How do the established concepts of Agile (and other modern SDLC) scale to address the complexities of these real-world team structures?
A large number of factors contribute to the complexity of highly distributed team development. One key factor is that different teams evolve different adaptations of Agile, and may not even be Agile in the first place. Several important authors discuss agile best practices for distributed teams, including Mike Cohn in Succeeding With Agile. Generally the recommendation is simple: Don’t distribute if you can avoid it.
One thing is certain: there is value in highly distributed development when executed well. 24 hour working cycles, risk mitigation, capability specialization, and economics. These trends are here to stay and will increase over time.
What are solutions and best practices for distributed, cross-vendor execution teams? I will share my experience in upcoming posts. I’m certain that Agile and other leading-edge SDLC will continue to expand and mature to include these scenarios, and this evolution is happening right now. SAFE makes some inroads but is not yet the answer. One thing is certain, these new areas of practice will lead to tremendous gains in efficiency since the potential for leveraging distributed teams is high.
Recent Comments