Episode Description
This week, Dan Neumann is joined by Gerardo De La Fuente to talk about Agile and what it looks like to really embrace this Agile methods.
In this episode, Dan and Gerardo discuss those cases when Agile seems to be assumed but actually, it turns out to be just a shallow performance. Are people just showing up or joining with heart and soul in the Agile ways? Listen to this episode for a great synopsis of what truly is to embrace Agile.
Key Takeaways
Showing up vs Embracing Agile
Teams need to understand the purpose of Scrum, its values, and its pillars (transparency, inspection, and adaptation) in order to fully realize the benefits of this Agile method.
Scrum Masters find a valuable resource in collaborating and sharing situations and ideas.
Receiving feedback is crucial!
There needs to be psychological safety on the Team so people can be open to feedback.
In a Team, all members are peers collaborating with each other.
Collaboration also takes place with the Product Owner.
Admitting you don’t know is tough.
It takes courage to provide insides about aspects that are not understood or are being done incorrectly. Being open from the beginning saves a lot of trouble.
When there is a knowledge or skill gap, it is helpful to reach out to someone else in the organization for help.
Agile Teams commit to delivering value
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro [00:03]:
Welcome to agile coaches corner by agile thought the podcast for practitioners and leaders seeking advice to refine the way they work band pave the path to better outcomes. Now here’s your host coach band agile expert. Dan Neumann.
Dan Neumann [00:17]:
Welcome to this episode of the agile coach’s corner podcast. I’m your host Dan Neumann. And today I’m joined by colleague Herardo de Lata another one of the consultants here at agile thought. Herardo thanks for joining.
Gerardo De La Fuente [00:29]:
Thanks for inviting me again, Dan. Happy to be here.
Dan Neumann [00:33]:
Happy to have you. I haven’t realized quite how long it’s been since, uh, you are on, so I’ve, uh, I’ve made myself, if you will, a little bit of a backlog going through some of the episodes and going, oh, so, and so hasn’t been on since December, I need to kinda reach out because, you know, we get busy with our day to day lives, our client work, whatever else is going on in life. And, and sometimes it can be easy to, uh, not intentionally, but just kind of accidentally go, oh, I haven’t talked to that person in a really long time. So appreciate that you, uh, accepted the, the invite when I reached out to you our topic today, um, I’ve mentioned it in the past. I’m doing some work with the community theater here in south bend where I live and it got me thinking about observations that I’ve had about agile teams as well, where effectively, it looks a lot like agile theater where yeah. People are kind of doing the thing, but it, but it’s not reality. They’re, they’re not necessarily doing agile or being agile. They’re not actually using the scrum framework to its full effect. They’re just pantomiming or going through the motions. Um, have you ever seen something like that where it’s just, it sort of looks right, but it’s not quite there.
Gerardo De La Fuente [01:52]:
Well, you know, I like movies, so I think that the actors when they are getting into a character or a role, uh, what I see is that there has to be a certain preparation, right? It is not just reading a script and just saying it out loud, uh, with the, with the audience and all the production and all the people that, that are involved. The thing is that they need certain preparation first to know, uh, about that character, how it thinks, how the character thinks that it’s, uh, I relate it with the mindset. For example, if we want to link it to, to agile the mindset to understand what is agile the way the, the, uh, how the character performs. And this is related that what, which is the methodology that we follow, right? How also this character reacts emotionally, right? And also this is related to behavior and how it speaks and communicates. And also that is very important. The, the effective communication in agile and also the interactions with the surroundings that also is very important part of agile, the collaboration. So there are many things that I, that I see that when you are doing a role in your heart and soul, you have to consider all of these points,
Dan Neumann [03:23]:
A agreed, you know, you, you talk about kind of really embracing the role, the director that I’m working with right now, I’m, I’m doing some assistant stage managing thing. So it’s a behind the scenes role, but I get to then watch him interact with all the other cast members. And one of the activities that he tries to encourage people to do is, Hey, when you get there, do your warmups be ready, do the, do get ready for what’s going to happen in that rehearsal or be ready for what’s going to happen in that show. And it makes me think of, you know, sometimes scrum masters, just showing up for the retrospective. They’re not ready. They just hopped in from the last meeting, they’re just showed up for the retrospective. And they’re kinda like, Hey, what, how are we gonna do this retro today, or product owners who don’t have the backlog ready for sprint planning? They haven’t done their prep. They haven’t done their warmup. They’re just showing up because the calendar told them to. Um, and I think what you’re talking about is have we done the prep? Are we in the right mindset? Are we ready to engage, you know, heart and soul with what’s about to take place, you know, at work. And that’s a very different thing than just showing up for the meeting.
Gerardo De La Fuente [04:45]:
Yes, absolutely. Because it requires, uh, in understanding of, of each of the different roles talking about agile and what are the expectations, what are the change because, you know, entering to this, uh, new way of seeing things, a new methodology, uh, talking about scrum, for example, uh, it requires a lot of, uh, patient, but also, uh, be open to understand this, these, these new activities and these new accountabilities that each one of the roles are going to have. For example, um, if we start talking about the scrum master, it is very likely on the leadership and with the clients that they want to start seeing results immediately, right? That’s part of the market and the dynamic. But for example, when the team is, has a, a challenge has a, has an issue. Sometimes the scrum master may be tempted to provide solutions, right? And providing solutions doesn’t help in, in, in, in seen, in a long term for the teams that they can get to their own conclusions and their own, um, their own solutions.
Gerardo De La Fuente [06:08]:
Right? So one of the thing is that we need to, instead of, um, directing or providing easily these solutions, we have to be facilitating and listening. And also it, it relies a lot on making the correct questions when, when we start ma being, having these curious spirit as scrum master and start providing these, uh, out loud questions to the team, they start working on this critical, uh, thinking, right. They start to making analysis of the, of the question. They start to providing some hypothesis and then together, they start providing solutions because also that’s very important right here. We’re not talking just of individuals. It is a complete team, sorry. That has to get to those solutions.
Dan Neumann [07:01]:
Yeah. And I think as, as you, you talk through that, obviously the facilitation and the listening is, is important. Uh, there are types of challenges maybe where it is appropriate for a scrum master to give the direction, Hey, in our, um, if they know how to use one of the tools, Hey, here’s how you achieve that goal in the tool. We shouldn’t make everybody go reinvent, uh, how, some of the basic things happening. But once you get outta that simple problem domain into things that are complex, like delivering a software solution for a business problem, or for a customer’s problem, the scrum master’s not necessarily going to quote have the answer it it’s, and neither will the product owner, neither will in an individual developer, it’s about putting, creating an increment in a sprint that achieves a sprint goal towards a product goal. And then you get feedback in the sprint review and, and from actual users. And then you figure out if that was a good solution or not, and you iterate as appropriately. So yeah, definitely. Um, having the scrum master in this instance not come forward as the solution giver. Um, but one of the people who can foster good teamwork, um, amongst the team.
Gerardo De La Fuente [08:14]:
Yeah. I think that, um, maybe, uh, what we need to do is give them some time to try to get to that solution. And if we, we see that they’re not advancing, then just, we need to, uh, point it out that we’ll move or give a step back from our, uh, scrum master and coach stance to provide that, that, uh, experience or that kind of solutions that we have seen on, on past customers.
Dan Neumann [08:43]:
Mm-hmm <affirmative>. Yeah. And I think the way you phrased that is important here is something that I have seen be successful in the past. What do you think of it? Might it be helpful here? Might it not? Um, it got me thinking, uh, about something that we’ve covered in the theater, which is I in a scene. And if you will, sprint planning is kind of like a scene. The retrospective is like a scene understanding what your character’s purpose is there. Why you’re the scrum master? Why are you there? What, what are you hoping to achieve? You’re the product owner, same with the developer accountabilities, you’re there, what’s your objective. And then what are the hurdles that are in your way? And if everybody understands kind of the mindset and, and the why they’re there, what their objective is in that particular event and the hurdles that they may need to overcome. And then when you’ve achieved them, the scene’s over, we’ve done sprint planning, we all have, we have it collectively achieved our objective, the scene’s over. We don’t need to keep going. Same thing with the daily scrum and with the retrospective and the sprint review and, and for the sprint itself, although sprints are time box, you don’t end to sprint early because your sprint goal is achieved. So that’s a little bit, little bit different there.
Gerardo De La Fuente [10:03]:
Sure. And related to, to what you are saying, um, scrum master doesn’t have the leading role in the play, right. Is the team. So we are like the secondary role that we are supporting them when they are, when they have doubts regarding the process, or when we are seeing that, um, following the, the scrum, it is not, there is something that is, uh, not correct. Right. That’s and, and, you know, that’s something that I see that it’s part of, uh, scrum master. And I coach that is that self mastery that when you identify those anti parents or those mid behaviors, it is very important that they can shift in at the moment. Right. So that’s why it’s very important to be listening and observing because there are these specific moments in which there is something that it’s a MIS correct idea, or, or a concept about the, about the, uh, about the methodology that that’s where we need to, uh, step in and provide that clarity.
Gerardo De La Fuente [11:09]:
Right. And as a recommendation, right? Because also we cannot, uh, we cannot get in a role as a scrum Lord, right. That we are seeing it as a legalist view of the scrum that you’re saying, okay, you are not doing the scrum correctly, so you are wrong and that’s finger point. And no, we are, we, we are servant leaders and we help them to, to understand. So they, because also in the way of saying that things is the way how they’re going to perceive it and that’s that, that is going to be a, a positive, um, sort of, um, inception for them. So they can start embracing right. The, uh, the methodology and, and the mindset. Of course,
Dan Neumann [11:54]:
I I’m laughing because I am very confident at some point in my past, I have been the scrum Lord when I, uh, earlier on in my career, fi starting off, especially in the scrum master role back, you know, 2009, I’m pretty sure I was the scrum boss at one point or the scrum Lord. So hopefully I’ve come away since then, but, uh, yeah, I’m familiar with that, right. Oh, says, stand up. So we gotta stand up or, you know, whatever, whatever the arbitrary rule of the scrum guide was. Uh, and that makes me think, um, you know, knowing, knowing the words of the scrum guide and what it says about your accountability, whether you’re a developer, a product owner, or a scrum master, that’s, that’s part of it, but then also really understanding what, what’s the purpose of scrum. Why are we doing this in the first place?
Dan Neumann [12:44]:
What are we hoping to enable? What are the values that if we embrace them will make us more successful with the scrum framework, what are the pillars of, of transparency and inspection and adaptation? So it’s more than just knowing the words or being able to recite what the scrum guide says about something, but it’s really knowing what, what the purpose is and why those values help us, and then making bold choices in the moment about what you need to do to bring forward those values. Um, that’s another thing kind of related to, to theater. Okay. The scenes, the scenes started something unexpected. There’s a chance will happen. So now what do we do? And, and those values and the principles and, and the pillars help inform everybody and their accountability, making the right bold choices at the time to, to help achieve those objectives.
Gerardo De La Fuente [13:38]:
Uh, and maybe you can correct me, but approximately very different reading, a following the, the example of an actor, reading only the script, then reading the script and then talking with the director on the perception of those words, because many, you cannot assume that they are just technically what is saying there.
Dan Neumann [13:57]:
Oh, for sure. Yeah. No. And, and, um, yeah, I think we, we can see that pretty regularly. Um, especially with, I wanna say folks that are newer to the accountabilities, but sometimes folks who just haven’t had a good exposure to what, what good looks like. And so, um, you know, thinking of when you see a really great actor, you’re like, wow, that’s, they nailed the scene. They, they did it, they got the emotion, the intention that they delivered. Um, sometimes you look at a scrum team and you’re like, something’s missing, and I’m not sure what it is. Uh, and that’s where I like having external critique. Uh, so whether that’s times when I’ve been on a team of coaches and I maybe facilitate something and that person afterwards gives me the notes, Hey, this worked really well. You lost me here, et cetera. There have been times, um, typically when I’m doing conference talks where I’ll record the talk and I’ll watch myself, <laugh> be a little, oh my goodness, I need to stop moving. Right. Stand, still do deliver right there. There are things that happen that become a distraction. And this happens in scrum events. It happens with scrum master accountabilities product or where there are things that people are doing that are not helpful to advancing the scene or there a distraction. And so having that neutral third party provide that feedback is, uh, is super valuable. Sure. Have you ever had, have you had situations where you’ve been able to pair up with other, um, coaches, trainers, scrum, masters, give each other feedback as, as peers?
Gerardo De La Fuente [15:45]:
You know, I, I think that that’s something that is very valuable from our coaching practice. And I have thought that, uh, uh, we have the opportunity to collaborate altogether and to share situations ideas, and, and, and as for the point of view, and also, um, things that we have performed, we, or form we also share, uh, are, are open to, to share that feedback. And I think that’s awesome because feedback is it’s very, very important, um, to improve. And also as we see it on, on scrum, it’s important that we can have this constant feedback so we can be delivering exactly the value that is expected by our end users and our business
Narrator [16:31]:
Habit topic. You want us to tackle, send an email to podcast agile thought.com or tweet it with a hashtag agile thought podcast.
Dan Neumann [16:42]:
And it’s hard at times to get that feedback, drum, masters sometimes, or product owners or developers aren’t comfortable having an outsider join. Of course, setting some expectations, getting the team’s permission can be valuable. Hey, what if we had, you know, Herardo come in and join us for, uh, the sprint planning event. Let’s, you know, maybe they’ve got some ideas on how we could do this better and, and would want them to, um, show up, give their critique afterwards, you know, share feedback with the team or, uh, with certain people within the team. I think that can go a long ways.
Gerardo De La Fuente [17:18]:
Yeah. And, and also it’s very important to build that psychological safety space right on the team. So they can be that openness for feedback, because when you are starting with a new team, um, you need to start having those interactions and conversations to start mainly that bonding. Right. And, and having that confidence and that trust to be able to express, uh, situations. Because again, it is not finger pointing someone it’s saying the situation that is happening and how that situation can be mitigated.
Dan Neumann [17:53]:
Yeah. And sometimes it’s just, uh, sharing the observation. Here’s what I noticed and asking what maybe it meant to that person. Um, sometimes in coaching sessions, it’s obvious, Hey, here’s, here’s the thing maybe you could do differently. Or here’s a, here are a couple options you could try. And sometimes it’s as simple as sharing back. Here’s what I noticed. And it felt like, you know, it, it, what did, how did it feel to you or what do you make of it? And so drawing that person into the, um, the problem solving of, if it’s a problem it’s problem solving, and it may not be a problem, it might have just been something that looked different and you weren’t sure what to make of it.
Gerardo De La Fuente [18:36]:
For example, one, one of the roles on the product owner, um, many times, uh, this product owner came from a background of manager, right. And has this, uh, essence of being like the responsible of the team, that it is not the correct way of the role, right? Because it’s a, the teams are self organized. There’s no one leading it. We are, we are all peers and collaborate. So I think that also, um, in this kind of situation also is very important to have a close communication, right. To be able to provide the feedback like, Hey, uh, I know that you have this management experience and all, all the things that you have achieved, but right now we are all the same. Right. And, and your role is very important because one of the things that the pro owner gives value is understanding from the business side, what is the value that we’re going to deliver?
Gerardo De La Fuente [19:35]:
And this, we have to transmit it to the, to the developers, right. And it is many times, um, these managers, they sometimes they don’t have this, like, or, or they have a, a lot of technical, um, understanding and experience that, uh, from essence, they say, okay, this is the solution, okay. This is what we need. And this is the solution. And also that is, uh, uh, not the, the correct behavior, right? Because at the end, the developers are the ones that when the product owner provides, uh, and explains what is the value that is expected? These guys are the technical experts. They’re going to decide and define together what is the best solution to deliver it?
Dan Neumann [20:20]:
Yeah. First of all, I wanna start with, and I, and I agree, and I have also a couple times in the past one in particular comes to mind where I’ve had a product owner who was able to really do a great job of articulating what the business need is, but they also had a lot of technical expertise. And so they were able to quickly provide feedback on some of the hows, or sometimes they would come to the table with maybe what had in mind for a notion, but somehow they still managed to walk the line and, and keep a good balance of not dictating to the team, but they would say, Hey, here’s a business problem. And I was kind of thinking, you know, X, Y, or Z, uh, from an implementation standpoint. Um, and the scrum guy doesn’t forbid a product owner from, from commenting on the technical.
Dan Neumann [21:09]:
I know we typically, in a training, we say product owner focuses on the, what developers focus on the how, uh, but there have been those times where I’ve seen people be able to kind of walk in both sets of shoes and it’s been, it’s been interesting, you know, typically again, not what the, the standard training would be product owners, what developers are, how, um, but I think it, it, there’s some interesting dynamics with, with just the right person in the product owner role. Um, and I guess that’s where it gets into, if you understand the intention of the product owner accountabilities and the developer ones, and, and you’re still adhering to the values and the principles of the scrum framework, because they’re going to give you a good chance at having a good outcome. Um, I just think it’s interesting. I don’t know.
Gerardo De La Fuente [21:56]:
Yeah. It, it is like a T-shaped skill, right.
Dan Neumann [21:59]:
That’s a good example. Yeah. So T-shaped skills, you know, we talk about those with developers have the deep specialty and, and hopefully the ability to work outside that specialty at a reasonable level of competence. Um, and you can see that then with product owners who maybe have a technical background, scrum masters, who, um, maybe have technical experience or product ownership experience in their past. Um, but then it becomes a dance. Right? How do you, how do you all engage in your accountabilities without, um, muddying the waters too much?
Gerardo De La Fuente [22:32]:
Yeah, for example, on the scrum guide, it says that the probe owners are, uh, accountable for the backlog. Right. And then sometimes they can delegate on creating the stories for the developers, but, uh, many times, uh, it happens the other, the other side, they <laugh> completely give the responsibility of creating all the stories. Right. Um, mm-hmm, <affirmative> so it’s, it’s, it’s like, um, a collaboration work, right? Because at the end, the product owner has to create the stories because he’s the one that knows what the business is expecting for that, uh, spring to be achieved. But also the developers on their technical spec on the technical perspective, they can see things that the proton doesn’t. So that’s where they add the, these stories and the proton revises them. So they can be, um, aligned to the definition of ready. Correct. And that they’re aligned to. Right.
Dan Neumann [23:31]:
Yeah. So it’s that again, kind of, kind of a dancer that, that interaction between anybody can contribute backlog items, the product owner maintains the accountability. You don’t wanna see the product owner back away from the product backlog and say, Hey, you guys just take care of it. Um, they have to stay engaged. They have to remain accountable for ordering it to optimize value. Um, but yeah, hopefully more than just the product owner in their interacting and hopefully the product owner’s not stepping out of that important activity. Um, I, I guesses, uh, looking here one of the, I wanna touch on the developers a little bit. It’s easy for us to, I think, talk about scrum masters and product owners, uh, quite a bit, but agile theater with developers sometimes too. I, um, I’ve maybe seen that where, yeah, they’re, they’re on the team, but they’re not really leaning into the work. They’re, they’re sitting back with a, tell me what to do kind of mindset, or just give me the requirements and then, um, and then I’ll go to the build, but that challenge of stepping into that role of developer and, and participating in the problem solving in the first place,
Gerardo De La Fuente [24:43]:
You know, for me, from, from my perspective, it is the most challenging role because many developers, they come from this classical traditional way of working of, uh, they, they are things that the requirement is provided completely to them completely. And at the end, the design comes also from a, a design team. So they don’t have these decisions to take on, on that point. And right now here that, uh, other things change now, they are accountable for taking the decisions. And it, it takes a lot of, um, a lot of courage that it is one of our, um, strong values to provide our insights, to say, when the solution we are doing, when something that we’re doing is not correct, having that openness to say, I don’t understand from the beginning that that’s something that I have seen on, on, on different experiences, that there is a, uh, a fear, right, to say that I don’t know what we need to do, and that it will, um, you, you can save a lot of problems having that open. And since the beginning, right. Because, you know, having a, a, um, cross-functional team is having all the pieces that we need, all the expertises, we need to deliver the solution. So what happens if there is? So if there is, uh, um, a domain that no one in the team has, you have to, you have to have that openness and C humbleness to say, to speak and say, we, we are missing someone, somebody with these, uh, skill sets
Dan Neumann [26:22]:
Mm-hmm <affirmative>, and it’s okay to go reach out to somebody, if you have a knowledge gap or a skill gap, and there’s a somebody else in the organization who could maybe help accelerate through that learning curve. There’s no scrum rule that says, don’t go talk to somebody outside the team or engage them, even in the problem solving. Uh, I think it’s a, a common anti pattern where it’s like, okay, leave me. I have to go figure this out myself, as opposed to saying, well, boy, I’ve never done that before. I, I could, I could really use a help and, and then reaching out, uh, to that, that person, um, before that helps. So, so definitely, uh, some opportunities there for developers, the scrum term, and that includes analysts and quality or whomever is needed to deliver the solution, those scrum team of members.
Gerardo De La Fuente [27:18]:
Yeah. Also on, on the role then, um, the team, uh, commits to deliver value, right? So what happens when there are these incidents or situations, uh, personally that one of the individuals may have, and then maybe that expertise, uh, no one else knows it at a hundred percent at that at, at the same as that person, it’s important that the rest of the team can, uh, jump in. And even if there is a few or non, uh, understanding there, we have to see the ways that we can contribute, because at the end, it is not, uh, um, this guy, this, this developer is, uh, making this, or he is accountable for that. No, it’s all the team. So I, I think that, uh, when we talk about the T shape skills, it’s something that it is also necessary in that, right. To put in at the, the service of the team, even though if it is, for example, making code that you don’t have, uh, you don’t know exactly that specific code, but you can work with other code. So you can peer you can see it, uh, uh, a couple of eyes, uh, that they can also provide some insights about it.
Dan Neumann [28:35]:
For sure. Um, one of the phrases that I’ve heard and used in the past is being the nodding dummy. You don’t have to have the answer sometimes just being there to listen as somebody else talks through the problem, walks through the code. And in a lot of cases, they’ll go, oh yeah, I see it now. <laugh>. And, and so you don’t have to go there with the answer. Sometimes it’s just being there to enable somebody else to work through their thought process, uh, can be tremendously valuable. I wanna appreciate Herardo you taking some time to join on the podcast? I wanna ask for, uh, a closing thought that you have about this agile theater thing.
Gerardo De La Fuente [29:14]:
Well, um, what, what I can say is that, uh, for all the, um, agile teams working on the different projects, um, I want to recommend that, uh, uh, when you are, uh, knowing about the role, don’t just, uh, get, uh, stay with quad, read this always also to base with the scrum master or with the ideal coach that is working with you. So you can understand the why of all the responsibilities and accountability accountabilities of, of each of the roles, because it is very, very crucial to understand it and embrace it so we can deliver value guys. And, and it is very important to have this in mind. We are a team that is serving to, to other businesses, to other end users to provide a value, uh, for them. So that will be my call.
Dan Neumann [30:12]:
Perfect. Thank you very much for sharing that. Her Geraldo, I was curious at the end of our shows, we typically ask folks what’s on their continuous learning journey. And so we’re, at that time, I’d like to ask you that, what, what are you learning about these days?
Gerardo De La Fuente [30:25]:
Sure, sure. My friend, um, there is a book that, um, my manager and friend TK, uh, recommended me that it’s the leader who had no title from Robin Charma. So that’s, uh, a book I, uh, I’m going to start to read. And, uh, there, there is very good insights for, uh, being, uh, a leader and, and different capabilities that you have that you can develop to serve the team with, uh, quality.
Dan Neumann [30:52]:
That sounds really interesting. I also suspect that could be a great topic for future podcast with you. Um, and we’ll have to get you on before six more months goes by.
Gerardo De La Fuente [31:02]:
Yeah, sure. I will be very glad to, to join you again.
Dan Neumann [31:06]:
Thanks for your time today. Really appreciate it.
Gerardo De La Fuente [31:08]:
Thank you, Dan
Outro [31:11]:
Has been the agile coach corner podcast brought to you by agile thought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of agile thought. Get the show notes and other helpful tips for this episode and other episodes@agilethought.com slash podcast.
Want to Learn More or Get in Touch?
Share These Tweets!
“Teams need to understand the purpose of Scrum, its values, and its pillars in order to fully embrace the Agile methodology.“ — Gerardo De La Fuente
“Teams are self-organized, we are all peers collaborating.“ — Gerardo De La Fuente
“It takes courage to provide insides about aspects that are not understood or are being done incorrectly.“ — Gerardo De La Fuente
