The Three Amigos
- Processes, standards and quality
- Technologies
- Others
The difference between what a customer really wants and what a development team thinks may cause real troubles. The Three Amigos helps to avoid such situations.
(Not that) long time ago…
Once upon a time in the West (or somewhere else) there was an agile team that solved even the toughest problems with the great dexterity. There was no daredevil among tasks that was able to defeat them.Their technical skills were incredible and the velocity was very high – they used to finish sprints with an ideal burndown chart. Until that one sprint. Until that one ticket.
Everything started inconspicuously. When the developer saw that ticket at the top of a sprint backlog, he was nowhere near aware what was going to happen. It was all about adding a new web service method, quite similar to the ones developed in the past – a piece of cake. He assigned the ticket to himself, read the description and started development. After a couple of hours he had it finished – so the ticket was moved to tests. A quality assurance engineer picked it up, checked everything thoroughly, and then sent it to a product owner for a review. Everything went as usual until the product owner took a look and moved the ticket back. In theory, everything was fitting the description in the ticket, but in practice the result the product owner got was different than expected. The web service returned the response with the expected results, but the website that was using the service displayed the results with no date – while it used to show it for each result when it was using an old method. After a short investigation, the root of the problem was found – the method returned the date with milliseconds while the old one was using only seconds precision. So the second precision was the only one the website was able to handle.
The team felt challenged to a duel. When the clock stuck high noon, the developer and the returned ticket stood back to back. Three… Two… One… Draw! Few shots rang out and the date precision was changed. The quality assurance engineer tested the change and also did the regression testing to be sure the fix had not broken the functionality – and moved the ticket to the product owner again. This time he was happy. So was the agile team, but not without a bit of uneasiness. They used all their skills to deliver an expected product and, in fact, they managed to do that in the first attempt… but the product owner did not get what he wanted, though. So after discussing the situation during the retrospective, they decided to introduce a new type of meetings to prevent such incidents in the future – the Three Amigos. From that time the product owner, the developer and the quality assurance engineer started to meet before letting a ticket sneak into a sprint. During the meetings they shared their points of view, raised any potential blockers and discussed anything that had come to their minds – so that they were able to get a shared understanding of every detail any of the three amigos was capable of thinking of.
A piece of theory
The difference between what a customer really wants and what a development team thinks is expected is a common topic of jokes, but when it leads to real troubles, it is not funny anymore. The reason of the misunderstanding is usually the fact that a customer is not familiar with technical details and a development team is not able to look at a problem from a business point of view. There are also various points of view inside a team – for example between developers and quality assurance engineers. Therefore, the good understanding between those three groups the most involved in the process is the key factor for the success. They should collaborate like friends who share knowledge and discuss features together. There is a bunch of regular meetings that are very helpful to agree the requirements for a feature to be developed in the Agile process – e.g., the planning and the backlog refinement. There is also a meeting called the Three Amigos that usually happens instantly when needed.
The meeting is facilitated by a person representing a customer – a product owner or business analyst. The person meets the team – a developer and quality assurance engineer – and creates an opportunity to share the domain knowledge and answer any questions that the team might have in order to deliver the functionality that meets the expectations. The discussion is the most beneficial when the team members are the particular people that are going to work on a given feature. Developers have a chance to get clarified anything they need to understand in order to deliver software. This is also a good time to address anything that might stop development or testing, for example, lack of credentials. Quality assurance engineers give their thoughts based on testing experience – for example, they may ask about the appropriate software behaviour in some edge cases that are not covered by the already-created scenarios. Therefore, such a meeting usually results in test scenarios that could be later automated. The “three” in the name refers more to the groups that need to be represented, than to the exact number of people. There may be, for example, two developers, one BA and two QAs – or any configuration that is convenient in a particular case. The other groups of people involved in a development process are also welcome to join – e.g., an architect or a team leader.
Example
The business needs an integers calculator. Addition, subtraction and multiplication have already been implemented and accepted. Now, there is a request for division to be available as well.
A Business Analyst creates a user story that describes the requirements. If they want to use Gherkin, that may look as follows:
Feature: Division
As a calculator user
I want to be able to perform a division operation
So that I can get the results of dividing one number by another.
Then, the BA might prepare some test scenarios to specify the requirements.
Scenario: Correct division
Given I have the calculator application open
When I choose the division operator
And I enter the first number
And I enter the second number (different than 0)
And I press Enter
Then I get the result of dividing the first number by the second one.
Scenario: Dividing by zero
Given I have the calculator application open
When I choose the division operator
And I enter the first number
And I enter 0 as the second number
And I press Enter
Then I get the message “Incorrect parameter provided”.
Let us assume the BA does not have any other scenarios in mind so is ready for the Three Amigos meeting. He or she gets a QA and a developer from the team that is working on the software.
The team members read the story and the scenarios and then give their thoughts. For example, the developer might ask for an expected accuracy – then the BA could specify that in the first scenario and add the last step: “And the result is calculated up to two decimals”. Then the developer might also want to know how to round the result up. The BA adds:
“And the result is rounded up or down to the nearest decimal”
Then the QA could have a question about the case of 5 as the third decimal – should that be rounded up or down? There can also be some doubts about the expected format of the result in case there are less than two decimals to be displayed – should zeros be shown to match the 0.00 pattern? What is more, the QA could raise some edge cases that would result in adding more scenarios – e.g., giving an incorrect input, giving no input, entering the numbers out of range (the BA could then specify the range of numbers that are expected to be handled).
Summary
The Three Amigos helps to improve the common understanding of the project that is essential for a successful collaboration. For example, if the product owner and the team members from the introduction story had met and discussed the new web service method, they would have had a chance to avoid the problem. The team members knew the expected parts of the new method response and they were aware the date was one of them. Therefore, the developer implemented the solution in the way he thought was the best – what meant, among others, the most precise date. The quality assurance engineer checked the response elements according to the list in the description – the date format requirements were not described in the ticket so he or she was happy to see a standard date time stamp. During the Three Amigos meeting the developer might have asked for the expected date format or the product owner might have mentioned that the new method was going to replace the old one in one place on his website – so the team might have had a chance to suppose that all formats should be consistent in both methods.
To sum up, the Three Amigos is one of ways, for a team, to agree on how the outcome should look like. By talking to quality assurance engineers and people representing a customer, developers get a chance to gain enough information to build the right product – and to do this right.
