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
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.