<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4958233&amp;fmt=gif">
RSS Feed

Distributed Agile | Thomas Behrens |
22 September 2020

test Skills instead of Roles

Although agility and distribution are seen by some as contradictory, the number of distributed and agile software development projects continues to increase constantly. In the COVID-19 era we are now faced with teams whose members are all in different locations. The discovery of requirements is particularly affected by this: Since the refinement of the requirements in agile projects is based on a communication promise made through a user story, 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 mitigations we have gained experience with, which I would like to share in this series: (1) “Domain Knowledge as a Catalyst”, (2) “Skills instead of Roles” and (3) “Communication Promises, yes, but…!” This is the second part which explores the notion of favouring skills over roles.


I look after our business analysts, who fill the roles of technical or business analysts within Scrum teams. Often, they play the role of Proxy Product Owners, trying to bridge the distribution gap between the Endava team and the client's Product Owner (PO). In most of our engagements we interact with a PO that is not co-located with the team. In the previous part of this series, I demonstrated the value of domain knowledge in bridging this “distribution” gap. The value of having domain knowledge is irrespective of the size of the engagement. In this part I’d like to focus on smaller agile projects and what we call “Team & Product” in our TEAM (“The Endava Adaptive Model”) SDLC, usually comprised of one to two teams working on a common backlog with a dedicated Product Owner. Nevertheless, a lot of the information to follow is also applicable to agile projects on a larger scale.

You may argue that bridging the gap is not that important as “it is a small project or product”. However, I argue the contrary based on my personal experience. Usually we start working with new clients on a small scale, i.e. with one or two teams. In addition, these clients often do not have experience with distributed teams, agile ways of working, or in fact the combination of both. This means that we have to prove our value, and the risk of creating a gap between the client’s business team and our team working remotely in a new methodology is high.


Figure 1 – Requirement-related roles

Now, what is so special about smaller engagements? We often think in roles and we fill project roles. The discussion with a client’s procurement department is about roles needed on a project, with different prices for different roles. If you work on smaller projects, some of these roles are just too broadly defined. Figure 1 shows different roles that are connected with the discovery of the product and with obtaining an understanding of what needs to be built. The reality is that some of these roles may come from the client, some from Endava, and some from other service providers or independent freelancers. Some of these roles may be filled part-time and not fully allocated to our product. All in all we have a number of dependencies on the project context:

  • Confusion about the skills attributed to a role (Take a look at a previous article on how the skills expected from the role of a Product Owner can be provided within the team.)
  • Capabilities and skills of the people involved
  • Skill distribution between the client, Endava, and potential other involved parties
  • Distribution of the team members across the project locations
  • Project type, i.e. is it more innovative, explorative, requiring more product discovery techniques, or driving the demand for different skills?
  • Product stage within the product lifecycle


Considering the above, you might agree that the question we have to answer is not “Do we have all roles filled?”, but rather more specifically, and more challenging: “Do we have all skills available in the right place at the right time in this team?” Unfortunately, the latter question is more difficult to answer, which is probably why it is often disregarded and substituted with the first one which is easier to answer.

Here is an example of this challenge: How can we answer this important question when it concerns a combined product team comprised of people from our client, their other service providers, and the Endava team? Naturally, the question is quite easy to answer for our own Endava team. I provide some insights on how we manage this within my business analysis discipline in the next section. But what about the client’s personnel? We do not often get the opportunity to interview the client Product Owner about their availability and skills before we start a project. With other service providers, getting this information can be even more difficult. Agility is about transparency and openness, but unfortunately this collides with reality when it comes to sales and competition.

So how can we solve this? There is no silver bullet, but we prefer to engage with our clients before the contract is signed to understand their problem, experience, and people and to get to know them as well as possible. Collaborating in workshops and engaging a diverse selection of team members, not just procurement and the management team, will provide answers through interaction and building bridges. Furthermore, carefully monitoring the effectiveness within the team over the first weeks and calibrating the team composition if necessary can contribute to a successful team integration.


“A developer develops. A tester tests. A business analyst analyses.” This quote is an example of role-based thinking, which is often too simplistic, especially in small team environments. I know developers who are extremely versed in discovering requirements together with a client. I know testers who validate requirements long before they are implemented, ensuring the right product is being built.

value contribution

Figure 2 – Endava Business Analyst’s value contribution

We chant the mantra of cross-silo thinking. The focus on skills over roles supports this since skills may be present independently from the role. In Endava’s business analysis discipline we decided to profile skills for the first time back in 2013. We coined the term “Core Skills” to identify important tools and techniques required to support successful delivery and to abstract them from the roles in the discipline.

Our profession changes, our customers and projects change, but roles do not adapt that quickly. However, we need to adapt quicker which is why we began assessing through surveys the actual skill demand regarding what is used on our projects and not what is important for the roles in our profession in general. This allows us to drive training and education and to staff projects with the right people. This kind of assessment is very granular and targeted, allowing teams to develop specific tools and techniques and to assess projects against this demand.


In summary, roles are often too broad as a capability definition, especially in small- and medium-sized product teams. In building the business analysis capability within a technical solution delivery organisation, I rapidly learned that a focus on the value added through concrete business analysis skills is more important than offering “a BA role”. Naturally, this notion has evolved as Endava expanded its service offers and our engagements got bigger. Nevertheless, this experience helps to promote and deploy new skills as the business analysis profession grows.

By favouring skills over roles, we move closer to multi-disciplinary and multi-faceted teams that can solve the issues in front of them, which creates mutual trust. By putting emphasis on core agile values and ensuring that teams have all the skills needed, they feel empowered to deliver the product together. This allows them to better connect as individuals, even within a distributed team

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.


From This Author

  • 05 January 2021

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

  • 09 July 2019

    Developing your Product Owner mindset

  • 11 February 2019

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



  • 13 November 2023

    Delving Deeper Into Generative AI: Unlocking Benefits and Opportunities

  • 07 November 2023

    Retrieval Augmented Generation: Combining LLMs, Task-chaining and Vector Databases

  • 19 September 2023

    The Rise of Vector Databases

  • 27 July 2023

    Large Language Models Automating the Enterprise – Part 2

  • 20 July 2023

    Large Language Models Automating the Enterprise – Part 1

  • 11 July 2023

    Boost Your Game’s Success with Tools – Part 2

  • 04 July 2023

    Boost Your Game’s Success with Tools – Part 1

  • 01 June 2023

    Challenges for Adopting AI Systems in Software Development

  • 07 March 2023

    Will AI Transform Even The Most Creative Professions?

  • 14 February 2023

    Generative AI: Technology of Tomorrow, Today

  • 25 January 2023

    The Joy and Challenge of being a Video Game Tester

  • 14 November 2022

    Can Software Really Be Green

  • 26 July 2022

    Is Data Mesh Going to Replace Centralised Repositories?

  • 09 June 2022

    A Spatial Analysis of the Covid-19 Infection and Its Determinants

  • 17 May 2022

    An R&D Project on AI in 3D Asset Creation for Games

  • 07 February 2022

    Using Two Cloud Vendors Side by Side – a Survey of Cost and Effort

  • 25 January 2022

    Scalable Microservices Architecture with .NET Made Easy – a Tutorial

  • 04 January 2022

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 2

  • 23 November 2021

    How User Experience Design is Increasing ROI

  • 16 November 2021

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 1

  • 19 October 2021

    A Basic Setup for Mass-Testing a Multiplayer Online Board Game

  • 24 August 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3

  • 20 July 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2

  • 29 June 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 1

  • 08 June 2021

    Elasticsearch and Apache Lucene: Fundamentals Behind the Relevance Score

  • 27 May 2021

    Endava at NASA’s 2020 Space Apps Challenge

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 12 January 2021

    Data is Everything

  • 05 January 2021

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

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

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

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed safe PI planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

  • 15 May 2020

    Performance and security testing shifting left

  • 30 April 2020

    AR & ML deployment in the wild – a story about friendly animals

  • 16 April 2020

    Cucumber: Automation Framework or Collaboration Tool?

  • 25 February 2020

    Challenges in creating relevant test data without using personally identifiable information

  • 04 January 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

  • 10 December 2019

    AWS Serverless with Terraform – Best Practices

  • 05 November 2019

    The Twisted Concept of Securing Kubernetes Clusters

  • 01 October 2019

    Cognitive Computing Using Cloud-Based Resources II

  • 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