One of the cooler things I saw teams do this year is the idea of a “Three Amigos,” session. Basically, before an individual takes on a new task from the board, they ask a couple of peers to do a quick sense check on the task. It’s a great idea because its so easy to be too close to a solution, and miss some architectural intent, or business value by simply getting on with it.
The first time I saw it done, it really helped a team who came under pressure due to changes forced upon them from upstream. Although the team had plenty of talent to respond to the changes, they wanted to be more proactive. The team had very strong business analyst support, but often the design mutated before a feature was tested fully. Having clear policies and definition in place made it easy to see a great solution. It also brought a new verb to the English language.
Amigoing (verb)-To amigo with some other people-(preferably 2 other people).
The idea is simple, whenever you pick up a new card from the board, you check with a couple of other people that what you are about to do is in-line with what is expected. So you and your two “amigos,” can make sure that you don’t run into trouble at the end of the task.
Ideally, a developer would choose a tester, and perhaps a business analyst, and then break out for ten minutes to run through the user story. Things to check are design guidelines, user experience, definition of done, and any appropriate governance. Perhaps the session will cover a bit of sketching too, which is great as it galvanises everyone’s understanding of the problem. domain. Just for the sake of a ten minute, lighthearted chat, you can save a sprint’s worth of rework to get back on track.
Of course it doesn’t suit all teams. I saw the idea fall flat with another team. Again, highly skilled individuals but in this case they had not found a problem with their understanding of requirements mid sprint. They were confident that they knew exactly how to proceed, and there was no reason to do another sense check. Introducing amigoing too soon, just made the team see it’ as yet more time wasted chatting.
I don’t think you can ever fault a team for wanting to align its effort with the customer’s need. In a self organising team, amigoing is a feedback loop which can help avoid waste due to building the wrong thing. However it is more effective as a fix to a problem, for instance if an implementation has an obvious architectural flaw. A team needs to experience the need for amigoing before it will truly embrace it.
