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 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 last part 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 (BA) 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’ve defined a set of ‘Core Skills’ based on a sampling of our projects with business analysis engagements as well as market observations and industry trends – see the previous article for further background. Having determined the toolset, we need to further ensure that we’re 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’s 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’s 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 explanations 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 upfront documentation? Surely not. Let’s 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.
So, let’s 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 (like alternative flows) |
Table 1: Levels 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). The D2D approach provides the essential planning and analysis practices you need to collaboratively deliver high-value products. We worked with Ellen and integrated this approach into TEAM.
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 us 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. IT allows our teams to improve their communication and better connect as individuals, even within very widely distributed teams.