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. 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 address the first approach.
Business analysis expectations
I look after our business analysts (BA), 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 client product owner (PO). However, in some cases, where we have the domain knowledge, we can also supply the product owner.
The way that we see the skills of our business analysts within a wider project context is shown in Figure 1.
Figure 1: The business analysis value pyramid
This diagram shows how our 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 BA core skills, the middle level is domain knowledge, and the top level is client-specific knowledge.
The core skills include BA-specific technical skills, tools and techniques, like storyboarding, and soft skills, like the perseverance to drive open questions to closure in order 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 client-specific 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 in our clients’ shoes, 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 rarely requested by the client, so it is difficult to ‘sell’ them. By contrast, domain knowledge seems much more valuable, and having real knowledge about the client and their environment creates genuine delight. So, overlaying the two perspectives, as shown in Figure 3, leaves us to focus on domain knowledge. We do this particularly for new clients to build mutual trust.
Figure 3: A combined perspective 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 them. We have found that the time when we, as an IT service company, can afford to lack an understanding of our client’s business domain has long since passed.
Building domain knowledge
So, how can we solve this problem of being exposed to multiple domains but not necessarily being able to have 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 with the steepness of the learning curve in the domain.
The reverse Dunning-Kruger effect
We make use of what I call the ‘reverse Dunning-Kruger effect’. The Dunning-Kruger effect is a cognitive bias where people of low ability have illusory superiority. What’s the reverse of this, then? I observed (admittedly without 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 tackle the learning curve with an appropriate cost-benefit ratio.
A Living Domain Glossary collects all basic information about a domain. This includes a wide selection of publicly available information, such as terms, value chains, high-level processes and systems, combined with examples from real Endava projects. 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 who can provide further information. In some areas, this knowledge is maintained by domain-aligned communities.
A little further up the learning curve are Domain Boot Camps in which project teams are educated beyond the level that we can achieve with the Living Domain Glossaries, following a train-the-trainer model. These Domain Boot Camps are run by internal or sometimes external subject matter experts who provide project- or account-specific insights around key topics in important domains, like asset and wealth management or specific parts of the payments value chain, such as merchant portals.
Through these initiatives, we avoid our people falling into the Dunning-Kruger trap, while building their domain knowledge, using the reverse effect to allow them to build a trust-based relationship with our client product owners and product management teams.
Another 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.
It takes a common language
In summary, the role of domain knowledge is becoming more and more important for technology service providers. 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-disciplinary team members on the basis of a very contextual spoken and written language that is used down to the levels of design and implementation; it's like the source code that ultimately solves the domain problem.
At Endava, we recognise the need to be very close to our clients and their domains. That’s why we’re investing to help our people develop the domain knowledge needed to better serve our clients and provide our business analysts with the ability to develop more valuable solutions together with them.