All in With The Three Amigos

On this episode of Eat Sleep Code, Jim Holmes gives his insight on running Three Amigos conversations at work. Learn how effective Three Amigos conversations cut confusion, reduce rework, and ensure the entire team clearly understands the why of what they’re building.

Jim Holmes @aJimHolmes

Jim is an Executive Coach at Pillar Technology where he works with organizations trying to improve their software delivery process. He’s also the owner/principal of Guidepost Systems which lets him engage directly with struggling organizations. He has been in various corners of the IT world since joining the US Air Force in 1982. He’s spent time in LAN/WAN and server management roles in addition to many years helping teams and customers deliver great systems. Jim has worked with organizations ranging from start ups to Fortune 10 companies to improve their delivery processes and ship better value to their customers. Jim’s been in many different environments but greatly prefers those adopting practices from Lean and Agile communities. When not at work you might find Jim in the kitchen with a glass of wine, playing Xbox, hiking with his family, or banished to the garage while trying to practice his guitar.

Show Notes

• Help the improve the show by filling out our survey.
• Jim’s Blog
• All in with the Three Amigos
• Telerik Test Studio
• Video: Automated Testing: Beyond The Basics - Jim Holmes @ Stirtrek
• Jim at Starwest conference
• XKCD comic, Developer's pass the salt

Transcript

00:01 Ed Charbeneau: This podcast is part of the Telerik Developer Network. Telerik, by Progress.

[music]

00:08 EC: Hi. This is Ed Charbeneau with Eat Sleep Code and I just wanted to let you guys know that we are trying to make the show better. So we've set up a survey at developer.telerik.com/survey and we're collecting feedback from listeners to see what we can do to make the show better for you. So please stop by developer.telerik.com/survey and fill it out. We'd appreciate it. We've also got 10 licenses to Telerik products and T-shirts that we'll be giving away to 10 lucky winners. Thanks for your help.

[music]

00:53 EC: Hello and welcome to Eat Sleep Code, the official Telerik podcast. I'm your host Ed Charbeneau and with me today is Jim Holmes. How you doing, Jim?

01:01 Jim Holmes: I'm doing very well.

01:04 EC: And today, we're gonna be talking about going "All In With The Three Amigos." We'll explain that in a moment. Let's start with a little bit about you, Jim. Tell us a little bit about yourself.

01:19 JH: So let's see. I will avoid going back to the dawn of time when I was born. I've been around various corners of software delivery coming up on 30 years now, so I'm an old fart. But I've done a lot of different roles, PM, developer, have been customer relations, I've done support. My focus really for kind of the last 10 or 15 years has been diving deeper and deeper into getting good quality out of software delivery teams, and have really been focusing a lot on kind of a human communication and how we get all of the hardest stuff, which is not the technology, but communication, collaboration, clarity, and what we're really trying to build and how to do it well.

02:15 JH: I'm currently an executive consultant with Pillar Technologies. That's a midwest consulting firm, although we've got offices around other places. I've got a side company, Guidepost Systems, that lets me also do different types of engagements. Used to work for Telerik. Was there about three and a half years working with the awesome folks on Test Studio. I was both the evangelist for all of that time and then for about a year, a year and a half, I also was director of engineering for that, and got to work with the teams in Austin and Sophia. So, Telerik is near and dear to my heart even after the merger with Progress, I still fondly think of... Gosh, I guess it's been about a 10-year association with Telerik. So, that's it for me.

03:11 EC: Well, thanks for sharing that with us, Jim. We appreciate the Telerik love, definitely appreciate your input on the Test Studio Project over the years. It's quite the useful tool that... I don't get enough chance myself to get involved and talk about. Really wish we still had one of the Test Studio evangelist spots in our team of evangelist folks.

03:44 JH: Right, right. It's a wonderful tool and I was lucky. They made the evangelist spot for me. When I started talking with Telerik years ago about coming on board, it was because I'd seen Test Studio. And it's not the perfect tool for everybody, but the thing was, it solved so many problems that I was struggling with on a regular basis. I fell in love with it and was doing the right sorts of things. You can have tools that kinda lead you off down a very bad path, and a few months after you've dived into this tool, it turns out that all of a sudden you're in the midst of a whole bunch of pain because it wasn't doing maintainable solutions, and Test Studio just nailed those sorts of things. So yeah, it was and continues to be something that's very close to me, close to the heart. So yeah, lot of loving for the tool.

04:54 EC: Yeah. So I don't wanna get too far off track with the Test Studio discussion. We may segue back into it with the other topic that we have at hand. But I was on Twitter the other day and you posted this blog post that caught my eye. And the title was, "All In With The Three Amigos," and I just reached out to you really quick and said, "Let's talk about this on the podcast 'cause it sounds interesting." So other than an epic 80s movie, what is The Three Amigos?

05:30 JH: So first off, thank you very much for the opportunity to chat. A little tangent and then I'll come right back. For years, I felt strongly that the single best thing any development in, pardon me, any delivery team could do to improve how they built software was to run regular disciplined retrospectives. You meet up as a group, you talk about what's working, what's not. You pick one or two things to focus on, good or bad for the next iteration or the next cycle and over time a retrospective just... It smooths out all the potholes.

06:12 JH: Well, I've come over the last several years to change my mind and it's because I've seen the impact of how Three Amigos worked. So okay, now back, what are we at? What is Three Amigos besides the awesome Steve Martin, Martin Short and Chevy Chase movie. In software delivery, for some time, and I don't even know where it started up, there's been this notion of three roles who typically don't talk enough and The Three Amigos is meant to bring those roles into an active, very frequent communication flow. So it's The Three Amigos, the BA, business analyst or system analyst, whoever is playing kind of the customer or product owner proxy, the developer and the tester.

07:15 JH: And the idea is that each of those three roles has a critical view into what needs to happen with the software. And that its basic implementation, Three Amigos is a conversation that you do when you're in your iteration and you get a work item that's ready to go. So it doesn't matter if it's... It doesn't matter if you're doing Waterfall or some form of Agile, Scrum, XP, whatever. Or if you've just got total chaos. You have a work item that gets ready to go. Before anybody lays their hands on the keyboard to write code, you have a discussion with The Three Amigos. So you get together the BA, the tester and the developer and this is an opportunity to clarify stuff as you're gonna move forward through development and testing as you're building stuff.

08:17 EC: We're talking about clarifying our deliverables and like architecture.

08:27 JH: So really it's... You take that work item and I've actually built up a little template that I created for the last team that I was working with of conversation starters. And the first thing... Here's a work item. So hopefully, it's a good thin slice of something that you can knock out in a very short time. The first question is, does everybody on the team understand why you're building it?

09:00 JH: We tech geeks get so deep into building stuff that we forget that we're building stuff for a reason. We are trying to solve someone's problem. And we don't talk about that enough. So the very first thing everybody should be thinking about is, "Man, does this thing make sense. Are we shipping some good value or do we need to go back to the product owner and have a quick conversation to make sure that we're all on the same page with this?" So it's a great... Just even there, just validation right from that point is extraordinarily useful. "Oh, wait a minute, this isn't clear, let's go have a chat with the product owner and we'll do something else in the meantime."

09:46 EC: Yeah, there's a comic from XKCD that I bring up when I talk about user experience and this conversation reminds me of it. Where the first slide is somebody asking another person across the dinner table, probably a developer, to pass the salt. [chuckle] And then, there's several blank slides later, and the guy asks again, he's like, "What's taking so long," and the developer's reply is, "Well, I was trying to figure out a system to pass you arbitrary condiments." [laughter] We get down these rabbit holes of architecting this flexible, always extensible thing before we even know what the deliverable is.

10:35 JH: Yeah. We've gotten so fixated on a technical solution that we lose track of, we're trying to make somebody's life easier, help them get revenue, help them better serve their customers. If you're doing something fantastic, you may be impacting, saving people's lives. And instead, we tend... Like you said, we jump down to, "Oh, how can I make this extensible and can I use cowbell version 4.2.89 and which version of the angular shift this hour. Time back to value I think is something we've got to sort of turn our heads back around on.

11:31 EC: Absolutely. I totally agree with you there. We definitely get down rabbit holes. Like you said, we're always looking for the latest and greatest thing to play with. But at the end of the day, we have to ship something.

11:44 JH: We do. Absolutely do. So, the conversation is a great starter point for things like, "Do we know what we're building and does it serve a why?" But there's also... That's the big business prop. But there are also things that are extraordinarily helpful for the work that you're doing right in front of you. There's a discussion of, at the high level, How are we gonna do this? What components are we touching? Do we understand what the value and risk trade-offs are involved with this? Because if you have a quick conversation around that, that then starts to inform how you're gonna build the system, how you're gonna test it, and how you're gonna make sure that acceptance criteria work for that.

12:36 JH: So all of those things come into play in this Three Amigos meeting. And it doesn't have to be long. The first time people do it... Sometimes there'll be a half hour of discussion because people are kind of stumbling around. But in a very short amount of time, if you're disciplined about having the discussion on every single work item, then the Three Amigos come together and it's a five-minute conversation of, "Okay, values clear, I get where this fits. Here's the test data that we're gonna need. Here's some edge cases that I'm gonna look at. Here are specific acceptance criteria."

13:19 JH: You flush those out a little bit, you make sure that there aren't any requirements gaps. And again, the beautiful thing about this is, it doesn't matter what methodology or process you're following. This is a conversation. You don't need permission to go do it. You don't have to go talk to your enterprise level process dogmatist. You can just go have a conversation, take a few minutes, fix those quick gaps that you've got, you've got a real-time feedback loop there of one minute, and off you go. And everybody is much clearer about what to build, how to test it, and to get good test coverage as well, so that you're very clear on your quality.

14:12 EC: So I don't wanna get you into an uncomfortable discussion. So if you don't have something that you can add here, then just let me know. But is there a specific case that you can remember back to where you had one of these discussions? And maybe stopped your team from making a bad decision, or it helped in some way that you didn't expect?

14:43 JH: So I'll say that since we've gotten... Well, and I see this with every... I've been with the same team now for a year which is, frankly, in my career, that's been pretty extraordinary to be heads down. I see this time and time again with a number of teams. Requirements gaps get immediately identified. Test data. You may have some of these discussions in iteration or released planning. But you learn more as you build more. So the Three Amigos, when you're pulling that work item off, gives you that exact bit of information at the current time you need it.

15:26 JH: A variation on this is a discussion that I pointed some of my testers to because they hadn't had a Three Amigos. When I'd just gotten there, I'd been at the project like three or four weeks. And they asked me to do 50 UI tests of this one grid because everybody in business seems to always wanna reinvent Excel 'cause apparently 30 years of Excel development wasn't good enough. [chuckle] Sorry, a little bitter there. So my current client had this grid where they would figure out product version offerings. So we have this one piece of machinery, it's got 89 options, we're gonna do five of these, four of those, eight of the other thing. And literally, if the calculations on this grid were off, tens or potentially hundreds of millions of dollars for the client could be at risk. That's some scary numbers.

16:39 EC: No pressure.

16:40 JH: Yeah, no pressure. [chuckle] You wanna talk risk value, these calculations are it. And my testers were very sharp about this. "Look, big risk here, we've gotta do 50 of these UI tests". Well, the particular component that they were using was a huge pain in the bleep to automate against. So I didn't wanna do all of them in the first place, but more importantly, I asked the testers "Okay, you guys didn't have any discussion early on here. Do you know what the developers did for unit testing?" And the two testers looked at each other and they shrugged their shoulders and they say, "No, we don't know what they have." So we literally swiveled our seats around, talked to the developers, turned out that there was 100% coverage of all of the calculations on that grid via Jasmine tests. So now, all of a sudden, because of that conversation, we knew we didn't have to write all those UI tests, we had good coverage at the unit level, and then all we needed was one happy path and one sad path test at the UI level.

18:00 JH: And then there was another thing, which is as testers... So developers think happy path and maybe an edge case or two. It's just how the brain works. I've been a developer for a while, I've been a tester for a while, it's okay. But the thing with these conversations is that, as the testers, we asked, "Okay, so that 100% coverage you've got, you've got complex formulas there, are you varying one parameter and checking the output? Or are you doing multiple parameters and checking the output?" So if that didn't make sense, think of, "I've got one variable, I'll test the outcome. I've got five variables, I'll test the outcome." Does that make sense?

18:49 EC: Yeah. You wanna make sure that if you change multiple variables, you don't affect something else further down the system.

18:56 JH: Exactly. So the thing is, it's complexity. When you have multiple parameters, you need to actually check interaction of that. Well, it turned out, guess what, the developers weren't doing any of that multi-parameter testing. So there was a risk that they'd missed something because they weren't doing anything other than the single parameter testing. Okay, so in the space of five minutes of conversation, we got an extraordinarily better picture of risk, of risk mitigation, and of better test coverage. And that's the sort of thing that the Three Amigos conversations is just gold about.

19:48 EC: Yeah, and I opened up your template. So on your blog post, you actually included a Word document template, so people can just grab this thing and get started.

20:01 JH: Yeah, absolutely.

20:03 EC: So it basically has some of the top questions that you should ask like, "Why are we building this? What's the value? What test data is needed? So the hard-hitting questions, and these are things you can get through in a just a few minutes.

20:16 JH: Absolutely. And what I tried to make sure that everybody understands is, those are just starting points. God forbid, anybody ever associate anything I do as a best practice, there's no such thing. This is meant just like if you're stumped and you can't figure out what to talk about in The Three Amigos, here, take this little card, print it out, hand it out to all of your team members. That's exactly what we did. And these are the sorts of things to chat about. And you said it yourself, you just kind of look down that and it's like five-minute conversation, maybe it spawns off something, more important or, I'm sorry, more longer. [chuckle] Maybe it spawns off something longer, that's the whole point of The Three Amigos, take the conversations where they need to go.

21:08 EC: I think it's funny sometimes in our industry it can be The Three Amigos that you point out, or even things like your design team, your UI, UX folks, nobody seems to wanna talk to one another. And I don't quite understand what the point of silo-ing everyone is in software, but it seems to happen a lot.

21:35 JH: Yeah. So, A, human nature. B, we geeks have done this to ourselves, 100%. Well, okay, maybe 95% we've done it to ourselves. You know, IT is viewed as where quirky introverts go to live and be cranky and testy to other people.

22:00 EC: And run the world.

22:02 JH: Yeah, yeah. This is not an American thing. This isn't America. It's human nature, and it's how IT has... It's how we have to find for ourselves and taking some point and pride in that. And so, yes, then you have the stereotypical Grumpy DBA, you have the tester that nobody likes to talk to because they're going off on insane edge cases that maybe one person in every 38 and a half million years will ever run into. And then you got the developer who just wants to be thrown the requirements under a door with pizza, and don't make him talk to anybody. But you know what? And again, you don't need permission for any of this.

22:51 JH: And if you start these conversations, pretty soon, you find out that that grumpy developer and the testy tester person actually care about the same sort of stuff. But it involves you be in willing to kinda step out of the persona that you've grabbed onto, opening up and being a little more empathetic to those other humans. And I tell you what, time and time again, I have seen teams, not turn around, but go from being borderline dysfunctional to at least well functional, if not highly functional. It's a long process, but everything starts with a step.

23:39 EC: Yeah, another thing that I find a bit surprising is the idea that people on these different teams feel like. Maybe the other team doesn't understand the language that they're speaking, or testers aren't gonna understand this type of code or the designers aren't gonna understand this code that I wrote or vice versa. And it's really far from the truth. The more I visit conferences and talk to people at meetup groups and get involved with the community, I find people are very much open to full-stack development, or their talents cross many boundaries.

24:28 JH: Yeah. We humans are a pain in the butt quirky lot you know. But those perceptions, sometimes, there's a nugget of truth there. But when you engage somebody, when I reach out to somebody about, "Hey, I'm trying to figure out a little more about what you do." When somebody else hears that, that you're expressing interest, it's very rare that there isn't some bit of opening up. It's a trust thing. It's a communication thing. Three Amigos is not about getting in and having a big group hug and singing Kumbaya. It's about learning not just to be open to other people's views, but understanding the extraordinary value and the helpful value at its heart. This is trying to make a team getting on the road to being extremely high performing. And if nothing else, if you're a lazy person like I am and somebody tells me that I can cut feedback cycles and I can prevent rework, "Yahoo, sign me up."

25:51 EC: Absolutely. Who doesn't like to save time? And I'm one of those people that's like if I have to do this task twice or three times, it needs to be automated. [chuckle]

26:04 JH: Right.

26:04 EC: I think that's... I'm probably stereotyping here again, but I would assume that's most developers. That's kind of our thing.

26:12 JH: It is. Sometimes we get a little too wrapped up and it's kind of... You've probably seen the Lego Meme, where the two guys are pushing a cart and it has square wheels, and there's a guy with a round wheel. And the two guys pushing the cart say, "Oh, we don't have time to improve. We run into that." But, yes, there's the mindset of how can we work better? And especially, as we start to kind of shift our view around from what's the work in front me to how am I providing value out in production? All of that kind of flows together in my view.

26:54 EC: I say a lot of stuff in here about integration and unit testing and the impact on functionality and whatnot, is there anything in here regarding, say, maintain ability and code standards, or is that for another conversation?

27:15 JH: So again, there's no hard, fast rules around what's in the Three Amigos. The whole point is you need to tailor it to what your team needs to move forward. Maintainability and code standards if you're using things like SonarQube, or NDepend, or any number of other analysis tools, that may be something that I'd normally have off to the side of Three Amigos. That's kind of a broader, "How do you do your work?" versus "How are we gonna do this effectively?" Now, I guess you could think about it in a way of, "Oh, we're gonna have to touch these three components. We may wanna look at re-factoring something out to make it easier to extend as we move forward." I'm speaking off the cuff here as I'm looking out the window. That could totally be in Three Amigos.

28:21 JH: And that's especially useful if your team is in the middle of trying to change how they build the code. So not necessarily to deliver but the actual craftsmanship principles. Maybe you're struggling with people who have been fairly low-skilled. They didn't understand good development patterns. A lot of duplication, a lot of other problems. Reminding people about that during the Three Amigos in those kinds of contexts, "Man, why wouldn't you? Hey, let's not fall back into the old bad habits. We've been doing two days of great development, let's have a third day."

29:06 EC: So if you guys would like to read Jim's blog post... I'm trying to pronounce your web address here, Jim. You wanna help me?

29:17 JH: Frazzleddad.com.

29:19 EC: Okay, frazzleddad. It kind of blends all in when it's one word up in the address bar.

29:23 JH: It does.

29:24 EC: So frazzleddadblogspot.com or...

29:28 JH: Just frazzleddad.com and it redirects.

29:32 EC: You'll get a redirect there. Jim has the template up on the blog post as well, so you can grab that and could use that as a starting point for your Three Amigos discussions. I think this is a great value-add for many big shops that are working with independent teams that may or may not talk a lot. So I appreciate you sharing this with us, Jim.

30:00 JH: Yeah. And so here's the deal. You do a bit of reading on Three Amigos, you have some discussions, you can make an impact on your team this week, literally. So software craftsmanship is something that is extraordinarily important to how we deliver good value, but learning craftsmanship skills takes months or years. And I'm not saying forego that, but Three Amigos, it's a conversation. You don't need new tooling. I don't have to go buy licenses. I don't have to go do anything. It's a conversation, and if you just started and you be disciplined about doing it on every work item, then I guarantee, I guarantee in five business days, if you're committing to it, you'll see a change, absolutely see a change.

31:05 EC: And do you have any advice for folks that wanna get on-board with this and maybe have a stubborn team-mate or a...

31:15 JH: Yeah, 'cause that's never ever happened. [laughter] So the thing is, this is also something we geeks don't do well is we have shorted ourselves on learning how to persuade other people. So something that I've found very helpful is if I'm getting pushback or if I sense that I'm gonna get pushback, I won't set it up as, "Oh, we're gonna implement Three Amigos." Instead, work starts on something and I am really good at playing dumb because I'm not the brightest star in the galaxy. So I'll just go ask people, "Hey, I'm a little confused on acceptance criteria here, and I need some help on figuring out data flows. Could we have a little five-minute chat and you whiteboard something for me." You can be... I was gonna use the word sly but that's got some negative connotations. Now, you can be sneaky about this. It doesn't have to be this big process rollout change. It's a conversation. If you have people that are still skeptical, ask to run an experiment.

32:37 JH: This is something else that we don't think about often enough, but ask for people to commit for one week, we're gonna meet on every work item, and we'll set a 10-minute time box. And we're not scheduling an hour-long Outlook meeting. It's a 10-minute conversation, we're gonna talk about these things, and I want to validate the number of requirements misses and defects that we head off at the end of that week. So you have something measurable, and hopefully, that will help persuade people that, yeah, it's got some use.

33:24 EC: So, Jim, are there any talks that you're gonna be giving? I know you're a speaker. Is this something that you'll be presenting or are you gonna be at any conferences coming up soon?

33:39 JH: I am pretty much done until October. I used to speak a whole lot even when I wasn't working at Telerik as an evangelist. But this last year, I've been pretty much focused just on work, which has been kind of nice. So I was at Stir Trek. There at stirtrek.com, there's a video of my talk I did there, which isn't specifically around this, but there's some of the concepts mentioned in there. I'll be doing a little bit of that same thing at StarWest in October. And then, if the gods smile down on me, I'll be back at CodeMash next year, maybe talking about something similar. But I write a lot about this stuff and I'm on Twitter, I talk about this stuff. If anybody's got questions, feel free to look up, contact me through my blog, ping me on Twitter. It's A Jim Holmes, not Jim Holmes. He's this funny developer over in London, just A Jim Holmes.

34:47 EC: So you logged out and your Twitter twin is also a developer?

34:52 JH: Well, it's pretty funny because some years ago, I had a Twitter account, Jim Holmes. I left Twitter. And then for the longest time, you couldn't get Twitter handles back, so I did A Jim Holmes. And then a year or two later, all of a sudden people are messaging him thinking it's me. And the guy has an awesome sense of humor. His Twitter bio, I swear to god, four, five years ago when Confusion was just rampant, his Twitter description said, "I put the bugs in. If you're looking for testing, see A Jim Holmes."

[laughter]

35:31 EC: Nice.

35:32 JH: It was awesome.

35:33 EC: That's great. Yeah, I've got a... Somebody owns my last name.com and they just so happen to be in IT, but from the 90s, and they still haven't updated their site.

35:46 JH: Oh, man.

35:47 EC: If you go to Sharbano.com, you get something that says: Internet Explorer 5, download here and it's just...

[laughter]

35:57 EC: They will not let go of that domain.

36:01 JH: Oh, bummer.

36:01 EC: At least the person on Twitter is aware of you. [chuckle]

36:07 JH: He redirects all kinds of stuff. I owe him so many pints of Guinness, it's pathetic.

[laughter]

36:14 EC: That's great. We'll wrap all this stuff up in a short post in our show notes.

36:20 JH: Okay.

36:20 EC: So we'll include your blog URL there as well if people haven't got the frazzleddad thing down yet. You can go to developer.telerik.com and look for the show and they'll be show notes with links to Jim's blog and Jim's Twitter account. So you can get in touch with him there. We also accept comments and feedback on the website and on SoundCloud. So if you guys wanna leave comments there as well, we do have discussions on SoundCloud. And please give us a like on iTunes. We could use the publicity, and listeners if you enjoy the show, share that with people, let them know. Jim, again, appreciate you coming on the show and chatting about Three Amigos with me. That sounds like a low-barriered entry and big rewards type of thing.

37:14 JH: It is, it is. Thank you for having me on and for tolerating my passionate rants about this stuff.

[chuckle]

37:22 EC: It's excellent. It's nice talking to you and we'll have you on again sometime.

37:27 JH: Thanks very much, man.

37:28 EC: Alright. Thank you.

[music]