Adam Weisbart: Make Things Simple and Your Team Will Move Faster

Richard:

Hey Adam. Thanks for joining us today.

Adam:
Hey Richard. Thanks for having me on. I’m super excited to be here. It’s good to see you.

Richard:
I’m super excited to have you. Thanks for joining us. What else would you add to that intro? What else can we say about Adam Weisbart?

Adam:
Yeah, that intro was spot on prior to COVID and now that COVID is here, I suppose and with us, for a while, you actually were part of this initiative early on, back in June of 2020, I hosted the Agile Virtual Summit. We had over 14 and a half thousand people register. And I was thinking if we got a thousand or so, that’d be amazing. And that has grown into some more events. We’ve had a couple of other events since then and a community called the Agile Mastery. And so while I’m still teaching classes and doing coaching and such, I’ve been spending a lot of time building community around all things, agile, around the summits and the Agile Mastery group that we have. And it’s been really, really fantastic to be connecting with folks during a time when we’re strangely more connected in that we zoom into each other’s houses every minute of the day, but also less connected. Because we don’t get to see each other at conferences where you and I used to run into each other, all the time, while we were wearing black shirts.

Richard:
Black shirts, like we’re running right now. We’re more connected and less connected and differently connected, right?

Adam:
Yeah.

Richard:
So Adam, this podcast is about teams and I know you definitely work with teams. I like to ask people about the best team of their life, the best team they’ve ever been a member of, right? So you and I, we both teach people who are on teams. We coach teams, but what about a team that you’ve been a member of? Can you think of like, what’s the best one of those that you’ve ever been on in your life?

Adam:
Yeah, yeah. Yeah. So this is hard for me. I imagine this is hard when you ask anyone because it’s like picking, I only have one kid, but it’s like picking your favorite kid.

Richard:
I would pick my one kid if I had to pick which kid.

Adam:
Yeah, no, I mean, that’s fair. I will totally pick my one kid, but in this case I’ve had more than one team or worked on more than one team so I could pick a number of them. But the first one that comes to mind I think was actually my first scrum team ever. And that’s strange to me, and that you would think maybe the first one is where you make lots of mistakes if you’re booting up a scrum team, which I did and we did, but looking back at it, it’s definitely one of my favorite teams. And it’s the one that pops into my mind first.

Richard:
All right. So what else about this team? What were you building? Who were they? What time period was this? Tell us everything.

Adam:
Yeah. Okay. So time I’d have to look at a calendar, but I think it was 12, 13, 14 years ago, something like that. We were building a private, labeled social networking tools for companies like Marriott and otherwise. And this is when I discovered scrum, right? So I think one of the things that makes it most exciting to me is like, I was super excited about agility and scrum and such. I took a certified scrum master course as at the time I was an engineering manager, right? So I had a team, I was heading up this product that I had pitched to the CEO, the CEO loved it, decided to fund the product. And I was managing the team as a manager. But at the time I was pretty frustrated with the idea that like, if I was sick or on vacation, I had this great team, but not much got done while I was not there. And I thought like, I’m a smart person, but I’m not as smart as these six or seven people working together. Why doesn’t stuff go as well.

Adam:
And so I discovered the scrum thing, got really excited about it, took a two day certification course from Jimmy Fosdick, way back when in San Francisco and who I hadn’t met till the course. And just got really excited that scrum was like all this stuff that I had accidentally learned over the years from running my own business, to being an engineering manager, it’s just a bunch of common sense wrapped up into a lightweight framework. And so I got super excited and introduced it to the team. And then we switched from me managing them to them actually managing themselves with a, I don’t know, crazy thing, like a product backlog. And I did a bunch of things wrong. It was my first time doing this, but we improved actually really, really quickly. And some of the dynamics that we had prior to that went away like the troubling ones, frankly probably stemming from me trying to manage people or managing people, doing it well, but then maybe not loving that to a really fantastic team.

Richard:
All right. So now if you could summarize that whole experience, that best team of your life in one word, and I know there’s a lot of words and how could you pick just one? What would that one word be?

Adam:
Collaboration.

Richard:
Collaboration.

Adam:
Yeah. Seeing how everyone came together, focusing on the same goal and together collaborated towards that goal was fantastic.

Richard:
Now, how do you know this was the best team? So far it’s just very subjective. So what else subjectively about this? It led you to say that this was the best team of your life.

Adam:
One of the things that we were required to do at the time at that organization was have all our stuff, QAed. That sounds weird, because every week we QA and all our stuff, but specifically we would lob it over a very tall fence to the QA team that was outsourced in China. Overnight we’d get some feedback probably, or a couple of nights later, a couple of days later. And that was really an organizational impediment as you probably can imagine, this organization was not huge. And this added complexity led to frustration delays, et cetera. And we were required to do that. That wasn’t something that I could remove even in my position there. And so I said to the team, like through one of our retrospectives, we discovered that this was a big issue for us. And so I said, well, what would it look like if we just figured out how to do that properly on our team, on our cross-functional team, we don’t technically have, I think we had one QA person on the team, but we don’t have all sorts of a bandwidth and resources that this bigger team over in China has.

Adam:
But how could we do that? What would that look like? We started doing some behavior driven development stuff. I think at the time we were using Cucumber to run some tests and such. And what we ended up with was a stunned organization in that all the other teams naturalization would lob stuff to China, get a bunch of bugs back, it would slow down schedules, it would blow stuff up. And we just sent stuff to China that never came back with any bugs. So they were testing and there was no need to be doing this anymore. So we got to, not according to us, but according to the organization, just stop doing that. We didn’t need to send it to China anymore because after a few months of this, we could show that, look, this isn’t even subjective. We don’t even get to talk to that team in person and they’re sending stuff back.

Adam:
So that was a really big win pretty early on. And it was just a great feeling because it wasn’t like me insisting, oh yeah. In scrum, we have cross-functional teams and we don’t need another team outside of ours to test. It was like, okay, we’ll keep sending it. And then they were like, why do we keep spending money on this? This seems silly. So that was quite rewarding. And the team was, initially they’re like, why do we have to test our own stuff so much? We used to just lob it over a offense, but then they were like, just relieved to not have the delays, the miscommunications, et cetera, from lobbing over a fence.

Richard:
All the extra work, all the heartache, all the negotiating and fighting. This is a bug. This isn’t a bug. Yeah.

Adam:
Yeah. And just the team members getting really excited about some agile engineering practices that they hadn’t discovered previously, right? So-

Richard:
So what else about those? You said BDD.

Adam:
Man, what else did we do? We started, I think we started using Git, this was pretty early on and sort of maybe GitHub was around. I think they were, but we were using, what we’re using prior to that? Something that frustrated us even more, even though I remember the time we were just like, wow, Git does a good job of making smart people feel really dumb, but once we got the hang of it, I think it was like a big relief. We also, you know that we’re the first team at that organization to start using Ruby on Rails. And we had switched over from some big Java tangled mess. And so that was a big relief to everyone. So like just getting introduced to simple things like dry, like don’t repeat yourself, was fantastic.

Adam:
And having opinionated frameworks that saved you from having to make a ton of decisions that if you were just starting from scratch in some, un-opinionated approach, you’d have to make as a team and argue that out for probably months or one person would make, and then other people would be unhappy with. Yeah. So those things were super helpful. And I think it was like one of the first times that folks on that team got to pick their own tools. I certainly had strong opinions at the time because I was trying to lead us to more opinionated frameworks and such, and I am often very opinionated, but I think we had more flexibility than folks were used to. So, going to the whole individuals and interactions over process and tools thing was helpful.

Richard:
Nice ideas there. And when you say opinionated frameworks, what does that mean?

Adam:
Yeah, so I will preface this by saying I haven’t coded for a very long time. But back in the early days of Ruby on Rails, for example, both of the founders of 37signals and DHH who came up with Ruby on Rails was the first author of it, really took the stance that there are some various standard things one does in software. Take something simple, like updating a field in a database, right? You could go and rebuild that from scratch every time, you could go and make your own decisions about the thing that everyone does over and over again on the web or Ruby on Rails, which was at the time extracted from their product base camp. So this framework wasn’t like created as we’re going to make a framework. It was created as we built a product.

Adam:
And from that product that works well in the real world and solved many of our own problems in terms of building this app, we are going to extract a framework from that, much like the agile manifesto, right? This is the four values came out of doing this work, not by sitting in an ivory tower, coming up with some new, cool values for people to follow. And extracted it from base camp and made this framework available to other people to use where you don’t have to make these same decisions over and over again, unless you have a very good reason from deviating from this. You might as well just use what’s elegant and built into the framework. So it saves you time doing a bunch of standard things. All right. Cool. Sounds pretty helpful. Seems reasonable, as long as you, I guess [crosstalk 00:13:24].

Richard:
I’m playing [crosstalk 00:13:28]. Tell us about BDD, tell us about opinion and frameworks. Back to this team, this awesome team. First scrum team you ever on, best team of your life. What else objectively that somebody could observe from the outside? What were the things that would help other people know that this was a great team if they were watching this team at work?

Adam:
Yeah. Well, I mentioned not getting any bugs back. That was a pretty big one, frankly. We were delivering more often than teams had traditionally there. And I guess this could be subjective from their point, but the team was happier. I think someone from the outside could see that. And that wasn’t true in the beginning, of course, right? We certainly went through forming and storming and such, and we were in storming for quite a bit. It was again, my first scrum team. So, I also remember like the biggest argument that I had dealt with as a scrum master ever happened on that team, right?

Richard:
And what was it?

Adam:
I don’t want to talk about it. No, what was it? It’s one that I think is [crosstalk 00:14:48] familiar to people.

Richard:
Welcome to the podcast called, I don’t want to talk about that.

Adam:
I don’t want to talk about it, no, it’s a super common one. And I’m sure most folks listening to this have run into it if they’ve been on a team or been the scrum master of a team. It was during estimation, strangely. At the time we were using planning poker as our approach for estimation, which I no longer used, except if I have like one or two items for a team to estimate. But generally I don’t use it for reasons like this. I think it leads to frankly, more arguments, but six people in the room were saying, this thing is super easy, it’s a one, there was another person in the room, seventh person in the room who was saying, no, no, no, this thing is a 21 and an argument ensued. And the six people were like, how can you disagree with us? We’re six people. You’re one. You don’t know what you’re talking about, this is super simple. The person was like, no, and this blew up, right?

Adam:
This went back and forth and being a new scrum master and new to facilitation and knowing that I’m not supposed to jump in and like stop an argument, like I might have as a manager, but I also didn’t know what to do for it not to keep escalating and it kept escalating, it was a disaster. In the end, I kind of realized what was going on. I think I asked a couple fumbly, but useful questions. And it turned out the one person in the room who was saying this thing was difficult, was the tester on the team and the other six people on the team were developers. And they’re like, no, this is like a two second change. Why would this be a 21? And the tester was saying, we don’t have much testing if any, around this section of our product by you making that change to test the entire world again, manually also because we can’t send it to China anymore.

Adam:
And so in the end, they ended up agreeing with her, but it took like 30 minutes of people, like close to yelling at each other because I did not facilitate that well, though, that never happened again, right? Not because I put my foot down because I was like, oh, I see what I needed to do there, right? So, I got better at that over time. And nobody, I ended up telling this to, I think this might’ve been to Jimmy actually after this happened. So Jimmy who I took my certified scrum master course ended up becoming my mentor. And I don’t remember it was him or someone else, but I shared this with them and they’re like, oh, I’ve had that happen to one of my first teams. Did you have to call HR? And I was like, no, why would I need to call HR? And they were like, because that happened on my team and there was pushing and I was like, oh, well, it didn’t get, no that never happened. There was never a physical contact. So I guess it could be worse.

Richard:
How do we know this was the best team of your life? Well, we didn’t have to call it HR.

Adam:
Yeah, we didn’t have to call HR. Yeah. So those were like in the sort of earliest days of this team, we got through the storming phase and things were substantially better after that. And I got better facilitation.

Richard:
Of course, of course. What about other concrete behaviors that you engaged in together? What are some of the concrete behaviors? You adopted scrum, that’s a concrete thing. It’s not exactly the framework, so what are some of the very specific things that you did that went into this being such a great team?

Adam:
Sure. I mentioned behavior driven development. I think that something we did that was unique at the time for us, like everybody on the team, was being really intentional and clear about the way we talked about features in the product. We spent a bunch of time upfront, like agreeing on what we would call this section of the UI or what this element in the UI was, which was painful. We’re like, why can’t we just get back to work, but getting really clear on those and sort of hashing it out, really made it so much easier moving forward to just talk about our product together. We have this shorthand for talking about complex things that we wouldn’t have had otherwise if we hadn’t spent that time upfront. And I think it’s really hard to do that upfront, especially with all the pressure a team gets to deliver. Doing that upfront is a surprising amount of time.

Adam:
You think it’s going to be simple and you start going through UI to have this conversation and realize, oh no, this is going to take us a while because we argue about every single one of these things. So that was one of them, taking that action at the beginning to clarify these things and get on the same page. And then in sprint planning, we were writing a bunch of these BDD tests together as a way to clarify what it is we’re actually building. And so that was super helpful. We had given stuff from the user’s perspective, a ton of thought, by the time we got out of spring planning. That was really powerful. And it took some getting used to because we’re like, wow, this is a bunch of time, but it just made the rest of the spring so much easier. Like we had figured this out. So those two things helped a ton.

Richard:
All right. And how about advice?

Adam:
What about advice?

Richard:
Advice for listeners.

Adam:
Just in general?

Richard:
Oh, a little bit less than in general. How about for how to have a team as good as this one, what would you tell people to do?

Adam:
Heck. I’d recommend spending some time upfront having conversations about how you’re going to talk about the thing you are building, like I just mentioned. It’s a thing that, what partly made that easier is that was really early on in the product, right? So we sort of had to do that anyway. And I’m thinking about it now. There’s certainly been teams over the last decade that I’ve worked with, that we haven’t done that. And my long pause there was sort of considering why, and it’s because the product already existed then we started doing scrum. And so it wasn’t like this relatively green fields project. We were sort of snapping this new team into this existing product. And so I think there was more rush and less thought about those things. So I would still do that even though I’m realizing now that I don’t always do that.

Adam:
The other thing I would do is like the broad thing is get good as someone who is facilitating and helping this team at listening. And the way that I would specifically do that is if you’re currently listening to this and are not fantastic or better at facilitating retrospectives, I would focus on running good retrospectives and really improving your art around retrospectives. Because your team will know whether they can articulate it or not the things that are in their way. And that is the best way I know to help surface those things in a way that’s not me jumping in and telling teams what they need to work on.

Richard:
Right. All right. [inaudible 00:22:21] at retrospectives. And I know you have started off this episode by saying you’re fun. I know you have fun tools and toys for helping with retrospectives. Like those retrospective fortune cookies.

Adam:
Yeah. So we’ve stopped shipping those for the time being just due to COVID. But I also have, behind me there, I think right there, at the back, right there. I’ve got recess, which is my retrospective in a box. Oh my gosh, you disappeared. Are you okay? Have you fall [crosstalk 00:22:49]. Oh they you go. Oh my gosh, look at that.

Richard:
This is not scripted, we swear. But under my desk, I have like one of the first boxes of recess, the fun tool kit for retrospectives.

Adam:
Yeah. In each box, you get everything you need to facilitate like a really fantastic retrospective that follows the five steps of Derby and Larson’s retrospective framework, a playbook you read out loud from and all the materials you need for stuff like welcome to Hollywood, mission to Mars, attack of the zombies, which feels too apocalyptic to play at the moment. Yeah.

Richard:
Global pandemic, remember the retrospective activity called global-

Adam:
Global pandemic. Yeah. So those are super fun. We’re not shipping them right now either because you have to be in the same location together to play it. And also there was generally food in each one. So we’re away from that. But yeah, I would get good at facilitating. I think they are the most, perhaps the most useful thing out of the scrum framework. And they work well on their own even if you’re not doing scrum, even if your organization was like, we’re doing an agile transformation and then decided they didn’t want to do that after some amount of time, if everyone just continued to do retrospectives. Well, they wouldn’t have the same advantage you would have with scrum or some other agile framework of being able to implement those things on their own easily with regularity, it still be amazingly useful and would help probably bring any team closer together and working better together over time.

Richard:
Absolutely. And is there anything else you want to add? What else is happening in Adam Weisbart’s world?

Adam:
What else is happening in my world? The summits taken up a ton of time. Oh, here’s something that’s happening. Doors are closed for it right now, but I think it’s worth noting. So I mentioned Agile Mastery, which is a community where each month we have a speaker come and do a workshop. We have weekly lean coffees or other similar events. We have an online community that’s away from the noise of LinkedIn and Facebook and such currently with several hundred Agileists in it. So we’ve got that and sort of an offshoot of that. We’re doing a program with Lyssa Adkins of coaching, agile teams fame, it’s that 10 year anniversary of her book. And I was talking with her and I said, Lyssa, it would be really great. I want to run a book club with your book.

Adam:
And I’m wondering if that’s something you might be interested in, like being involved with in Agile Mastery. And so we talked about it and realized that what we wanted was something more than a book club. Because anyone can run a book club, you just get the book and some people, but we have the author of said book wanting to be involved in this. And so what we started is a 12 week program called the coaching agile teams study and practice group. The first, roughly third of her book, we meet almost weekly. We meet every three weeks, then the week break and then another three weeks, et cetera, we have activities in the community and Agile Mastery, there’s a subset of it for the coaching agile teams folks.

Adam:
And we get together on Tuesdays. Lyssa gives a talk, gives us field work. We often break out into two groups to do some coaching triads and such. And we get the opportunity to go through this program with Lyssa herself. And so that has been fantastic. We’ve got, I don’t know, 250, 260 folks in that program. And it’s just been really great to see folks connecting, having conversations in the group. Working on this field work and building more of a community. We got folks from all over the world tuning in for this and taking part of it in on the platform. So that’s been great. The doors are closed now. So when you’re listening to it, you’re like I can’t get in it, but we’re going to run it again.

Richard:
Oh good. And we’ve had Lyssa as a podcast guest, so you can go back and listen to that one. One of our best episodes ever.

Adam:
She’s fantastic. I have no doubt it’s one of your best.

Richard:
And okay, Adam. So how could listeners get in touch with you to learn more about all this great stuff?

Adam:
Yeah. So they can go, specifically they should go to Weisbart.com. That’s W-E-I-S as in Sam, B as in boy, A-R-T as in Thomas .com/Richard. And at that URL, I actually have a gift for everyone that’s listening. We’ve been talking a little bit, at least about retrospectives. We mentioned my retrospective in a box and the cookies, but I also have agile ad-libs, agile ad-libs are a, do you remember Mad Libs as a kid?

Richard:
I do.

Adam:
Yeah. So they’re like Mad Libs, but you use them for your retrospective and they’re specifically focused around a scrum team. And so for those of you not familiar with Mad Libs, if you live outside the US for example, it’s where you and a partner get together, you ask for a verb or a noun or some other part of speech. They give those randomly to you, you fill them into blanks where those types of words go, and then you read back the story and it ends up being hilarious because it’s got ridiculous words placed in places accordingly. And then at the end of that, after you and your team have laughed at the story that you came up with accidentally, there is a retrospective question.

Adam:
So it snaps you out of like your normal meeting mode. It’s sort of raises your state a bit because you’re having fun doing this. And then you get to consider a serious but useful question for your team. So that’s PDF. And if you go to Weisbart.com/Richard, you can, for a limited time, I’ll leave it up there for a couple of months, probably. You can get this PDF, just type in your name. My other contact information will be there. And yeah, that way I can let you know when the Agile Virtual Summit is happening again, or doors open to Lyssa’s program or whatnot, and you’ll get a cool retrospective out of it that you can use with your team.

Richard:
That’s awesome. Thank you so much for that gift for everybody. And I’m imagining what if we did a podcast that way, [inaudible 00:29:22] like the Mad Lib podcast, I would just say, hey Adam, give me three verbs.

Adam:
Sarcophagus is not a, sarcophagus is not a verb. A verb is an action word, Richard. Let’s try again. Sorry, I stepped on you.

Richard:
All right. Adam Weisbart, thank you so much for joining us today. It has been super fun having this time chatting together. Thanks.

Adam:
Super good to see you. Thanks for having me on.

Richard:
You’re welcome and listeners, remember to support this podcast, visit my website, kasperowski.com.