Transcription

• Intro/Outro

  Welcome to Mastering Agility. If you want to listen to authentic conversations with the most inspiring guests, find like-minded people in the Mastering Agility Discord community, or both online and face-to-face events, this is the platform for you. Grab a drink, sit back, and join professional scrum trainers, Sander Doerr, Jim Sammons, and their guests in an all-new episode.

• Jim Sammons

  Well... Welcome back, everybody. Happy fall, at least here in the United States. We're recording this on October 8th, and this is going to be the last warm week of the year, it seems. So I'm joined today by Rich and Ryan, and we'll do introductions in just a little bit. But what we're going to be bringing to you today is Ryan did what many of us try to do, is he's taking his homework and he's... crowdsourcing and rich and i are going to kind of play like his own little llm like his own little gen ai but instead of typing he's going to speak to us which one of you is chat gpt5 and which of you is three rich v so maybe it's roman numerals maybe maybe so We're all PSTs. And for the audience who isn't familiar with everybody's voice yet. So we've got Ryan Brooke coming at us from England. PST out of the what part of the country are you in again, Ryan?

• Ryan Brook

  In Gloucester, about two hours south of Manchester, two hours northeast of London, because that's pretty much the only two places most people know in the UK.

• Jim Sammons

  So if you hear that accent, that would be Ryan. And he will be playing kind of the role of MC. And if you hear one of the Midwestern US accents, that would be either me or...

• Rich Visotcky

  Shpistatsky. Yeah, coming out of Wisconsin. And I think I've picked up enough of it. So thank you, Jim. That's good to know.

• Jim Sammons

  Yes, you have definitely picked up enough of the accent. And I was just back home in the... uh south wisconsin north central illinois area for the last week and i already found my voice slipping and sliding into old patterns i'm in ohio so i'm also still here in the midwest in the u.s i'm a you know six seven hours away from rich and but uh we sound a little bit more southern than others and we can i can draw if i need to if i go down to cincinnati and hang out with those family or northern kentucky my voice will start to lengthen a little and Yeah, that's me. I mean,

• Ryan Brook

  I can do some further. And if you want me to.

• Rich Visotcky

  Oh, yeah. Yeah, definitely. I think for all of us,

• Ryan Brook

  we would prefer not to.

• Jim Sammons

  Fox already is on the call, everyone. Here's your sign. So Ryan's got a list of questions that fall into four kind of broad topics. And Ryan, tell us where these came from so that the audience knows why we're answering these.

• Ryan Brook

  Absolutely. So about three or four weeks ago, like many of us who work alongside Scrum.org have the opportunity to do to attend something called an Ask a PST session. It's something that we kind of sign up for and lots and lots of people register for. So for this session, we had 400 people register and about 160 turn up, which was pretty cool. And as you might expect throughout sessions like that, where people get the opportunity to ask questions, the topic for this one was agile leadership. there are simply too many to answer in the hour. Often we kind of just leave them. But I thought, hey, as Rich nicely said before this recording said, I'd find two chumps to help me out. And the two chumps sat in front of me right now are Rich and Jim. And hopefully the chumps can give you some answers. So that's why we're here, Jim.

• Jim Sammons

  Awesome. Love it. All right. Well, without further ado, let's just jump right into it. Let's see where this goes.

• Ryan Brook

  All right, folks, what I'm going to do is I'm going to be playing the role of the questioner. So for those of you who've never listened to an Ask a PST session before, you tend not to get a huge amount of context. I'm going to try and put some context into where some of these questions came from and kind of prod Rich and Jim. They are our experts here. So the very first question, gents, that I didn't answer was from a guy called Robbie. And it said, how would you advise a Scrum Master to handle joining a new organization? So what would they do in that kind of first week, first two weeks, first month to be both successful but also respectful?

• Rich Visotcky

  I'm going to start with the first thing they shouldn't do, which is come around and be like, that's not Scrum, right? Just run around like you're the expert. You get to go and ruin everything because you have no one will care. What's more important is, I think, starting to learn about the people. on there, starting to just observe who's connected to who, who's working with who, observe what are they working on, and just start to actually build up a little bit of, I think Jim has called it a couple times, political capital, right? To start to understand more of what people are actually trying to accomplish. Because as a scrum master, you're here to help them be more effective in whatever it is that they're doing through the use of scrum Right. So just if you're not if you don't understand what it is that they're trying to do, you could easily step in and actually ruin some of the good stuff that's happening there. So, yes, we'll get to using Scrum and maybe they already are. But if you don't know who who it is that you are actually engaging with and what levers that you're trying to pull to help them get there, it might all be for waste.

• Jim Sammons

  Yeah. Just to add on to that, I would say and I'm going to answer this. whether the title of this person is scrum master or not, like if they're somebody who's there to help other people, teams deliver good work. I think you're always being tested in your early weeks. I mean, and really all the time, but especially in your early weeks. So you have to be careful a little bit. A few things that I suggest new people like this be careful about is prescribing a solution before you've diagnosed a problem. One good way to start that is by meeting people, going for walks, sitting down for coffee, eating lunch, asking open-ended questions, maybe things like, tell me about what's working well here, or tell me about what is working less well, or what are the current problems. That's going to be very useful to hear multiple people's answers to those questions. in individual and group settings to start to tell you what to lean in on. Like, you know, I think that the difficulty in doing that is doing it in a genuine and trust-inspiring way where it doesn't feel like you're taking a bunch of one-on-one inputs and you're weighing them against each other and trying to figure out who's telling you what you want to hear, who's telling you their truth versus the truth and all that good stuff. Another technique that I always suggest to people is to have an opinion on certain things, because one of the things people are going to be doing is normally you're either backfilling somebody who's left the organization, you're backfilling somebody who's been promoted. So hopefully during the interview or the hiring process, you know why you're being added. Maybe you're the first one ever to hold this role. And that's great. That's a great position to come into in a way. Um, but trying to figure out why were other people successful in this role? Why were other people not successful in this role? And I have so many memories of just like walking through the halls of a company with somebody and then saying, Hey, what do you think about X? X could be a tool, an idea, a process or whatever. And they're looking for me to say, Hey, does this guy know what he's taught? What I'm talking about? Does, do I agree with him? Um, Is his response going to be way out in left field, which is going to maybe make me concerned or whatever? So I try and have an opinion on certain things, but I also that doesn't mean I'm going to do anything about it. Like it could be as simple as just like a nod or, yeah, I'm familiar with that or I've seen this before, so that people can say, oh, okay. He's not going to come into day two and tell us we're doing this all wrong and we need to do it. different way or whatever. So I think it's kind of about being a little calm and inspiring confidence for the future.

• Ryan Brook

  Do you guys ever see a worry though, in those kind of first few weeks? Because we often hear this adage of go in and listen and observe for the first two weeks. Do you ever see the risk of almost a level of inaction in those first two weeks? Like, do you need to, you say sort of having an opinion, but do you need to take a position on some things?

• Jim Sammons

  identify a small change just to prove that you have that that social proof you know what you're doing do you guys see that i think so uh i i know i don't think so i know so that and i always cringe on the inside maybe sometimes on the outside when somebody's like oh for my first month all i'm gonna do is listen or observe no that is not a good answer in my opinion but i i think it's about actively being a part of the team from day one but also knowing that none of us would like anybody to come into our house, our world, our life, and start throwing their opinions out, making a bunch of statements, changing things, or derailing conversations. While we're already working, like more than likely, the team's already working. They're already successful in some areas. Maybe you're there to help in other areas. But yeah, I am not a fan of that passive, that huge passive period at the beginning. Rich, how about you?

• Rich Visotcky

  I will also say that I see it. I don't agree with it, but I see it. I think to add to what Jim's saying. You're here to be helpful. And if all you're doing observing and that's not actually helping anybody, you're not really doing your job. But to to try to prove something, you got the job. You were hired. Right. I think you've already you've already at least proved that you should be here. And now you have to go and actually do the work. And and part of that work is understanding what's going on. And I think that actually is kind of true for. whether you're a scrum master or a product owner or a developer or a CEO, to come in and just muck with things to say, look, I'm here, I'm doing something. Regardless of the role, that's a good opportunity for disaster. So better to really understand why things are going the way that they're going, what objectives people are trying to achieve, and look at the system of how it is or is not getting there. So that when you do decide to take that action, right, that action is focused and purposeful, right? So I think more, it's not just observe, it's that the default stance is observe, right? And even for any Scrum Master, the default stance is observe to understand and then act with purpose.

• Jim Sammons

  One, one... kind of pair of statements that I just wanted to get out there before we move on to the next question is one of the piece of advice I gave someone recently is I use the phrase the sage on the stage right to kind of describe like this keynote speaker type like I'm this expert with a microphone and the audience is listening with rapt attention like that is a bad stance to be in almost any time as a scrum master or delivery manager but affect essential uh really bad early The opposite end of that spectrum is what I call being a rat in a cage, right? You don't want to week one be like, yep, I'm just here to suffer along with the rest of you. I'm on the team and I'm just receiving whatever our master kind of puts through the bar. I think it's about finding that balance between hopefully you are there because you're smart and you have something to add and you have some skills that the team can use. But it's kind of that's the dance between. not getting in the quicksand with the team, not just putting yourself in that cage immediately, but also not saying that you're some big person with a microphone and everybody should just keep their mouth shut and listen and wrap attention.

• Ryan Brook

  Brilliant. Well, thank you, gents, for those contributions. We're going to be here forever with the level of detail, but hey, I can't complain. Right. The next question then on the topic of management expectations and alignment. What, this was from an anonymous attendee. So what is the best way to coach leadership that still expect fixed scope and deadlines whilst claiming that they are actually agile? So I guess quite a common one that we come across. Business thinks they're agile, but actually, hey, when is this going to be done? No, I need it to be fixed. How do you deal and coach that leadership team?

• Jim Sammons

  Well, for me, fixed deadlines is just a fact of life. I don't see fixed deadlines as... um, anti-agile. I see it as complexity. I feel, I see it as a constraint. Um, I would, between those two things, uh, if given a choice, I would of course challenge scope, be like, you know, if you're trying to fix, I got to have all this stuff done by this date. Um, okay. I can, I can maybe do that, but it may cost you, you know, that's the third leg of the iron triangle there. Uh, but I would. understand most likely what's behind the date and if it's a valid deadline uh or if it's uh if there's some sort of squishiness there but then i would kind of go after the scope and start trying to figure out like do you really need all this you sure yeah

• Rich Visotcky

  i also i always get curious of the proof side of things right um like how will you know that what we built was the right thing and like jim said is this really a fixed date What is the driving factor behind that? And start to ask more about the business reasons for it. the customer actions and behavioral changes we're looking for, the things that start to get to help us be more agile on understanding, well, maybe this isn't the right solution. And I also often try to remind a manager in that kind of situation, it's like, no one here wants to miss this stuff. Like, no one wants to purposefully extend out the scope or just drag their feet to get here. They want to work hard. They're actually, they're probably, they might actually be getting overworked. We'll talk about that maybe later. But the more core aspect is they want to do the right work. We don't know if this is possible in this period of time, but we do know there's something that we're trying to get out of this. If you can help us understand that, it'll inspire everybody to do their best to get as close as possible. So tell me about those things.

• Jim Sammons

  Yeah, I think. I would say like 77% of the time when I'm told this is the deadline for this date or for this body of work, I've had success in sitting down with both parties, the delivering group and the requesting group and saying, what is the actual date? What is the minimum needed to satisfy that real deadline? And then what's left? almost always 77% of the time, just to throw a, an incorrect internet statistic at you. There is a, well, we have to have X and Y by December 5th, but we really want all this other stuff too. Okay, cool. That's fine. So X and Y team is December 5th reasonable. Yeah. That's totally reasonable for those pieces. Okay. What about the other duties as assigned? Yeah, we can get those into some future. iterations or time boxes or whatever. And look, it doesn't always go that easy, but this is the benefit also of being new. If we add this to the last one now, now, if this is, you know, these are two different questions, but if a third party, a pivot person like myself, who's not in either camp can facilitate that conversation, it is almost always worked out well for me to do that.

• Ryan Brook

  I think something that I'm hearing here is that there's kind of different types of fixed deadlines. There's the valid fixed deadline because of a legal framework or a drop dead date. But there's also a deadline for creation of control. I see in some managers I work with, it needs to be done by December the 5th. Well, why? And the honest answer is kind of because I said so. And that kind of like Rich was saying, people being overworked, working with your teams to try and... figure out what and why they're asking the question, why does the deadline matter, is a really important point.

• Jim Sammons

  Something Rich and I have connected on over the last few months is an appreciation for the architect Frank Lloyd Wright. And I've just been watching a short miniseries on HBO here in the US called The Last Right about just an average couple, a mother, daughter who were building Frank Lloyd Wright's last home. And they acted as general contractors. And there was a very real, it must be done, the concrete must be done by this date because it needs to cure and we can't do this next step until that is done. Now, that is a very valid thing in the world of work as well, where the reason somebody gives a group of people a date is because there's a cascading effect to where that work's going to go and how other people are going to consume it. A lot of times people hold that knowledge inside. They don't tell people, hey, the reason I'm driving you to this date is because there's this huge other organism that you don't see. And we are step 37 of this 62 step process. Tell people that. Show them that. And you will almost always find that their acceptance of deadline driven work will go up a little. It may not go to 100%, but they'll have some empathy. The other thing you can do there. Is it gives people like the three of us and others the ability to come to be creative then to say, well, how can I decouple this? How can I say, well, OK, what if we do the concrete over in this part of the business or this part of the building so that the work can continue over there? But we don't have to do this. Or maybe it makes sense to say we're going to not do that at all so that that other work can continue in this. So there's so many options you have when you can explain. the deadline but so many times people just say the deadline is december 5th and they don't want to answer the question about why it's december 5th or maybe they can't answer why. And they don't want to take the time to go understand why that's the deadline they were given.

• Ryan Brook

  So going back to the question, then the final answer really is how do you coach leadership? It comes back to transparency and understanding why and where that fixed deadline came from. All right. Thank you, Jens. All right. I've got a horrible one for you now, or at least it's horrible in mind. And I'm glad that you two are answering it and not me. So we have three projects that depend on each other. Two work using the Scrum framework and one is Waterfall. How can we create and align a long-term project plan?

• Rich Visotcky

  You don't. I'm going to start there. I'm sorry, what, Rich? So I view this kind of problem as you've got three different projects. I'm going to say that you actually work at three different companies. Two are Agile. One is not. They all have different dependencies on each other. You are but a stakeholder for, you know, the group that you depend on. And so you can tell them everything you want about how it would make your product better, what you need to integrate with, what else you could go do. And the fact that if you don't get it, it's going to delay these other things. The concrete's not poured. We can't do this next piece, whatever that might be, right? And your desire to go and move that ahead changes nothing. When it's done, it's done. And when it's done is when you can use it. So I say you don't because I've I saw this in action. I worked with a group that was doing like contact centers like thank you for calling so and so, you know, press one to talk to a real human. Press any other number to continue this, you know, long and automatic session, that kind of thing. Right. They were going from, you know, hardware. based solutions to a more server-driven kind of thing, you know, voice commands versus pushing the buttons, all that kind of stuff, right? This group wanted to work in a more agile way. So they did, they were doing Scrum for a while. I think they, we also brought in elements of Kanban before we had PSK and stuff. We were trying to figure that out. I think they eventually transitioned some away from Scrum as the complexity of the work changed. But what they did was they were building these things up on what would become the VOIP solution for the whole company, which was getting rolled out at that time in a waterfall effort. So this group was at their own servers or testing things out. They were talking to real customers. What are the types of things that we needed to do? They started getting contact centers like ready to go. and their customers, different departments said. Yeah, this is great. Like I want this now. Right. And it's done. So they should be able to get it now. Right. But the whole backbone that they were going to build this on had at least another five months to go. And it's probably going to be more like another nine until they finished out this deployment. So it's like, well, we have dependency. We can't give you anything. They actually worked around that. They built up a whole other network around them to start connecting different groups. for their contact centers, right? Different departments got spun up at VOIP at different times versus like, we're going to roll this whole thing out at one time. So they actually, they removed some of their dependencies in some areas. Other parts, they just said, we have to wait. Like we can do all this work and try to create this value. But if the linchpin is this waterfall thing that's going to take a long time, we, one, don't know if it's actually going to work until that.

• Ryan Brook

  piece is in place we have to wait or two we can't give it to you until that piece is is in place we have to wait so um when the when it's done it's done and that's the unfortunate reality so i think i'm hearing what you're saying is it it's not necessarily you don't it's you can but you accept the cost of delay from working in that way and

• Rich Visotcky

  anything that you can do for creating a long-term plan could easily be waste.

• Ryan Brook

  Yeah. Yeah. I often refer to the phrase of, you know, people ask you for a deadline. You know, it's a lie. They know it's a lie, but we all pretend it's the truth. And that's how a lot of business works at the moment. Jim, sorry, I cut you off.

• Jim Sammons

  I'll try and be brief because I just want to add to what Rich said. I'm going to take a slightly different stance on this. So I'm just going to stipulate from my answer that the two Scrum teams have a Scrum Master and the Waterfall project has a Project Manager. For first step, no matter what, those three people need to talk and have empathy for each other, which means the waterfall PM needs to understand what words like sprint and refinement and iteration and all that and backlog mean. And the two scrum masters need to have some empathy for a Gantt chart view and critical path items and work breakdown structure and all that. Doesn't mean either side has to adopt the other's mentality or mindset, but they need to have some common vocabulary. And then ideally, the three of them would talk regularly on a regular basis to say, this is what team A is doing in. sprint 17 this is what team b is doing in sprint 17 this is how does that line up with the the critical path items or the more plan-driven approach and then those three people need to be able to argue disagree find common ground and have a a plan to deal with the inevitable you know when two immovable objects seem to meet and that's where if they can't do that because of time personality, location, whatever, that's where they may need to enlist the help of a third party to come in and facilitate that discussion. And there's hundreds of different descriptions or names given to that concept. But I think this is just a reality. Like I've never been in an organization. Actually, it's not true. I've only been in one or two organizations where everybody works the same way. And I think it starts with transparency, empathy.

• Ryan Brook

  in understanding that you all are playing a pivotal part in something and not working together is probably not a long-term strategy for any anyone involved yeah i get the sense that question came from a problem to solve rather than a problem to work within and assist with you know not all problems can be solved even

• Rich Visotcky

  if there's not a waterfall team like there's just two scrum teams that are working on things and and have dependencies on each other That kind of conversation is still important, right? Because just because both teams are more agile and they have the ability to shift direction, well, that doesn't mean that the dependency that they have is satisfied yet, right? So you're still, it's like, if you get to a point where you need to use something, you either have to wait because somebody else is building it, or you have to figure out how to get around that problem. That is a new realm of complexity here, a new thing that you're... your team has to go and solve for if you want to create some new increment of value.

• Jim Sammons

  One technique that I, it's not a technique, just one thing that I am proud of doing in the past is I had a group of people, it was not three, it was more like five, very similar to this question. And I told, I remember telling them, everyone around us thinks that this is going to go terribly. and that you people are going to argue and fight and backstab and do all that. Can we agree that if we can do this well, we can drastically change the way that all of us, the waterfall folks, the agile folks, the scrum folks, the Kanban folks, are perceived in the wider organization? And it was really good because everybody kind of willingly accepted a second burden. Their primary burden was delivering the thing they were all asked to do. The secondary burden was showing people that we are capable people who can act as adults and disagree and work differently and still get shit done.

• Ryan Brook

  I think you've nailed it there. It reminded me of, I don't know if you guys have ever seen it, that very famous lecture by Mary and Tom Popendiak about the building of the American building and how fast you can do waterfall and how agile you can make waterfall. I won't explain it all now, but if people want to go and find it, I'd recommend it. All right, moving on. So a question from our tools and techniques category, question four of 12. What metrics are useful to share with stakeholders when they want to see progress in agile delivery, i.e. not traditional milestone tracking? What are those good agile metrics that prove we're making progress?

• Rich Visotcky

  I'm guessing you don't have the right context, but a question that comes up for me is, is progress on what? Progress on the outcomes for our customers or progress on agile delivery? Yeah, right. But I mean, like the other part was progress in like the adaptations of our processes and in our organization. Because like I can see, we might create lots and lots of value, but internally, we're actually kind of stagnant, right? Or there's an ability to say we are shifting and changing things constantly. And our team's capabilities are improving. And yet still, we have not figured out how to solve a customer's problem yet. Those are the kinds of things I tend to look into as one of those sides, right? Are we looking for changes in customer behavior that lead to changes in business impacts or social impacts or whatever that we're looking for?

• Intro/Outro

  Jim and I are also, well, actually, Ryan, you too, right? I forget, we're all sensor responding trainers here too. But when we talk with Jeff and Josh, and they're talking about impacts and outcomes and like the mattress case, right? You want more revenue, people have to buy mattresses, like that's their action. But if a person lays down on a mattress, then we're likely to go buy it, right? So you're looking for those kinds of behavioral changes in the market to say, is actual delivery working, right? So are we actually... responding to what customers are doing? Are we seeing that behavioral shift? Are we creating actual value for them? That's part of getting delivery working. I think then there's the output activity side. Like, are we actually getting increments built at least once a sprint? Are we getting multiple done per sprint? Does that, that indicates that we're also looking at our work and we're splitting it up a little bit more. Are we achieving our sprint goals, right? Are the sprinkles, you know, hard thing to measure is are they challenging? And I don't know if there's a measure to that, but you said a really easy goal and it's and then, oh, I hit it 100 percent of the time. But, you know, so like, how are we doing there? Do we go from we're never hitting it to we start actually, you know, getting these things accomplished a few times? How often do we see, you know, bugs come back in? What's the quality of status look like? How often are we releasing? Questions like that from a delivery aspect of the activities that could drive the behavioral impacts that I mentioned earlier are what I would start looking at.

• Jim Sammons

  It sounds a lot like evidence-based management, what you're talking about there, Rich.

• Intro/Outro

  It would help, I think.

• Ryan Brook

  A common meme that I throw into chats when this topic comes up with the people that will not take a meme as an insult is the dude from The Big Lebowski. With like, yeah, that's just like your opinion, man. So I think one of the biggest problems in the industry is people make this concept of feedback and what do people think about the work we're doing way too difficult. It is not that hard, people, to ask other people who are consuming your work, what do you think of it? And then when they tell you what they think of it to say, can I record this and post the transcript? Can I take that? soundbite from your email or your team's message? And can I put that on a slide or in a sprint review or send that to so-and-so? That's not that hard.

• Jim Sammons

  You're giving away the trade secrets, Jim. Don't give too many away.

• Ryan Brook

  Yeah, I know. Those are the sad secrets of what we do that is not rocket science. When somebody wants to measure agile delivery, two things inevitably come up. flow-based metrics and value-based metrics. So what I tend to do is start with the simplest thing we can do for those two things and value and value-based metrics is difficult for everybody. Even the most advanced innovative companies I've worked with defining and quantifying value is difficult. So it normally starts with, can we see things moving? Like, can we see the proverbial traffic moving on the A24? Yes. Is it the right traffic? Is it high value? I don't know yet. Then it's as quickly as possible saying, here is your flow of value and here is your flow of no value. And that's also not difficult. And we're probably all old enough to remember in school, like the overhead projectors where you had like clear plastic that would overlay something. And I had a lot of teachers that would stack those things to tell a more compelling story. So if a listener just imagines in their mind's eye, one of those big 3M flip charts, and you've got a flow metric on it, cycle time, throughput, you know, whatever. Then put another clear plastic thing down that shows the different type of work. Maybe you separate your work into three categories. You've got value creating work. You've got support work. or operational BAU, whatever you want to call it. And then you've got like discovery or experimentation based work. Okay. So what's your definition there? Then you put the next clear plastic sheet down that shows quality metrics. Okay. Like what's our help desk doing? What's our ticket load doing? What's our data dog or test automation looking like? You could, I've literally done what I'm describing, which is to create a physical visual that shows the same group of work for the same product and same people with, from different perspectives. And that's really what we need to do. Because when somebody says, show me how agile delivery is going, I'm going to start by asking the question, Richard, like, well, what's that mean? But I think we often make this way too hard. And evidence-based management is great. I mean, it tells us about a lot of these different things we should measure and all that. But you can get started in an afternoon with Sharpies and a wall or Sharpies and a flip chart.

• Jim Sammons

  Yeah. I think it sounds a lot like a product wall and an obeyer. And there's lots of complex ways of solving this problem when fundamentally it's, what does value look like to you? And what are those things that we need to track? Yeah. But evidence-based management being a good place to start. FYI, anybody who's never heard of an overhead projector, you're far too young and you're not allowed to listen to the rest of this podcast. Thankfully, by the time I was teaching, those things were gone and we were onto smart boards.

• Intro/Outro

  I'm sure they're going to start showing up in like, you know, antique stores soon and they're going to become the new hotness. You know, people are going to like overhead project what record that they're listening to.

• Jim Sammons

  And our kids will go, what's that daddy? Yeah. Vintage.

• Ryan Brook

  Everything old just becomes vintage and retro at some point.

• Jim Sammons

  One day we're going to be called vintage, gentlemen. Right. Next question. So how can a scrum master influence a culture where failure is punished? So experimentation feels unsafe. I really, when I saw this one pop up in the chat, I really felt for the person asking this question. It's anonymous, so I can't reach out to them directly. But it felt like a very emotive question. So how can a scrum master influence a culture where failure is punished?

• Intro/Outro

  Oh, that's hard, right? Because when failure is punished, experimentation is hard, right? And finding safe spaces for experimentation is perhaps the interesting one for me. There's a part of my mind that also goes like, is failure punished asymmetrically? ah this team gets punished all the time but failure over here isn't right and if i could see that if i observe that making that transparent is um i think something that i do to influence you know culture because perhaps it is it's very localized uh culture and and broadly we actually don't really believe that there's just bad behavior happening in one area um so that that's one part but kind of you know i think um i i want to like give all those people a hug and just be like like it's it's not your right yeah like like you failed it's okay i feel most days too right i'm something right just like i i made the coffee wrong i you know i forgot to shave i did something right there's there's little failures all the time that don't really matter um and and those are and it's okay so like i just want to give you a hug for that um but finding those and then afterwards like what are the little experiments that are are more okay right like it's like okay what can't we fail at and like this okay we're gonna really just like i don't know almost i guess get as hands off as we can but what's something that we can start to try it's like if we um you know and if we're to fail and i don't i don't like to even say fail if we were to learn that this is wrong It at least prevents us from doing something. And is there something like that that we can start getting into to say, what's something we want to go learn that we don't know? And it could prevent us from actually doing the wrong thing and failing to achieve an outcome or failing to spend our money correctly. Or I don't know what the failure is. But if we can go, if there's a we're not sure kind of thing, then there's an experiment to run. And it's really not learning it or it's really not failing. It's just learning. This wasn't the thing. So now we have new data. We can go do something else with that. So that's my thought is one, try to learn a little bit more about is it localized in culture? And then two, can I create more of a culture of learning to lead to a culture of experimentation and hopefully drift away from a culture of blame for failure?

• Ryan Brook

  Yeah, it hasn't been that long, but it's been a while since I've found myself in a company and realized this. My first reaction back then was always to run, was to immediately look for the door. If I find myself in a not safe to fail, blame heavy, unsafe culture. But the sad reality is many people would be grateful to have a job today, even in that culture. So running isn't a viable strategy. And I, and I often didn't run. I often leaned in and took the bull by the horns. So some of the things that I do and have done in the past is understanding what fail means at that company and in that team. Like if you get the sense or you're told, you know, it's not safe to fail here, what does that mean? And I'll give you a real example. When I worked in petroleum, they really struggled globally with the agile mindset of, you know, failing fast. They're like, failure's not an option here. Okay. Tell me more about that. When we fail, we kill people. When we fail, we kill the earth slowly. When we fail, it costs. Oh, okay. Got it. But like this little project we're doing in SAP, what about, oh, who gives a shit about that? Okay. So like, okay. What about if we failed to deliver this, the goal of the next two weeks? Oh, whatever. Like we measure times in years, not sprints. Okay, cool. So setting some context, reframing kind of what. fail means and what even localized failure means. Another thing that I do is I identify what leadership calls the, or what I call the glass balls. A glass ball is a ball that if you drop it, it breaks. Versus what's a rubber ball. Like, yeah, it's going to suck. And you might get a nasty email or you might get a little check mark against your name in somebody's mind. But if you drop that ball, it's not the end of the world. There's no negative outcome, but what are the glass balls? And then that knowledge itself is valuable, but then also saying, okay, what do I need to do to increase the quality, decrease the likelihood of failure while knowing I can't control or prevent or guarantee no fails on a glass ball? Two other quick things. One is when you inevitably make a mistake or fail or your team does, raise your hand and say, hey, we let you down. We screwed up. We did this because a lot of people in a lot of companies over the years, they build up this mindset of it's not OK to fail because they think and some of them have actually told me this. Like if I tell people that 100 percent perfect work is the goal and I know they're going to give me 85, but that's good. If I tell them 85 is acceptable, they're going to give me 65. So when you screw up, even in a small way. Raise your hand and own it. And what you may find is that changes the dynamic with people where they're like, wow, I don't have to demand things and punish things almost proactively. They're going to come to me and say, hey, just so you know, here's how you're going to find out tomorrow we let you down. Okay. And then the last one is quickly fix your shit. Okay. Like there's so many little things that, yeah, we screw up. You're right. I didn't send that. You're right. I did have an incorrect distribution list for that. You're right. We did not cover this part of our product with a test or with automation. We're going to get right on that. Here's number ticket number one oh three four two two where you can follow that work along. We'll talk to you in a few weeks and we'll give you an outcome of how that work. Like all of those are techniques that I think I've used.

• Jim Sammons

  I think that level of accountability is something not just in professional work, but also in your private life as well, in marriage, right? Hey, I screwed up, right? It sounded a lot about what you were just saying, Jim, about the kind of risk-based governance. We often see failure as this binary failure, but sometimes they're not glass balls. Sometimes they might not be rubber. They might be wood, to extend the metaphor. In different contexts, failure is more serious than others. I once read a book by a guy called Rory Sutherland, and he did this four-box model of learning versus outcome. And he basically said, if you take the logical choice and it works out, cool, that was just good work. You make the logical choice and you failed, you're unlucky. You make the illogical choice, okay, and it worked out, you were lucky. If you take the illogical choice and you fail, you're fired. We value logical-based decision-making. But when it comes to culture influence and failure, actually... we should be praising the illogical failure choices because those are the ones that are likely to drive us forward.

• Ryan Brook

  I think all of us love Rory. And for a listener, if you're not familiar, just do a Google, you'll find a lot of his work. And yesterday, Ryan, I saw a post online from a very high level person in a tech company. And they said, hey, I was asked on Tuesday about the new API around... e-commerce based ai stuff is this going to do this and he said i gave an answer and i sounded really smart and a lot of people agreed with me and all that and then wednesday sora 2 was released and i realized i was answering the wrong question with outdated information 24 hours ago. So this concept of logical and illogical, yeah, but shit is changing under our feet so much that today's logical solution could be totally obsolete by tomorrow. And that person raising their hand in one of the most public ways possible with, and they had tens of thousands of followers to say, I sounded smart, but I was 100% wrong within 24 hours. Like That is kind of what I'm saying is like that. I think that is going to inspire people to trust that person a little bit more and to go to them again and to say, wow, they were willing to say I was wrong. I was logically correct at the time, but I am wrong already tomorrow.

• Jim Sammons

  Yeah. Labeling. I know we've spoken about Chris Fox in the past, Jim. But yeah, he talks about that in his FBI books.

• Intro/Outro

  I mean, if you're doing scrum. Here's another perspective on the whole logical piece that comes into it too. From a failure perspective, if you don't meet the definition of done, you still use what you've worked on anyway with your customers, you've failed. Right. That that's wrong. And so there's a lot of failure. Like what can't we fail on? And again, when you were talking about like, we can't kill people, like that's it. That'd be a great one to see on a definition of done, but you know, just those kinds of things. If you, if you want to say like, These are the can't- do's, putting those in a definition of done helps you with that, right? And then it's like a logical, illogical kind of choice of, we met the definition of done. We've, you know, accounted for all this quality aspects, all the things that could be considered failure, you know, in a lot of people's minds. We had, we have a guess, we built something, we put it out there. It was a logical choice. It felt like the right thing. And everyone was happy with it, including the person who might punish us if we got it wrong. Like it was their decision to... to go in this way and we did it and look and it looks great and three or four days later the market reaction is not all that great is it a failure or like some you know competitors do something and now suddenly it's worthless uh is it a failure no it was it was absolutely the right choice at the time and now we pivot right now we go do something else uh and we learn from that right so and we all do it together whoops like that's not going to let us continue here i'm to shift.

• Jim Sammons

  I think based on what you've just said there, Rich, it dovetails quite nicely into the next question, which is, and it kind of comes back to one of the ones we had earlier, but what is an effective way to measure whether agility is genuinely improving outcomes or just improving output? So how can we measure agility as improving outcomes rather than just increasing agility? I guess this comes down to measuring behavior rather than volume of stuff, maybe?

• Intro/Outro

  Yeah, a lot of measuring customer behavior. and I think being able to see how quickly you can shift that behavior is what really starts to on agility. Because you can shift that behavior over a very long period of time with like a big release, you know, and waterfall, I guess, too. You just, people will do whatever they want without any other change from you. The thing that we can start to do by being more agile is actually nudge that behavior in a direction we want it to go might start to create and put things out in front of people give them give them a new feature give them a new opportunity create a new product create a whatever it is that that allows people to say actually I want to choose your thing rather than choosing a competitor's thing or rather than choosing to do something in this convoluted way and so that our ability to activate that mechanism, those nudges a little bit quicker, starts to drive more of that behavior. And if we see the behavior moving in the right directions, I think that's the biggest correlation to our agility is helping with that. If the behavior is not moving, it doesn't necessarily mean that the agility aspect isn't working, but maybe that we haven't found the right thing yet. And thus, again, keep changing until we're finding that right shift.

• Ryan Brook

  This is one that's near and dear to my heart because I... and currently and often have led agile programs, right? Where leadership is always saying, well, what are the three dials I need to look at to know that this is working? And I'm not going to say it's impossible, but it's very, very hard to give them one, two, three dials to say, if these three things are all green, you can be confident agility is working. I think there are, I think it comes back to, well, what is it we're attempting to do? And there is value in just making. workflow. Okay. So like, if you think, come back to my, my busy motorway analogy, if the biggest problem that agility is trying to solve is getting things moving and getting things across the finish line and, and unclogging the flow of work. Great. Look at measure flow first. It's going to immediately lead to, yeah, but what about the quality or what about the value? Great. We're also tracking that here. like, let's agree and let's talk about how we're going to talk about and describe quality and value. And those are two of the most difficult words, if not the most difficult words to define in our industry, quality and value. So you have to start somewhere. And the problem is, the problem with those two words is both of them are in the eye of the beholder. What I find to be a quality office chair may not be what Ryan and Rich define as a quality office chair. They might need different features, different things than me. Neither of us is wrong. We just have a different perspective. But when we apply that concept to an organization, it's important that we either try to find some way of quantifying that that satisfies differing opinions, or we just say, you know what, we're going to adopt Rich's opinion of quality of an office chair. And we're going to use that as the standard to say, here's where we were, here's what we're now producing. Do we agree that's better quality? Right? I do think that one of the biggest problems with agile efforts in the world is an over focus on compliance. Getting people to do the same thing or getting people to do any one thing perfectly or compliant to a process is not indicative of any type of way of working effort. It's. literally just a measure of compliance. And often the most truly agile and innovative and experimentation and scientific method-based organizations I work with are not compliant at all. In fact, they're full of people who run from this concept of compliance, let alone use it as a bar of success.

• Jim Sammons

  Brilliant. I think when it comes to, like you say, I just love your metaphors and the way you explain things. But yeah, when it comes to quality and value, you need the word quality to define the word value sometimes. And so, you know, bringing those into organizations as two new words, we all know what they mean, but how do we apply them to our domain? You know, there's not a blog usually written by Atlassian. There's not a blog written that actually explains it. All right, brilliant, gents. Let me give you hopefully a bit of a funny, well, a funny one. How do I tell my senior management that Gantt charts are stupid?

• Ryan Brook

  Ask them to pick one that has ever been right.

• Jim Sammons

  Okay.

• Intro/Outro

  My favorite time watching somebody use a Gantt chart to tell his management that Gantt charts were stupid was a product owner that laid out a two-year plan across all these different aspects of business work and things that had to get done for their product. And at the bottom, there was an extra line that said confidence. And it was broken up by quarter. And the first quarter, the confidence was medium. The second quarter was low. And then every quarter after that, it was none. And it says, if you have no confidence in this plan, then why did you create it? Because you made me do it. And it's all going to be wrong. But I just want you to show that this is worthless. And I'm... going to learn and change from here.

• Jim Sammons

  I was just, I sometimes see, I'm actually not as an MC now, the value in the Gantt chart is not the thing you create, it's the conversations you have through doing it. You know, like most things, it's not the output that matters, it's the chat and the transparency alongside.

• Ryan Brook

  That actually is a great segue to what I was going to say is a statement that I've said probably hundreds of times over the last 14 years is. Gantt charts are a warm blanket that people wrap themselves around to feel comfortable and safe. It's kind of like a thunder shirt or a weighted blanket. But what I often do is I ask a leader who values Gantt charts, what is it you like about this view? Almost without fail, the two most common answers I get are, it shows me where we've been and where we're going and the critical dates. And it makes me feel that people are in control. That word in control is so common. And I said, okay, what if we can show you those two things? If we can make you. feel that we know what's already happened, what's about to happen, and when our key dates are, and that we are in control of what we're doing, does it have to be a Gantt chart? No, I don't care. Sometimes they say, no, I don't care. Sometimes they say, well, just stick it on the Gantt chart. But I think, Ryan, to your point, the year was 2016. I was in a big, big healthcare company here in the US. And when you got off the elevators on the floor that about 30-some teams worked on. There is a 18 to 24 foot Gantt chart, about six feet tall, that was owned by the PMO and updated regularly and all that. And I mean, every single person walked by it a minimum of, I don't know, two to four times a day. Many people walk by it a hundred times a day. And we did have conversations in front of it. And often those conversations were like, all right, this thing we're talking about, let's go find it on this massive work breakdown structure. Oh, it's right over here. What's it say? 10% confidence won't have, and it's a year and a half from now. Okay, then why are we talking about it? They were doing Moscow prioritization, low confidence, probably shouldn't even build it for a year and a half. Why are we talking about it today?

• Jim Sammons

  Good point.

• Ryan Brook

  Okay. And then there was 100 other conversations like that to the point where The Gantt chart became just that big warm blanket that everybody felt good about having at the elevators, but really was not telling any useful story about what was actually going on by 250 people on that floor.

• Jim Sammons

  I love when you mentioned Moscow. I just call it Moss now because everything is must or should. I don't really, nothing's really could or won't in my experience.

• Intro/Outro

  What is the least important piece of information on a Gantt chart?

• Ryan Brook

  I don't know, Rick. What is it? I feel like there's...

• Intro/Outro

  it meets the dates right um because jim i'm gonna go back to your concrete for example right or the concrete build on the found you know the the structure and then you know all this other stuff like you're looking at is there a dependency like this this other thing can't start until this is done like that's and they're they're right next to each other that's great if they overlap that tells me i i have options i i you know this work isn't dependent i can do lots of different things And it's going to be done when it's done, right? If the concrete took longer to cure because it was really wet, then the concrete took longer to cure because it's really wet. The date that we put on the chart doesn't matter. I can't start that next piece until it happens. So the dates are happy wishes, I guess. But to me, they're the least important thing on there. The conversation around why does this work connect or not connect is far more.

• Jim Sammons

  I must admit, I thought it was a joke. which is the reason why I was struggling to figure the punchline.

• Intro/Outro

  To a lot of people, that's a joke, I think. They're like, no, there's absolutely no way. Or it's an inflammatory statement. No,

• Jim Sammons

  I think you're right. If a team can't plan two weeks, why the hell do you think a roadmap or a Gantt chart can be two years out? And I mean that with the greatest respect. I can't plan two weeks of my own life, let alone in a complex product environment. So, yeah. All right, guys, we've got four questions left. Let's get through these. So I've got one from Dennis here in our tools and techniques category. So what is a good tool for user story mapping that gives me a clear overview?

• Intro/Outro

  Good tool for user story mapping, like beyond these things?

• Jim Sammons

  Yeah, well, that's kind of where I was going with it, Rich, but I don't get to answer here. How would you guys do it? How would you do user story mapping in the age of, I don't know, I guess in-person and remote? What would you use? Would you use Jira, ADO? Would you use stickies? Would you use a Sharpie and a flip chart? What works for you?

• Ryan Brook

  I use Mural or Miro, doesn't matter. But I use Mural integrated with whatever the work management system is or both. Jira and Azure DevOps. If Dennis is asking, what's the tool? My answer would be Mural or a physical wall. and digital or real post-it notes. Okay. But his question about an overview, you know, without context, I don't know if he means an overview of how to run a user story mapping workshop, or if he means the output of said workshop.

• Jim Sammons

  And I think he means an output.

• Ryan Brook

  Okay. So to me, the output is if I'm using a digital tool like Mural, I have that output because I can look at that thing that we created and dragged under this and sliced out of here. and I can say, oh, it's this. thing over in the tool that the team works in. Absent that, if you're not integrating those tools that way,

• Intro/Outro

  You just need to see user story mapping as an activity that then shows up on your backlog and as the team. And that could be as simple as just the parent-child relationship between the resultant work of that workshop.

• Jim Sammons

  I think there's a lot of good things as well that happen in a user story mapping session that no matter what you're doing, you can't. Yet the adaptation of the tool, like if Jira or ADO are your sources of truth for the information and you move things around on a board or you find a new category of work that all this fits under when you're doing user story mapping, it's not automatically moving things in a product backlog for you. It's not tagging the work with that new category. Like there's probably still work to do in wherever that work came from. And so I think it's important to recognize. that kind of aspect um because like everyone also uses that different ways like some people will tag their items with the category some will create a parent item for that like the the epic that goes over it there there's just because they're tools and different people use tools in different ways there's there's not going to be a solution so you'll always have a little bit more work that kind of goes along with that so the the other thing i i like jim love the fact that if you're doing this in a digital fashion. One, you can get access to your teams no matter where they are. You can all look at the board. You can get back to the board easily. And that linkage between a virtual wall, like Miro or Miro, I always mix up that pronunciation, and your actual work management system is direct. They allow that kind of integration. It's really easy to get in and Look at that. But I will say, I mean. This goes back 14 years, did a session like that using sticky notes. But I had a very clever person on our scrum team who laid out sticky notes on a sheet of paper and created a template for printing directly onto sticky notes. Right. Fed them in and got them printed. And so each one had like the ID of the item and in the bottom, a little QR code. that you could scan the QR code and bring up the item inside of your actual work item management system. So we did the physical activity and it had digital linkage, right? You could take a picture. And if you really wanted to zoom in on those things, take the QR code, process it and pull up the item. So this was a long time ago in terms of tooling and you could, it could still work. I won't say that that was an easy setup. you know, for anyone how he was doing that and place on all the stickies down. There's maybe better sheets that you can use for something like that these days. But yeah, like just know there's always going to be a little bit more work and do the thing that helps create the right engagement and then go do the actual work for last month.

• Intro/Outro

  I taught the product backlog management skills class and I really like this class. But the number one takeaway every time I've ever taught it is the hamburger method, hamburger technique. And if you're not familiar with it and you're a listener, just Google it. It's fairly well known out there in some circles, but it's sort of user story mapping. You can use it in conjunction with, you can use it in place of, or whatever. I like to use it in conjunction with user story mapping. But the biggest problem with either of these two techniques is the same, which is how do we have a great workshop where we break something down, either in a map or a hamburger, and then correlate it to... what the team does and the number one thing in my experience that makes that difficult is teams that have vast backlogs and i regularly am telling scrum masters why the hell is it hard for you to answer this question wow you know like how could i find it look at my backlog it's 940 okay well that's the problem so there is no tool or no effort i'm going to expend to try and help them find a needle in a haystack i'm going to say we need to get rid of the haystack So when do you have a small backlog? If you have a scrum master who doesn't know, at least generally, where the things are and how yesterday or last week's workshop showed up in the tool that the team's working in, that's a problem. That's the problem to solve. Not what brand of markers to buy or whether you should buy Mural or Mural. Those are the wrong questions, in my opinion.

• Jim Sammons

  As a scrum master, is something you help your product owner solve too?

• Intro/Outro

  Absolutely. Yes. you you're right you're right yeah i should not put that burden on this on the scrum master shoulders um All too often, we're the ones bringing these techniques like user story mapping or the hamburger method to the teams, but it's a good call out, Rich, for sure.

• Ryan Brook

  Brilliant, guys. We've got lots there. I think what I'm hearing is the tools are useful, but actually it's the how you do it and the transparency you can create amongst the team. And in that way, the tool doesn't matter so much, right? There's lots of cool ways you can do it. You can just do it with a whiteboard and a pen, but it's the understanding and how it shows up in your planning tool of choice. Thank you, guys. Right. Three to go. How do you balance giving teams autonomy while ensuring organizational alignment on strategic goals? So you kind of want everyone to be moving towards the same thing, but you also want teams to have autonomy.

• Jim Sammons

  Two things that come into my mind. One, do they know the organizational strategic goals? More often than not, they don't. at least or I see a huge disconnect between what teams are doing and maybe their goals and they can maybe parrot back out whatever the CEO said recently on a call to the investors if they watch such a thing. So being able to know what those things are is important and and what are what are the behavioral changes what are the measures that we're really looking for there and less of what are the activities and outputs. that we're doing to to get there right because if it's true strategy um and and um i'm gonna go back to the russian martin thing right where do we play how do we win right you're focusing on the segment the area the part that you're working on and the things that that you're going to do to differentiate yourself right so that's great and now how do we do that in our day-to-day work is important um then autonomy to me comes a little bit more on i can give you more autonomy one if If you. know the direction that we need to go right so i actually know that objective that we're working towards i understand that strategy um and then two do i have to have the right boundaries in place right and that i'm not overly constrained right so that um you know i wouldn't have any autonomy because there's too many things this is what you need to do this if it needs to be done by this how you're going to go do it there's no autonomy there right if i wanted but if i want to give you autonomy, I'd say, here's the direction I needed to work in. We have a limited budget of $200,000. Our investors are going to have to see something moving on this within the next three months before they give us any more money. We can't break any laws. I don't want to invest a lot in tooling, but if you find the right thing, let's talk. And here's the market that you can go play in. Have fun. So they understand, here are the constraints around it that allow me to operate autonomously in this set of bounds that help me focus on going to work on that objective. And that's what I would say for allowing and creating that autonomy in the face of organization change.

• Ryan Brook

  Do you tend to find that, I think the question says balancing teams with autonomy and organizational alignment. Do you think it's a balance or do you think it's more of a correlation that actually as they understand the strategic goals, that autonomy almost grows with it? Or is it an either or?

• Jim Sammons

  The lack of autonomy usually comes from a lack of trust, in my opinion, and perhaps because those constraints and that purpose weren't really well defined. So, you know, we say, oh, we're going to. let our teams go be more autonomous and they just go to do it and they don't know what to do and they take no actions well i tried autonomy it didn't work yeah maybe they were afraid maybe they like the last time you did this to them they did something and they got their hands slapped because we didn't set the right boundaries right um so i i agree i think that there is a definite connection uh between those uh those things there that like to uh that the balance exists that I'm happy to give you more autonomy. When I see that you are aligned with the right goals and you are staying within the appropriate balance or you tell me the balance need to shift a little bit more to allow us to achieve this objective because we're constrained too much or I don't know where to play. Like, I do not know how to take action here and I need some guidance. So autonomy grows in that kind of space.

• Intro/Outro

  Just in brief, I would say I think autonomy, balancing autonomy with strategic goals can start with. making sure that the goals are written in a way that it doesn't constrain teams into how the goals should be achieved. OK, and then the question from from the sense and respond folks in the OKRs would be, OK, so you have this measure that's going to achieve. key result. Can we allow teams to hit that key result in many different ways, but with some boundaries, right? Like if you say, hey, you must lose 10 pounds. And I'm like, cool, I'm going to cut off my left arm from the elbow down. Well, that's not a healthy strategic way to achieve that goal. So I think there's a very small amount of common sense and governance that needs to happen. But all too often I see goals that were key results that will basically say you're going to implement this feature, finish this project, do this thing. And it's a very output focused key result, which constrains people, which is the opposite of autonomy. And I don't know of an easy way to do that other than what I just said, which is like, can we revisit what our goals are? But it does start with identifying them. like, uh, To Rich's point, can you even tell me what our strategic goals are? And also admitting that it's okay that that team over there isn't working towards the same goal that this other team over there is. It is highly unlikely that everybody is contributing to every goal or OKR, whatever word you want to use, in an organization.

• Ryan Brook

  I think I once read somewhere that giving someone autonomy is fundamentally a disempowering thing. I think it was from Turn the Ship Around by David Marquet. You should take...

• Intro/Outro

  autonomy and take empowerment rather than being given it yes i wonder how that plays in here yes that's i think that his quote was around empowerment but it's the same thing right like if you need to give or even verbalize that you are giving someone empowerment it means you you've taken it from them in the past or

• Jim Sammons

  that you don't even think they have it today which is often the case just like jim some of you were mentioning before around like the boundaries and teams working on different goals. I think that also helps on creating the right sense of autonomy. I was working with a client that they were looking at some strategic goals and some objectives, and the objectives that they were identifying were actually outside of their group. They were more on a marketing-focused kind of thing. It was big organizational impact. That's not our team. We can't influence this. We have no power here. We don't get access to these kinds of systems. And I think it was important for them to realize, like, actually, maybe this isn't your goal. Like the overall organizational strategic goals are still there, right? Their strategy still matters. Marketing still has this thing. But what is what is your goal that connects up? Right. Because at that point, they just they didn't know they didn't know what to do. Like they were like, well, we have boundaries here. And these boundaries actually say we can't go in here and affect this. Where is what's the field that we're playing? playing in that allows us to help move our organization ahead. So sometimes teams need to understand and define that. And if they're not either created on themselves, you know, and do it autonomously or be given, you know, a direction and then say, yeah, go ahead and go figure that out.

• Ryan Brook

  All right. Thank you guys. Two questions to go. So at project kickoff, when the UI or UX design changes before. or during handover to developers, how should we approach change management? So this sounds very much handoff. So the UI or the UX design has changed before being handed over to the developers. How should we approach that change management? I get the sense as two professional scrum trainers, you might have a good answer to this one.

• Intro/Outro

  I'll take this one first. The biggest problem is woven in this question that this is a handoff, right? That these two teams are... passing the baton rather than working together. But let's just set that aside for a second. And I think it starts with whoever is designing the look, feel, UI, UX behavior of something, sitting down and walking the developers through it so they can understand what the changes are, why they are there, and understanding the different levels of urgency between them. Because often, I won't say every time, but most of the time when I talk to UI UX folks, they'll be like, we need all these changes. The app has to look like this or we will not accept it. And that pisses developers off. They're like, well, they just, you know, it's going to take four months to get all those changes done. How is that agile, Jim? Like I thought that we could deliver something less than perfect that works and is professional and is high quality that they should have to accept. Like, God, I love facilitating those conversations. So I think, yeah. Come at it from both ends. The theoretical input end is why are these two separate groups that are just now talking when a whole bunch of work is done? And then also building in some lightweight process and facilitated conversations so that everybody can start to have empathy and awareness for what the other side is doing.

• Jim Sammons

  That empathy is key. There's a sense of unhealthy ownership that can occur with teams that have to deal with like, this is mine. right you don't get to change that um and we forget like we all probably all still work at the same company we're still serving the same customers we're all trying to help us you know be successful here can we just partner up on this and get something done it's funny i was thinking i had actually been on the opposite side of this at one point in time i was a developer that was on a team that was asked with um making some changes to some really wonky ui like graphing stuff right it just People can figure out where they were interacting on the board, what graph that they were affecting, how to create the right kind of flow, how to choose their data sources. We had many little issues we had to go and work out. Our team didn't really do a lot of UI work, but we had the skills to write HTML and some JavaScript and make this stuff happen. And we had the availability. So that's why it came to us. And so we started doing this. and the one of the very first things that another developer on our team went and said was like hey maybe we should talk with the ux group and see if we can get some of their help on understanding what would create a better experience for our users um in in this section of the ui uh and when we talked with them we came over the busy group there again separate group that was often handing down designs and workflows and things like that to other teams And we approached him and said, hey, so we're working on fixing this graphing section here, and we can use a little help. And the guy that we talked to was confused, and he's looking around, and he pulls up his Gantt chart or something. It's like, we're not going to get to that for about another six to eight weeks. So yeah, we can't do that work right now. I'm like, the funny thing is, it's going to change tomorrow. We are doing the work now. we just want to know if you want to help and make it better because we really appreciate your insights into how our users actually engage with this stuff um and we will make something but it'll probably be better if you can help us get the right kind of design um and they're like oh well i don't know and then another guy's like you know i got some time tomorrow i can i can pop over and take a look you know and okay so he came over to our area cube area and started working through and he's just like well this looks weird like is there if there was a way we could highlight this to show like this was the active graph that'd be really cool we're like well hold on type a little bit like big red border around it you know it's like like that it's like just not that color like is there a different way we could do that yeah yeah sure what do you want it to be like right and started asking and making the little adjustments here and there because yeah that's a lot better so we we We built that empathy through actually working together, which I thought was really cool. But it was like, we don't have time to wait for handoff. This is going to get done. And again, this is ours, like all of ours, not just yours, not our team, but collectively we were one of, I think about 10 or 11 teams at that time working. So it's all of us that have to go and get this job done together.

• Ryan Brook

  You've got to love cross-functionality.

• Intro/Outro

  I don't think it's an accident that the two most enjoyable, most productive, most everything teams that I've ever worked on had UI UX people on the team, fully 100% on the team, not a second group, not whatever. Now they had matrix management, right? Their leadership sat in a different part of the org, but they were on the team sitting in the team room, two feet away from the developers. And it didn't go great all the time, especially at the beginning. but Within a few months, wow, it was so cool to be able to go from idea to I want that to design to develop to an increment in a single workday for a huge product with millions of users. I mean, we're not talking like some internal accounting package where we're changing a font on some nine level deep screen. I mean, I'm talking a mobile app with.

• Ryan Brook

  millions of installs it was it was very enjoyable to be a part of oh i love your stories guys um right let's bring it home then last question um i am using several sprints in parallel with the same team am i creating problems for myself by using that approach So what I understood this to be in something like Jira, same team, but for some reason, some creation of different sprint buckets for an unknown reason.

• Intro/Outro

  So I have seen this before. This is one where, man, I really wish we had context. I would love to talk to this questioner because if they mean I went into my tool and I've created what I would call. sprint plus one sprint plus two right to start to create a runway of work for the team in in parallel but their word parallel leads me to believe that's not what they're talking about if they're doing but but let's just say they are if that's what they're doing they're creating the current sprint the next two sprints and they're kind of pre-refining and pre-teeing up work i don't think that's a bad thing at all as long as it doesn't become this huge Gantt chart in, in JIRA or Azure DevOps. If they mean they have a, a team that's got three parallel sprints all going on, what I would, I have seen this as well. And what normally is behind it is two common problems. One is much too large of a team. You know, I know of a team right now that a friend of mine's working at, that's got like 24 people on it. So they, they have three concurrent sprints because you know, this team is looking at this part of the work. This team's looking at this, this team's looking at that. I do think you are making your own life harder there. The other problem, if the team size is not the cause, is normally the type of work. Like you've got a sprint for all your support and operational work. You've got a sprint for all your design and discovery work. And you've got a sprint for all your bug fixes and development and enhancement type work. I also think that's bad. And you are probably... going to come to regret that in the future. But what do you two think?

• Jim Sammons

  To me, terminology matters here, right? Because I immediately got confused when I heard the question. You have multiple sprints running in parallel. Because to my mind, that's not possible. A sprint is just a unit of time. So we're in sprint five. It goes, like we're in the middle of it, right? So for a week earlier and a week later, let's say they're two-week sprints, it's sprint five. I don't care how many. teams there are. I don't care how many products there are. It's sprint five right now. There is no other sprint in parallel. It's just a unit of time. Unless you're like multiple universes all in the same times. I don't know. But so to me, the question that I, Jim, I want to know more context that, but I have to assume in some way, I'm going to take a different assumption that there's actually multiple products getting worked on at the same time. multiple different types of things right because let's start there and if that's the case I I have a specific view on that my view is you are actually on multiple scrum teams working in parallel at the same spring cadence which sucks for focus right like it's great for each product like they have their own little time and and then you have to figure out as a person What do you do with your time as a team? What do we do with your time? Let's say it's the same group of people, the same six people working on the team. Do you spend the first three hours of your day working on one product, the next two hours working on another product, the final three working on the third product? Do you just kind of scatter through them? And again, where's the focus? What's the most important thing you have to work on at any one time? What's the thing that's going to create the best outcome? uh for your users and thus also your business um and so like that's that's one aspect if it's really just there's a bunch of disparate work that goes to different pieces but it's all part of the same product that's that's a product owner ordering kind of issue right and if we were to try to put all these things together and say well we'll order it all at one time let's even say three different products the issue we run into there then is what's the most important product work on and I can create a lot of focus for the team to say, this is like, we need to invest more in this product and these two just a little bit here and there. But then when it comes to like a sprint review, you're going to get a bunch of different disparate stakeholders who some maybe don't care about two of the products that you're talking about today. And the conversations are going to be, my guess, lacking a little bit more there. So there, to me, there are no parallel sprints. because it's just a bucket of time. It's really more about what's the work that you're doing.

• Intro/Outro

  I think, yeah, Rich, I'm going to amend my statement to the three most common causes of this I see is, the third one is what you're highlighting, which is a team has three products or three projects that are... going on consistently. And just to tell one real example from my past is I worked at an e-learning company and we had 85% of our work was towards the big flagship product. And then we had these two other small things that had a much smaller base. They were mostly just minor fixes or occasionally a little feature here and there. When I first hit that team, they had three sprints. They're like, well, this is... product A sprint. This is product B. And I go, no, no, no. Let's just set the word sprint aside. And even the word iteration say like, this is just time. This is the same group of people for a few weeks and we're doing work. So let's stop making our own life harder to say we have three boards, three backlogs, three of this. But they said, but Jim, you don't understand. We have three different groups of stakeholders and three different product owners. I'm like, oh shit, that is the problem. So multiple products. One team that works multiple products, multiple product owners, multiple product backlogs, one team, huge problems. So the good news is whoever asked this question, it's not hard to figure out which of these causes are at play and the solutions aren't that difficult. And you will likely just need a whiteboard and a marker to say, well, here's what our sprints are.

• Jim Sammons

  So to tie back to like some of the stuff we're talking before of like boundaries and autonomy and things like that. If you're in that state that Jim just mentioned, I've got one group of developers, maybe even one Scrum Master. I've got three different product owners that are representing three different product backers for three different products that we're all working together. You know who gets to make the final choice on what work gets done? The person doing the work. And that's likely going to create all kinds of headaches and management. Why is this team focused in the right area? We're structured to allow that. If you want to create more focus, we have to make a different change into how we structure our work, who's actually choosing the direction, where we go from there, or whoever's in the moment doing it. And if that's you working on one of these scrum teams, congratulations, you get to choose. And that's probably unfair to you. So like Jim said, go work through that problem. And that will help create more alignment up and down to make sure that you're getting that right autonomy. to work on the right things at the right time to achieve the right objectives.

• Ryan Brook

  I think in the PSM or the PSMA class, we have a Judy scenario about something similar. You know, when you bring in the complexity of billing lines as well, you know, three products, it almost brings in timesheet fraud. It's something I've seen in a lot of organizations. Like, how do I split my time across three products? I don't know what I worked on last Monday. Like, people can't remember what they worked in yesterday in a daily scrum. When they come to Friday. They're just making it up. I'm sorry to tell you that, senior managers, but their timesheets are mostly lies. And it's a problem. I know I'm being sarcastic here, but when that kind of has a knock-on effect to invoicing to customers, I think it's really tough.

• Intro/Outro

  I'll never forget the first time I saw the Judy and David slides from the Scrum.org curriculum, and anybody who's taken a Scrum.org class likely knows what I'm talking about, because I lived that every day for a year and a half. And we had the five-headed Hydra of... product managers at a company I worked at. And it got immensely better after we, me, after I finally lost my shit and went to the head of product management and said, we're not dealing with your five people in every meeting from now on. You need to designate one person. I was literally living the, what would you do if you were Judy's advisor? about four years before I ever saw the Judy problem. So when it got time for me to teach it, like I still had the mental scars in the stories to tell, which was, it was both good and bad, I guess. But yeah, that just tells you how real of a scenario that is in the course of curriculum that almost every single time I've ever taught that multiple people raise their hand and be like, here's the name of my David. Here's the name of my Judy, because we've all likely. been in that scenario where we've got multiple masters trying to hit one small group of people to fight for their own work getting done.

• Jim Sammons

  Hugo was my team from another class.

• Ryan Brook

  Oh we need to talk about that some more, but for those people listening who don't know who Hugo is, you're in for a treat. Well guys look we've gone through the 12 questions, hopefully the people who asked those in the initial ask a PST have been able to listen and get something from it. If you heard your question and we interpreted it wrong, you know, three people, well, two to blame. OK, so please feel free to reach out to Rich and Jim. And if I misrepresented your question, please feel free to blame me. I'm going to hand it back to Jim now or Rich to do some closing. But guys, from my part, thank you very much for your knowledge.

• Intro/Outro

  I've got nothing else to say. Just thanks, Ryan, for giving Rich and I the opportunity. I mean, I love these Ask a PST sessions and just any kind of these. AMAs, right? Because you just don't know what you're going to get and it keeps you on your toes.

• Jim Sammons

  Our pain to your all gain, right? Ryan, thanks for bringing the questions. Trying to keep Jim and I on track and despite all of the constant trainer dilemma of well, I got one more for that too. You did a great job there.

• Intro/Outro

  A little Jimmy Carr, like Ryan Brooks slash Jimmy Carr.

• Ryan Brook

  Do I need to do a head wobble as well? I don't know if this is video or just audio, but for anybody who is listening, I just wobbled my head like a bobblehead. Well, guys, thank you so much for your time today. And have a great rest of your day.

• Rich Visotcky

  That is all for today. Thank you for listening. If you liked this episode, let us know by hitting that like button. Share it with friends and colleagues. Sharing a message on LinkedIn. Joining our warm and welcoming Discord community. Or attend recordings as a virtual audience. You can find all the relevant links in the show notes. We hope you'll tune back in for the next episode of the Mastering Agility podcast.