Life at the intersection of finance and technology

Frequent acceptance testing

Today (which is day nine of a ten-day sprint) we had our eighth UAT or user-acceptance testing session. We have these sessions almost every day of the sprint, allowing the testers and the product owner (and usually the designer as well) to look together at the features and fixes being developed by the coders. This is on top of the almost daily code reviews among the development team in which coders look together at elements of the code they are writing to make sure that they all follow similar standards of form, elegance, and test-ability And this supplements the practice of having testers look at the fixes and features locally on the coders’ machines before new code is deployed into the wider development environment. All of these features of our development style are supported by a growing regression suite of automated nightly tests designed to catch unintended impacts from new code and to ensure that enhancements and fixes function as expected once introduced into the broader codebase.

Why do we work this way? It is all in the service of two key principles of Agile: “Business people and developers must work together daily throughout the project” and “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” We surround our entire development process with multiple forms of overlapping testing to ensure that we deliver working software at the end of each sprint – not semi-functional software or software we hope will work but fixes and features with functionality we have proven internally through rigorous testing at multiple levels. And we are convinced that this working software will be much more valuable to our clients when it has been developed with a close partnership between business people and developers.

I have of course written frequently about this close connection and the crucial bridge-building role that the product owner plays in making sure the relevant information flows efficiently among these two groups (you’ll find this in the many blog posts linked to the ‘bridge’ category in the sidebar). There are many of us in my current firm who are convinced that one key to our competitive advantage is our unique combination of extensive market knowledge and outstanding technical talent. This is a big part of why the Agile approach fits so naturally into our company culture.

This approach differs significantly from the traditional waterfall methodology. In the traditional approach, business people lose connection with the development of a product as soon as specifications documents are handed off to the development team. Several months later, they are presented with the end result of a lengthy development process that may or may not have produced the results that the business people actually intended. Often the waterfall approach more resembles this classic depiction of product management: http://bit.ly/18u74ZT.

When we first began to implement Agile in the company where I work, we started with six-week sprints that ended with a presentation by the development team to the product manager and select business users of the results of the project. This presentation often generated additional feedback that would be fed into the next sprint cycle. While somewhat more iterative than the older waterfall model, this early attempt at Agile didn’t yet embody the key principle of significant and regular interactions between the business and development teams that we now utilize. The more closely our business and technology teams have worked together on product development, the better the process and the results have been. Of course we still have plenty of room for growth, but as we continue building out our unit test coverage and our automated tests and as we remain focused on frequent UAT sessions we catch more and more of the potential issues before they go to production.

There are of course challenges inherent in prioritizing the kind of close connections between the business and technology teams that support the development of valuable working software. One key issue is that this approach really requires a knowledgeable and dedicated product owner who can be fully available throughout the sprint. This availability goes beyond the frequent formal UAT sessions and extends to multiple daily questions and interactions between the product owner and various members of the development team. We have definitely found that our most successful development experiences come from teams with a full-time product owner, while teams without such a person encounter more bottlenecks in development and less satisfaction with the interim results. Our frequent UAT sessions mean that the business and technology teams are collaboratively engaged throughout the development cycle, and a strong product manager is vital in that process. In our experience this is helping us have a more effective development process and more satisfied end users as we continue releasing working software every two weeks. Of course, in truth it’s not that simple.