Enabling Agility and Quality in large product organisations

1) The challenge

Agility has permeated the IT world as a proven set of values, good practices and methods that help empower software development to keep track of an ever-faster changing world. Integrated with architecture paradigms such as microservices individual teams gain the flexibility to make decisions about a wide range of issues, such as approach, architecture, technology stack, and tool chains based on their concrete needs.

Driven to the extreme, this would result in quite heterogeneous landscapes, both with regard to technology as well as regarding methodology. While in some situations, particularly in small organizations favouring the high velocity, the added flexibility outweighs the drawbacks. In other organizations, particularly in larger ones, concerns around the feasibility of knowledge management, operational efficiency and similar considerations prefer a higher degree of commonality, reuse and knowledge sharing between teams.

Additionally, there are some specialisms that prove quite challenging to cover from within a single feature team, yet, at the same time can have catastrophic consequences if not handled properly. Cybersecurity, and particularly the secure software development lifecycle is such an area with application performance engineering being another.

So, how can a useable approach be defined that preserves a high degree of agility and flexibility while still retaining the benefits of commonality in specific areas?

2) The non-starters

Let’s first revisit those solutions that fairly certainly won’t work well so that we can get them out of the way:

1. Reverting to a fully predefined technology stack, architecture and specialist teams for disciplines such as test automation or cybersecurity. This is a sure way back to slow, inflexible and error-prone waterfall hell.
2. Ignore the issues and focus on feature implementation. This will not only create and increase inefficiencies but may also lead to issues in areas such as cybersecurity with insufficient in-team know-how. Ignoring these risks is could lead to serious compromises and even hacks of the application.

3) A solution

While there is no silver bullet or be all and end all that will work for all organizations in all circumstances, we used an approach with a number of clients that works very well in retaining agility and flexibility while gaining a degree of standardization and access to specialisms.

We called the chosen approach the “Enabling Layer”. The picture below illustrates what it entails: The feature teams remain responsible for their (part of the) product and have their own Quality Engineering competency in the team.

At the same time, commonly used assets such as API/UI test automation infrastructure and frameworks is maintained and supported by a common team of specialists who can also join any of the feature teams for a limited time, for instance to kick-start automation or to support more complex integrations into e.g. CI/CD infrastructure.

This same Enabling Layer also provides specialist support for Cybersecurity and Performance Engineering. Again, the logic here is that feature teams need to take responsibility for the nonfunctional quality of their product but it is recognized that in any feature team, deep know how of topics such as Cybersecurity is either not available or cannot be utilized full time and, thus, should be shared among teams to increase efficiency and agility.

Subsequently, Cybersecurity and Performance specialists train feature teams, conduct reviews, suggest improvements or support with specific tasks for a set duration. Any knowledge gained with one feature team is communicated and made available to the other teams as well.

We have found that this measure relieves feature teams of niche or recurring tasks (such as implementing a TA framework) while at the same time reducing the number of wheels reinvented and subsequently, waste.