Applying Acceptance Test Driven Development (ATDD) in a Bank

Added to Process

My guest for this interview was Sebastián Ismael, a software professional and visiting lecturer from Argentina.


Sebastián has been been with Grupo Esfera, a boutique software consulting company in Buenos Aires, for eight years. The firm serves very large companies in Argentina and elsewhere. He is passionate about the technical side of Agile, specially eXtreme Programming, and he’s also a frequent speaker in national and regional Agile conferences.

For this interview, Sebastián chose to talk about his recent experience coaching a large company in Argentina that has embarked in a massive multi-year Agile adoption. He started by saying that he has been working several months with a team at this bank building a product and using technical practices as a vehicle for changing culture. Providing more context, he mentioned that the team had been working together for over a year but the results were not completely satisfactory, and that was the reason his company was called to help.When he started coaching this team, he identified Acceptance Test Driven Development (ATDD) as a technical practice that can help to build better understanding with the team’s Product Owner. His thinking was that by better defining testing scenarios and automating them, the culture, performance, and internal communication will improve for the team.

Sebastián commented that because ATDD was something new for the team it had a slow ramp up and required learning and training, but eventually started to pick up and ended up producing great results. A few months after adopting ATDD the team was capable of taking a story, automating its acceptance criteria, and starting building the story itself. Nine months into this effort, more positive effects started to be observed — the improvement in interactions with the PO was one of the most significant. The PO changed from someone who used to just used to send work to the team to someone that collaboratively built the product with the team.

Another fundamental change that Sebastián observed was that this team took ownership of the product and all its technical decisions and implications. This team started to operate without centralized decision making, whereas before they used to have a software architect. Motivation is also high as everybody feels more involved. This team also improved other technical aspects and is now capable of putting stuff into production several times per week.

Sebastián mentioned that the product this team is building has many interdependencies with other systems and that several of those were not automated yet, implying that some level of manual testing is still required. Nevertheless, ATDD and other technical practices enabled this team to guarantee that its product is working as expected, with integrating testing automating the next jump. This team had to learn about infrastructure and configuration so they could put its product into production without handing of the work.

Sebastián made two important observations: leadership in this bank fully supports Agile practices, and this transformation effort started three years ago. Speaking of Agile practices, he mentioned that besides XP practices this bank in using things like User Story Mapping in Product Discovery workshops. The combination of all these practices is helping this bank to stay ahead of its competitors.

Sebastián told the story of how a Quality Assurance engineer — with a good attitude, curiosity, and dedication — learned new skills and greatly contributed to the team. This QA professional expanded his knowledge by learning how to automate test scenarios and now is starting to code alongside developers. For Sebastián, this is proof that people can learn things and that collectively building a product is far more efficient than separating the work into specialties.

Sebastián believes that this bank is already committed to Agile, has seen benefits, and will not go back to old practices. The bank still has lots of things to learn and improve but ison the good path for harvesting the fruits of Agile.

In closing Sebastián provided a short definition of ATDD: for him this is a practice in which the PO and the developers together define the acceptance tests before building the product, and these tests guide the development of the product.


About the Author


Juan es un capacitador, expositor y pensador alternativo. Desde que Juan se expuso a Scrum a principios del 2007 se comprometió a continuar aprendiendo y aplicando Scrum en los equipos y organizaciones donde trabajo. Su camino lo ha puesto en los roles de ScrumMaster, Scrum Trainer, y Product Owner. Juan cumplió el 2014 con todos los requisitos del Scrum Alliance para ser un Certified Scrum Trainer® (CST) y es ademas un LeSS Friendly Scrum Trainer.

Como CST y LeSS Friendly Scrum Trainer Juan ha entrenado a más de cuatro mil trescientos estudiantes en cursos de CLB, CSM, CSPO. A-CSM y A-CSPO en diez países del continente americano. Juan también a dado cursos privados para compañías como: Citibanamex, Marsh, Slalom, Deloitte, Walmart, CGI, SAIC, Express Scripts, T.Rowe Price, Time Warner Cable, ViaSat, Garmin, Moffitt, Kyva Systems, Blue Book Network, Insurance Auto Auctions and BlueCross BlueShield.

Juan fue miembro voluntario del Board de Directores del Agile Alliance donde sirvió por dos periodos consecutivos de tres años hasta el 2019.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.