Enabler Teams v Community of Practice: A Field Report From a Large Bank 

In large organizations with several dozen to several hundred developers, there will soon be discussions and questions about the best scaling strategy for agile transformations. Agile working has now arrived in many large organizations.

However, SCRUM – as the most important representative of agile methods – has always had the stigma that it wouldn’t scale well. 10 or 15 years ago, this criticism was perhaps justified, but the method has evolved as it has become more widespread, and today scaling is no longer a problem – at least in theory – thanks to the higher-level project management approaches such as Nexus, LeSS or SAFe.

In practice, however, organizations often still struggle with this, in part because it involves areas that are not covered explicitly in the approaches I’ve just mentioned.  

For this reason, I decided to write this article in the form of a field report that covers one specific problem:  

How can many teams work together on a major software in a way that there are no bottlenecks and few dependencies?

I’m using my experience from a major German bank as an example, where numerous teams created many front-end products in parallel, which used all services from core banking bidirectionally.  

The problem

The above-mentioned front-end ART’s used the classic core banking functions, e.g., to transfer a SEPA transaction or to query an account balance or investment portfolio, which was of course available to customers or bank advisors in all front ends.  

The core banking system itself was maintained by non-agile teams, a circumstance that is probably not unknown to many, and which, for obvious reasons, will still represents reality in large organizations for quite some time.  

To secure access to the core banking system, a special API was designed to allow communication with all ARTs and, of course, the core banking system itself. This is basically a classic and reasonable architectural approach. The recommendations of agile project methods such as SAFe & Co. would lead to the same conclusion. But this is where the problem begins, which must be solved in practice.  

The question is: Who provides this API in such a way that all ARTs, which have to pass through this bottleneck, can still implement their features with full speed, parallel to each other and based on their individual priorities, schedules, and capacities?

Different Approaches

To this end, we discussed three approaches and finally decided on one of these approaches.  

Approach No 1: The Enabler Team 

If you are already familiar with SAFe, you have definitely come across Principle No 1: 

„Take an economic view.“ This means, expressed in a (too) generalized way, “Business Value First” (Mr. Trump also discovered this basic principle for himself).  

At the same time, SAFe recognized the need for certain technical prerequisites in order to create business value. These must be created, even if they do not represent any business value. That is why they are called “enablers”. They enable business value, but they themselves are not.

It’s obvious that, according to Principle No 1, you should always look at the enablers with a certain amount of suspicion and not let them get out of hand. This means that the approach of an enabler team – i.e., not just an enabler story, but an entire team – must always be critically reviewed.  

The enabler team should be a team of specialists who provide the API that all other ARTs then work with.

After all, it is clear that such an API is a neuralgic point in an organization with a business purpose as sensitive as a large bank; both from a technical and business perspective (including data protection, security, fraud protection, compliance, etc.).  

The advantages are obvious:

• A highly specialized team is very efficient. 
• Compliance is well maintained by this one team. 
• Code is developed only once and is available to everyone.
• Uniform code styles and thus good code quality and maintainability. 

But such an approach also involves some risks: 

• The organization can only scale slowly.  
• The team must communicate intensively with all ARTs to find out their requirements, which involves a lot of overhead. 
• Customizing functions is difficult, e.g. the mobile app might want to do without a lot of information that it cannot display anyway for performance reasons, or it might need a special offline mode that other do not need.  
• Prioritizing the requirements becomes difficult, because each ART sees its requirements as highly prioritized. 

Comparing pros and cons obviously only makes sense when reasonable alternatives are available. Because this approach has disadvantages in addition to the evident substantial advantages, and these become all the more apparent the more the company scales, the decision was made to discuss alternative scenarios.  

Just to put the problem into perspective: The ART “mobile app” was added just a few years ago. The bank’s launch of the mobile app was so successful that they experienced their “mobile moment” after only 3 years, the moment in which more transactions were processed via the app than via online banking.

And during this time, online banking was also functionally upgraded more and more. Without these two developments, or even prior to these two developments, the question of an alternative to an enabler team would never have been raised. It is a fundamental question, but a question that can only arise under changing circumstances.  

Approach No 2: Community of Practice (CoP) 

I use the term CoP to describe an alternative approach, although here the term is perhaps not quite correct in its original meaning. But I think it’s fitting.  

This second approach was developed with the aim of not jeopardizing the advantages of the first approach while overcoming the disadvantages of the second approach. For this reason, I won’t compare advantages and disadvantages here, but rather describe the approach. After all, it depends on whether this approach plausibly succeeds in achieving the goal. This should of course not result in any new risks. This is exactly what an organization that chooses this approach should pay special attention to.  

This approach assumes that the shared API exists and that it is technologically available in the same form as in the first approach. If possible, it should implement functions only once, but should also allow for individualization if necessary. It should have a high degree of compliance, i.e. it should comply with the code guidelines specified by the architecture organization and thus of course meet all quality standards.  

And yet it should be possible for the organization to scale at will, allowing ARTs to set their own priorities and implement features according to their own capacities. At the same time – and this is also a key asset in agile project management – should the ARTs be able to strengthen their self-organization and the development of vertical (end-to-end) domain knowledge.  

All in all, these are high demands that go far beyond the technical aspects. This is why all this was not only discussed by architects, but also by various representatives of the entire organization, including the agile coaches who were entrusted with the introduction of SAFe.  

This approach is slightly based on the “open source” model, because open source software is very common today and has found its place in the industry. Almost all companies have collected lasting experiences with it and can now fall back on them.  

This approach brings the ongoing development of the API back to the individual ARTs and the Scrum teams based there. This allows each team to make changes to the API independently. This means that nothing stands in the way of the greatest scaling possible.

But such an approach obviously involves high risks in terms of quality, security, and compliance, which must be be addressed! Because the API still has to be protected because of its special importance

This can be done with the following measures:

Of course, the “best practices” of a DevOps culture also apply here, right up to Release on Demand, so that the individual ARTs and teams can also use the implemented functionalities in their independently defined release cycles.  

Approch No 3: Microservice Architecture 

This approach was discarded very quickly. Not because it wasn’t good or useful, but it was practically impossible to do in this setup. Nevertheless, I would like to briefly mention this approach as a viable alternative, even though we unfortunately could not gain any practical experience with it.

According to this approach, there is no uniform API, but each ART develops its own interface into the core banking system.  

It goes without saying that the same quality standards apply here as well, right up to developer licensing, an architecture sovereignty with respective reviews and tests (especially for write access). At the heart of this approach is the fact that there will be redundancies, because all functions will be set up individually for these ARTs. This also includes custom data storage, which is why this approach is also called the microservice architecture approach.  

Regardless of whether the ART’s real microservices are created in the individual front-end or only an ART-specific API, the ART would be responsible. This would allow each ART to implement its own architecture, which would further enhance the self-organisation of the ART. The effort required is, however, considerable. 

Conclusion 

All three approaches have their place in organizations. It is not possible to say per se which approach should be used. We opted for the second approach at the bank and made great progress with it, particularly in terms of better scalability for the individual ART. I would have liked to try the third approach as well, because there is a lot to be said for it. You should definitely keep an eye on it and perhaps work it out in more detail than I can do here in this article.  

However, the most important aspect was the realization that this question should by no means be answered only from a technical point of view. The answer should always be in the context of the goals of agile transformation.

One should really take the trouble to find an approach that does justice to all goals. At the very least, all perspectives should be examined equally.