Vasco Duarte: First Scrum Team Was the Best Team of My Life

Richard:                        00:43                Hi, Vasco. Welcome to the podcast.

Vasco Duarte:              00:45                Thank you, Richard. It’s a pleasure to be here. You’ve been on my podcast; I guess it’s now my turn. It’s an awesome topic you have for the podcast so I’m really excited about participating.

Richard:                        00:56                Oh, cool, cool. Welcome. Yeah, yeah I had a great time on your podcast. Thanks for joining us here. To get started, will you introduce yourself to our listeners?

Vasco:                          01:07                My name is Vasco Duarte. You can call me Vasco because that’s what most people around the world do. As I usually say in my podcast, I’m a polyglot when it comes to mispronouncing people so no worries. You can call me whatever it sounds like in your language. That’s perfectly fine.

Vasco:                          01:28                I’ve been an Agilist, I’ve been practicing Agile since 2004. There’s actually a nice story about that, we’ll get into that later. I’m also the host of the Scrum Master Toolbox Podcast where I interview every week a new Scrum master and we go through five questions that Scrum masters need to face every day and we get 52 different answers for every one of those questions per year.

Richard:                        01:54                Yeah, that’s really nice. This feels like a love fest. I really love your podcast, I love being on it and it’s so awesome to have you here on mine. Thank you again.

Richard:                        02:02                This podcast is about high performance teams. I ask every guests to tell me about your best team ever, the best team of your life. What can you tell us … Can you identify that team and what can you tell us about it?

Vasco:                          02:18                Because I host a podcast, I prepared. I have my notes here.

Vasco:                          02:25                Yeah, so this was a team I helped build but that was not the reason why it was good. I’ll give this team a name. I don’t think we called ourselves a name at that time, but I’ll give it a name here for the sake of making it easier to refer it to. Let’s call them the pioneers. They were all new. Everyone in that team was new to the company and they were totally new to the process. Actually, it was my first Scrum team.

Richard:                        02:54                A-ha! Interesting.

Vasco:                          02:54                The first Scrum team. Now, notice that I said my first Scrum team. At that time, I already had eight years of experience in the IT world-

Richard:                        03:04                Right.

Vasco:                          03:04                -but my first Scrum team was definitely the best team that I’ve ever worked with.

Richard:                        03:09                Oh, cool. How long ago was this if this was your first Scrum team?

Vasco:                          03:14                This was 2004. That’s when I got started. We did the whole transformation in two weeks. It was literally get on board and two weeks later, boom, you’re in a Scrum project. At the time I was actually building the team so a lot of the team members came from the outside. Later on a couple of the internals joined, but when we started there were only people who joined as new and first time employees.

Richard:                        03:41                Right.

Vasco:                          03:42                These were not easy people or something. It wasn’t like this kind of teams where everybody is happy from day one. It was tough to get it started, there wasn’t agreement about who to hire. The people were … I mean, they were all nice people but they weren’t these people who would say yes to everything. None of them had that kind of personality. These were people who stood for their ideas. Even from the start we had pretty heated debate about how to do Scrum and what kind of technology to use, what kind of architecture to use. All of them were outspoken.

Vasco:                          04:22                Even, this is the funny part of the story, during the team formation one of the team members got fired by the team itself.

Richard:                        04:30                Oh, wow! Fired by the team. I’ve always wanted to hear story about getting fired by the team. It’s a really common question that people ask, what if somebody is sort of like a freeloader and how do you handle that?

Vasco:                          04:44                Yeah. The cool thing is that this team, they were all outspoken. At some point, there was this new team member who obviously had gotten the job not because he wanted it but because he probably either needed it or maybe he was just trying out a new position, whatever. He definitely wasn’t being productive.

Vasco:                          05:04                The team got together, they came to talk to me and say, “Hey, Vasco. We have something to talk about and it’s not very nice.” We talked about it for a while and they said, “Look, we don’t think that this new team member,” let’s call him Ryan, “We don’t think that Ryan is able to pull his own weight so I think we should consider firing him.”

Vasco:                          05:31                We did, actually. We had the conversation with Ryan. We established a new set of goals and say, “Hey, during the next two, three, four weeks we need to get better at this. When you need help, you need to ask for help. You can’t just hide and wait for the end of the sprint to say that you didn’t do anything.”

Richard:                        05:51                Right.

Vasco:                          05:51                Things didn’t get better so we eventually ended up firing this Ryan person. It was a tough moment but … I mean, at the end of the day I’m still in contact with him. It wasn’t a bad thing, I don’t think. I think it was a good thing both for the team and for Ryan himself who found another job doing stuff he was familiar with and love [crosstalk 00:06:17] before he joined.

Richard:                        06:19                I love it when exit stories turn out like that, and it seems like they almost always do. They’re good for the team that remains behind and they’re good for the person who left.

Vasco:                          06:29                Yeah. I mean, if Ryan had stayed, it would have caused resentment towards the … the rest of the team would be resentful and not very cooperative with him so-

Richard:                        06:40                Right.

Vasco:                          06:40                -I think it was the best for everybody.

Richard:                        06:43                Yeah. All right, now … I hope this story didn’t prime you in a sort of negative way. I want to know about, getting back to that best team ever and the story of the rest of the team that remains, if you take yourself back to that time, okay so we rewind back to 2004 and you’re with this team, maybe around the time they’re spinning up, maybe during the time that you were together doing the work over the next months or years, I’m not sure how long it was, maybe we’ll find out, as you re-experience that team, could you summarize the experience in one word?

Vasco:                          07:22                I thought long and hard about this and it’s not that easy but knowing what I know now, not necessarily the word that I would have used back then, but knowing what I know now, the word would be flow.

Richard:                        07:38                Flow?

Vasco:                          07:39                Yeah, and the reason for that is that no matter what we did, things always happen. Now, when I say things happen, that doesn’t mean that everything we did was successful or that we did everything we planned to do but it was clear that whatever we put our minds to, we were able to achieve sooner or later.

Vasco:                          08:00                I’ll give you a small hint of how this went. Actually this was a completely new product for the company with a completely new business model for a completely new set of customers, and we pulled it off. This had not been done before except once in the life of the company. This was a small team. When we got started we were like five people then it grew up to 10 people but it was a small team and we actually made it happen. That included marketing material, conferences, visiting customers, all of the stuff that many teams actually are used to get through the product owner, right?

Richard:                        08:44                Right. Right. When you say flow, different people mean different things when they say flow, when you say flow, what’s your meaning?

Vasco:                          08:55                By flow in this specific context, I mean when you’re … Let’s say you love to write. You get up in the morning, you start typing and then when you look at the clock it’s four hours later and you go, “Oh my god, four hours just went by.” That’s how it felt to be in that team. We got into the room and we started working and soon enough it was evening and we had to go home.

Richard:                        09:21                Nice. Nice, and it was a sense of group flow, not just individual flow, yeah?

Vasco:                          09:27                Correct.

Richard:                        09:28                Yeah. Okay, so this was your best team ever, you got this feeling of flow always feels good so there’s one way that you could subjectively say it was a great team. What else do you have for how you know it’s the best team ever? What other subjective opinions or feelings, anything, objective? Okay, you’ve got something objective, you ship that product first time or second time, whatever happened in that company. What else about how you know this was a great team?

Vasco:                          10:04                From the objective point of view, of course a new product for the company, a product that went from not existing to 10 million in revenue in four years.

Richard:                        10:16                Wow.

Vasco:                          10:16                Building a 10 million business in four years is not a feat to sneer at. Definitely, a small team has to go through a lot of trouble to be able to pull that off. That’s on the objective side.

Vasco:                          10:32                Also, on the subjective side, the team had a great atmosphere. Whenever you went through the room you immediately felt that something was happening. They were always receptive to people that came in to the room but they were also pretty clear about setting their own boundaries. I mean, they started silent hours in that company. From 10:00 am to 2:00 pm nobody was allowed to disturb anybody. If you wanted to talk, you would email first and then meet outside the room and you wouldn’t disturb the rest of the team.

Vasco:                          11:06                It was also the first team in that company that had a collocated room. We had a room just for ourselves, we had whiteboards everywhere. Everybody was sitting next to each other so it was easy to get at and ask questions and get feedback. It was the first cross functional team in that company. It included business people, product people, design people, testers, developers and even infrastructure people. This was 2004 so none of these dev ops thing existed.

Vasco:                          11:39                We already had the infrastructure people working with us because we understood that if we want to get this done, we need to start bringing in some of the responsibility into the team. How do we do that? We get more people. We get people to work with us, right?

Richard:                        11:53                Yup.

Vasco:                          11:55                In a lot of ways, it spoiled me what a team is and how Scrum should work. I’ve never been in a team that worked so well as that team after that. Today is 2019, so that’s 15 years later. I have 15 years more experience, and that one experience has never been repeated.

Richard:                        12:23                Oh, that’s fascinating. You had this great, great first experience and really solid evidence that this was a great team. Just the business result itself is solid evidence.

Vasco:                          12:36                Actually why you say solid evidence, I want to tell a story about my own journey that also helps understand why this team was so important for me and still is important for me. I mean, we’re still in touch. People are all over the world; one guy is in Canada, another guy is in California, I’m in Finland, a couple of guys joined a consulting company, another guy started his own company. The team is all over the world now but it’s still very important for me and we’re still in touch. There were definitely connections created at that time.

Vasco:                          13:12                Regarding the solid evidence that Scrum and Agile works, I’ve said this several times, coming completely out of the closet as it were, I did not believe Agile could work. When I got started, I was a skeptic. I did that project with the intent to show that Agile doesn’t work.

Richard:                        13:34                No way.

Vasco:                          13:35                Absolutely. Actually I was very structured about it. We did it by the book. We took Scrum as defined by Beedle and Schwaber in their Agile Software Development with Scrum, the black book.

Richard:                        13:49                Yeah.

Vasco:                          13:49                Right? The first book about scum?

Richard:                        13:51                Yeah.

Vasco:                          13:51                We did it exactly as described there. When we started doing it, it became obvious; wait a minute, this actually work and this is better. Having the team make decisions on their own is better than having a project manager do decisions for the team.

Vasco:                          14:12                Having the team, I’ll tell a story about that in a minute, having the team own their physical space is better than having to go through this committee of, you know, the building management people that want to know exactly where the tables go and all of that. It was so much better than anything I had experienced but I started it as a skeptic. I didn’t believe it would work.

Richard:                        14:39                Interesting. Interesting. So, you did it by the book. It was sort of a well-controlled experiment so if it fails it wouldn’t be because you weren’t doing it right.

Vasco:                          14:50                Yeah, absolutely. It worked so well that, actually, that is my first no estimates project. I know that some of the people listening to the podcast might have heard about it. Just don’t go to Twitter to learn about it, right? [inaudible 00:15:04]. Don’t use Twitter for that.

Vasco:                          15:07                Anyways, it was the first project where I discovered that estimation was not only useless but it was actually actively negative in terms of team collaboration and stakeholder trust. We stopped estimating all together but we were still able to tell people what’s going to be ready and when because of the simple technique I developed back then that is now a core part of the no estimates approach which is to just count the number of stories.

Richard:                        15:37                Just count the number of stories. Let’s pause there for a moment. Wait a minute, Vasco. I thought estimating was one of the elements of Scrum that you said you were doing exactly by the book. What do you mean you weren’t estimating?

Vasco:                          15:53                We were estimating. Actually at that time I remember reading Agile Estimation and Planning by Mike Cohn. Definitely a book that influenced me a lot. I would never recommend that book to anyone today. If you want to read anything about estimation, read about how the Egyptians built the pyramids, no estimates; or how the Romans conquered half of the known world, most of Europe and a lot of Asia, no estimates.

Vasco:                          16:25                There is a story about Caesar going to Germany and they are being attacked by a certain number of local tribes and they have to create a way to win that particular battle. They actually build a bridge, this was about 1700 years ago. They build a bridge in less than a week to cross the Rhine. Now, anyone that knows a little bit about geography knows that Rhine is a huge powerful river.

Richard:                        16:54                A-ha.

Vasco:                          16:54                No machine-

Richard:                        16:54                Nobody has ever built a bridge across it in a week, before or since.

Vasco:                          16:58                Do you see what I mean?

Richard:                        16:59                Yeah.

Vasco:                          17:01                That for me was important, kind of a moment of realization not because I didn’t want to estimate. On the contrary, I was pushing the team to estimate. I was asking them, “Come on, guys. We need to estimate better.”

Vasco:                          17:17                At that time in 2004, many of our listeners probably will not remember, but at that time we were estimating stories and we were estimating tasks under those stories. That’s how we did it back then. Of course, I understood, at some point the team said, “Look, Vasco, I understand you want the numbers but we don’t use them for anything so do we really need to do this? Can’t we just break down the story and that’s it?”

Vasco:                          17:45                That’s eventually what we ended up doing. I used the historical data to project our future delivery; we were exactly on time with the exact features we said would be live; we had three releases in one and a half years, which was also something new for our new product in that particular company. It was a bit far from continuous delivery, though, but there you go. That was a seminal project and a foundational project from my own understanding of Agile, and at the same time it was the best team I ever worked with.

Richard:                        18:19                Oh, super cool, super cool. What were some of the other behaviors that that team engaged in? You had Scrum by the book, you had no estimates, you had the collocation, cross functional. What are some of the other stuff that went on?

Vasco:                          18:33                Okay, so in my own podcast a lot of people have talked about the book, The Five Dysfunctions of a Team. It’s a very short book. It’s a fable. It’s very easy to read, but there’s one thing that stuck with me forever since I read that book. I read the book way after this project I’m talking about so I didn’t rationalize it then but I do that now, which is that this team, they held each other accountable.

Vasco:                          19:01                I want to tell a short story about this. There is this new guy, he joins the team. The rest of the team is happy with this guy, they think he’s good, he’s technically competent, he works hard but he’s got a problem. We have one retrospective and the team basically turns to this guy, let’s call him Jeff, turns to Jeff and say, “Jeff, we’re tired of your CVS bombs.

Vasco:                          19:26                If you don’t know, CVS is the version control system and a CVS bomb … CVS is a pessimistic locking version control system which means that if you’re editing the file, no one else can edit the file.

Richard:                        19:42                Right.

Vasco:                          19:42                This guy, he kept the files in his machine for two to three weeks-

Richard:                        19:46                Oh, god.

Vasco:                          19:46                -and then he committed all the changes at the same time and then you got, what all developers listening to us will understand immediately, you got into merge hell.

Richard:                        19:55                Yeah.

Vasco:                          19:56                Right? The team turns to this guy and said, “Jeff, we’re tired of the CVS bombs. Could you please commit every day or two instead of every two or three weeks?” Of course the guy could have been offended by this or whatever, but he wasn’t. He said, “Okay guys, I’ll try my best but I’ll probably need help,” and then they did it together. They held each other accountable.

Vasco:                          20:23                I think that was perhaps one of the most important-

Richard:                        20:26                Excellent.

Vasco:                          20:27                -behaviors that I’ve learned from that team. That wasn’t me holding them accountable. Heck, I couldn’t care less what they were doing with CVS. I was encoding, right? But they care. They held each other accountable.

Richard:                        20:42                Holding each other accountable to the promise that this person, who we’re calling Jeff, made to the rest of the team. You also said … you didn’t say it explicitly, but they had the ability to talk to each other and feel safe and tell each other when something wasn’t going wrong. They had this ability to point out conflicts and to resolve them.

Vasco:                          21:08                We had a very interesting mix of cultures in that team. We had a very outspoken Finnish salesperson which is rare to have a Finnish [inaudible 00:21:17] but we had one and she complained about everything she didn’t like. Sometimes the conversations were hard but we were able to collaborate. We had a very talkative Irish. You know how talkative the Irish can be? Well, double that. That’s how talkative he was.

Vasco:                          21:38                We had a bunch of Finns that although they were much more silent, they weren’t afraid of conflict. When they disagree, they just said, “Nah, I don’t agree with that.” I think that this was also a good mix of personalities.

Richard:                        21:55                Yeah, cool. You’re bringing back some of my memories about how interesting it is working with a multinational, multicultural group of people and how, I don’t know, joyous it is. It’s really fantastic to work with people from all these different backgrounds, different ways of thinking and [inaudible 00:22:15] together.

Vasco:                          22:16                Although it can be problematic if the particular personalities are not compatible.

Richard:                        22:23                Yeah, yeah.

Vasco:                          22:24                In this specific team, they had no problem in criticizing each other because they were all trying to get the best out of what they were doing and the criticism wasn’t taken personally. I bet people weren’t necessarily happy about it but it wasn’t taken personally.

Richard:                        22:45                Yeah. Hey, I have another question about your one word “flow” and how that relates to Scrum. Sometimes people look at Scrum and they think it’s discrete, like these events at the beginning and the end of the sprint, they disrupt the workflow or the group’s thinking flow. Do you have any opinion about that?

Vasco:                          23:08                Yeah. I don’t see anything wrong with working in [inaudible 00:23:12]. I think that if that works for you, that’s great. These days I would advocate for one week sprints rather than two-week sprints. It makes the planning conversations much easier, the demos are easier, we know what we’re talking about. There is very good active memory because everything is within one week. There is no break in the flow-

Richard:                        23:40                Right.

Vasco:                          23:40                -but I do have to say that I am a big fan of cycles. By cycle, there’s a clear beginning and there’s a clear end. The clear end for me is important because when I go home on Friday, I feel I have achieved something. I don’t need to worry about the story that isn’t yet delivered that I need to deliver on Tuesday or Wednesday next week. I can feel that I have accomplished something and it cleans me off this mental overhead of things that are hanging and not finished that I left at work on Friday.

Vasco:                          24:18                For me, the combination of weekly cycles and this clear marked boundaries between beginning and end of the cycle are very important. That’s a personal preference, of course. I think you can have extremely good flow in Scrum that does not feel disruptive at all.

Richard:                        24:39                Okay, nice. As we talk about week-long sprints and finishing up by Friday, you literally mean start on Monday, end on Friday. Other teams have a practice with starting on, say, Wednesday, ending on Tuesday.

Vasco:                          24:53                I don’t like to break natural flow-

Richard:                        24:55                Okay.

Vasco:                          24:56                -natural cycles. The Monday to Friday cycle is just so natural. People come in on Monday. Everybody is kind of, their head is in the air, they are fuzzy about what to do next; we get together, we do the planning. Boom! We got everybody on the same page and now we start rolling.

Richard:                        25:13                Yeah. Yeah, great idea. Let’s add on to that. What other advice do you have for listeners? How could they take the example of your pioneer’s team and this sensation of flow? What else can they do to reproduce that team’s success?

Vasco:                          25:33                Okay, there is one secret sauce here. All of what I said so far was absolutely true but there was something else I haven’t talked about, at least not directly.

Vasco:                          25:43                The team had direct feedback from potential customers. They were presenting their product to customers, potential customers at that time because the product didn’t exist before; they were getting feedback; they were putting that feedback back into the product. They were actually iterating.

Vasco:                          26:04                You know the whole idea of iterating software development, the iterative software development? That’s exactly what we were doing. Most teams these days they don’t do that, right?

Richard:                        26:15                Right.

Vasco:                          26:15                They do the sprints but they do, like, 20 sprints and then they show something to a customer. That’s not iterating. That’s no way to get feedback. Of course that creates a lot of emotional debt because when you show something to a customer, if it works you’re like, “Awesome! Let’s build on it.” If it doesn’t work you go, “Okay, why doesn’t it work? What do we need to change?” There’s no emotional debt of working for half a year and then the last month of the project is coming and you go, “Oh, will they like it? Is this going to be good?” whatever.

Vasco:                          26:50                For me, that was an extremely important part. The product owner was part of the team, it was not an external. It was not a chicken, it was a pig. Right? Looking back at the old Scrum joke, the product owner was as committed to the product as the team. The product owner was building a new business that didn’t exist. If there were no sales, there would be no success.

Richard:                        27:15                Right.

Vasco:                          27:15                Right? The team was part of creating a new product and they really felt that they owned the creation of that new product. I think that was, for me it was the secret sauce. We were not working for an abstract and possibly monolithic massive product backlog, we were actually getting feedback all the time. We were cleaning the backlog, taking stuff out, doing things we didn’t think about doing before as a result of that feedback.

Richard:                        27:46                Genius. Like you said before, kind of just doing Scrum by the book.

Vasco:                          27:50                Exactly.

Richard:                        27:55                Okay, so do Scrum by the book. What other advice do you have for listeners?

Vasco:                          28:00                Well, it depends on what book you read.

Richard:                        28:03                All right. Well, [crosstalk 00:28:04].

Vasco:                          28:04                Let’s be clear. I’m talking about Agile Software Development with Scrum, the first Scum book by Schwaber and Beedle.

Richard:                        28:11                Yeah.

Vasco:                          28:11                Don’t do the one month sprints, though. That’s out the door [inaudible 00:28:14].

Richard:                        28:14                Yeah, yeah, yeah, yeah for sure. One week sprints. Well, yeah, 30 days or less for sprints. What else? What else could listeners take away from your experience with that pioneer’s team?

Vasco:                          28:28                The understanding that customers and market, access to customers and market, is a fundamental need of teams if you want them to contribute. If you just want to code monkeys, it’s okay. You don’t need to give them access to the customer or the market, but at that time we created a team that was a creative ensemble. It’s like a jazz band; they saw the customer in front of them, they saw each other and they just jammed-

Richard:                        29:02                Oh, I love that.

Vasco:                          29:03                -and they jammed really well.

Richard:                        29:07                I love that. I love that analogy. It’s like with your musician on stage, you get the feedback. What songs; what riffs are people jiving to; what works tonight, maybe we’ll do more of that tomorrow night; what doesn’t work, maybe we’ll drop that. We’ll actually iterate; we’ll change our song list, we’ll change our backlogs for each night. Yeah, cool.

Vasco:                          29:29                Inspect and adapt.

Richard:                        29:30                Inspect and adapt, which is what every good bands does and people in performing arts if they get this out.

Vasco:                          29:37                Indeed.

Richard:                        29:39                All right, is there anything else you’d like to add?

Vasco:                          29:44                Yeah, there’s one story I wanted to share. Now, I’ve talked about how this team was holding themselves accountable and how they felt responsible for the creation they were putting together, the new product, but there was something else in this team. It was the first team that was truly autonomous. I want to tell this story because I think it’s quite illustrative of what autonomy can be.

Vasco:                          30:09                At some point, a few months into the project, we had to move rooms, to a new floor and to a new room. The new room was different than the original room so we couldn’t just copy the layout. The common temptation is to ask the people responsible for the building, just prepare a room for us, here’s how many desks we need, blah, blah, blah but the team said, “No, we’ll do the room ourselves.”

Vasco:                          30:37                They actually did, as part of their work. They planned the room, they organized the desks in the best way they saw fit, and they actually assembled the room themselves, physically put the desks in the right place. They came out with the layout that every time I think about that layout I have to ask myself, “Why isn’t anyone else doing this?”

Vasco:                          31:03                Here’s the layout. They had a developer station. There were four desks turned towards each other. Remember how the cubicles prevent face to face and eye contact? They set the desks so that they could see each other in the face all the time, so they could see the feelings the other people were experiencing. The feelings of doubt, maybe a question is coming; or they could see who they were talking to, right?

Vasco:                          31:34                Then we had another table which was set completely different. It was like a long table where you could come in and sit. Even people that were not in the team, they were just visiting, they could come in and sit. That table, which was the long table, had a designer, a frontend developer and a tester and they were not far from each other. There was a clear division between the work, and that’s expected because they do different work but they were not far from each other but the way that the room …

Vasco:                          32:06                Then there was another part which was a table with a whiteboard where they got together and they had their daily standups and they had their design meetings and so on and so forth. This was all in one room. We had, I think it was seven people when we started it, it grew up to nine or 10 people later, in a room that would have been enough for six to seven people if it were laid out as originally planned. We had access to the windows which we would not have had access to if the room was laid out as originally planned. Get this, they figured out the exact layout of the desks so that they wouldn’t get window glare on their screens.

Richard:                        32:50                Ha, ha, every developer’s dream.

Vasco:                          32:54                They did that themselves, right? There’s no way that somebody who is just putting the desks there would have thought about that.

Richard:                        32:58                Yeah, no way. No way.

Vasco:                          33:01                That’s how autonomy can be so powerful for a team.

Richard:                        33:04                Autonomy. Okay, so that’s perfect. As we were talking, my wife logs in, gave me a kiss, goodbye. I don’t know if I will have edited that out of the podcast or not

Richard:                        33:16                This is something that people who don’t write code, like you’re saying, people who would setup the furniture, they actually don’t understand. Molly is always wondering why I have the lights off when I’m sitting with the computer, like “Why don’t you have the lights on? Don’t you want to feel happy?” I’m like, “Oh, I feel so happy right now that there’s no glare in my screen.”

Vasco:                          33:36                Indeed.

Richard:                        33:38                I know you’re working on a lot of projects, Vasco. You tell us a little bit about your projects and anything else like how can listeners contact you?

Vasco:                          33:49                I’m on Twitter. That’s duarte_vasco, and I’m sure the links will be on the show notes. You can also pin me on LinkedIn.

Vasco:                          33:59                There’s only one project I want to talk about and it’s also a podcast on which you have been. If you want to hear Richard on the other side of the mic, go to scrummastertoolbox.org. That’s the name of the podcast, Scrum Master Toolbox Podcast, or just fetch it from iTunes.

Vasco:                          34:19                We’ve been recording since 2015. That’s now four years and every week there’s been a show. Let me just look at my date to tell you how many-

Richard:                        34:34                Four years of weekly podcast. That’s incredible.

Vasco:                          34:38                It’s not just weekly, it’s like every week day there is a new show.

Richard:                        34:42                Four years of almost daily podcasts.

Vasco:                          34:45                Yeah, so we’ve recorded 218 shows-

Richard:                        34:49                Whew!

Vasco:                          34:51                -and we’ve published now 210.

Richard:                        34:55                Incredible. It’s a prolific library of podcasts that you’ve recorded and shared with the world.

Vasco:                          35:01                And with real practitioners talking about their real stories, what they’ve learned and what they still use now. There is an element of what actually works over time rather than what I like today.

Richard:                        35:15                Yeah, and I love … This conversation we just had, I love that you orient things around these stories. Also, when I was a guest on your podcast, I loved how you guided me to tell stories. You’ve got 200 something episodes, four years’ worth of almost daily episodes, about people telling concrete stories about what they have done and it’s really great stuff.

Vasco:                          35:40                Actually it is 1,050 episodes [crosstalk 00:35:44]-

Richard:                        35:43                Oh my god.

Vasco:                          35:45                -weeks.

Richard:                        35:45                Oh my god. I bow before you.

Vasco:                          35:51                [crosstalk 00:35:51] library about Scrum right now.

Richard:                        35:53                It’s incredible. It’s incredible. All right, Vasco, thank you very much. I know it’s late there where you are. Thank you so much for joining us today. I really appreciate it.

Vasco:                          36:03                It’s been a pleasure, Richard. Thank you.

Richard:            36:06    Hi, friends. Thanks for listening. Remember, to support this podcast, sign up for my newsletter at kasperowski.com.