DocDur Agile is an open office where Agile Practitioners can ask any question they encounter in practice situations and would like to have some advice or a different perspective. Think of it as seeing a regular doctor have a physical check-up.
If you have questions or requests that you would like the Doc to have a check on, please drop a message on LinkedIn or join the Mastering Agility Discord community!
Sander Dur (host)
Scrum Master, Agile Coach, trainer, and podcast host for ‘Mastering Agility”
Sander Dur is a Professional Scrum Trainer at Scrum.org, podcast host of Mastering Agility, Professional Scrum Master and Lead Agile Consultant, and trainer at Xebia. Besides this, he’s an avid writer for predominantly Serious Scrum on Medium.com. Sander has a major passion for the human side in complex domains. Ensuring a high level of psychological safety, therefore, is a critical part of his work. Organizations in complex domains can only survive when innovating. Innovation can only take place with the right balance between low social friction and high intellectual friction. While most organizations now understand how to apply Agile frameworks, they struggle with the delivery of value. Psychological safety is the next step in this evolution and Sander has a huge drive to help organizations reach that step.
He gained experience as a Scrum Master, Agile Coach, and Leadership consultant in many different top-tier organizations, including Nike and ASML.
Sander is enthusiastic, open-minded, and ambitious. He finds interpersonal relationships and intrinsic motivations very important in team dynamics. Besides his work, Sander loves to spend time with his family, enjoys sports and eating healthy, barbecuing, riding his motorcycle, and traveling.
Let’s connect! Sander is always up for new connections and discussions!
Masteringagility.org
https://xebia.com/academy/nl/trainers/sander-dur
https://sander-dur.medium.com/
Additional resources:
Discord community: https://discord.gg/6YJamBJxUV
SUMMARY KEYWORDS
product, product backlog, product owner, sprint, part, backlog, scrum team, developers, team, work, understand, feel, client, ux, focus, scrum master, question, user, skills, situation
SPEAKERS
Sander Dur, Carmen Andujar
Sander Dur 00:02
Hello everyone and welcome back to a new episode of this podcast. My name is Sunday deer and I’m your host. Today’s episode will start something new in these 15 to 20 minute episodes, I will open up my doctor’s office and in this doctor’s office in this open office, agile practitioners can ask me any type of question they encounter in practice and would like to have some advice on whether you work as a product owner, scrum master developer, agile leader, you name it. Everyone is welcome and Dr. Agile office. Get it? Some they’re their doctor. No. All right. I’ll see myself out later. Anyway. If you’d like to get some free advice or other perspectives on your questions and your practice situations, drop me a message on LinkedIn, or join the mastering agility discord community, you’ll find the link in the show notes. First patient please. Welcome to the doctor’s office. How can I help you today?
Carmen Andujar 01:06
Good morning. Thank you for having me. Well, I’ve been not feeling great lately, I’ve been experiencing some mild symptoms that I want to have checked on. So I kind of start by telling you about one of them that I’ve been experiencing in my current organization, so let me tell you about it. So right now, as part of the Scrum teams, we have UX and UI designers. However, they don’t participate in the sprint nearly as much as the developers or the testers. And I sometimes end up feeling like they are wasting their time being in the scrum team meetings. But at the same time, I do see how the close collaboration is beneficial for the product. So is there a solution to the situation? Should the designers be stakeholders instead of part of the Scrum teams? Is that a cure for this? Is this grave doctor?
Sander Dur 02:26
Well, as the consultant answer goes, it depends. Like what are the skills that you need on board to actually create a done increment consistently each sprint, if those UI people have skills that you would need on a continuous basis to involve during the sprint throughout each sprint? Then I would say yes, involve them as much as possible and have them on the team. Also, I wouldn’t be curious on why they don’t want to participate for the rest of the sprint, maybe other than the UI and UX work, maybe they have skills that could support the work of the others as well. Also don’t focus too much on we are developers. We are coders. We are testers we are UX or UI. The scrum guide specifically mentioned as developers are people who work great and stuff for, for the product, whether it’s UX or anything else, it doesn’t matter. You’re a developer. I would also question whether you’re able to work as a team if everyone sticks to their individual silos. So that might be a really good question to discuss during your sprint retrospective as well. Have you ever done that before?
Carmen Andujar 03:35
Yes, and within exploring a solutions proposals for this issue, we are trying to have collaborative sessions for the user flow implementation for the managing of its cases for the design for some improvements, from the feedback we get during the sprint, but even so, we are still a struggle to to to have the designers as involved in the sprint, because they are also designing the next features ahead. They are also working in, in other parts of the company, maybe for the marketing, because this is not a very big company. So the designers have to deal with several other things at the same time. And that is the main problem that for the first week of the sprint, they collaborate. And they have a flow like user flow sessions and design sessions with the developers. They contribute to the spring goal, but then for the more coding, like the coding a focused part of the sprint. I don’t think they collaborate that much. That is why I see them potentially as external stakeholders.
Sander Dur 05:00
They could be a consultant as being a subject matter expert. But I think there’s a really important thing in your answer as well as that they’re being basically being requested or needed by other parts of the organization linked to context switching, they are focusing on other stuff than the product that you’re working on. So they continuously have to switch and it has its impact on the motivation of people as well. So this might be something to address not just with the scrum team, but with the wider organization, what are we trying to do here? Do we want people to really focus to it? Can we get that focus? And if yes, how should we do that? How should our Scrum teams look like? Does that help?
Carmen Andujar 05:40
Definitely, awesome. Yes. And we are building cross functionality in the team’s A and for example, we are trying to run away from the testbed versus developer, a, by merging the skills testers becoming the becoming coders, let’s say the other way around. So like, I can see the willingness from the organization and from the team members to to blur those lines.
Sander Dur 06:13
Just for the sake of very purely sticking to theory, cross functional just means that you as a team have all the skills on board to deliver that done increment, not necessarily that people are able to pick up each other’s work. But as a team, you have all the skills on board to create a done incorrect.
Carmen Andujar 06:33
Definitely, yeah, definitely. But at the same time, they want to, like personally, a, all of them want to develop, let’s say full stack skills. So I work on that as well.
Sander Dur 06:47
Awesome. Hopefully, that’s gonna help you a little bit. I’m really curious what’s gonna come out of the conversation. If this doesn’t cure the issue, feel free to come back.
Carmen Andujar 07:00
I think a focus conversation will be an interesting, an interesting one to have. Because we are struggling in general with with focus. And it’s no wonder because the company is growing is changing. The product is changing, too. And we are struggling to keep the focus on this can be a good conversation to have, both for the designers and for the rest of the company as well.
Sander Dur 07:27
Yeah, absolutely. It does. detrimental things for the quality that you can deliver. Exactly. Yes, some more symptoms that you want to discuss.
Carmen Andujar 07:41
Yes, so those that one was like a mild symptom, let’s say is not causing me much pain. But this following one is a little bit trickier. So here it goes. A our product backlog right now is divided into multiple ones. We have our technical depth backlog, our back backlog, and even our natural language processing backlog because that is something that we do. And that later Later, a backlog is managed by another product owner. So the main product owner is focused on the main product backlog, the one that contains features picked by teams every sprint. And the reason behind this is that the main pro toner doesn’t have any technical background and is unable to understand tasks that talk about natural language processing or technical staff in general. As you can imagine, the situation has led to bugs and technical debt not being paid attention to as well as having a separate team for infrastructure matters. And they manage their own backlog as well. Yes, I have proposed unifying the backlogs, but I’m not sure this is the right approach. How can I handle this situation?
Sander Dur 09:06
unifying the backlog into a single one would be the best option to start off with. That’s the solution. Now, why? Because from beginning from conception till the point that the product goes out of commission, your scrum team is accountable for any part of the work, whether that’s new features, technical depth, bugs, any other word database, I don’t care, all the work that needs to be performed on the product is in that single source of truth, the product backlog. This has a lot to do with focus relating to the previous question as well. Yes, you’ll be splitting into focus and you won’t see that much pressure also. Transparency is very much being limited if you have multiple backlogs. That’s part one. It also feels like you have multiple captains on your ship. They have two product owners responsible for specific parts. And not just the one product owner who is accountable for the entire thing. To some extent, I understand the argument that he doesn’t have the the oldest skills on board to understand the technical part of it, I wouldn’t be able to do that instantly as well. But by putting another product owner next to it is persevering that behavior. And to give you an extreme example of what that can do, my childhood childhood hero, Dr. Phil always refer to this as for instance, parents of a drug addicted kid, now this drug addicted kid comes to their to its parents, saying, Hey, can you give me $50, so I can buy new clothes. And even though the parents know that 50 bucks won’t get spent on clothes, but in drugs, they still give them the money, give her the money. And why because else you don’t know when we don’t know what she’s going to do for whether she’s going to steal or do even worse things to get 50 bucks, so we will just give her the 50 bucks. So with no, it’s, it’s done in a safe way. This is enabling behavior. If you enable your product owner to have a separate product or next to it, you’ll just be enabling that product owner to dive away from his accountabilities. And you’ll be persevering with this kind of behavior. It’s also very much a unicorn mentality to think that you can add that there is going to be one point where you’re going to possess all the knowledge as a product owner, to know everything and anything about the entire product, whether that’s technical details, how you’re going to sell it, sell it, how you’re going to market, it is just not doable. You want to create a team around you that knows this stuff. I mean, me as a Scrum Master, I don’t know the technical part either. But as to people wouldn’t do know. And this way you’re being fed the information that should know, at least to make the right judgment calls to create that order in the backlog and to maximize value coming out of the product. What do you think about that?
Carmen Andujar 12:11
I mean, I agree me as a scrum master. I also don’t understand all of the technicalities. But I do ask a lot. What does this imply in the product? How this impact the impact the product, and I always try to, to change the titles of the tasks, so that the bro tone around every one in the company would be able to understand the purpose of the task. And then, in the description, I add the technicalities that were previously in the title. Yeah, I agree with this. But I wasn’t realized that that situation was bad. And the product owner had to make an effort to understand and to unify the product backlog. Yep. So that was the part that I didn’t see, I didn’t want to push him that way, or I didn’t want to give him more work, let’s say, you know, because I see him struggling already, because he has a lot on his plate. And I, for me didn’t feel right to tell him, maybe you should pay attention to these other things as well. But now I would consider it.
Sander Dur 13:34
Remember this rule of thumb, one product, one product owner, one product backlog. And one definition of Done. So there’s just one list and one accountability that handles that?
Carmen Andujar 13:49
Well, this, this is not a like I wasn’t planning on asking this. But now that you mentioned the rule of thumb, one product, one product backlog. And it’s true that the natural language processing, for example, is part of the product is not a different product is the same product, we just need to do some natural language processing for it. But we do have an internal application for data entry, user management and all of that. Good that be a different product
Sander Dur 14:24
doesn’t contribute on the same thing and the same features on the same goal that you’re trying to achieve with the functionalities
Carmen Andujar 14:34
it does I mean it does contribute to because it’s the as I said is the data entry point for the internal users or for the for the workers of the company to to enter the necessary data to later display. Well analyze and display in the in the platform and to manage the clients, the users that benefit from our platform. So it is Part of the proof but at the same time, it’s never seen by clients is used by our workers, but by our people by the customer success by the
Sander Dur 15:13
back end platforms they never usually never been seen. Or the part that you as developers create your scrum team creates is not being seen by the client, either. It’s still there. And it’s the same for the issues that you mentioned here. Even though they don’t see it, it’s still part of your product. Right. So it gives it gives you something to think about.
Carmen Andujar 15:40
Yes, yes, we are treating it like that. But at some times, I had my doubts, should we have different Plutonia? Or not? Or our team focused on that or not? So how do you
Sander Dur 15:55
feel? How do you think focus would be impacted if you create separate backlogs or separate product owners for each and individual parts?
Carmen Andujar 16:07
I think it would be detrimental for the motivation of the team that works for that product. Because in the end is not the same to be releasing cool stuff to clients that you get praise for. Okay. And we celebrate, maybe we should celebrate everything. But it’s true that we celebrate the client features more than the internal features. And I think it would be detrimental for the team that has to focus on that because they would lose sight of the client facing platform. And they will then feel as celebrated as other themes in terms of focus. I don’t necessarily see a problem with the focus, but I do see a problem with transparency and with motivation, in that case,
Sander Dur 17:10
as its impact definitely. So what would your solution be?
Carmen Andujar 17:21
I think they like these internal application has different stakeholders from the client facing obligation because it is the the internal users that will tell us what they need to do that what to in the end satisfy the the customers. But I see how we can prioritize them equally prioritize their work in that area. Along the work in the client facing because in the end, they need each other. Those two, exactly. They are part of the same thing. I agree. One is the engine and the other is the car. But it is in the same.
Sander Dur 18:12
Beautiful. This answer your question?
Carmen Andujar 18:16
Yeah. Awesome. Yeah, definitely think you.
Sander Dur 18:20
And the big thank you to today’s patient and having the courage to step up in this office. I hope this relieves some of the symptoms now if you feel like having some advice, or you would like to get some different perspectives, send me a message on LinkedIn or join the mastering agility discord community. You’ll find the link in the show notes. I hope to welcome you guys all back in the next episode of this podcast series. Have an amazing day.