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

Agile | Thomas Behrens |
05 January 2021

'COMMUNICATION PROMISES, YES, BUT…!' 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. I shared in previous articles how using 'DomainKnowledge as aCatalyst' and 'FavouringSkills overRoles' can help to address this challenge. The third and last part, 'Communication Promises, yes, but…!', explores the appropriate use of established business analysis tools to improve an agile remote working environment - even across hundreds of home offices. INTRODUCTION

Since the introduction of the Business Analysis practice in 2013, I have been looking after our business analysts at Endava. Often, they play the role of agile business analysts supporting our client Product Owner (PO). In most of our engagements, we interact with a PO who is not co-located with the team. In the previous part of this series, I showed how deviating from a strict role model helps to improve a successful interaction at this boundary. In this part, I will focus on the tools and techniques of the business analysis practice.

These tools and techniques are defined by a number of industry bodies for our profession. The International Institute of Business Analysis (IIBA), which Endava is a member of, defines knowledge areas into which these practices are grouped, such as 'Strategy Analysis' or 'Elicitation or Collaboration'. Depending on the context a business analyst works in, the emphasis on the different practices can vary significantly. Someone who creates user stories as part of an elicitation exercise is doing business analysis as much as someone who works out what the next payment product is to surprise the market with.

How do we know what is required for our projects? Within our business analysis practice, we define a set of 'Core Skills' (see previous article for further background) based on a sampling of our projects with business analysis engagements as well as market observations and industry trends. Having determined the set of tools, we need to further ensure we are using this subset of analysis tools and techniques in a way that supports our distributed agile delivery process.

THE CHALLENGE

A user story is not a requirement, but it is a communication promise. It is a promise to have a dialogue whenever it is needed. Keeping a verbal communication promise is harder in a distributed working context. Virtually walking to your Product Owner's desk is harder. Talking about tasks without a whiteboard is harder. Engaging with other team members is harder. We all know it is not impossible, but it requires more effort.

We continuously address some of these challenges by improving our workflows. Such changes can start very simply, for example by announcing your availability or indicating when you are busy in the collaboration tool you use, or by using virtual whiteboard tools effectively. But a key factor is to avoid meetings for verbal explanation when they may not be necessary. How? 'Complement the communication promise!'

COMPLEMENTING THE COMMUNICATION PROMISE First things first, we do not want to avoid verbal communication in general. Such an approach would be doomed. To make the most of verbal communication, communication promises can be enhanced with lightweight, temporary documentation. So, when a communication promise is made, ask some forward-looking questions. The responses can be captured with appropriate analysis tools like an entity model, the definition of the context, or by recording some state model for key business concepts.

Does this mean going back to the 'good old days' of up-front documentation? Surely not. Let us consider a photography analogy: by moving from analogue to digital photography, we moved from the darkroom to 'Lightroom'. We still use techniques like depth of field to emphasise a specific object, though nowadays we have other options to achieve this, like using blurring in your favourite photo editor rather than the aperture of your camera. In the same way, I can use a lightweight domain model to ensure we capture key concepts without having to create a formal model; some years back we might have attempted to solve this with a model-to-code transformation.

Let us not throw out all the established tools in our field but rather use them appropriately for the individual context. The usage of these tools is not black or white; the art - or better, experience - is to find the right level of detail and formalisation in the use of tools and techniques. The following table shows three examples to illustrate the two ends of the scale.

Tool	'Light' - less detailed	'Formal' - more detailed
Domain Model	Identification of Domain Concepts and brief description of the most important ones; optionally, key attributes which help people understand the concepts	Detailed description of all Domain Concepts, including attributes, operations, and value range; description of the relationships; definition of synonyms; graphical representation as class or collaboration diagrams
Scenarios / Story Maps	Rough structure referring to the Domain Model; descriptions based on cards, keywords and/or bullet point lists	Granular structure; consistent use of (visible) references to the Domain Concepts and their attributes; reference of states and transitions back into the scenarios; use of standardised formatting or even modelling tools
Life Cycles	Identification of a few key states of central Domain Concepts; possibly simple state diagrams mainly used for analysis purposes that are not preserved	State diagrams with (possibly) hierarchically structured states for all important Domain Concepts, including descriptions for the states; transitions being referenced back to use cases or parts of use cases (e.g. alternative flows).

Table 1 - Level of detail and formalisation

We harvest this information and guidance in our own delivery model TEAM ('The Endava Adaptive Model'). In the specific case of agile business analysis tools, we went one step further.

Why re-invent the wheel? There is a popular approach in agile software product development established by Ellen Gottesdiener called 'Discover to Deliver' (D2D). We worked with Ellen and integrated this approach into TEAM. The D2D approach provides the essential planning and analysis practices you need to collaboratively deliver high-value products.

D2D uses '7 Product Dimensions' and 'Structured Conversations' to understand the product options you have from different angles and understand the value they create. We use this highly visual framework to decide on the appropriate analysis tools we utilise for the dialogue within the team or with the client's PO. It also helps to decide where to create documentation to provide context, for example, on the small scale for a user story satisfying the 'Definition of Ready' or on the large scale for the entire backlog to remain healthy.

CONCLUSION By appropriately using existing core business analysis tools, we can effectively support a distributed agile delivery model. This approach complements the agile communication promise effectively and keeps parts of the communication promise through temporary, but relevant, written communication. We use our TEAM delivery model to harvest this experience and share it amongst our teams. This allows our teams to improve their communication and better connect as individuals, even within very widely distributed teams. Thus, it is another building block in closing the gap between the client's product owner and the team.