Businesses need distributed Agile Development to offer a first class service with 24×7 support. There are strategic benefits in the Agile software development life-cycle (SDLC) outside of cost benefits to this approach.
Distributed Agile Teams
Most teams that try to do Agile Development end up with a Frankenstein process that keeps the spirit but lacks execution. The Agile process will have a daily standup ritual and continuous avoidance of documentation. While Agile Development relies on communication, it can also create gaps. Communication in Agile needs to have a purpose. In most cases it just turns into noise. Here are two gaps that impact distributed Agile Development and how to fix them
Business Process Gap
The team closest to the process understands it best. Distributed Agile teams have great technical capabilities, but generally lack understanding of business requirements. Agile Development should have documentation that captures business requirements. There is a high tendency in Agile Development to not create a Software Requirements Specification (SRS). The SRS is a living and breathing document that needs to be created.
Communication Gap
There is a trend to keep all Agile Development management local. Having leadership in one site is good for executive management but horrible for low-level management. This means global resources have no local points of escalation. Creating proper escalation allows for work to continuously flow and not become blocked waiting for a response. Distributed decision makers will cut the risk that blockers cause development to stop.
Agile Work Distribution Strategies
There are a multiple ways to align Agile Development with outsourced resources to avoid these gaps. Two of the ways are by Development Phase and my personal preference, by Framework Management.
Development Phase Based Work Distribution
This is a more traditional approach for Agile SDLC. One team handles the development and another team handles the testing. This approach is extremely useful when requirements are explicit and clear enough. Daily handoff meetings discuss ambiguities and issues.
Framework Management Based Work Distribution
This is my favorite approach when dealing with Agile remote and distributed teams. It helps to transfer knowledge faster. Agile remote teams tend to struggle with business requirements due to lack of documentation. This process allows the outsource team to learn the requirements through changes more naturally.
Framework Management Example
I have an outsourced team that is working on creating new patterns and libraries. These will enable my local developers to create new applications with boilerplate code handled by the framework. The outsource team has managed to create a Docker based Spring Boot template, a framework for handling UI components, CI/CD tasks, and get everything running on AWS Fargate.
As local developers run into problems with requirements that need help from a framework perspective, they are able to collaborate with the outsource team. The outsource team also can inspect all of our repositories to make sure they are building the best framework they can. We meet weekly with their senior developers (so everyone has a local escalation point) to make sure everyone is on the same page from a project management perspective.
Everyone uses these high value development components – whether for application modernization and/or new development. This has allowed the outsource team to give tremendous value with low ramp up costs. Local developers can stay focused on implementation and raising the overall quality of products.
Conclusion
Globally distributed teams are a huge benefit for multiple reasons, if executed correctly. Mismanagement, assumptions, and lack of clarity on requirements will cause issues and discourage great things from happening.