#37 - Lean Inception & Fun Retrospectives - Paulo Caroli

Episode Introduction [00:00:58]

Henry Suryawirawan: [00:00:58] Hi, everyone. Another week goes by and I’m back here again with a new episode of the Tech Lead Journal podcast. Thank you so much for tuning in and spending your time with me today listening to this episode. If you’re new to the podcast, know that Tech Lead Journal is available for you to subscribe on major podcast apps, such as Spotify, Apple Podcasts, Google Podcasts, YouTube, and many others. Also check out and follow Tech Lead Journal social media channels on LinkedIn, Twitter, and Instagram. And you can find amazing quotes and words of wisdom from every podcast episode, and I share them on those channels to give us some inspiration for us to get better each day. And if you’re thinking about making some contribution to the show and support the creation of this podcast, please consider joining as a patron by visiting techleadjournal.dev/patron. I highly appreciate any kind of support and your contribution would help me towards sustainably producing this show every week.

For today’s episode, I am happy to share my conversation with Paulo Caroli. Paulo is a principal consultant at ThoughtWorks, co-founder of Agile Brazil, and the author of the bestseller Lean Inception, and the recent FunRetrospectives.

I learned about Lean Inception when I used to work at ThoughtWorks. And during my time there, I found that Lead Inception is one of the key techniques that ThoughtWorks uses in many client engagements to bring everyone together, come up with a successful product vision, and create alignment between multiple stakeholders involved. And hence most of the projects that started with an inception will most likely result in a successful project delivery.

In this episode, Paolo shared with me the history of ThoughtWorks Inception, how it evolved into the current Lean Inception and its connection with the Lean Startup movement. He also explained the similarities and differences between Lean Inception and the other well-known Design Sprint, including the interesting story on how both techniques were developed almost at the same time, and why they ended up quite similar, but different in a few strategic ways. Paulo also shared an example how to come up with a good product vision, the concept of MVP canvas, and the importance of shifting our mindset project-mindset to product-mindset.

In the second half of our conversation, Paulo then shared his latest contribution, FunRetrospectives, which brings together many different techniques to conduct effective retrospectives. He explained the reasoning behind the fun techniques, shared some of those fun activities that we all can try in our next retrospectives, including the interesting token of appreciation technique. He also emphasized the importance of psychological safety and facilitation skills in a good retrospective. And if you’re interested to find out my examples of fun retrospectives that you can try, you can check them out on his website at funretrospectives.com.

I hope you will enjoy this episode. And if you like it, consider helping the show by leaving it a rating, review, or comment on your podcast app or social media channels. Those reviews and comments are one of the best ways to help me get this podcast to reach more listeners. And hopefully they can also benefit from the contents in this podcast. Let’s get this episode started right after our short sponsor message.

Introduction [00:05:00]

Henry Suryawirawan: [00:05:00] Hey, everyone. Welcome back to a new episode of the Tech Lead Journal. Today I have a special guest. His name is Paulo Caroli. He’s a colleague of mine last time in ThoughtWorks. So he wrote a book called “Lean Inception”. For those of you who are not aware of it, it’s actually one of the techniques that ThoughtWorks use, still doing, I guess. For all customers, before they start a project, they will conduct a lean inception, and understand what the products, come up with the agreement about how to build the products, how to approach your products until you come up with an agreement of what kind of MVP that you want to build. It is a very good technique. So I’d love to have a talk today with Paulo to understand further about lean inception, and also to share with all of you. So Paulo, welcome to the show. Thanks for agreeing for this.

Paulo Caroli: [00:05:40] Thank you, thank you. It’s a pleasure to be here.

Career Journey [00:05:43]

Henry Suryawirawan: [00:05:43] So Paulo, maybe to introduce yourself in the beginning, maybe telling about your career journey, your highlights and turning points.

Paulo Caroli: [00:05:49] Sure. So, I’m Paulo Caroli. I am Brazilian. I was born and raised in Rio de Janeiro. Then I went to a software engineering school. I did a Master’s in Brazil, and then I went to Silicon Valley. It was back in the days in the late nineties. I was an Object Oriented developer. I used to go to the OOPSLA conference, a big conference in US and fell in love with Silicon Valley. One of the trips to the conference, I went to Silicon Valley, and I was like, “Oh, I wanted to live here.” So I moved to Silicon Valley. I spent eight years there. I worked on quite a few startups. When I got to US, which was in 2000, because of Object Oriented, I used to follow Kent Beck, which wrote the book “Extreme Programming Explained”. And then I met him in 2000. And then I start following all those things that later were called agile. It was one of the reasons that I went to work for ThoughtWorks, because a lot of those folks, quite a few of those, went to work for ThoughtWorks. So I did the same. When I joined ThoughtWorks, I always had the lean startup thing on me. Like, I really liked that side, but I also liked the agile development side, and ThoughtWorks usually work for big clients. Then I started traveling a lot, several organizations, I moved to Asia, Europe, back to Brazil. From a developer, I started being a facilitator. One thing I realized I was pretty good on getting people together to align about something. Usually the beginning of the project was a very important part, especially for developers, who work for six months, one year, and then you don’t see your product like being successful. It was really bad. And then I started getting involved from the beginning phase, which is called the inception demo. Well, what can we do to better align, so we have a great success with our product, our team?

And then from 2011 forward, I started to concentrate those inceptions to be more lean. Lean aspect like, be shorter and more effective. Imagine that now with agile, we try to be more effective now. 2011, like 10 years after the agile manifesto. We could be even there before the beginning of the birth was inception. It was like, “Oh, let’s understand all the user stories,” and then installed and left. And I realized, thanks God. I used to live in Silicon Valley. And they were following the movements from there. We gave an entry to lean startup, and they should start with the MVP. That’s why the Lean Inception. It’s lean because of Lean Startup. It was a big shift in my career. And I think on ThoughtWorks and the projects that I was working nearby, that’s why lean inception start spreading the word around the globe. In Brazil, it’s a big thing because I was living there, I think from 2011 to 2019, which was really good. And because I had three kids in Brazil during those years, I was not traveling abroad a lot. So I was doing a lot of lean inceptions for Brazilian companies. So in Brazil, like everybody’s doing inception nowadays. 2019, I moved to Europe. And now with the remote world, I started doing more lean inceptions all over the globe remotely. Now I think that they were spreading faster.

Lean Inception [00:08:35]

Henry Suryawirawan: [00:08:35] So maybe if you can share what is Lean Inception in high-level summary for people who are not aware of it.

Paulo Caroli: [00:08:41] Sure. Lean Inception in high level, you need to align a group of people to be successful. That’s it. It’s about alignment. Usually I go to a company, a corporation or product, it doesn’t matter. There is a vision. “Hey, that’s amazing. That’s the vision. Ooh, we are all going to be rich. We’re going to be successful.” Yeah. And then what? And then you need to align, is this strategy, like what’s the path? Traditionally, we would go with the strategy, and it’s like a long train wreck. “Oh, we need to this and this and that and that.” We realize the world’s not like that. So the lean inception align that group of people. Okay. What is the vision? And then we try to align what is the MVP, the Minimal Viable Product. So we’re okay with the vision, it’s important to have the vision. But what’s that very first step? It’s very hard to align about that very first step. Because when you think about a Minimal Viable Product, you need to think about it from three angles. The business angle, which is super important, the business behind it. It doesn’t matter if you’re a small company or big corporate businesses. The users, because you’re always doing something for someone to use them. Like you want the users to love it. And then the engineers. Because you need to build it, right. When you put those three people together to figure out what is that minimum, it’s not that easy because each one has different perspective and they want different things. So Lean Inception is about it, getting those three perspectives together. So they align and decide, okay, what is that very first step?

Henry Suryawirawan: [00:10:00] And you mentioned it’s also an evolution since it was created before, right? Like you mentioned the portion of the lean. So it becomes lean inception. So, how do you actually combine this lean startup movement with this inception? And how does this relate to design thinking? To me, it sounds a little bit similar.

Paulo Caroli: [00:10:18] Yeah, I know. It’s definitely has a lot of influence from design thinking. You have to put this in perspective. I was in US from 2000 to 2008. So I was there in the beginning of the agile movement. So I’m highly influenced by the agile movement, but I was a developer. So I had that pain of growth. But it’s not successful, because like, “Hey, I build something and no one’s using it.” This is from 2000 to 2008. Before that, on the nineties, I was Object Oriented person. So I like object oriented analysis, design, limitation. All that thing that used to have like years ago. But from that, there was something interesting because we used to have inception phase. In fact, Rational created the UML. One other thing they created was the Rational Unified Process, which was agile like. The industry was moving towards to actually be more agile. And RUP was one of those first methodologies that showed up. Today, you look at it like, “Oh, it was so slow.” But at the time, it’s fast. And then they named that beginning of the understanding of what we need to do on a project as inception.

So when I went to US, and we start with the agile movement. Now, we start doing more like of an agile inception, where we understand everything we need to do for that project. We used to use the word “project”. You would map it to user stories. For example, like another colleague of ours, Jeff Patton, he wrote a book “User Story Mapping”. That’s from that period where we tried to understand everything: the users, their journey, the business needs. And we mapped everything to user stories, and you do this huge release planning with all the sprints. So sprint one, two, three. We even estimate everything and have story points and have burn-up for, “Oh, we’re going to deliver 300 story points, and have that release planned for one year.” Nowadays looking back, I’m like, wow, I was crazy to do that. Why I’m saying this? Because like in 2011, Lean Startup movement in Silicon Valley. They’re like, “Hey, I don’t care about doing agile. We cannot do the product for one year to see if it makes sense to the user. Let’s do something.” The minimal thing we can do to validate if we are going in a good direction. And that’s the MVP.

So the lean inception is a shift from, let me understand overall project to, yeah, let’s talk about the vision, and then figure out how do we get started? So the focus is not more on release planning of all the user stories. The focus is like, okay, how do we start? When you talk about MVP, now, the focus not that much on what were all these stories behind it. It’s more like, what are you validating? What hypothesis are you validating, you know? Let’s talk about the business, the user experience, and then the engineering side, what is the minimum we can do to validate we’re going in a good direction. Of course, after the lean inception, if you’re a software delivery team, you break it, you choose your story. But now, it became much easier because it’s much smaller, and everybody is aligned. So that’s the shift on inceptions, like bringing that lean startup thinking as a central piece, the central outcome, like a central result of that alignment. And of course, as I’m doing inception 2011, design thinking as a movement, something that was getting more and more popular as well.

I, myself, am a really good facilitator. Besides being a software engineer that like process and improvement, I’m a really good facilitator. So I brought off my facilitation skills on how to align a group of people from different perspectives. You need a lot of fine skills like handling post-its, cluster, and do a fish bowl, all these kind of stuff. The book exercise, one is like, Hey, let’s talk about MVP. It’s very important. We should focus on it. The sequence of activities, they work well really well. So, if you want to figure out, okay, how to align a group of people and do an MVP? You can do like I did. Took me like four or five years to figure out a good single set of activities that went well, and I was running sessions like almost every week. Or you follow that recipe that you’re going to figure out. Wow. If I follow these, we achieve great results at the end. So that’s the lean inception. It’s a mix of the activities and the sequence and why MVP with some tips and notes on how do you facilitate it.

Lean Inception and Design Sprint [00:14:06]

Henry Suryawirawan: [00:14:07] How about the design thinking? Because design thinking, I mean, we also have this sprint design, right? Sounds like it’s also similar timeframe where you envision what do you want to build? And you have an MVP at the end of it. So what’s the difference here?

Paulo Caroli: [00:14:19] Design sprint and inception, right? I find it fascinating. Jake Knapp, he was also in Silicon Valley, right? I think he’s a little younger than me. I was more of a developer. He was more of a designer. You have the difference there. But he was living in Silicon Valley. We went through similar companies. He was feeling the same pain that I was feeling. It’s like, “Damn it. I need to align these people to figure out what they’re going to do.” Even as a coincidence, I was a consultant at Google for one year, same time that he was there as well. We almost worked on the same team. It was very interesting. I even remember him from there. Of course, like both of us were not famous, but like, I remember, oh, there’s this design dude, which I like his style. Like I could see he’s a good facilitator. Google is huge. So we worked on different teams.

What happened is in common, both of us use design thinking. Post-its and okay, how to align people. The double diamond, open the options, and then you close some options. Both of us have that same style. Both of us came to the conclusion that like you know what, it is a week. It is a five day thing. I have time. Sometimes I would make it or sometimes I would make it shorter. If it is shorter, you don’t have time to have a brainstorming. It’s more like, if you try to do something, design sprint or lean inception in one day, probably someone telling that’s what I want. Go figure out. If you have a week, you can open the options and then make a decision to close it at the end. The thing is like from the time I was working on Google, I went to India and there I was running inception for UK, and then I went to Brazil. So I was not following what he was doing, and he was not following what I was doing, especially that I was writing a lot in Portuguese. And we came to a lot of similarities based on practical experience.

But the place where we differ, where we do differently. And of course this has to do with our backgrounds. He has that week about the design thinking. So he’s more focused on the design. So get the people there to figure out the design. They’ll have some options for the design to put in front of users. He’s going to get to like five users, for example. They will test and then they’ll decide. Okay, we have one mini prototype, but based on a design on an interface. At the end result, it’s a prototype. It comes from the design world. I come from the startup. I come from agile where we used to have the user story that tells you exactly what’s the value it’s going to bring? How I’m going to implement them? Sometimes even has the interface. I don’t want that as an MVP. As an MVP, I want to be very clear. What do I want to validate? But I don’t want to specify the how. So it’s a big difference to know if at the end of the week you have a prototype and use the prototype for something bigger. That’s design sprint. On the lean inception, you align a group of people about the vision, and you have a plan for the MVP. But you do not have a prototype. Use the prototype for something bigger. MVP is a plan for something small, that first step. That’s a major difference. It’s a strategic difference. If you think you know where you’re going to know the big picture. If you’re already aligned about what you want, design sprints. If you want to align about what do you want? How do you start? Lean inception. Or you combine both, and then it’s amazing.

Lean Inception Frequency [00:17:18]

Henry Suryawirawan: [00:17:18] So then my next question will be, how often do you run this lean inception? Is it like if you have a new product only, or is it like, even if you have a product you can continuously run these inceptions from time to time, maybe quarterly or something like that? So what’s the frequency to run this kind of inception?

Paulo Caroli: [00:17:34] First, I want to bring another person which I really admire his work, Marty Cagan. Marty Cagan writes a lot and talks a lot about product teams. That you should have a product team and everybody’s together. So in the perfect world, if you have a very strong product team, everybody’s together the whole time, they’re doing continuous discovery. They are aligned. It is the same team. You probably don’t need the lean inception because the teams are aligned. They are doing discovery, and they are also developing the product. They know what they need to do, just do it continuously. But it’s very rare to find those people, and sometimes difficult for the company to structure their organization with product teams. Majority of organizations I go through, even though I love those theories about product teams, that’s what you should aspire for, but sometimes we are not there, and then we need somehow to get some people together to align. Okay, what are we going to do? What is the vision? Sometimes you do have some discovery going on. So some people that did discovery, get together with some business people, that maybe they’re not part of the product team. They’re not together the whole time, and then the engineers, unfortunately they’re not sitting together with the product team the whole time.

Then you need the lean inception. So when there is a hard moment, a new feature coming, or important thing that we need to align, that’s perfect for lean inception. If the group gets aligned and it is the same group, probably you don’t need another inception. Because they’re already aligned. You’re aligned about the vision and the MVP, not about continuously working, or pivoting, change a little bit like it’s normal work. It’s not a lean inception anymore. If the pivot is a huge change of direction, then you need to align again, then you do a lean inception. It’s not like continuous delivery or continuous discovery. It is okay, we need to align and get together aligned.

Henry Suryawirawan: [00:19:13] So if I understand correctly is that every time you have probably a potential difference in terms of vision and alignment, you would conduct this lean inception in order to bring everybody towards the same vision, and towards the same alignment in order to build the same kind of understanding of MVP or in terms of product. Is that a correct understanding?

Paulo Caroli: [00:19:29] Perfect words. Whenever we need to either align or re-align people about vision and the MVP, that’s a call for lean inception.

Henry Suryawirawan: [00:19:36] And it’s also critical to have these three types of people: from business, from developers, and also from users.

Paulo Caroli: [00:19:43] I would say it’s critical to have those three perspectives. Because sometimes you go to a startup, and you do not have a lot of people, because they’re start up. Even though you don’t have the three kinds of people, you want to invite the three perspectives in the room. So I did run an inception for a very smart entrepreneur. The second day we’re meeting about the personas, and the journeys. He dressed differently. He brought costumes as if he were the persona. I’m like, I felt that amazing, because he was inviting the perspective of the users. Of course, that’s more into startup, right?

Big companies are different because in big companies, you want to invite the people that represent those three perspectives, and you do have sometimes more than one people. And then the chance like, okay, there are a lot of people here, how do we align? In the startup, when you invite the perspective, even though you do not have people, or I don’t have all the engineers in, but you want to invite that perspective into the room.

Lean Inception Agenda [00:20:33]

Henry Suryawirawan: [00:20:33] So maybe if you can walkthrough, in terms of high level, what is typical agenda of a lean inception?

Paulo Caroli: [00:20:38] Sure. First, I like to think about it from outside in. First, what is the goal of the week? What is the vision? And what is the MVP? So if that’s the goal of the week, before that week, you need to understand why I’m bringing the group together to talk about the vision. So probably there was a… might vary a lot. Big company that use a lot of project there, and not old style, but more traditional project oriented, finance oriented. Probably has a portfolio of growth concern. One of them, so hey it’s a really good approach, going to like, okay, you’ve got them approved. And then after you got the approval, maybe you do an inception. If you’re a company doing like discovery, there are a lot of discovery going on, and looks like by comparing those five different offers, this one’s a winner. Let’s do an inception on that one. I showed you two different sides. Or customer research, we have a lot of customer research and data, and the user research, oh, cool. Looks like we have something here. Call for a lean inception as well.

There’s something that happened before lean inception, or even a design sprint. Let’s do design sprint and prototype a big thing. Okay. Now how do we start? Even test a few users, but like your users now need to think about MVP and really validate it. So put in the hands of the user, only invite them to test the prototype which is amazing, but let’s now figure out what is the MVP that we’re going to put in their hands. So call for lean inception again. So I talked to you about what happens before the goal of the week. Because there is that goal of the week, the week needs to start for kickoff.

What’s the kickoff? You tell the story what happened before. Hey, we’re here like 10, 15 people together, because this is the top priority project for our company. Here’s the data from UX research. Here’s the data from the business requests, like whatever information you have, that’s shared on the kickoffs. And then the main sponsor, whoever that person is, probably make a beautiful speech. “Hey, we’re here. It’s going to be amazing. The best team ever, the best enterprise, the best product,” whatever. So kickoff, speech from the main sponsor, information of why we’re here, why do you kickoff of this lean inception for this initiative? And three, usually it’s myself or whoever’s the facilitator, to bring the importance of, Hey, you know what’s lean startup. You know what’s MVP. We will talk about the big vision. But at the end of the week, we’re going to have MVP. To get there, we’re going to follow these agenda. So we need to bring that message on the agenda. It’s a very important message. You need to bring on the kickoff. Why is that? Because you want to bring it up like, Hey, whoever’s staying in the room. I want the perspective from the business, from the users, and from the engineers together. It’s not like the old world where someone. Okay, here’s the business requirement document. Here’s the data from the users. Here are the engineers. They meet on separate meetings, and they’ll throw all those documents. Let’s hire a consultancy, figure out and tell me what I should do. No, no, no, No. We don’t work like this anymore. Yeah, let’s talk about vision first. Listen, let’s talk about users first. Listen, let’s talk about the engineers and then together, we’re going to figure out what’s the MVP. It’s not the external thing that some, “Oh Paulo Caroli, he’s really smart. Draw all the information in, and at the end, he’ll bring the plan for them.” No, not at all. In fact, there’s no such a thing as that perfect plan for MVP. The perfect thing is like people align about that plan, and they’ll make the plan a success. They will make the plan a success, not because they follow the plan. It’s because they’re aligned. They know what they want, and they will pivot together. Especially working with MVP, we pivot a lot. So it’s not about the plan, it’s about being aligned. So that strong message is on the kickoff.

Now that we have this central message, also on the kickoff, you tell, “Okay. Friday 3:00 PM. We’re going to have a showcase. A review of the week.” Well, it’s going to be nowadays in Mural or Miro, whatever to use. Last year, it’s going to be on the walls here. Everything we did. But they’re going to show you the final outcome, which is what is the vision? What is the plan for them? So I invite you stakeholder that would love to be here, but I do know you don’t have time to be here because we have other things going on. I invite you to come back here Friday at 3:00 PM and we’ll have a conversation about it. Conversation, not a presentation. Because I want to hear your input as well, to see if whatever plan we came up with, it’s a good plan. So that’s the beginning and the end of the week.

Now, I’m going to go day by day. Day one is more about understanding more about the business context. We’re aligned, validate the business context. We use that product vision statement from Geoffrey Moore. What is this product? What it’s not? And if possible, bring a product perspective, right? We need to make that shift from project to product. So that’s why I use the product vision to know whatever you’re building, treat it that as a box. It is a box of product to deliver something. What is the name that goes in the box? Fill up the product template statement, everybody together. It’s different than the statement that comes from the product managers or the product owner, the business owner. No, we are going to fill it together because we’re together here, and we all understood what we want out of this. So first day, a lot of things about everybody’s together. It’s a little bit more from the business perspective, right?

Day two is a little bit more from the user’s perspective. Let’s share the information we have about all the personas. If you had user research and these people in the room together and together, we will share this information. It’s not a presentation. Together, we are drawing who do we believe are the personas that we think will be impacted by this thing we’re building? Or who are the personas we should talk about before making decisions. And then the journeys, what are the user journeys that those personas go to solve their problems today? That’s it. It’s like, day one, perspective from the business, day two, perspective from the personas.

Day three, if it is a product that you build, it’s a feature brainstorm. Okay. Now that you look at the business goals the persona needs, which features should we build to fulfill those business goals, and to help achieve those personas' needs. If you look at the journey, it might be easier to find the feature ideas, but you might look at the persona needs, and the business goals, and that’s it. It’s a feature brainstorming. You have some boundaries around it. You’re not starting with the feature brainstorm. It’s very dangerous. Sometime you’ll get the engineers, and they want to start from the feature brainstorm from the technical perspective. No, no. Like when you put the feature brainstorm, it’s hard for me to say because I’m an engineer myself. But when you do the feature brainstorm on day three, there are more boundaries around it. So even if you come with an amazing technical idea, like it is a mistaken idea to solve some of the problems, either from the business or the users. It’s important to have those boundaries. Otherwise, we, I’m going to include myself on that as engineers, many times we think about the solutions before we think about the problems. So when it is on day three, it makes you think it more about the problem than the solution. And then day three also start making a review for each of those features. And that’s the thing. That’s the design thinking again, you’re opening the options right there. That feature brainstorm you’re opening. We are not speaking about MVP yet, so it’s a brainstorm.

And then day three and day four, you start to make camera view of all those features. We understand them isolated. It’s like small Lego bricks. We know the vision. We don’t know what’s the MVP. But you talk about possible piece of those bricks, those features. And then review each one of them individually from the perspective of the business, the users and the technology.

And then what you do on day five in the morning is, okay, now that we talk about all of them individually, look back at those user journeys, and answer the question, how do we improve their lives with our features? And once we start answering this question, you have a sequencer in which order should we work on those features to fulfill those needs? But wait a second, we are on lean inception. Now’s the time of the strategy, right? You know all this information. How do we think big, but start small and validate? And then this goes on the sequencer. And usually on the sequencer people go, “Oh, I think here’s the MVP”. But people need to talk about what is the next increment? What do you think will come after that? It’s also part of the strategy. Even though, we’ll focus on the MVP. The following week, the business people, especially, we need a strategy. That’s not only the first step. Your first step is also influenced by what you think would happen next. And then from that, you go to the MVP canvas, which goes in greater detail about that very first step. And that’s the final day. Day five and showcase.

Henry Suryawirawan: [00:28:26] So if I can summarize, probably from the beginning. You have the kickoff from the project sponsor, setting the right mindset, the right goal for everybody within this inception workshop. And then on day one, you talk about the business. You set up the vision. What the product is all about? And set a vision that everybody agrees. Day two is about user perspective, understand personas, the user journeys involved. Day 3 is about feature brainstorming. What this product would have in terms of capabilities and features. And the crucial thing is about setting the boundaries. Not to come up with the features without vision, but coming up from vision into the features. And then day four, you do some kind of review from the Tech, from the UX, from the business perspective. And then on day five, you agree what kind of MVP that you want to build, including the sequence of the features that you want to build. And then the last deliverable would be the MVP canvas.

Paulo Caroli: [00:29:17] Exactly. Well, only part to think about day three is, if your product is a little more technical, day three might get a little more technical as well. It’s okay. When you do the feature brainstorming, as engineer, I know that sometimes you need to get into some technical details. It’s okay. Don’t get into too much detail, because you don’t know yet what’s the MVP. Get in the first level, just first to understand those blocks and all those features.

Product Vision [00:29:41]

Henry Suryawirawan: [00:29:41] Makes sense. In terms of vision, you mentioned there’s a template that you came up with. So maybe if you can share, because to me, vision sounds a little bit vague, right? We can talk about so many things, but what is a good template?

Paulo Caroli: [00:29:53] For the vision, the first thing I realized is vision is vague. I’m not talking about the organizational vision. I think this is very important. I’m talking more about the product vision, and I like the word product. It’s not a project, it’s a product. Even if you’re within a project scope, you need to figure out I’m building something. What is this? Sometimes people are not so sure. Oh, we’re building, it’s a microservice. No. Okay. What are you building? Imagine it is in a box. What is the box? Who are you building it for? What needs do these people have? What is different from what we have today? What is the main thing that thing you’re building is bringing to these people? So Geoffrey Moore, Geoffrey Moore is amazing, right? I really like his work. On his book, “Crossing the Chasms”, he was really good on the early adopters. On that graph that he makes like, oh, you have the early adopters, and then you need to go to the early majority. It’s hard. That’s where the lean inception kind of fit. We kind of already agreed that, Oh, I think we have a solution. You know we have that on the kickoff. Also tell me what is the product? So he has a product vision template.

So the template I use is from Geoffrey Moore, which is amazing. I read the thing from his book, from 1991. The template goes like this, “For”. That’s what I find it’s amazing. I don’t even think it’s grammatically correct in English. You start the sentence, for who is this thing that you come up with? Who? What are the needs that these people have? For who? Then, what’s the name of this thing you’re building? Give it a name. And then, like the product needs a name or like, that box needs a name. What is that box? It’s a mobile app. It’s a collection of APIs. It’s a data mesh. What is it? Because sometimes we confuse it’s a product, it’s a project, it’s a team. What is it? That. What are the main characteristic of that thing? Are those people today without that box you put in front of them? Our product, what is the main differentiator?

I find that template amazing because it forced you to think about all those perspectives. To start with, you start from there. So I’m not going from the organization vision perspective, and I’m not going for all the teams aligned on that box. Because later on, at the end of the week, I want to even add a smaller box. It’s not even a box. I want the MVP. But it needs to start from somewhere. But I’m not going to start from somewhere huge, oh, what’s the organizational views? Oh, that is a large issue, to make this a better world through the environmental. Yes. I’m talking about the product issue. Put this in perspective, the shifts from project to product, as a product. That’s why I like Marty Cagan. Because he talks about product team. It’s like data as a product. Like that’s the thing, right? We need to think about those solutions that we’re building as a product. And the lean inception started with what is the product vision.

Henry Suryawirawan: [00:32:30] So maybe if you can give an example because just now when you describe it, it’s a little bit like in pieces, right? So maybe if you can take one product example and come up with the hypothetical vision for us to understand better? If that’s okay.

Paulo Caroli: [00:32:43] I cannot give you from the clients, because a great majority of the inception are from the clients, right? I wouldn’t disclose their product’s visions. I’ll give you from the book. For people that like playing soccer, who need to find other colleagues to play after work hours, then, “Find Your Soccer Colleagues” app is a mobile app that helps connect people that play soccer after work hours or at lunchtime. Unlike, well, getting fat because you do not find the people, or like sending messages on generic WhatsApp group and Facebook groups, our app will connect you to people nearby that have the same problem, and need to play that game at the end of the day. That’s a product vision. In fact, it did happen in one of the inception, but it was for a community in Brazil long ago. They create a mobile app for that. And of course, it’s only the vision, rights? We haven’t talked about MVP or anything, but it gets us started. To get us started as the business perspective, the users, and the technical perspective. And if you go through all the activities on the week, at the end of the week, you have a preferred MVP.

Henry Suryawirawan: [00:33:49] Thanks for giving the illustration.

MVP Canvas [00:33:50]

Henry Suryawirawan: [00:33:50] So the other thing that I find very interesting from lean inception is the concept of this MVP canvas. Maybe you can share a little bit, what is MVP canvas?

Paulo Caroli: [00:33:59] I started running inceptions in 2011. And ThoughtWorks in Brazil, we have a ThoughtWorks Porto Alegre where I was working at. We had 200 people. It’s a city in the South. We have ThoughtWorks Sao Paulo and ThoughtWorks Recife, throughout the cities. And I was invited to run all the inceptions, a great majority of them. The teams that I would run the lean inception, Porto Alegre in the South, majority of crews are from Sao Paulo, I would travel to Sao Paulo to run an inception. And those usually would come back to Porto Alegre, where I was originally working. They would go better to the teams that were in the Recife. Even though I was running the same lean inception. And I was like, “Why is this happening?” And then I realized that the weeks after the inception, I would walk by the table of the teams, and like, “Hey, how’s that MVP would be doing? How are you validating the MVP?” Because on the lean inception, we talk about the building blocks of the MVP. I’m like, okay, now you’re getting close. Like how you’re releasing? Are you opening to only specific group of people, or you open it to the whole client’s database? Which part of the journeys are you validating with the MVP? Because on the inception, we talked about a lot on journeys, but the MVP is very focused, right? And then I’ll go like, what is the expect results for the MVP? Not for the product. Okay. That MVP that you’re releasing now, what do you want? Oh, I want everybody to play soccer. No, like that one. What do you want to measure on that MVP? That MVP has very few features. What are the metrics that are you are collecting to verify it?

So I realized that I was making questions that I should have left them written down during the lean inception. Even though I would make all those questions in the inception, they’ll just vanish after that. Cause the team would go the next week and build a user story and have a backlog of work, and that’s it. And then you go on delivery mode, and you’d lose a little bit of that strategy. So I decided to bring this as a canvas on the lean inception. And then all the teams would come on the lean inception. So when they go to their table, and then you sit together, and had to know the sequencer in the backlog of work. Next week, they would have the MVP canvas, so they know, it’s that bridge of, okay, why are we building this, and how are we going to see the results? Or how are we going to get the information?

So then the MVP Canvas. Canvas has seven blocks. One, what is the MVP proposal? Which very narrow focused on the MVP, right. The proposal for this MVP is to validate if people from that neighborhood who download the app. It’s something really small. Segmented personas. Okay, for all the personas. Oh, we’re talking only about amateur soccer players from neighborhood. We’re not talking about the more professional, the people that own soccer fields that want to make some money renting them, maybe the coaches. No, No, this one’s only for amateur soccer players. Not all over Brazil, only that one neighborhood where I have one soccer field that I could rent. The user journeys. What are the user journeys that you’ll impact on this MVP? Well, this MVP is only finding other people to play with you. You cannot share the view. You cannot do this and that and that. We cannot create a tournament. It’s only that one. It’s very specific. We’re talking about MVP. Okay, what are the features or workout that we need to get sorted on this MVP? We need to make the Google Form work, but we’re going to connect it with WhatsApp. We want to be calling people, so okay, we need at least integration with Google Form and WhatsApp. You detailed the work you need to do. What’s the expected results? Well, damn it. Okay. How are we going to make this work? Oh, we should hire AdWords on Google for that neighborhood. Okay, cool. So let’s hire like $200 on AdWords. So $200, with this we can buy a hundred thousand click-through rates. We expect that at least 10% of those will click. And from those at least around this number download the app and schedule a match. Cool. Wait a second, but we should have the NPS. If they played the match, we should contact them. How are we going to contact them? Oh, we should go out with some message. No, we can call them. It’s only a few people. Okay. We expect the NPS to be at least this number. So we know the metrics. And once you know all of this, what is the cost and schedule? Oh, cost and schedule. Well, 200 bucks for the Google Ads. Well, we need the team. No, we don’t need the team. We can do this ourselves. So we need three weeks. We can get this done. And after it’s done, we need at least one month collecting data to decide the next steps. That’s called the cost and schedule, and that’s it. That’s your MVP canvas. It’s very narrow focus for the MVP.

Henry Suryawirawan: [00:38:04] Yeah. If I can probably try to summarize, so there are seven different key things in the MVP canvas. The first is what is the MVP all about? Maybe the vision of that particular MVP. It’s not the whole product, definitely. And then who are the personas involved, and what kind of user journeys that you will build as part of that MVP? The features that you are committed to build for this MVP, and then what is the expected result? Or what are the expected results that you want to achieve with this MVP? And then you will have to find out some metrics in order to validate those results. And then the last point is about cost and schedule, like how much cost you need to build? And how long the time required to build the product?

Fun Retrospectives [00:38:44]

Henry Suryawirawan: [00:38:44] So, Paulo, I know that you also wrote another book called “Fun Retrospectives”, right? So the word “fun” here is very interesting because many people know about retrospectives, but why specifically fun retrospectives?

Paulo Caroli: [00:38:56] Yeah. In fact, like I still have two loves like, it’s lean inception, fun retrospectives. It’s two of my things, and both the output people at the center, right? It has a lot of facilitation, but like putting people at the center of the room, making decisions or improving the way they work. Retrospectives are influenced by Scrum. I think was really smart when they said, Hey, you should always have a retrospective in your sprints. You should have one retrospective per week, because some teams don’t use Scrum, but you should have a retrospective per week. It’s that continuous improvement moment there, where you get together with your team and say, “Hey, let’s listen to each other and see, how can we be more effective as a group?” It’s a moment to listen to each other, to look for process improvements. But a lot of the tests should go into people improvements.

It’s almost like if you go to therapy every week, it’s that one hour with your therapy, but a group thing. For that reason, many times you get the group together. We work on software delivery. The glass is always half-full. It’s never, “Oh, Woohoo! The glass is chilled.” No, it’s always half-full. And for some reason you get people together, my realization is that we have a tendency to focus on the negative thing. We have a tendency to always say, “Oh, look, the glass is half-full. We never celebrate the glasses.” We always say the glass is half-empty, not half-full. So I put the word there for two reasons. One is, “Hey. You should celebrate the achievements.” And teams, when they’re happy, they deliver more. So if you celebrate that the glass half-full is much better than if you keep on saying, what do we do to fill up the other half? So the fun there, one, it’s like fun to remember to celebrate the achievements, and to make it a light environment. Because we do need to talk about problems as well. It is important. But in order to be effective, and bring difficult conversations, it needs to be a friendly environment.

So before getting to, " Hey Henry, how are you doing? I need to talk about a problem." Like, Hello, this the context. Let’s have him energized. Let’s laugh. Let’s relax. Let’s talk about the prime directive. And then maybe, well, not maybe we’re going to bring the problem, but like now the environment is more lighthearted. So that is why the fun showed up there. And also our colleague, Pat Kua, we worked together for a few years. And he also is really good on retrospective. He also has a book on retrospective. And when I was selecting the name of the book and the website, and I was like, “Hey Pat, I need a name. What should I call it?” And then he told, “Paulo, you always make the retrospectives more fun. Even though we’re talking about serious stuff, like whenever you’re facilitating it, you make it fun. You make it light.” I’m like, “Oh, Fun Retrospectives. Thank you.” And then it became fun retrospectives.

Retrospective Celebration Activities [00:41:28]

Henry Suryawirawan: [00:41:28] Thanks for sharing the story. So you mentioned a couple of things very interesting. The first thing is about celebration, right? So what are some of the probably examples of activities that you can do to come up with this celebration within the team?

Paulo Caroli: [00:41:42] One is very simple. Like, you go to retrospective. Usually I split the board into two or three areas or four. When you split the board in two areas, name one of the areas “Thank you”. And then say, “Hey, on here, please write down thank you notes to your colleagues. Write down, why do you want to thank them for?” Usually, retrospective is about a period. Like, thank you, or name one of their accomplishments. Let’s write down the accomplishments we did during this period. That’s super simple. Like, I’m not even telling you exactly what retrospective activity is. But whatever retrospective style or activity you select, think about having one area for thank you, for acknowledgement, for accomplishment. Unless you ask for it, people won’t write. I think it’s human nature. We will talk about the problems. If you were going to talk about the problems, have one area and say thank you.

Another one activity super simple. This was more fun, but essential. Bring a box of chocolate, and then you name it a token of appreciation. Then introduce it as a facilitator, “Hey, as part of retrospective, we are going to appreciate each other. So I have a chocolate box here. Let’s please form a circle. I’m going to start. I want to appreciate Henry for that day on the sprint planning. He was really helpful to me when he brought these lights and shorten all the things we did last week. So Henry, thank you.” And then I walked to Henry with a box of chocolate. Henry, get one chocolate, and now you appreciate someone else, and then you give him that person a chocolate, and verbally tell why you’re doing it. It’s amazing, the result. Going face to face, thanking each other in front of the group. That boosts the group morale. It’s amazing. Simple. It’s a box of chocolate. I just feel bad because until now I didn’t find remote how to make it like, you can say thank you. But like that chocolate taste, how do we make it happen remotely?

Henry Suryawirawan: [00:43:30] So how would you do it remotely? Because these days, everyone is remote, right?

Paulo Caroli: [00:43:35] Yeah, I did that one remote, like you made a circle in Mural or Miro, whatever. It’s like you put people’s avatar in circle, and then each time like one person will walk with a flower to the other one, and verbalize why he’s giving the flower, and the little flower would stay there. In person I prefer because I like chocolate. It is something when you receive a compliment, and right after that, you have a taste of chocolate in your mouth. That’s amazing, because it’s like you get the compliment and then your body also gets a compliment. A nice taste. It’s a really good feeling. But we need to verbalize, at least. I know we are remote. One thing I did, like I did a token of appreciation. I organized to deliver chocolate for everybody on the meeting. So they all received the package. I said, “Hey, you are going to receive a package. Please don’t open before the retrospective. You can only eat when you receive the appreciation”. It was cool. It worked out.

Henry Suryawirawan: [00:44:24] Yeah. The one I’ve experienced before is somebody giving the post-its. Just a post-it with maybe a few messages, like why you thank the person. But I can understand that giving it with maybe token of appreciation, like chocolate or flowers or something tangible, at least it also gives some meaning for you to actually enjoy after that actual message. So definitely I think for people, maybe you can try these kinds of fun activities, giving a token of appreciation, not just like post-its or letters. That will be a good experiment, I guess.

Lightweight Environment [00:44:52]

Henry Suryawirawan: [00:44:52] Another thing is about light environment, right? I think many people try to make retrospective really lightweight, but many times of course, we talk about problems, right? How to actually be conscious on making this more lightweight?

Paulo Caroli: [00:45:05] That’s a really good question. Because we will talk about the problems, right? We need to talk about the problems and retrospect. It is that maybe first talk about the problems. So how do we handle it? First, the context. You have to be very clear about the context. If the team is on a sad moment, like the energy is low, do not make a context that invites for problem. Be cautious about the concept of the retrospective. The team is super happy. It’s achieving. Cool. Let’s focus on the problems. The team morale is really low. Let’s have a retrospective to boost morale. So that’s part of the context. When you are deciding what is the concept of the retrospective that we need to be aware of the moment of the team. Don’t choose a context to dig further into problems if the team morale was really low. So first do a retrospective to boost morale, and then the next one you dig further into problems. So the context is very important.

After the context, do run a short energizer. It’s a five minute activity to… You need to break the ice. Especially now remote, because before when you were present, you leave the table, you leave the desk and then together, we walk to a room, and then as you walk in the room, okay, I’m coming to retrospective. It’s similar to when you walk to the psychologist’s office, and like, okay, I’m physically walking here to a place where I’m going to open my heart, right? Retrospective was the same. We’d walk into the room. Now it’s just another meeting. So you need to break the ice. If possible, the energizer should be fast. It’s not, “Oh, we’re going to have an activity. We stay one hour playing here.” No, we cannot do this. It needs to be fast, like five minutes. And if possible, a subtle message related to what you want to achieve from it. If you’re having problems of self-organizing, an energizer that has a subtle message on self-organizing teams. You have problems with user stories, energizer that has a subtle message, hey, we need to communicate, not only rely on reading documents. So find energizer with subtle message, that will help you with the context. So you had the context, you have energized them.

The prime directive where you remind people about, “Hey, it’s not a blame fest.” But the prime directive after I energize, it gets easier because everybody’s laughing, and then you read the sentence. Okay. The environment’s already better. Let’s get to remind about the prime directive. And then after that, a check-in. What is a check-in? It’s a quick, let me feel how people are feeling right now, in the context of this retrospective. And then check-ins like people kind of open their heart or how to save their feeling, before you move on into digging for information. If the check-in results show you, yes, move forward because people are safe to talk about it, then you go and dig into the problem. And then you do your filtering and then a check-out.

But before you dig into the problem, have you realized like how many steps you went through? And as a facilitator, if you have signals very clear, “No, I’m against that context.” The energizer explodes, people are not laughing at all. The check-ins show people are not safe. Don’t go in that direction. If people are giving you red flags, like I cannot talk about problems. I cannot talk about problems. Then we go talk about problem, guess what’s going to happen? They’re going to explode. Don’t do it. If there’s a red flag, what do you do? It’s like it’s people decide the retrospective. Oops, safe and slow. We should talk about what should you do to increase safety and not talk about what’s the problem with continuous integration or whatever. That’s the importance about planning the retrospective and facilitate it. Facilitate not only following a plan. It’s like, go through the activities, making decisions. Yes, we are moving this direction or that? You need a plan, but then you need to facilitate.

Retrospective Check-in [00:48:29]

Henry Suryawirawan: [00:48:29] Right. So how do you actually do these check-in? Is there specific question that you ask? Are you feeling safe or is there kind of survey? What’s the process like?

Paulo Caroli: [00:48:38] On the site funretrospectives.com, I organized the activities as per those steps. There are activities for energizers. There’re activities for the prime directive, because you have two kinds of prime directive. One about retrospective. One about futurespective which is different. Another one about team building. So prime directive. Then there are check-in activities. Then there are main course activities for retrospective, futurespective and team building. Different activities for each one of those. And then check-out activities. Oh. And filtering activities.

So check-in activities, the most famous one are safety check. But people only did the safe check, and that’s it. The thing about check-in, like it needs to be fast. To verify how people are feeling as they answer, before they do the main course. Another example we can do is like one word. Share with us in one word, how you’re feeling right now, in the context of this retrospective. Another one is draw your feelings. Please draw how you are feeling right now, in the context of this retrospective. Or happiness radar. Please share with us on a scale of being really sad, super happy, how you’re feeling in average during these periods. How you’re feeling in average during this period for things related to the business, for things related to technology, for things related to the process? It’s only happy, sad or medium face for each of those categories. And then you carry this forward to the next one. Okay. So now tell me why you’re feeling this way? Maybe draw something. Now you need to ask them, why you’re feeling this way? Gather data. But you as a facilitator, based on what you get from the check-in, okay, yes, I can move forward safely to this next activity or no. Tell me how safe you are about sharing and talk about anything. If the group’s not safe, what are you going to ask now? Like, “Hey, now let’s talk about anything.” No, the group told you they’re not safe.

Facilitation Skills [00:50:24]

Henry Suryawirawan: [00:50:24] It seems that the facilitator’s role is very important in this kind of activity. So what would be some good attributes or some good things that facilitators should possess? I know that probably it’s not like everyone can do this facilitation really well. So what are some of the key things, do you think?

Paulo Caroli: [00:50:42] Well, first thing is the distinction about the facilitator hat and the participant hat. If you’re facilitator retrospective for your own team, would even be nice if you bring the hat. I’m talking as a facilitator, remove the hat and talk as a participant. If you have the luxury to have an external facilitator, even better, because then there’s no hat in that corporate space, right? That’s the first advice, because I know that we need to facilitate a lot of retrospectives for our teams. So bring a hat and say, “Hey, I’m here as a facilitator.” If you’re talking as a facilitator, facilitate the conversation, don’t bring your opinion trait. If you want to bring your opinion, remove the hat, raise your hand as anyone else, and then talk when the moment’s appropriate. That’s the first advice.

Second, if you’re going to facilitate, there is some work that happens before the retrospective. It’s like talking to different people, trying to understand the moment of that team, and then think about the agenda to that moment. And be careful because sometimes you talk to people and they want too many things for one retrospective. You want to be a retrospective. Not a, “Oh, let’s lock ourselves for one day here in the room.” It’s like having a five-hour session for psychologist. No. Psychologist like they do a lot of one hour sessions. That’s on purpose. Same with retrospectives. Don’t bring too much in one session. It’s too much for us to handle. So when you talk to different people, you need to think about the agenda, the context, the activities you’re going to bring. So prepare the agenda. Fun retrospectives can help you with that because the combination of activities will make you think about the agenda, that check-in, the main course, the check-out, the context, the prime directive you select, is a retro or a futurespective. Once you prepare the agenda, then it’s about facilitating. Pay attention to the results. And how do you create a good environment? Then pay attention if it is really good environment. And if it is, move forward with your plan. If something goes off track, bring the focus to the people, not your agenda. That’s the thing like, look at the people, see how they’re feeling. Don’t move forward in your plan or digging into a problem or something if someone’s not feeling good about it.

3 Tech Lead Wisdom [00:52:47]

Henry Suryawirawan: [00:52:47] Thanks for sharing all this. Unfortunately, we are going to the end of this conversation due to the time. But I have one last question that normally I ask for every guest. It’s about three technical leadership wisdom. So Paulo, do you have some kind of a message or wisdom that you want to share or pass along to the audience here?

Paulo Caroli: [00:53:04] Definitely. Three wisdoms for a leader. Empathy. Put yourself in everybody’s shoes. I know it’s a hard thing because we cannot give them the context. But try to understand where people come from with open heart. Be very empathetic to understand people. The second would be openness. The moment you want to be empathy, you have to be very open to everything. Be very open minded for the difference that we have. You cannot find two people alike, so you need to be very open in order to have that empathy level of connection with people. And then the third, I would say, servant. The world has changed and if you want to be a leader, you want to figure out how to be a servant leader.

Empathy, openness, and servant. Because the other stuff, leadership, you have a lot of books and things that you probably already have covered. But like empathy, openness, and servant. For me, those are the three skills that you need to really work on to be a leader for today. Because we are right in the future. The world has changed drastically.

Henry Suryawirawan: [00:54:03] Thanks for the beautiful wisdom message. I think I agree with that empathy, openness and servant leadership will be like very rare, critical skills for leaders in the future. So thanks again, Paulo, for your time. If people want to connect with you or find out more about you, where can they find you?

Paulo Caroli: [00:54:17] My website. I blog very often at caroli.org. If you want retrospective stuff, funretrospectives.com. You’ll find me in my contact. I’m very active on the blogs, the books, Twitter, LinkedIn. But go to the website, you’ll find me.

Henry Suryawirawan: [00:54:34] Thanks, Paulo. I hope that people listen to this episode and they will try some of these things like lean inception and fun retrospectives. Thanks again for that.

Paulo Caroli: [00:54:41] Awesome. Thank you so much. Cheers.

– End –