Maximising the outcome of the Three Amigos Agile workshop
Introduced into Agile workings in 2013, The ‘Three Amigos’ or ‘Example’ workshop is quickly growing in popularity. Why? Because it fosters a shared understanding of the requirements and tests across a Scrum team – while establishing consensus on whether features are ready to enter a development sprint.
Aligned to behaviour-driven development (BDD), this collaborative workshop – usually held a couple of days prior to sprint planning – fulfills the Agile promise of ‘Individuals and interactions over process and tools’, and ‘customer collaboration over contract negotiation’ by exploring and uncovering business rules using examples.
However, guaranteeing a successful ‘Three Amigos’ workshop is no simple task. A common problem I hear during retrospectives is that the workshop takes too long – with too many people involved. From my perspective, what I’m actually hearing is that the investment is just too high.
To avoid potential issues and maximise the value of Three Amigos, it’s helpful to consider your options when it comes to the workshop set-up.
One common approach is to have the business analyst and product owner sit down to discuss the business rules using examples for delivery and testing. Those examples produced should be for specific features for specific sprints. Let’s call this the ‘lone wolf scenario’.
An alternative approach is to get the entire project team together to try and apply a collaborative process using a series of methods to discuss the business rules with examples.
So which approach is better, or is there potentially a different approach we can take – one where the simplicity of the process is further improved upon and overall investment reduced?
The lone wolf
On paper, the ‘lone wolf’ scenario sounds efficient and effective. Nevertheless it’s important to consider what efficiency entails, and what effectiveness means in this context – and specifically, the type of ‘effectiveness’ we desire.
I believe the effectiveness of any workshop is defined by the value it brings versus the cost incurred, however each business is different. Hence, ‘lone wolf’ drastically reduces the cost of the workshop by reducing the number of attendees.
However, it does so without increasing sufficient value, with risks such as the wrong assumption being accepted into requirements, or undeliverable / incomplete features being requested and built into the sprint plan.
The desired value output from a Three Amigos workshop is to collaboratively find the smallest solution for the biggest problem. While the participants of a ‘lone wolf’ style workshop are certainly qualified to identify the biggest problem the project or business is facing, can this team – without in-depth technical experience, for example – be relied upon to accurately conceive the smallest technical solution?
In some cases – for example, where problem domain is well explored and solutions are well known – the answer is ‘yes’. This, though, does not eliminate the need for validation from the wider team.
With that in mind, ensuring the workshop includes all the team undoubtedly improves its value. Collaboration, after all, improves the quality of the requirements we may be given. Yet, this goes hand-in-hand with rising costs implications.
Another approach
Let’s now return to our alternative scenario, where the entire project team gets together. Again, it sounds good on paper: the entire project team and key business stakeholders collaborate to uncover each requirement and talk through the examples and the biggest problems the business faces in a sprint.
But, in my experience, this style of Three Amigos workshop presents as many issues as the lone wolf scenario. For starters, it takes up far more time and resources, and with a larger team in the room, participants can be less engaged than they might be in a smaller group.
So what’s the alternative? Let’s take the example of integrating a store with a warehouse – where we’re implementing the order and shipping codes.
In this example, does having five engineers and two quality assurance experts, but no warehouse representatives, provide all the information needed?
The answer is ‘no’ – because only the warehouse team can supply information such as the length of the order code to be sent, accepted / rejected characters, handling multiple line orders, and structure of order codes sent.
In the same vein, would having five warehouse representatives and zero engineers in the workshop provide information including the structure of the order code we output or how we manage stock? Again, no.
It is at this point I came to realise that only a single representative from engineering and quality assurance is needed to fully validate the proposed solution.
This is a classic example of where it’s advantageous to have a separate workshop with the relevant stakeholders of the warehouse team – away from the majority of the project team. You are able to elicit the requirements of a feature without the entirety of the development team.
The requirements elicited are validated by the client, any third parties and the engineering team, whilst lowering costs versus a traditional inclusive Three Amigos approach.
So why is this approach not the status quo?
My understanding is that it’s usually due to the fact that stakeholders’ availability is far more limited than the delivery team itself, but is there another way?
Finding a new model
It’s a question that inspired us to try a very fluid model for a recent project at Inviqa. In this model, the requirements for a feature are discussed amongst the developer, quality assurance expert, product owner, and business analyst in a very quick and informal way, only when a developer picks up a story. It’s a ‘just-in-time’ approach.
We had a backlog, as most projects do – ours being a story map on the wall. At the end of each iteration, as normal, we looked at what stories were completed and could be removed, which had not been, and which from the next sprint or even further in the future, could and should be incorporated into the next iteration of work.
This was built into a list, which I, as the business analyst, alongside the product owner, then prioritised. Now the developers had a list of sticky notes on the wall in priority order.
Real Options gives project teams the mindset to sidestep blockers, commit frequently to small tasks and continuously deliver value while others in the background uncover the information or mitigate the risks which are blockers.
Following in such a methodology, we decided to delay our commitment to implementation and instead commit to the problems being solved. This forced us to change when and how we discussed the solutions.
Going forward, developers, during stand-up, would make it known they would be picking up a new story. That allowed the business analyst and the product owner time to make themselves available for discussion.
Then, when the time came, the business analyst, the product owner, the engineer, and – if available – the quality assurance expert, and any necessary business stakeholder, would swarm around the list of stickies and talk (in a timebox) through the requirements, as per the Three Amigos workshop.
Features described in the sticky notes were then split into two or more stories – the highest-priority aspect of that feature then being brought into development. The remaining sticky notes for that feature were then prioritised into the story map, or a list of prioritised stories for that iteration.
With around 5-10 minutes dedicated to each story, we are essentially holding a mini breakout session for each story.
Our learnings
By implementing the new process, we’ve made the workshop far less time-intensive.
Based on an average of 30 stories per iteration, the time spent by the business analyst and product owner – in eliciting and documenting requirements – may be comparable to that spent in an inclusive Three Amigos workshop.
However, much less time is spent by each developer, and therefore investment can be drastically reduced.
Additionally, the requirements can be relied upon to be 100% exact as the skills represented in a traditional ‘breakout’ are incorporated during discussions directly with the engineer picking up the task.
What’s more, the new process allows for on-the-fly prioritisation of feature aspects, rather than prioritising further down the line when budget and / or time becomes an issue.
This ensures the most important aspect of features are continuously being worked on, and therefore the team never loses sight of the original problem being addressed.
The value of this approach is clear. Bored faces in long-winded workshops can become a thing of the past. More importantly, this variation on the Three Amigos workshop can lead to a higher-value output while minimising costs.
Perhaps the most interesting learning from this experiment was that focusing on collaboration sometimes means limiting it to smaller groups and shorter bursts. We yet again rediscovered the value of just-in-time – one of the central principles of Agile Specification and BDD.
