<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4958233&amp;fmt=gif">
Article
6 min read
Thomas Behrens

Although agility and distribution are seen by some as contradictory, the number of distributed and agile software development projects continues to increase. In the COVID-19 era, we are faced with teams whose members are all in different locations. 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.

 

There are a few mitigations we have gained experience with at Endava, which I would like to share in this series: ‘Domain knowledge as a catalyst’, ‘Skills instead of roles’ and ‘Communication promises, yes, but…!’ This is the second part, where we explore the notion of favouring skills over roles.

 

Introduction

 

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). In most of our engagements, we interact with a PO that is not co-located with the team.

 

In the first 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’m going to focus on smaller agile projects and what we call ‘Team & Product’ in our TEAM (The Endava Adaptive Model) software development life cycle (SDLC), usually comprised of one to two teams working on a common backlog with a dedicated product owner. Nevertheless, a lot of the following information also applies to agile projects on a larger scale.

 

You may argue that bridging the gap is not that important since ‘it’s a small project or product’. However, I argue the opposite based on my personal experience. Usually, we start working with new customers on a small scale, with one or two teams. In addition, these customers often don’t have experience with distributed teams, agile ways of working or 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
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 be held by the client, some by Endava and some by 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, there are a number of dependencies on the project context:

 

  • Confusion about the skills attributed to a role
  • Capabilities and skills of the people involved
  • Skill distribution between the customer, Endava and other involved parties
  • Distribution of the team members across the project locations
  • Project type, that is, is it more innovative, explorative, requiring more product discovery techniques or driving the demand for different skills?
  • Product stage within the product life cycle

 

The challenge

 

Considering these factors, 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 is more difficult to answer, which is probably why it is often disregarded and substituted with the first one.

 

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 customer, their other service providers and our team? Naturally, the question is quite easy to answer for our own team; I’ll provide some insights on how we manage this within the business analysis discipline in the next section.

 

But what about the client’s team? We don’t often get the opportunity to interview the client PO 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 goals, experience and people and get to know them as well as possible. Collaborating in workshops and engaging a diverse selection of team members, not just procurement and management, will provide answers through interaction and building bridges. Furthermore, carefully monitoring the team’s effectiveness over the first weeks and calibrating the team composition if necessary can contribute to a successful team integration.

 

Core skills

 

“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 that the right product is being built.

 

Figure 2: The business analysis value pyramid
Figure 2: The business analysis value pyramid

 

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 our 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 usually do not adapt that quickly. However, we need to adapt, which is why we began assessing through surveys the actual skill demand: what is actually used in 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.

 

Conclusion

 

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 focusing on the value added through concrete business analysis skills is more important than offering ‘a BA role’. Naturally, this notion has evolved as we expanded our service offers at Endava 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 in a distributed team.

 

No video selected

Select a video type in the sidebar.