We are proud to say that the Endava is our gold sponsor at the 4th Agile Serbia Conference. On the DEV stage they will introduce you with the speaking session āHow to fit security testing in each sprintā? Also, sent us a great blog post by Thomas Behrens, Endava’s Group Head of Analysis and shared experience about Domain knowledge.
Although agility and distribution 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: the refinement of the requirements in agile projects is based on a communication promise given with a user story and usually the geographical distribution cuts right through this communication flow. This raises the question of how this gap can be closed to ensure the team creates the right product. There are a few enablers we gained experience with, such as “Domain Knowledge as a Catalyst”, “Skills instead of Roles” and “Communication Promises, yes, butā¦!” In this blog I focus on the role of Domain Knowledge as an enabler in distributed teams.
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 organizationā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.
Original post you can find on this link.
