#0021- 3 amigos

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode we discuss the Three Amigos pattern where a product person, a developer and a tester work ahead of the team to define features before estimation. We explore the benefits, challenges and anti patterns of the Three Amigos approach, emphasizing the importance of early preparation, collaboration and testable requirements.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

Hey Murray. Another lovely week in paradise. And I think this week we decided we're going to talk about the Three Amigos.

Yes, the Three Amigos. So Three Amigos is an organization pattern. The idea is that you get a product person, a developer and a tester from your team, most senior people usually, and you work ahead of the team by a week or two to define each feature before you estimate it, so that the developers will have a pretty good idea of what they need to do when they're developing the feature. And the idea is that it saves the team a lot of time and a lot of confusion when they start developing. Yeah.

So the Three Amigos gives us a way of doing some initial exploration, some initial thinking so that we have a little bit more certainty because we've done some research.

Yeah, so before you start developing, you need to do some preparation. Otherwise the developers are confused about what they're doing and they, they can waste an awful lot of time doing things that is not needed. There's this problem that has occurred in some scrum teams where the teams hadn't done any preparation at all by the time it came to their Sprint planning meeting. They'll come into Sprint planning and then it'll be extremely confusing and people start wasting enormous amount of time. So that was the kind of problem I saw where Three Amigos could help. Is that the problem that you're saying too? Yeah.

For pretty much every team I've worked with, the developers feel like there's value in doing that light work up front early. So the Three Amigos has been really useful. And in the data space we tend to have one of the Amigos is the product owner. So they're telling the other two these are the things we need to do. These are what the acceptance criteria will probably look like. One of the other Amigos is in the analysis space, so they have those skills. So they're analyzing those acceptance criteria and the data that may be needed to support it. And the third amigo is typically the more experienced data engineer or architect. So they're coming in with that expertise to look at the platform and the patterns that are already being used and going, ah, okay, we've got a problem because now you're talking about data from Salesforce and we haven't actually collected or plumbed data in from Salesforce yet. So there's a whole lot of work the development team will need to do up front to get that data to start coming in. So that tends to be the makeup of the three amigos when we're in the data and analytics space, it's interesting.

That you don't have a test specialist.

So in the data and analytics space, the person with those analysis skills flip over to testing skills as well.

I agree with you that it's very helpful to have a subset of the team do some preparation and planning for a story before it comes into the sprint because that will make it a lot easier to estimate and plan and build. I just like to add design in there. Design is absolutely critical in anything with a front end and that work really needs to be done at a higher level before coding in my experience. So I would add a designer. I also like the idea of having a business analyst in there because the product owner shouldn't be expected to define all of the detailed rules and requirements and processes around the feature because they have a lot of other things to do.

You've just got to five roles, so you're almost at a scrum team. It's just the poor old developer that's not there. They listening to everybody talk about what needs to be built.

I have tried having the entire team there do this and then we've had a retrospective where the developers have all complained about us wasting their time in these meetings to define all these features. They didn't want to be there, they wanted to send their most senior representative there.

I've had the same experience and I wonder if that's a symptom of an immature Agile team where the developers think their role is to get a spec encode it. And yes, we're not doing the level of documentation we used to do in terms of the requirements of the specification. But they're still in the mindset of tell me what you want to build and I'll go build it, not tell the team what the problem is and I'll work within the team to solve it. So I think it's a sign of immaturity within that team about what a self organizing team actually looks like. But that's okay. We know that agile is not a methodology that's written down in black and white. It's a bunch of patterns we put together to make things better. If the teams get value out of the three amigos, good on you. If it's adding value to your life, keep on doing it.

Yeah, you always say that there's four levels, right? So a developer could be a novice, a practitioner, an expert and a coach. So a lot of this planning is extremely challenging for people who are novices and also quite difficult for people who are practitioners. And so they want the experts in their team to sort out some of these architectural issues because they're better at it and the developers want to do what they're good at.

So it's about level of input. If you're a novice or practitioner level and you're one of the three amigos, you're in a hard place place. But I still believe that the novice or practitioner sitting in those sessions has value because they're learning how those expert or coach level people taking this big problem and breaking it down into smaller chunks, but not going down into the details. So again, I still argue there's value.

The developers don't think so, because it's always developers who push back and say, I don't want to be in all these meetings unless they're the expert or the coach level person.

Yeah, I'd agree with that. And a lot of developers just want to code.

Yeah, well, coding is challenging enough anyway without having to worry about all these other things. There's a concept related to this called ready to build and ready to test. So ready to build means that the team agree that something is at the point where it's ready to build and they define what that is. But usually it means it's top priority. It's been defined in a way that's testable. And some architecture and design planning has been done so that when the developer starts, it's in a good state for them. They can start coding confidently, knowing that they're on the right track and doing the right thing.

Yeah. So what I tend to talk to about teams is the idea of definition of ready, definition of done, and then my favorite one definition of dun, dun, dun, and then the last one being definition of value achieved. So definition already the team say, before we start some work, these are the things that should be completed, otherwise we're walking into a nightmare. And if we're running three amigos, then what the amigos are producing should be part of that definition of ready. And that comes back to that conversation around how much documentation do we do? One of the things I've seen more successful teams do is refine the artifacts or the templates or whatever the documentation is that the 3 megas is producing. I hate documentation as handover. We much better value in handover via conversation. But when that conversation is supported by reusable artifacts, the work done early seems to have more value for the team doing the delivery work.

The three amigos are part of the team though, aren't they?

So this is interesting because I have worked with organizations where the three amigos actually sat outside of each of the squads and they went through and triaged the work early for the squads.

Yeah, it could work, but it could become a kind of waterfall silo as well. I have seen cases where the business analysis team and the design team does this work six months ahead in a giant document which is made up of user stories and epics, but it's 100 pages long and it's in a different functional group and they sit up at some sort of architectural or program level. And that's not agile at all. That's just standard waterfall with agile words. I think there are times when you've got multiple squads working on something where you can get a lot of value from an integration team. Scrum Nexus has an integration team, but the integration team is made up of representatives from the various squads. Let's say you have on your integration team your lead technical expert. They might be 50% of their time in one squad and 50% of their time coaching people in other squads. And being in the integration team, I think it's also quite viable to have the product owner or product manager sits in that central team full time and then they're supported by bas and other people like that in teams. I think some designers would sit at that integration team, but whatever we do, we need to downplay the handover with documents, as you said.

Yeah, I like your idea that our ideal state is we have the level of expertise in every squad. So each squad has their own three amigos. So I think that's what we should be aiming for. Sometimes the expert or the coaching level doesn't sit in every squad and we see that a lot in the data space around the architecture role. The platform and technology and data architecture is normally a highly skilled capability and often you only have one when you've got two or three squads. So you're starting to deal with the scaling problems. Of course, now we've got people in the squad coming out to do work early, so they're no longer fully dedicated in the squad to do the work in the current iteration. And as long as we deal with that, it's okay.

Yeah. And there's a couple of interesting ways of dealing with that. One is you just accept it and that's fine. The other way is that you create activities for preparing a feature. I'm not a big fan of that. I actually prefer to set up a Kanban board that says prioritize, analyze, design, build, test, deploy, something like that. The team decides what it is, and you have a feature that's been prioritized, and you take that feature through that cycle. Maybe the analysis and design part is more of the three amigos, and then the rest of it is more of the whole team. But I find it very useful to be able to map out the whole life cycle of a feature on a board so that the team can see what's coming, see what the blockers are.

Yeah. So I think it's really important that you have a product roadmap and that you have that at multiple layers. So I talk about time horizons, the first time horizon being somewhere between three and six iterations. That should be on your roadmap of work that's about to be done. And that helps the amigos focus on what they should look at next. And then another time horizon that's somewhere between six months and 12 months, bigger blocks where we know that maybe there's some spikes because we've got a whole lot of new technology we haven't even touched yet. And then the third time horizon is over the next four years. Here's the big themes or strategies that we know may come into the product team.

Yeah. My principle here is just enough planning, just in time.

So there is definitely a problem with the three amigos getting too far ahead of the team. If they get more than one sprint ahead, then they need to stop and go back and help the team doing the work.

Yeah. I give them two.

I think we need to make space to be able to prototype concepts and test them with customers and users to see if they get a good response before they agree with the product owner that it should go into build. Because if you have a hypothesis and you build it, it's going to cost you somewhere between times more in effort than it would cost to mock it up and show it to people. And you get a lot of really good feedback just from mocking something up. And the same for the architect or development expert to do a bit of prototyping.

When we do that, we tend to fall into the pipelining problem. We're now segmenting the work into the designer designs it and the app developer builds the screens and the architect does the architecture. It's not a problem that I've got a good answer for because I agree with you that some work done early have a lot of value in figuring out how we're going to deliver something. But we fall into that habit of locking it in and making it inflexible. So we just got to balance it out.

I think the pipeline is only really a problem if it's done in functional silos. I think if the team is doing their own pipeline, it's fine. And it's fine when you've got a group of squads doing it together. It's not fine when you go back to the traditional functional silo models. That's where it all goes bad. Yeah.

So I have a preference that we still don't pipeline even within the squad, but often we do.

I find it works really well, actually, just related to this, I just wanted to dig down into the detail a bit more on the handovers. Let's say you've got your expert technical person and they're doing some of this prep work with the product owner or a designer and the tester who next sprint. What I like to do is say to the developer, when you're going to pick up this feature or the story off the backlog, I think it'd be really helpful for you to have a chat to the people from the three amigos who've been working on this. So it's not just reading through it.

One team I worked with worked out that yes, conversations are great, but light documentation still had value. So they talked about the artifacts they created in the life cycle of development. The idea of a sketch or a pencil and then coloring it in a little bit more and then coloring it on a bit more. And then when it was built, it was pretty much completely colored in because the code was dumb. And so they would lightly fill out the artifacts as a guess. To give you an example, they building a dashboard and it's the first time they've touched that data. So the person with analysis skills would go and look at the data coming from the source system and go, yep, looks like it's got a product and it looks like it's got a customer, and it looks like it's got an order. So they would do a really light sketch of a conceptual model that says concept of customer, concept of product, concept of order. And then everybody would go, cool, we've Already got customer from everywhere else. So we know how to bring that customer data in and match it up with everything else to give us a single view of customer. We've got products, but we know this is a separate product catalog and we haven't dealt with it before. So we know there's a bit of naughty stuff in there we'll deal with later. And we haven't got orders so we know we need to build some stuff out from there. And so they would likely sketch out some of the things that would be developed or created during the development cycle. There was actually a really interesting unintended benefit of this because they picked up the documentation as code pattern, which is effectively you're writing code that becomes your documentation. And as part of that, as soon as you check your piece of code into your git repository, it automatically updates the documentation site with that version of it. So a really interesting thing happened because we were running three or four squads at that stage and ideally the squads were working on things that had no crossover but every now and again because it's data, they always did. So we're sitting in a planning session with Squad 1 call them and the squad was saying oh, we're going to go do this and that's order. We haven't touched orders before. One of the other squad members said yeah, but Squad 2 is working on orders for another system at the moment. And they were how do you know that? And they said well I just had a look at the draft documentation and in their conceptual model they've got order. So in the past what they had to do was finish the planning, go around and ask anybody else and come back and this way that documentation added value. So I thought that was a really interesting use case. But we have to be careful that we don't go to the nth degree of everything is a fully fledged document and there is no conversation.

Yeah, I've seen people write a 10 page epic description whether the BA team were a separate team. And that's not what we're talking about at all. One thing that George talks about in Sri Mego's articles is testable requirements. So if we are writing requirements, they're written in a testable way in a given when then form. So that's quite a lot more detail than bullet points. It's almost like pseudocode.

I think it's a great idea but haven't seen it a lot. And from the data space, our tests normally the last thing we worry about and they should be one of the first.

This is the concept of shift left. So we're changing the testing expert from being somebody who finds problems to somebody who helps the team prevent problems by helping the team to define their acceptance criteria before they start coding. And I think that's very helpful. That adds quite a lot of clarity because then when the developer's coding, they can start doing TDD straight away. Maybe it's part of the transition from the Three Amigos to the developer that they work together to write the acceptance tests. Three Amigos is a pattern that's developed because developers have said, stop wasting our time making us go to all of these meetings that we don't want to be at or add value to and stop wasting our time by giving us shitty, poorly defined things to do.

And as humans, when we know complexity is coming up, we want to do early work because we think it helps. And again, every time I've seen a team use the Three Amigos, it has helped solve a problem.

Yeah, I found it very useful as well. I was once working with some teams that were very confused about what they were doing and wasting a lot of time starting something and stopping it and changing to something else. And I found that helping them to prepare their stories for Sprint planning for the estimation meeting on the first day of the sprint, that really helped. And having the Three Amigos do that work, which was basically the most senior expert level people in the team, that helped them a lot. It brought a lot of clarity and it really helped the team improve their productivity and get more things done and do higher quality work as well.

Yeah. And then I think there's a bunch of anti patterns that you've got to be really careful of. The Three Amigos, I think one that you raised was we effectively implement waterfall with a whole bunch of really experienced people right at the beginning of the process pretending to be the Three Amigos, writing lots and lots of documentation that is requirements. That's an anti pattern. Yeah, I think there's an anti pattern of a single hit squad of three Amigos across the entire organization and they're the only people that can do the early planning. There's an anti pattern of planning far too early. So the Three Amigos run way ahead of all the development teams and all the prioritization roadmaps are there out iteration six ahead and that. So I think that's an anti pattern over documentation or no conversation. So either they document in too much detail or when the squads are picking up the work, they don't actually have a conversation about the early work that's been done. So I Think they're Andy Patterns you've got to be careful of.

Yeah. Another one I've seen, which I think is a bit of a problem, is where requirements aren't written in a testable form, then the developers build it and they hand it to a separate test team who then starts to write test cases and then they test them. So that's just going back to waterfall again. Yeah.

I'll preface that a little bit though, because as you may have learned over the last few months, I'm really fond of the idea of patterns. So I think understood stories, requirements, acceptance criteria and the tests that support them is one thing that can come out of the Three Amigos. Early sketches of patterns is also another thing that can come out of the Three Amigos.

Yeah, yeah. Like contributing to your architecture.

Yeah. So they're saying there's this complexity coming up. We haven't dealt with it before. We've done some research and we think a pattern that looks like this may be useful. So I think we should be able to throw in that producing sketches of patterns that may add value is something that 3Amigo should focus on.

Yeah. I'd also like people, if they're doing this, to make sure that they define ready for build and ready for test.

So we should do that anyway. So every team should have a definition of ready that they use to go through and say, this work we're going to do next, it's in a ready state for us to start. Or it's not.

Yep. But overall, I found this pattern very helpful for teams. Sounds like you have too.

Yes. As much as I hate to admit it, it is a useful pattern and therefore, if it solves a problem, go forth and conquer.

All right, thanks, Shane.

All right, on that note, I'll catch you later.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help to create high value digital products and services, contact Murray Evolve Co. That's Evolve with a zero. Thanks for listening.