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.

INTRODUCTION

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

THE CHALLENGE

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.

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

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.

CONCLUSION

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