Predictable Global Delivery through Acceptance Test Driven Development

Prashanth Balakrishna
Prashanth Balakrishna
Director – Delivery
1 December '16

Orchestrating the delivery of a mission critical project through a Global team requires heightened collaboration. If the key team members across geographies are not in sync with the business requirements of the project, we have a recipe for disaster.

My team recently completed four successful releases of a complex Enterprise System for a large US Client. The geographically distributed Business and IT teams discovered that Acceptance Tests can be a powerful way of getting in sync with each other on requirements. Acceptance tests became the basis for the development team in India to Design, Build and Test software, and rollout to production with zero critical issues.

If this sounds like any other IT-outsourced project story, read some of the challenges below:

  • The Client had never worked with an IT team in a different geography.

  • The development team, located in India, needed to understand a complex business area (US Healthcare), to which they had no exposure. Any meaningful feature development could only be done after the technical team developed deeper business knowledge.

  • Regulations necessitated software changes within a short span of time, so all the work had to be done under tremendous time pressure.

  • The Business team was not familiar with Agile or Iterative software delivery processes but wanted incremental high-quality deliverables.

I wouldn’t blame you if you thought that this project was headed south and would likely to be an addition to the statistic of failed projects.

Recognizing the above risks, the senior management from the Client as well as Opteamix invested a lot of time to remove the barriers for Global team collaboration and instituted several practices to address the above challenges. Some of these practices were intentional and others were happy accidents, but they all came together and helped us successfully deliver high-quality software releases. More importantly, it brought predictability to the overall software development process and built a solid trust between us and the Client.

I have outlined some of the tactics we employed through the lens of the Tuckman Model – Forming, Storming, Norming and Performing. 

  • Getting the right team - Forming: We knew upfront that the key technical talent joined the team had to truly understand the business domain. We spent a lot of time on hiring, in collaboration with the client. A combination of US-based and India-based developers were picked, and were fast tracked through business domain training.

  • Resolving initial conflicts – Storming: Several initial conflicts centered around development process, communication and the technical team’s interpretation of business requirements. The Senior management had to step in often to smooth things over during the storming phase. We discovered that when the technical team played back the business scenarios -written as test cases, the business team could clarify the understanding faster. This meant that the technical teams had to write acceptance test scenarios before they even wrote a line of code, and business teams had to sit through marathon meetings reviewing test scenarios. The benefits of this process were soon evident, we had our stormy first release, slightly elongated but with minimal UAT issues.

  • Formalizing the development process - Norming: After we realized the benefits of acceptance tests and how we could get business and technical teams to be on the same page, we refined the development process and during the second release solidified as well as formalized the development process.

  • Creating a repeatable model - Performing: The success of the second release with no critical issues was a great confidence boost to the team. Enthusiastic collaboration continued through the subsequent releases, and we fine-tuned the Acceptance Test Driven Development process. The team’s collaboration steadily improved and as the business knowledge of the technical team’s increased, the Acceptance Test Review meetings became shorter, and the team velocity improved. The next three releases were delivered at a faster pace with no surprises either in UAT or in Production.

In the beginning of this post, I referred to intentional practices and happy accidents that led to the success of the Global Delivery. The deliberate hiring of top technical talent, that also had the ability to learn business quickly, was a deliberate move. The discovery of acceptance tests was a happy accident. As a global team, we discovered that everyone got onto the same page faster when technical teams played back Acceptance Tests to the business team. As the business team started seeing the deeper understanding of business developing within the technical team, the most important ingredient of success – “Trust” was built. A predictable software delivery ensued -- leading to customer satisfaction.