What is Missing to Make Agile Alive with David Pereira

What if your team could work smarter, not harder? Discover the secrets behind this transformation with product coach David Pereira as he shares actionable insights from his book, "Untrapping Product Teams." Learn how to prioritize learning over rigid processes and explore David's unique "adding by subtracting" approach to streamline workflows and foster collaboration. You'll also gain tips on how to empower your Agile team, pushing boundaries while avoiding the pitfalls of control.

Join us as we dive into adapting plans to ever-changing realities, focusing on specific issues rather than falling into analysis paralysis. Through personal anecdotes, David reveals his iterative process for writing a book, emphasizing the importance of gradual risk-taking and continuous learning. Whether you're a seasoned Agile practitioner or just starting out, this episode provides practical advice and profound insights into the Agile mindset, humility, and adaptability for both personal and professional growth. Plus, don’t miss David’s top picks for enjoying Munich, no matter the season!

Connect with David on LinkedIn:
https://www.linkedin.com/in/davidavpereira/

Subscribe to David's Newsletter:
https://dpereira.substack.com/

Chapters

• 0:06 Agile Insights and Empowerment Discussion
• 13:12 Adapting Plans to Changing Realities
• 28:32 Uncovering Agile Mindset and Growth

Transcript

Mark: 0:06

Welcome to the Agile Within. I am your host, mark Metze. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Well, welcome back everybody to the Agile Within. This is your host, mark Metz. My guest for today, from Munich, germany, is David Pereira. David, welcome to the show. Thank you for having me here, I'm glad to be here.

Mark: 0:51

So it's a tradition here at the Agile Within to ask our guests if I were coming to your city for a day. So if I were coming to Munich for a day and had never been there before, what's one thing that you would say I couldn't miss doing?

David: 1:06

Cool question. So I will give you two places, because it depends on the weather. So let's say you are coming here in summer, so it's very sunny and beautiful. What I would recommend you doing is go to a lake and enjoy the day by the lake, have a picnic there, swim by the lake and I would recommend going to St Bernese and then you could see the mountains. Just enjoy the lake and have a picnic there. It would be awesome because it's beautiful, it's incredible close to the nature. But if you decide to come here and then it's winter, full of snow, I would recommend something different. Go to the Alps it's one hour from Munich and then you do something different. There you have a walk with the alpacas by the snow through the Alps. It is one of the most beautiful things I have ever done around Munich because alpacas are quite special animals. They are very strong-willed and it's nice to walk with them through the mountains and just have a good time there.

Mark: 2:12

Are they tame? Can you walk up to them? You walk with them, all right, so you experience the Alps literally with the alpacas.

David: 2:22

Then yeah, and it's quite funny With more people. So it's kind of. Sometimes they start running so you need to hold them back and sometimes they will say I'm going to go anywhere. They stop and you need to kind of convince them to start walking again. So it's an honest experience.

Mark: 2:40

Sounds like fun. Well, thanks for sharing that, David. Well, David is a product coach and he's also the author of a new book, which you may be familiar with, called Untrapping Product Teams, which is the number one new release and bestseller in software development, and the title for our podcast today is called to go over here today to talk about those eight different things that you might find that are missing, maybe that you're missing, maybe that your company or your teams are missing, that truly make Agile come alive and make it really vibrant. So the first point is prioritizing learning over processes, David. Why is that important?

David: 3:29

The key is that we simply don't know what we don't know, and when we start talking about processes, it's like if we would know what is the right thing to do, and we want to put the process to optimize how we work, process to optimize how we work. And actually what we need to have is a room that we can ensure we learn the key things that are fundamental to create product. And what am I talking about here? For example, when I wanted to write a book, I could start with the process. What is necessary to write a book? I need to have a structure, I need to have a table of content and all of that.

David: 4:04

But at this stage I decided to write a book. The only thing that was relevant at that moment was to find what I could create of value for my audience, and I didn't have an answer for that. So I didn't care about the process, and that's how I uncovered something that was worth writing about, and I learned things that I didn't even know I could write, and then I started figuring out on the way how I could write the book. It's a kind of a learning is your unfair advantage? That's what matters most.

Mark: 4:38

How do you approach teams? When you come in and work with a team that is extremely process heavy and let's just say process first.

David: 4:46

So one thing I like doing is understanding the workflow of the team. So the bigger the workflow, the more I get scared. And I like doing one thing which I call as adding by subtracting. So I look at the workflow and there are a few things that I know they are detrimental to collaboration. Common one, which is the first to remove for me, is a step called PM or PO approval. So at the very end there is something saying the PM or the PO need to sign off the items. Just by removing these, you start collaborating on the same level, because PM or PO is not on a higher level than any team member. We are all on the same level. So we need to start doing that.

David: 5:31

So I would start doing this, removing one step at a time. Another thing I like removing is, for example, it is ready to go to the sprint, in other words, the finitions of ready. So many times we can improve how we work with each other by simplifying how we collaborate, that is, by removing processes. Sometimes we just add processes because maybe we had a situation that was painful. Then we go to a retrospective and we say what could we do differently? Then we talk about the process, but that is making things more rigid. I would say let's try figuring out the root cause of that. Most of the time, it's about having a conversation and collaborating with each other.

Mark: 6:24

I assume if you go in and if the team is using a board to look at their work and you see the workflow and you see a dozen different statuses or columns that the team has to go through for each work item, that's a telling tale, right? Yeah, yeah, all right. Well, let's keep moving here. Number two requires empowerment instead of control.

David: 6:41

So a lot of people say about empowerment right of control. So a lot of people say about empowerment right. And one of the key aspects of empowerment is you need to earn that. From the agile team perspective, empowerment is not a given. But when it comes to leadership, if they try to control the team, asking them like did you meet the deadline, how are you going to meet that and how are you progressing All of this, this collaboration, will lead to a service provider relationship, which is not fun for any of the signs. And then you limit the potential of the team. And what does empowerment mean in this case? Empowerment means we are struggling to achieve A and we need to do that in order to reach our objectives. How can we get there? So it's a more collaborative, showing vulnerability to the team and collaboratively figuring out how to do that. And then you ask the team what have you learned so far? How confident are you in solving this challenge? Instead of saying are you delivering the feature on time?

Mark: 7:48

This one really requires a certain level of bravery or strength from the team to be able to push back, because it's not easy, right?

David: 7:58

No, and what you say about bravery is key, because, when it comes to agile, you need to be brave. And one thing that I say a lot it's a very stupid sentence, but to get where others don't get, you need to do what they don't do, and one of the things is about being brave.

Mark: 8:19

Yes, Not being afraid to say what needs to be said.

David: 8:24

Yes.

Mark: 8:24

All right, well, let's keep moving. Number three implies setting direction and uncovering how to get there.

David: 8:32

Yeah, this is very related to the direction of empowerment, right, empowerment means you trust a team, and now, if you trust a team with problems worth solving, but you don't tell them what success looks like, then you're setting them to fail, because then how can they solve something that is relevant? So I like saying that we need to know what success looks like, as well as which cards we have to play the game. What am I talking about here? Many people say our objective for this quarter is to increase our conversion rate by 0.5%. Oh, that's very easy Just drop the price of everything and then it will increase very fast. But what are the cards you have? So which trade-offs can you make? What are the metrics you have to protect? And this is what about setting the direction, because if you set this, the team will know how to play the game, and if they don't have that, they will simply not know how to play the game.

Mark: 9:37

So you mentioned uncovering how to get there. Tell us a little bit more about what you mean, about how you chose those words about uncovering.

David: 9:46

Uncovering is accepting that we don't have all the answers. We may know where we want to be, but then we have no idea how we would get there. I will give you an example. Once I wanted to create a cohort to help people apply product discovery practices, and my final objective was like people feel empowered to start doing that in their day-to-day life. That is the final objective. How do I get there? I had no idea exactly. So what I started doing to uncover that was talking to people, interviewing them, and one of the things that I uncovered was that the real challenge was not about which methods to use. What product discovery meant was how do I gain support from management? That was a challenge that I found that many people were facing and they didn't know how to solve that, and I didn't know that was a challenge for most people. So I uncovered this challenge and then I could address it. If I would have started the course with the initial table of content I had, I would have missed the mark.

Mark: 10:58

All right, David. Number four signifies being comfortable with the uncomfortable. Sounds like advice from a doctor.

David: 11:06

Yeah, because what happens in this case? As humans, there is one thing about us Anything that we don't have the answer, we start feeling endangered, because we are risk-averse animals, I would say because that is imprinted in our brain, meaning that we don't like stepping into the unknown. That's the reason we create processes, because then it makes us feel safe. Going back to the example I said the PO or PM approval that makes the team feel safe, that someone is checking there, saying quality is good, we can go live. Someone took that responsibility. There is a process for that.

David: 11:51

But if we want really to be agile, we don't need to remove these things, meaning that we don't know if some things are going to fly or not. We don't know that. And this I connect about being humble, because we need to be open to learn about it. And that reminds me of a quote from my dad, which is be humble and the world will teach you nice lessons, few nice lessons. Be arrogant and you will miss chains of evolving. So if you are arrogant and you think you know it all, you create a lot of processes and then you're going to miss all the chances to evolve because you are not hitting reality in a way that you are flexible to change, so you need to be humble, and then you share your mistakes with everyone, and then you learn, and that is anything but comfortable.

Mark: 12:45

So how about the environment that you walk into, where the culture is very much set to having the answers up front From the top down? It is pushed where we need to do more research to make sure that we're doing things correctly before we start acting. How do you start tearing down those walls and making some progress? What small steps do you make to help those organizations?

David: 13:12

There are different ways of starting this. The first thing is understanding the status quo. So how successful is the company? That's the very first question. You need to understand If the company is struggling to grow or if there's a struggle there that disturbs them. That is where you can anchor and you could see if changing would contribute to this. That is one aspect.

David: 13:37

Another aspect is, even if the company is successful, if you look at everything that was created over the last 12 months, how often is it used? And if you realize that there are many things that are not used, you can share that with others. Say, I learned that 30 to 50% of features we created over the last year they're just ignored. What should we do about it? Should we review how we work or is that the way we want to continue working? Creating features nobody needs. So you can bring to dialogues, help the other, see what you're seeing. And there are different ways of entering here. I generally see about anchoring on something that a change could drive, potential desired results, or the results of the work, the best work and seeing how that drives value.

Mark: 14:30

And then if I have a conversation about trying different things, Product manager in that situation that continues to say well, I need to do more market research before we start this endeavor to make sure it's something that is worthwhile, that we won't need to remove later on because it's not being used. That analysis paralysis that we get into.

David: 14:54

So that is something we need to change, and what I like saying is what is the worst thing that can happen if we just put it live and it doesn't fly Most of the time, the reality is that the bad decision is better than no decision, because a bad decision creates learning. No decision creates nothing. So if we are just researching for the sake of it and we are not confronting reality with product, then we are just researching for the sake of it and we are not confronting reality with product, then we are being risk averse. The problem of being risk averse is that maybe our competitors are not, so we leave ourselves vulnerable for disruption.

Mark: 15:34

So I think this is taking us into your fifth item here about. It's about taking risks gradually instead of having answers to everything.

David: 15:43

Correct. So one of the things here is most companies I see they spent a lot of time into prioritizing, so they decide what to work on next and they may even have roadmaps for the next year and they go all in. It means the teams will have to figure out how to deliver what was promised. This means, like if you're playing poker is you are putting all of your bets into that, so you are going all in. This strategy can work if you have the cards in your favor and then you're going to be successful. But when it comes to digital products, the truth is we don't know what we don't know, because users are going to surprise us very easily, and what I mean by gradually taking risks.

David: 16:31

Let's go back to my book. When I had the idea of writing the book, what if my first approach was I have the idea I'm going to write the whole manuscript, 70,000 plus words, before I share with anyone. It would take me at least three months to write that before I talk to a single person. Which risks would I have? Is this story I'm sharing, anything that will resonate with my audience? I would bet on that. The other thing is writing a book is different than blogging. I used to blog a lot but I had never written a book. Is my storytelling contributing to a way that people will understand the book from end to end? So that's another thing about the usability and the feasibility of that. So I had to de-risk-end so that's another thing about the usability and the feasibility of that. So I had to de-risk my ideas. So the very first thing I had to de-risk was the interest. So what I started doing, I posted on LinkedIn and my experiment there was given my past engagement, I wanted to see at least 200 plus engagement and interaction with the post when I announced I would be writing a book. So it turned out that it got more than 400 engagement there and there was a resonance and I said, ok, should I go all in now? No, that was an experiment. I did in just a few minutes. I said now let's scale a little bit for a few hours.

David: 18:00

So I put a survey and instead of asking people like, which traps do you have? That is a very biased question I asked them like what challenges you in your work? What are things that you want to solve? And you don't know how Can you share a story? So I put this survey out, and what I wanted to find out was patterns, and one pattern that I found that was really much unaware of was the following there are many books from the Silicon Valley saying how great product companies work, but I am from a product company that has nothing to do with that, and all of those practices I have no idea how to bring to my game, so I don't know where to start. That's what resonates with me, because I also don't have any experience from product companies from Silicon Valley. But, as most product people, I come from ordinary product companies that even struggle financially. So I said I can share loads of stories on that. So then I de-risked this.

David: 19:08

The next step I entered was can I write this thing? So then I ran a product experiment of writing a guide and sharing with a few people and put on my newsletter and so on and so on, and then I learned that actually my message went sideways. People understood differently, so I had to adapt. But I learned what would help people was about sharing more stories and less theories. So I adapted, and all of these things I'm telling you happened in a span of one month.

David: 19:40

I didn't have the book, I had the idea, so I was doing all of this to level up and then eventually I committed to write a manuscript. But instead of doing upfront writing, I found a way of learning fast. I created better reading cycles and people would read and provide me feedback and then gradually I would adapt. So I did that five times before I finished the manuscript. And that is what I mean by gradually de-risking your ideas, because you will learn what doesn't work before it's too late, before you did this investment of putting all in and then you realize, oh, something was wrong, but then it's too late.

Mark: 20:23

I think of another example, david, of going all in. I know not all of our listeners follow sports, but I think everybody understands the idea of sports betting, and I'm not one to. I've made one bet in my entire lifetime and I lost it in sports. But if you do have some money that you want to spend on betting, would you rather have a large number of small bets that you're learning from as you're betting on, let's say, games or matches? What have you and you're able to learn as you go, because you may know a lot about sports, but the gambling side is totally different. So I hope I'm not offending anyone by talking about gambling here, but the gambling side is totally different. So I hope I'm not offending anyone by talking about gambling here, but we're talking about making bets. Or would you rather make one huge, large bet to say, okay, before the season even starts, I'm going to bet $100,000 on who's going to win the World Cup.

David: 21:18

That's a great example. And when you bet gradually as you suggested, if you have like 10 bets you're making, you realize one bet is going sideways. If you put more money there, the chances that you're going to lose more money because you don't make a worse bet better by putting more money into it. And one of the learnings I had about this betting is the first loss is the smallest. So the sooner you cut that, the better. So if you see something is really going sideways, just cut it and double down the winners.

Mark: 21:54

Great point, all right. Number six requires ditching plans when they become obsolete. That's interesting.

David: 22:02

Yeah, this one. It is inspired by Martin Daumann. One of the things he wrote in his book Driving Value with Sprint Goals is like plans the more confident we become, but when we hit reality, we quickly realize that our plan may not survive. What do we do in this case? If we are unempowered and we have received a plan from someone outside the team? We are probably going to continue to follow the plan, which is not a good idea because we have just realized that the plan is not sound anymore. A better approach would be hey, this is what we learned. It's not a good idea to start here. Should we just go back to the drawing board to decide what to go next? So going back to the example board and decide what to go next.

David: 23:02

So going back to the example of my product discovery cohort, I didn't have anything about how do you gain support from management, and I realized that this was top one people wanted. What should I do? Should I still create a course, even though evidence told me otherwise? In this case, I could make the decision. So I ditched my plan of creating the course the way I wanted and I pivoted to something a little bit different, and that was necessary. So if you keep following the plan as if it's final, then you are going to go down a cliff. Once you realize the plan, it is not going to help you drive your goal.

Mark: 23:40

I think that goes hand in hand with our previous point that you talked about taking risk gradually. So hopefully your plans aren't like you say, five-year plans that you consider set in stone so that when you get into year three you're like, well, I've already spent three years, I don't want to throw away those three years. We might as well just stick with it. That's the cost fallacy.

David: 24:03

That's the cost fallacy. It's very related to what happens in product. So if you have invested three months on something and you don't see any value and there's no chance you're going to see any value, you continue investing on that. That's going to fail. That's going to see any value. You continue investing in that. That's going to fail. That's going to fail. And one thing in relation to that in terms of the personal side is invest on yourself continuously. Make yourself better. You may have goals. Maybe in five years you want to become this or you want to become that, but that doesn't really matter. What matters is how are you becoming a better version of yourself? Because as you develop yourself, when you're ready, opportunities will present themselves to you.

Mark: 24:49

My advice to our listeners out there you really hit on a spot that I'm passionate about with that, david is that you absolutely cannot wait for your employer to educate you. You have to take matters into your own hands. I've shared this story one time before and I'll just repeat it very briefly. But in the days when I was a developer, I was a very solid Windows desktop developer, but I didn't have any skills on the website when the web was starting to emerge and no one would hire me as a web developer because I didn't have experience. But I had all this desktop development experience. I just had to do a volunteer-based engagement where I just contracted with a company to do some work so that I could get those skills. And yes, it did cost me time for my family, time at night and on the weekends to do that, but it did enable me to make a step in my career. And so I think about where my career probably would have ended as a developer at that point, because those skills were becoming obsolete. Yeah, so that's my story. That's a great story, all right? Well, moving on, this one's really interesting to me.

Mark: 26:08

David. Number seven takes care of current fires while ignoring potential ones.

David: 26:16

So that's something quite interesting, because potential ones. This is the what if? Question. So there's a problem staring at our face. We know the problem, everyone understands this problem is critical, and then someone in the team comes up with a solution. Then the other team members start what if this happened? What if that happens? What if this happened? This question is healthy up to a certain point, because if you keep on that, what is going to happen next is you start talking about all the problems you don't have and you may never even have them, and you don't talk about the problem that is staring at your face. So solve the problem you have and if some side effects happen, deal with them. You may think a little bit of what are potential side effects, but not to the point that block you from acting right now to solve what is standing in front of you.

Mark: 27:14

Richard Lawrence put together some patterns for splitting stories. One of the patterns that I love the most is what's the simplest implementation that we can do now? So when all those questions come up, when team is trying to discuss what they're trying to do and you hear what if? What about, how are we going to handle? Well, why couldn't we just split those off into separate work items and focus on just what's the most important thing now and some of those things that we're saying what if? Once we implement? The easiest version might not even materialize, you never know. But at least you're getting something started instead of trying to bake all the what ifs into one big, huge effort.

David: 27:58

Yeah, that's totally true, which reminds me of the story of my book, because I was pondering between self-publishing and searching for a publisher. Many people told me you go with a publisher, I will see you in two years, because they are going to nail you. Everything will be more complicated. And people told me they are very classic. You don't know what you're stepping into, but I said that's what they are saying and let's see what I can do. I'm not going to worry about it.

David: 28:32

The only thing I had toward that moment was to write a book that I was satisfied with and I said once I write this book, I decide what I'm going to do with it. So what turned out was I end up publishing with Pearson. But when I shared my manuscript with Pearson they look at the manuscript they said we like it, you put a lot of work into that. So the change we're going to do in terms of editing it is flow editing and, as English is not your native language, we will ensure it flows like native. But that's what we are going to do for you and we are going to exchange. So everything that people told me that would happen never happened. But that moment I had to keep my mind on the only thing that mattered, which was writing.

Mark: 29:18

Very good and you got value out of that up front as opposed to sticking with the what-ifs right.

David: 29:24

Yeah, exactly, who knows?

Mark: 29:25

you'll find a.

David: 29:27

Yeah, it does distract me, because the truth is it didn't matter if I would find a publisher or not, because I didn't have a book, so I had to find the book first.

Mark: 29:39

All right, david. Our last point, number eight, means being humble to accept that we might be the problem.

David: 29:48

That's a strong one and highly important. One moment in my life I was talking to a CEO of a company I worked and he told me one thing which was quite interesting. He said you need to pay attention when people state their opinions, because they may state as a generalization and you need to read between the lines. He said many people say Scrum doesn't work or they say that Agile isn't helpful. Then the CEO said what they are saying in the other lines would be Scrum doesn't work. The way I practiced Didn't work for me. Agile isn't valuable for me. So context matters and you need to put your contribution to that.

David: 30:42

I could say that in 2012, when I started working with Scrum, it didn't work, but it didn't work because I was a big problem on all of that. I was a product owner behaving as a waiter, so I was collecting requirements from business and loading product backlogs with requirements, and that's how I worked. Well, you can say, okay, you did a poor job. You're probably right, but I learned that was not how I was supposed to do it, and then I decided to do differently. Once I received the chance of going for an interview for Bookingcom for product manager I was still in Brazil. I failed the interview and I realized I failed on the third question with the technical person because I didn't even know what the person was talking about. So I said okay, so what would you like to hear? Help me understand.

David: 31:33

I understood I failed already, so I learned from that. And then I realized that the environment I was in wouldn't help me acquire those skills. So I decided that I had to step into cold waters and I wanted to go to a startup. So I went to a startup to explore different ways of working, because my knowledge was limiting me and my expertise so I was trying to explore different things was limiting me and my expertise, so I was trying to explore different things. When it comes to Agile or Scrum, many people interpret it differently, which doesn't mean right or wrong. It means that we always have a contribution to the end result and that is important to accept and say what could I learn from it and what could I do differently next time.

Mark: 32:17

So you mentioned your father. I'll mention my father. My father gave me some good advice and that was be honest, just don't be stupid. Honest, so you can be too honest in some situations. Maybe that's a topic for another episode, but I feel like if we really don't focus so much in Scrum and we're just trying to make sure that we're being agile, make sure that we're following the rules of Scrum, make sure that we're limiting our whip in Kanban, whatever it might be, those aren't the outcomes that the business is after. The business and our customers don't care about that. So make the most important thing the most important thing and you know that can go across lots of different disciplines across your personal life, but I will just leave it at that. Is that really? Look at it yourself and see what am I truly bringing to the table and don't just blame it on a framework or a methodology. It's awesome.

David: 33:27

Awesome. This reminds me of one presentation I watched from Tammy Rice and she said that there are only three questions you need to ever ask, and I was quite interested about it. And she said it is like where to where now, where next? So you look at whatever you're trying to do where do you wanna be? And then you step back and say where am I right now? And instead of creating a plan for everything you want to do, you say what is the next thing I want to do, just the next thing, and stop there, do it. And then you do it again and again, and again, and that helps you progress and reflect all the time when am I right now? And that's what matters. And then you decide what to do next.

Mark: 34:16

Fantastic. Well, we're coming up to the end of our time here, david. It's been a great talk. I've really enjoyed just having a conversation with you on this about what's missing to make Agile alive Our listeners. If they want to get in touch with you, what's the best way for them to do that?

David: 34:35

So they can join my newsletter I'm driving product teams or connect with me on LinkedIn, so that's the way you can reach out to me as well.

Mark: 35:00

Well, David, it's been a pleasure. My friend Really appreciate you coming out on the show and to our listeners, thank you for listening. We'll see everybody next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, Mark Metze.