Distributed Agile – Closing the Gap Between the Product Owner and the Team

Domain Knowledge As A Catalyst

Although agility and distributed teams are seen by some as contradictory, the number of distributed and agile software development projects continues to increase. The discovery of requirements is particularly affected by this combination of factors because the refinement of the requirements in agile projects is based on a communication promise made in a user story and geographical distribution can cut right through the effectiveness of that communication around the story. This raises the question of how this gap can be closed to ensure the team creates the right product.

At Endava we’ve been trying to solve this problem for some time and we have gained experience with a couple of approaches for minimising it, namely "Domain Knowledge as a Catalyst", "Skills Instead of Roles" and "Communication Promises, yes, but…!". In this article I will only address the first approach - "Domain Knowledge as a Catalyst".

INTRODUCTION

I look after the business analysts within Endava, who fill the roles of technical or business analysts within Scrum teams. Often they play the role of a Proxy Product Owner, trying to bridge the distribution gap between the team and the Product Owner (PO). However, in some cases, where we have the domain knowledge, Endava also provides the Product Owner for a product.

The way that we see the skills of Endava’s business analysts within a wider project context is shown in Figure 1.

Figure 1 - The Business Analysis Value Pyramid

This diagram shows how Endava’s business analysts connect with our clients in order to add value to our projects. If we look at our BA value pyramid, our foundation is a set of Business Analysis (BA) Core Skills, the middle level is domain knowledge and the top level is client specific knowledge.

The Core Skills include specific BA technical skills (tools and techniques), like story-boarding, and soft skills like the perseverance to drive open questions to closure to successfully engage in agile business analysis.

Domain knowledge is the subject matter expertise in the business domain of our clients, such as understanding the merchant acquisition process in the payments industry.

Finally, the specific client knowledge covers the organisation’s processes and systems, such as fraud identification within an insurance client’s claims process, as well as specific domain context that may be the client’s unique selling point.

Unfortunately, if we put ourselves into the shoes of our clients, we find that their perspective on the value pyramid doesn't look like the neat and stable shape in Figure 1, but is really an inverted pyramid like the one in Figure 2.

Figure 2 - The Client's Perspective on the Value Pyramid

BA core skills, like the ability to create a Story Map are essential, but are rarely requested by the client, so it is difficult to "sell" them. However domain knowledge is much more valuable and having real knowledge about the client and his environment creates genuine delight. So overlaying the two perspectives, as shown in Figure 3, leaves us to focus on domain knowledge, which we do particularly for new clients where we are building their trust in us.

Figure 3 – A Combined View on Business Analysis Skills

You may be familiar with the saying ‘there are no stupid questions”. So while asking a payments client what a CVV code is in a first meeting may not be stupid, it will definitely not impress the client. We have found that the time when, as an IT service company, we can afford to lack an understanding of our clients’ business domain has long since passed.

So how do we go about solving this problem, when we are exposed to multiple domains but we can’t afford to keep a very large group of domain experts “on standby” in the hope of needing them? How do we build the trust to bridge the gap between our client's business and our distributed teams of expert software engineers?

Figure 4 - Building Domain Knowledge

The key to our approach at Endava is making appropriate investments in specialist domain knowledge, where “appropriate” is aligned to the steepness of the learning curve in the domain.

We make use of what I call the "Reverse Dunning Kruger Effect". The Dunning Kruger Effect is a cognitive bias in which people of low ability have illusory superiority. What's the reverse of this? I observed (admittedly without a scientific analysis) that on the contrary, experts with long-standing experience in their domain appreciate other individuals making an effort to comprehend the context and the basics of their (very complex!) domain. As a result, we initiated "Living Domain Glossaries" and "Domain Boot Camps" to climb up the learning curve with an appropriate cost benefit ratio.

A "Living Domain Glossary" collects all basic information about a domain. It includes a wide selection of publically available information (such as terms, value chains, high-level processes and systems) combined with examples from the projects that we carried out at Endava. The information was originally gathered as part of a programme we called "Let's Share Domain Knowledge" and is continuously maintained and shared. It provides an entry point for individuals to understand the basics of the domain and to establish an internal network of people from which to draw further information. In some areas this knowledge is maintained by domain aligned Communities.

The next level a little further up the learning curve are "Domain Boot Camps" in which project teams, following a “train-the-trainer” model, are educated beyond the level that we can achieve using the Living Domain Glossaries. These Domain Boot Camps are sessions that are run by internal or sometimes external subject matter experts to provide project or account specific content around key topics in our important domains, like asset and wealth management, or specific parts of the payments value chain such as merchant portals.

Through these type of initiatives we avoid our people falling into the trap of the Dunning-Kruger-Effect, while building their domain knowledge, using the reverse effect, to allow them to build a trust relationship with our client Product Owners and Product Management Teams.

The other important aspect of this approach is that we are open and honest about what we know and how we can contribute. We are not using this approach to pretend we know more than we actually do. This would backfire quickly and not be in line with our values.

In summary, the role of domain knowledge is becoming more and more important for technology service providers like Endava. The pace with which we need to deliver our projects requires knowledge and interest in the domains that our clients work in. If we look at approaches like Domain Driven Design, one of the strategic tools is a Ubiquitous Language. This language unifies the multi-disciplined team members on the basis of a very contextual spoken and written language that is also used down to the level of the design and implementation, i.e. the source code that ultimately solves the domain problem.

At Endava we recognise the need to move closer to our clients in our sectors and we’re investing to help our people do this and develop the domain knowledge needed to serve our clients better and provide our business analysts with the ability to develop more valuable with them.