Entry/Exit Three Amigos are agile rituals that facilitate a minimum level of shared understanding for the units of work that flow in and out of a team's value stream.
The Agile Alliance definition of Three Amigos explains what and why, but is not prescriptive over the process. The implementation details are left up to the practitioner to fill in.
Agile Alliance Definition:
Three amigos refers to the primary perspectives to examine an increment of work before, during, and after development. Those perspectives are:
- Business - What problem are we trying to solve?
- Development - How might we build a solution?
- Testing - What about this, what could possibly happen?
Entry/Exit Three Amigos Process
So, a Product Owner, a Developer, and a Tester walk into a bar, sit down, and begin to talk about something that the system under development should do. The Product Owner describes the user story. The Developer and Tester ask questions (and make suggestions) until they think they can answer the basic question, “How will I know that this story has been accomplished?” -
Keeping in mind a Lean Startup (Continuous Delivery, DevOps, Product Driven, etc) mindset, the conversation should revolve around a hypothesis, what does done look like, and determining ways to extract learning outcomes. They should occur at least twice, entry and exit, per backlog item that makes its way through the value stream. Additional ad hoc amigos meetings should occur as the details of the work, or customer, demand necessary pivots.
I would prefer the amigo personas to be named: Product, Engineer, Quality. Different nomenclatures that create a slightly different picture. At its best, this would be a two minute meeting between the product owner, a software developer, and quality/automation specialist about the feature outcomes. At the other extreme, it becomes an extended conversation that yields to a refinement meeting. Teams should not work on items in which the scope and vision cannot be agreed upon.
Team members may step in and fill a persona, when the subject matter expert is not available, if he/she has the necessary domain knowledge to put on that 'hat'. IE an engineer putting on a 'Quality' hat.
Suggested Process
A checklist makes a great starting points to adapt a new process. The following checklist are team artifacts that I have used to help initially facilitate these meetings. This is a team skill. Start small with relatively well defined work items!
Entry Three Amigos Checklist
[ ] - Product backlog item meets team definition of ready
[ ] - Each amigo represented: PO / DEV / QA
[ ] - Time-boxed at 15 minutes or less
[ ] - Target outcomes (hypothesis) presented
[ ] - Feature introduced by subject matter expert
[ ] - Similar system functionality identified
[ ] - Conditions of satisfaction (gherkin) finalized
[ ] - Three amigos agree upon definition of done
Exit Three Amigos Checklist
[ ] - Product backlog item meets team definition of done
[ ] - Each amigo represented: PO / DEV / QA
[ ] - Time-boxed at 15 minutes or less
[ ] - Feature introduced by DEV
[ ] - DEV demos conditions of satisfaction
[ ] - QA / PO accepts or rejects user story transition
Latest comments (0)