Skip directly to search

Skip directly to content

 

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

 
 

Agile | Thomas Behrens | 11 February 2019

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.

Roles of Domain Knowledge 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.

Roles of Domain Knowledge 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.

Roles of Domain Knowledge 3
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?

Roles of Domain Knowledge 4
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.

Thomas Behrens

Group Head of Analysis

Thomas is Group Head of Analysis for Endava. He has over 25 years of experience in software development which he has gained in various sectors including investment banking, telecommunications, mobile payments and embedded systems. He is focused on setting up distributed agile software development teams and shaping the business analyst force at Endava. When he isn’t doing that, Thomas can be found delivering training or speaking at conferences.

 

Categories

 

Related Articles

  • 17 September 2019

    Cognitive Computing Using Cloud-Based Resources

  • 03 September 2019

    Creating A Visual Culture

  • 20 August 2019

    Extracting Data from Images in Presentations

  • 06 August 2019

    Evaluating the current testing trends

  • 09 July 2019

    Developing your Product Owner mindset

 

From This Author

  • 09 July 2019

    Developing your Product Owner mindset

Most Popular Articles

11 Things I wish I knew before working with Terraform – part 1
 

Architecture | Julian Alarcon | 25 June 2019

11 Things I wish I knew before working with Terraform – part 1

11 Things I wish I knew before working with Terraform – part 2
 

Architecture | Julian Alarcon | 23 July 2019

11 Things I wish I knew before working with Terraform – part 2

Kubernetes Design Principles Part 1
 

Architecture | Armen Kojekians | 30 April 2019

Kubernetes Design Principles Part 1

Developing your Product Owner mindset
 

Agile | Thomas Behrens | 09 July 2019

Developing your Product Owner mindset

Infrastructure as Code with Terraform
 

Architecture | Vlad Cenan | 25 February 2019

Infrastructure as Code with Terraform

Evaluating the current testing trends
 

Agile | Gregory Solovey | 06 August 2019

Evaluating the current testing trends

Creating A Visual Culture
 

Agile | Madalin Ilie | 03 September 2019

Creating A Visual Culture

Extracting Data from Images in Presentations
 

AI | Alexandru Mortan | 20 August 2019

Extracting Data from Images in Presentations

Microservices and Serverless Computing
 

Architecture | Radu Vunvulea | 30 May 2019

Microservices and Serverless Computing

 

Archive

  • 17 September 2019

    Cognitive Computing Using Cloud-Based Resources

  • 03 September 2019

    Creating A Visual Culture

  • 20 August 2019

    Extracting Data from Images in Presentations

  • 06 August 2019

    Evaluating the current testing trends

  • 23 July 2019

    11 Things I wish I knew before working with Terraform – part 2

  • 12 July 2019

    The Rising Cost of Poor Software Security

  • 09 July 2019

    Developing your Product Owner mindset

  • 25 June 2019

    11 Things I wish I knew before working with Terraform – part 1

  • 30 May 2019

    Microservices and Serverless Computing

  • 14 May 2019

    Edge Services

  • 30 April 2019

    Kubernetes Design Principles Part 1

  • 09 April 2019

    Keeping Up With The Norm In An Era Of Software Defined Everything

  • 25 February 2019

    Infrastructure As Code With Terraform

  • 11 February 2019

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

  • 28 January 2019

    Internet Scale Architecture

We are listening

How would you rate your experience with Endava so far?

We would appreciate talking to you about your feedback. Could you share with us your contact details?

 

By using this site you agree to the use of cookies for analytics, personalized content and ads. Learn More