Ask a Professional Scrum Trainer- A Focus on Agile Leadership with Ryan Brook

In this recorded episode of a live Ask a PST session held on September 16, 2025, PST Ryan Brook answered a wide variety of challenging questions from Agile practitioners! He explores the importance of vision-setting, accountability, and building a strong agile culture. Ryan shares practical strategies for leading distributed teams, breaking down silos, and addressing challenges such as complacency, unplanned work, and knowledge gaps. Drawing on his unique background as a chemistry teacher, he highlights how planning and decision-making skills translate into effective leadership.

Transcript

Lindsay Velecina  0:02  
Announcer, welcome to the scrum.org community podcast, a podcast from the home of Scrum in this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others.

Lindsay Velecina  0:18  
This episode is a previous recording of our live ask a professional scrum trainer series where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Hello everybody. Welcome to today's Ask a professional scrum trainer. Give a few moments here while people trickle in. I'm Lindsay valasina here@scrum.org and I will, oops, sorry about that. I will be our moderator today, and I'm very lucky to have with me Ryan Brooke, one of our professional scrum trainers from the UK, here to answer your agile leadership questions. So with that, you you're welcome to start entering those into the Q and A if you have them ready to go. So please utilize that Q and A box at the bottom of your screen. If you have any technical questions, you can utilize the chat for that. Or if you just want to share some comments with me and Ryan, you can drop those in there as well. So this is being recorded, and it will be available on scrum.org community podcast within 24 hours. So very quickly about scrum.org. We are the home of Scrum. We were founded by Ken Schwaber back in 2009 and our mission is to help people and teams solve complex problems. We do that through our training certification and ongoing learning. Ryan is one of our 300 plus professional scrum trainers around the globe.

Ryan Brook  1:53  
Make me feel special now Lindsay

Lindsay Velecina  1:57  
and he's super excited to share his insights with us today, and I hope that today's session plays an important role in that learning journey. So with that, I will hand it over to Ryan to introduce himself and kind of set the scene and get us started.

Ryan Brook  2:15  
Well, good morning, good afternoon, good evening. Wherever you are, folks, it is an honor to be here with you today, for you to spend the next you know, 45 minutes to an hour with me try to answer questions. I always feel a little bit doing these things is kind of like in the hot seat. But yeah, a brief introduction to who I am. So my name is Ryan. I'm based in the UK, as Lindsay said, I'm a trainer for scrum.org which perhaps isn't a surprise. One thing I believe in quite strongly is that those people who train Scrum, and in fact, train anything, you should be one of those people that practices what you preach. So I'm also an active consultant. I am the director of my own company called opti learn. But also I'm an enterprise product consultant. So primarily I work in the government domain, but I've also worked in publishing and in lots of different domains, primarily in the UK. My focus mainly is on product leadership and agile principles and everything kind of within that realm. What I'm going to try and do today, and I want to try and be honest with you at the start of this, agile leadership is quite a nuanced topic, in that there's no perfect or even wonderful, amazing single Fix It answers. So I want to try and create this opportunity for just open questions. I'm not aiming for perfection. It's a really challenging topic for me to try and do almost a bit of drive by consulting from, you know, one or two lines of questions in a zoom, Q, amp, a. But one of the things that's things I'm kind of seeing right now is is a shift that agile Leadership isn't just seen as this thing that happens at the top of an organization. It's happening kind of throughout multiple levels, which I'm really enthusiastic to see continue, particularly as we evolve more into talking about agile product operating models and how organizations can embed some of the principles we've Well, a lot of us on this call, I'm sure, have been, have been thinking about for many years. So the kind of questions I want to see today are, well, firstly, anything that you want to ask about, but don't be afraid of those kind of dirty, tough, messy questions that you kind of don't know how to make progress on. I will do my very best to answer whatever you write about. If I need follow ups, I'll try and call it out. But if not, you've got my email address on the screen there. If you need any follow ups, just just come to me. My background, other than being a scrum trainer, is I was a chemistry teacher in a secondary school for four years in the UK. I absolutely love doing that, but I've kind of found my home now training Scrum and doing product consultancy. So hopefully Lindsay, I've kind of filled enough time for a few questions to appear and we can get going. Fantastic.

Lindsay Velecina  4:46  
Yes, all right, so I'm just going to stop sharing here. Okay, so this first question, with a team that is completely new to all of this, what do you focus on those first couple. Of months. So I'm guessing all of this means agile, agile.

Ryan Brook  5:04  
I'm going to make the same assumption. But if the person I think it's John who asked the question, if I've made the wrong assumption, please do feel free to correct me. New to agile teams is really challenging, because I don't entirely believe a lot of people are entirely new to this kind of way of thinking. The first thing you can do, depending on your level of control and sponsorship and stakeholdership in this process, is just ensuring that vision is there, which is obviously something you'll hear quite a lot within, you know, agile principles, setting that vision, setting that goal, that idea, but something I feel people miss quite a lot is the accountability piece. So you can be a really great agile leader, but not always be 100% present. It doesn't mean sitting with the team, doing everything with them every day, but holding the team to account when it comes to deliverables or when it comes to do you know, what you just screwed up a little bit over the last couple of weeks. Holding people to account is not something to be shied away from, particularly in my industry, we almost feel like the developers are these they have this given right to sometimes say, Yeah, we didn't do it. Well, stand up in front of your stakeholders and explain why you weren't able to do it. That's really important for you as a leader, to teach them that. Do you know what we all screw up. I've got no problem with that. Trust is absolutely here, but also you are accountable for the value delivery you're aiming for here. So agile leadership, fundamentally supporting accountability, setting that vision, but most importantly, then stepping back and allowing them to learn how to do this themselves. Hopefully that gives you more more information, but if you want to ask a follow up a little bit later, I'm happy to come back to that topic.

Lindsay Velecina  6:44  
Okay, sounds great, but yeah, if you have further questions, feel free to add those. So next one here, how would you manage and create sprint teams that work across different time zones and prevent silos of knowledge, but also consider people that cannot always work out of normal working hours.

Ryan Brook  7:08  
Oh, I thought it would. There would be at least a few more easy questions before I got given a challenging one, right? Let me take another read of that. So how would I manage and create sprint teams? I'm going to kind of break this question up. Actually, the first thing I wouldn't do as a leader is create sprint teams, or at least the way I'm interpreting that question, it feels very much like I go I need three testers, two developers, one business analyst, one product owner. That's not entirely what I would do at all. The first thing I would I would do as agile leadership is ensure that we fully understand the problem space, discovery and validation. In fact, scrum.org, have a class called the ppdv, which is wonderful for solving this problem. But I promise I'm not trying to use this as a marketing opportunity. When you, when you fully understand the problem space, the teams will naturally form around that. Once you have someone, typically a product owner or a product manager trying to help with that, I'm trying to focus on, often what we call component teams doesn't work. Feature based teams is a much better way of trying to address that. Working across different time zones is really hard. Particularly, I'm making an assumption here that we're working on, sorry, I've got a bit of a frog in my throat. Sorry about that. Um, assuming we're working on the same product. Now, that's a big assumption that hasn't been addressed here. But obviously, typically, when we've got multiple sprint or Scrum teams in in a in this fashion, they will be working on the same product. Um, if that's the case, obviously they would be independent Scrum teams based on time zone. They would have one product goal per product. There's three teams, for example, they would all be working towards the same product goal, but each team would then have their own sprint goal. It is something I would be encouraging from an agile leader, leadership perspective, preventing the silo of knowledge is something I'm quite passionate about, because when people leave a company, that knowledge exits, but typically, we only ever see it as a problem as they leave the business, and that's obviously too late. So blowing down to speed up is it sounds like a complete anachronism, but what I really mean by that is enforcing that pair programming, encouraging people that reading a blog on a Friday afternoon because you've got time, you don't have to pick up another ticket, which is a horrible word, right? Product Backlog item, it is okay to view work as non feature based product backlog item, stuff. It's okay to say, Do you know what I'm going to write a blog or form a video, or do a little bit of research on an area that we need to improve on encouraging that from an agile perspective, and not worried about timesheet billing lines and that kind of stuff, how we define work, is what I'm truly trying to say here, also considering that people cannot work out of normal working hours, hopefully, once you have independent Scrum teams with their own sprint goals and own value. Based views on what work is really considered as hopefully those silo knowledge will slowly remove themselves, but it's about good communication and understanding what is work? Okay, that was a tough question.

Lindsay Velecina  10:15  
Yes, it was all right, so thank you for that. Moving right along. Keep those questions coming. So we have been implementing scrum for the last three years. There are four teams following the same sprint schedule. There are different opinions about how to handle the planned and quick hitters work during the sprint. Few of the team members don't agree to sizing the showstopper and quick hitters, lots of fun terms here during sprint. My question is, how can you get your historical velocity projected if you don't size your unplanned quick hitter work?

Ryan Brook  11:00  
Okay, I think I'm going to try and summarize that question into what I understand it to be. It's basically how we've got multiple teams working on the same product, two different thrusts of work. We have to kind of feature based, trunk, large pieces of functionality, but also those quick bugs, those quick kind of I just need to update this kind of work, I hope that's the right assumption. The first thing to say is multiple teams. Velocity should never be equated across teams. I know a lot of people like it because it's numerical, it's quantitative, but you know, one team has a different skill set to another. We all size things based on our perspective, and sometimes, if you size on a Friday afternoon and you've had a bad day, you're going to size something bigger cross team. Velocity forecasting just doesn't work. Velocity generally is a metric. Remember, it is a measure of functionality delivered, not value. So often I tend to focus with velocity. It should only be used for mature teams. And it sounds like you are a mature team if you've been trying to use Scrum for three years. Sizing, remember is a complimentary, complimentary practice when it comes to Scrum. If it's working for you, great if some of the team members, though, and it says team members again, assumption, I'm hoping that might be a team level. But if teams don't want to use velocity, they shouldn't be forecast or forced to, however, that doesn't stop you needing to hold them to account. For example, they bring in 10 things into a sprint. They deliver four of them. They didn't size them. It is well within your right as an agile leader to say, I don't care how you do it, but you need to be able to forecast more effectively. And there are other options. Work Item, age, mainly slow metrics, a good place to look. Here is the evidence based management guide, but lots of different metrics that you can possibly do based on my drive by consultancy. I know I've already used that phrase once some of the team members don't agree to sizing it. If you're using story points as a as a tool, you need to do it for everything or as much as possible. But remember, it is just a forecasting tool, forecasting things like bugs, things IE, that you don't know what it's going to include or involve. You can't size them. You're putting a number and guessing a nice sizing technique if you want to try and move away from velocity, something that I actually got told only a year or two ago was to have what we call no knowns. I think in your words, they would just be called Quick hitters. You know what you need to do. You can just deliver them at every one. You then have your unknowns, but knowable, so things you don't currently understand, but we need a bit of research. But actually it's within our email we understand. They're your bread and butter, your core, and then you have kind of unknowable unknowns, those things that come in and we go, I do not know how we would achieve that as a team. You're only bringing one of those unknowable unknowns into the start, because it could take the entire team, and then you kind of size some of the smaller stuff to bring in to fill in the gaps. I hope that gives you something, but that's a really challenging question to answer without knowing your context.

Lindsay Velecina  14:14  
Yes, we have a lot of challenging questions here, so feel free to add context if you would like. Or we can follow up with Ryan after the session as well with follow up questions. So this next one here. So this is kind of a very vulnerable question. So something that happened to my team is they lost trust in me due to some incident after like one and a half years they they do not remember the incident, but the effect is still there. How can I reestablish my leadership, especially in an agile environment? So it sounds like this person did something to lose the team's trust.

Ryan Brook  14:59  
So firstly. See. Thank you for your honesty, in your courage in raising this question. You obviously have the empathy and the self reflection to know that something's gone wrong. I'll be honest now and say I actually don't do a huge amount of business related reading. My reading is more for pleasure and fiction and that kind of stuff. But there are a few books that I remember from kind of my recent history, and one is called never split the difference by a guy called Chris boss. Chris boss is an ex FBI negotiator, and he talks about something whenever you're going into negotiations or whenever you're having a problem. He calls it, giving it a name, and he also calls it, and what did he call it a negative? I'm not even going to try and quote the guy, but basically he says, If you give all the negative stuff a name at the start, I call it out, people are much more likely to go, okay, an example might be, if I'm trying to sell you something, I might say, so you're really concerned. I'm just a sales guy trying to sell you something that you don't need, and it's going to take, you know, 25% of your take home pay, that's a concern of yours, right? And then it automatically opens you up to having an honest conversation about what you're really trying to do. So my short answer to you there is, firstly, thank you for your courage. To us, hopefully you are able to raise that to your team and say, Guys, something I'm feeling right now is, and I have a vulnerability about this. It's something that I know I did wrong in the past. I'm feeling it, and I'm probably sure you are feeling it too. This is what I'm proposing we do to get over this. How do we do that? I think showing that vulnerability, that honesty, and also calling it and saying it as it is will help you to move forward. Okay, the first step is acknowledgement, and, you know, well done. So I hope that

Lindsay Velecina  16:45  
helps you. Yeah, thank you, Ryan. Just to add to that, I just want to you know I think you're on the right path just based on the fact that you're being this vulnerable and realizing that there's something wrong. So I think you you're definitely on the right path there. Thank you, Ryan, okay, next one. So in my organization, teams are using the Agile Framework, but management is quite traditional. As a Scrum Master, I found it difficult to create awareness about agile culture within management. Do you have any inputs on how to handle this situation? So how can the scrum master kind of embody this and get management on board?

Ryan Brook  17:35  
Okay, so I'm going to answer this twice in two different ways. So the first thing I would say is that this very much comes down to your personality. My personality is very much. I do not mind walking into a room and telling people that they are approaching something in a very, very poor way. So one way I've done this in the past is I've walked up to someone and say, oh, you know, can you do something for me? But then proceed to make the point, give them 10 or 15 caveats of how they're not allowed to do it. Also, you know, be able to write this report for me, but please don't do it like this or this, like this, like this, like this, like this, and in a coaching session, you can follow that up with, well, how did all those restrictions and how did that traditional management and control make you feel? Obviously, the honest answer is restricted and you lose that creativity, right? Okay, so how do you feel? Or how do you think the teams may feel nice? Tactical approach there is to use a nice technique called empathy mapping. Empathy mapping is a completely free template available online, and I would encourage you to take a look at that template with the with some of your traditional managers alongside that, if you've ever done or O, R, S, C at work, within that, there's a really nice technique. Or the third entity, coping exercise, is something I talk a little bit about in the PSMA class. Effectively, it's structured coaching session for people who are not, not very good coaches. And I'm holding my hands up, I am not a very good coach. I like to give people answers, but that's one thing or two things I would try. The other thing is to say so I and my company do quite a lot of work in Japan, and obviously from a cultural perspective, management is quite traditional in that sense too. So we kind of had to fit Scrum and Agile within, within their culture, and the way we did that was simply by finding out what drives these managers. So another nice book, Daniel Pink, it's called Drive, autonomy, mastery, purpose. What do these leaders really want to achieve without going into a massive kind of speech. Generally, it's control and mitigation of risk and sometimes fear for their jobs. Again, going back to a previous answer, giving something a name, say, Do you know what? I obviously get the feel that we're having quite traditional management here. Can I check is it to do with these things? Because that's certainly not something we're trying. Make you feel like, how can we work together with your vision to execute on it in a way that allows us to be creative and also flexible on implementation? So those would be my inputs. Arun Kumar,

Lindsay Velecina  20:17  
that is awesome. Thank you, Ryan. I hope that helps. So next one here. So I have teams who are experienced in scrum but have become complacent and bad practices such as carrying work over sprint by sprint and not focusing on the product goal. I'm coaching the teams to help them refocus on sprint goals and adding value, but the teams aren't great at holding themselves accountable once coaching ends any advice. So it sounds like this person is leading them in the right direction, but when they're not present, then they fall into their bad habits. So how can that we get that to extend?

Ryan Brook  21:00  
Yeah, yeah. This is kind of comes down to a few different things. I guess the first assumption I'm making is that you're a scrum master in this although Scrum Masters typically being close to the team's agile coaches being a little bit further away. So if you're an Agile coach, that kind of consistent sponsorship is really hard. It almost reminds me of my children, right? If I ask them to do something, they'll do it while I'm present. If I go and make a drink, I'll come back and they're throwing things at each other. You know, it's a natural human kind of action to only stay focused when someone's watching you. The carrying work over sprint by sprint. Stephanie ockerman, I can't remember exactly what it is, has a wonderful blog about the kind of Sprint carryover. I would really encourage reading that, because it honestly, it just says What a stupid idea is. But I don't want to paraphrase what she said. She did it much more eloquently than that. The kind of tweak I would make is it says that they're not focusing on the product goal, and you're coaching the teams, helping them refocus on sprint goals. Actually, I think you should take a step back and help them refocus on what the product goal is, using the product goal Canvas created by effective agile and Ralph Yocum, I must admit, I always thought canvases were a bit of a waste of time, and that may be going a little bit too far, but I worked with my product owner, a guy called Stu and basically said, Look, mate, fill this in and let's change the team. And I don't think he really bought into it initially. However, we filled in this product goal canvas, and it took, it took us sort of two to four weeks validating it and getting it back with the stakeholders. But then when the teams really understood, particularly the description section, not actually the product goal, it really kind of got them to understand what they were trying to achieve from a product owner perspective. It also helped them to basically stop scope creep, because it was a case to say to the stakeholders, this is what we're working on, and why anything that doesn't contribute towards this needs to stay. You will also often find work carrying over sprint by sprint, when people are picking up things in a bitty way, a nice technique for that when they have got their sprint goal, and there's a nice sprint goal hypothesis template available on scrum.org in one of the blogs. Is only this is just a kind of semi control thing, just to teach them something at the start, but say that this is the sprint goal when they've collaborated and agreed to it, and tell them they're only allowed to pick up product backlog items immediately related to the sprint goal initially. Now we know that's not a restriction on Scrum, but what you're trying to do is get them to focus on the sprint goal, to understand that their initial understanding will usually change and get bigger as we progress through the sprint and so they end up collaborating around the sprint goal, nice technique or writing sprint goals, is the Jeff Goffe and Josh SEIDEN kind of came up with it. I guess if you like, it's the who does what by how much it's an OKR template, effectively. But once you can go back to the product goal canvas and get them to understand that, refocus the product backlog itself, then you can move on to the spring goals, but don't be afraid to hold them to account and say, Guys, you worked on stuff that that didn't contribute towards the spring goal. Why? Okay, remember, that's not a rule. In fact, that's actually to be encouraged, but while you're training them on it slow them down and get them to understand how to work together on a single sprint goal, because that's often, often a blocker, okay, hopefully that helped mark.

Lindsay Velecina  24:27  
All right, thank you. All right, this next one here. So how do you keep yourself from hitting your organization too hard? I'm guessing, like, you know, going going too hard with the Agile and Scrum stuff. So I know a lot about Scrum, Kanban, etc, and find it easy nowadays, but I hear myself answering question to rich in details.

Ryan Brook  24:50  
Not quite sure. Yeah, I think I understand what they mean. You're answering questions almost like I'm doing now. Okay, so a. But I'm eager. I could I love the little addition that's just been made, right? How do you keep yourself from hitting the organization too hard? A good friend of mine, a guy called John Albrecht, once said, and I apologize for my mind, a little bad word in this. He said, You're not being a great scrum master unless you're constantly pissing one person off. I kind of agree with his intent there. You kind of want to be rocking the status quo just a little bit. There's a there's a really nice model. It fits in with Cotters seven wise. I think it is. But effectively, it's about doing something, testing it. And the final bit is normalizing. And when we mean normalizing, we mean allowing an organization to find the new status quo. If you constantly make it, make too many changes, people just have changed fatigue. It's it's very natural. So how do you stop yourself from hitting an organization too hard? I personally would write yourself a strategic, almost quarterly goal for the thing you want your organization to get better at, and just focus on that one thing to allow the status quo to evolve. How you can help yourself by answering the question to reach detail is almost just imagine what their problem is. Rather than I want to know everything you know about this topic, because natural right? We want to say everything we know about something because it makes us feel good that we know stuff. But actually, a really nice tweet to that is, what is the purpose you're asking this question for? Why are you asking me this when you understand the why, you can kind of go, ah, actually, you don't want to know about how to create sprint goals. You want to create a way that the scrum team are more likely to achieve them. And that's a much more actionable question to answer, to try and drive questions to actions, rather than theory, and both of you will get more out of that. Hopefully that helps.

Unknown Speaker  26:49  
Dennis, okay, thank you.

Ryan Brook  26:53  
Oh, I don't think I'm gonna be able to answer the next one there.

Lindsay Velecina  26:57  
Lindsay, we are going to so this next one here. So how do you come up with a sprint goal when a scrum team works on different projects during the sprint? Oh, cool.

Ryan Brook  27:09  
You skipped the one I didn't think I could answer, yeah. How do you come up with a sprint goal when the scrum team work on different projects? Okay, so the first thing to say is this is obviously within a professional scrum context, remember that a scrum team work on a single product. What you've actually got there are a scrum team working on multiple products, and therefore trying to create a sprint goal across multiple you are never going to succeed. You can't, because a sprint goal is a tactical step towards your overarching strategic step being a product goal. And what you will end up doing is creating here incoherence by building on a little bit of product A a little bit of B, and there's no coherence. A nice thing you can do, and it depends very much on how big your scrum team is, is splitting your team into two smaller teams, even if they're kind of three or, you know, even three would be good enough, and then each team could have their own spring goal focused on a product. Yes, it creates more of the siloed knowledge. One of the t1 of the people heard earlier asked about the problem is, though, you're being forced into a position where the team are trying to work on multiple things. If you really have no option but to work on multiple you call them projects. I'm going to call them products for now. There is nuance there, but it's an assumption I'm making. If you really have to work on multiple products, I would encourage you to work more in a flow based framework, rather than Scrum. Remember, Scrum is is a framework that obviously has structure. I'm absolutely not saying something like Kanban doesn't have structure. It's harder than Scrum, in my opinion, but you can, perhaps more easily adapt it to work on multiple products, and therefore, things like spring goals. I'm not saying you don't need them. I'm just saying it's easier to adapt. If you want me to have a call with you on that topic, I'm very happy to but I could spend the next 32 minutes talking about it.

Lindsay Velecina  29:13  
All right, thank you. So yeah, feel free to reach out to Ryan with extra questions there. So how do you cope with expectations that you cannot meet as a scrum master due to external circumstances such as a developer role within the team being vacant for way too long, causing an understaffed team there?

Ryan Brook  29:38  
Okay? So first thing is, it's not your fault, okay? And that's me speaking to you. That's not me kind of giving you this, this kind of agile leadership answer, it's not your fault. So I don't know where you feel the pressure coming from for this question, the expectations, but wherever they're coming from, fit them down. And I miss making. An assumption they might be internal to your organization, and say, I'm going to call them John. Okay, look, John, I totally understand what you're feeling. We're feeling too. We want these, this additional support to, you know, be able to deliver more work. Unfortunately, that's not practical right now, and therefore, here's our product backlog. Allow me to connect you with the product owner, and you can help influence some of the stuff right because we can't do everything. They'll help us to understand the things that you really need. There's no specific answer to that, other than making sure you're working on the right stuff as much as possible. A good scrum team doesn't pump out loads of work, at least initially. They just build one or two things that are validatable, that your customer really wants. Just trust me on that if you if you've never experienced it before, your customer would rather have one thing they actually asked for that's done well than 10 things that were to be honest guesswork on the behalf of the developers. Okay? So, yeah, it's not your fault. Be open about the facts and the impact it's having on you and your team in a retrospective and raising that up to your leadership. Yeah, there's not much you can do if a specific problem is a developer role being vacant for too long.

Lindsay Velecina  31:23  
Okay, thank you. All right, so what do you do when your managers and management want to keep a tight grip on things? So there's a lot of context missing there, so you can make some assumptions. Oh, I

Ryan Brook  31:35  
think I'm going to have to, yeah. So a couple of things, I'm going to have to start referring back to previous answers, because I don't want to feel like I'm having to repeat myself for too long. But yeah, so managers and managers typically want control because there's a fear of risk. It is. We sometimes call it the frozen middle. And I don't know if this is true in your case, Peter, but where there are managers who almost are calendar fillers, they are their job exists to kind of turn up to daily scrums and go, oh, so what's the progress on this? And then they go back and they feed it back. I'm not saying you don't need those people, but I think we need a lot, not we need a lot less of them than the industry currently has. How do you help when managers and management want to keep a tight grip of things, you go and directly speak to them and say, Why do you need this control? What are you trying to achieve? Typically, it will be, I need to be able to provide updates to X, Y and Z. And then you think about that as the problem to solve. Okay, turning up to things like sprint reviews is a really good way recording sprint reviews. A lot of people feel like they can't record the event itself. Most of them are online now. Recording a little overview is not a problem or recording a slide deck or a demonstration, however, it is that you can then send out to your on a new your newsletter, your user base to get you feedback. Management and management want to keep a tight grip of things, because they see there's an element of risk in your team. You need to find out what that risk is. They're trying to mitigate by keeping a tight grip on things. If it's that they honestly don't have that much else to do with their time, bring them in and give them problems to solve. Right? In the retrospective, when you come up with three or four things, I'm going to use John again, right? John, thank you. It's amazing that you want to keep a tight grip on things. Here are three or four things that would really help us move faster. Let us know if you need any help. So throw the ball back over the fence and give them a problem to solve, and that should hopefully help keep them at arms. Then a little bit.

Lindsay Velecina  33:35  
Okay, okay, that's awesome advice. Thank you. All right, so I'm going to skip around a little bit. There's a lot of questions here. So as an agile leader, how can I deal with the status quo?

Ryan Brook  33:51  
How can I deal with Well, hopefully I'm not entirely seeing where the question is there. I understand what you're saying, but I don't understand if your status quo is positive, if it's negative, you know, if you if you want to change it, if there's organizational appetite to move it, that's that's very, very different. But the first thing to do is to try and document your status quo. So what actually is the position you're in, whether it's a process, you know, a good place to start with the status quo is to identify two things, your value stream map and your customer journey. They are not the same thing as much as some online project management tools would have you believe, once you can identify your value stream and your customer journey, you are going to be much more able to identify your bottlenecks in that process? It's much easier to call out and address the status quo when you can say, Did you realize there's a blockage or a slowdown in our process? Here, it gives you a really nice place to focus. So if you want to come back with a more specific status quo question, please do but I don't want to do too assumption, too many assumptions, and waste. Am so thanks, yeah.

Lindsay Velecina  35:04  
All right. All right, that one's just a comment, bear with me a second. All right. The team is new to agile, including senior management, and currently hold on to their old way of working. Don't necessarily accept agile adoption or support in general. They feel it is an interference besides setting the vision for senior management as to what could be quick wins, example, connect with early adopters, or is it simply long breath and continue to build trust solving issues and show up to lead them in the right direction?

Ryan Brook  35:53  
I think this is actually, these are really big

Lindsay Velecina  35:57  
questions, so I so I applaud the audience for bringing some real thinkers for Ryan today.

Ryan Brook  36:05  
Don't make me regret it, guys, no. So I actually think this is one of those areas where training will help. And when I say training, I don't necessarily mean you know, two, three days of long training. It doesn't need to be that, but a basic introduction to Agile. So I'll give you an example. I'm currently working with two organization. One of them is a bank, and one of them is a home builder, and that basically they have a their bank, calling it their hearts and minds problem, where people just kind of understand the the hows, the whys the whats, but they don't really, they don't really feel it. So what we're doing basically is a playing Lego with them for three hours, which no one ever turns down a quote that includes Lego, but then the second, the second half of it is pretty much a case of, right? You've just just understood now why we're doing stuff, okay, which you probably already knew. But what of the things we've just learned will directly apply to currently, how you're working and FYI, this should include senior managers. It doesn't matter how old you are, you still love Lego, and you come back to these identified problems. Now, really nice thing to do, and I'm going to call it a retrospective, even though, obviously, retrospectives wouldn't typically include senior managers. Claudia Califano wrote a blog once called the white elephant. It's definitely called the white elephant. I can't remember the rest of the title, but it's a retrospective where, effectively the team come up with, you give them a set of, like, 12 or 13 cards, Scrum Master, product owner, product refinement, product goal, Scrum values, you know the deal. And basically, the team go around in a room and say, best, the least good, and individually, they put a card down, silently justifying it as they move forward. Once they're all in a row, you can then go through and discuss and debate. The reason why that's important is because at the very bottom, the least good what you've just done there is given your scrum master or your Agile coach, whoever it is, three things to work on, and it gets by in at an organizational level, because the senior managers were involved in this. They understand the problems when you justified them, when people have seen you discuss them, seen you debate them, and pick those three things to focus on, it becomes that kind of that spark that then hopefully creates more change so they don't necessarily accept agile adoption. But this might sound awful for a from a professional scrum trainer, but kind of forget the glossary when you're trying to build trust. Just prove to them that it works, because some of these people have been in the industry probably 2530 years, and they'll say, Well, it's been great. It's worked for the last 20 years. With respect working and being more effective, very different things. And so your job is to try and pull and drag and go and coach them to do things better, a phrase I use, which is while say it to end this answer is that when a team says they can't improve anything, they are either lying to you, or they are the world's most perfect team, and I know which one My money's on, so sometimes bit of humor calling out that accountability. Get them to pick something small to improve.

Lindsay Velecina  39:13  
Okay, awesome. Such small. That's great advice. So this next one, we're going to shift a little bit so someone came with, like, a career advice type of question. So during a career shift, I discovered agile and fell in love with its mindset, principles and Scrum as a framework. I earned my PSM one from scrum.org and to support my goal of landing my first scrum master role. My background in it is pretty limited. So my question is, can someone without a developer background really become a servant leader for a scrum team? Or am I being unrealistic?

Ryan Brook  39:50  
Okay, I guess background for me so because also it ties into a question that I think Dana has asked a little bit later. Or Dana, sorry, i. Yeah, yes, it is absolutely achievable. Is it harder now than it was five years ago? 100% okay, I came in as a like I said, a chemistry teacher never did any formal software development, and it's worth saying at this point, Scrum is not just for software. It's much more accepted within software, but it's not you are now competing with people who've been doing this for five to 10 years. And you'll see more commonly redundancies coming in now, direct buyers for scrum master, if you look on Indeed, and LinkedIn and those kind of job boards are decreasing. What you are finding increasingly more common are things like agile product managers or delivery leads, or even just project managers. Those kind of roles Don't be restricted by the job title. Remember, a scrum master, effectively is a team coach. There's a lot more to it than that. However, once you're within an organization being that change manager, that that support to try and get things better, you can kind of craft your own role. So yes, it is absolutely achievable. But what I would do is remember, in your organization, whatever job you do right now, you are likely to be a problem solver at some point. Because you are a problem solver, you are a developer yourself of a problem, of a solution, and you are a stakeholder manager, the person who raises the problem. Don't be afraid to use though that language, because, let's be honest, that is product development and Scrum language, and apply it to your situation. If you're looking to get into product, think about the domain you are in, because that is actually more important than the skill set. Sometimes, if you're in education, you should be looking to education companies to work. Start working in product. If you know banking, start looking into fintech. Don't be restricted just in looking for this software, Scrum Master, golden goose, because honestly, I probably wouldn't pick anyone brand new. You're going to have better luck if you pick bigger organizations, but also, and some advice I've given to some people over the years, organizations will find you on things like LinkedIn. Okay, so start posting, start blogging, start creating videos. If they know who you are, they're much more likely to come to you with with openings and saying, This doesn't exactly align with you, but maybe this will help. So so hopefully cast your net wide. Don't be restricted by by job titles. Yes, it's achievable. Yes, it's also hard,

Lindsay Velecina  42:29  
okay, yeah, and that should have hit a few people who asked similar questions as well. So thank you for that. Alright, so when you're implementing scrum with a new organization. Do you follow specific framework or playbook, or do you start by listening and adapting as you go?

Ryan Brook  42:50  
Wow, okay. Oh, I have so much I want to say, right? Let me try and be quick again. John, follow me up if you need more info. I have. I have my own playbook. It's a very personal playbook, something that I've seen based on experiences. But obviously there is listening and adaptation as I go. First thing I do in an organization, people will say, just observe for the first two weeks. Yeah, that's great, but sometimes it doesn't. You need to be seen to be an initiator quite early on. The first thing I'll do in the first day or two is just arrange chats with everyone that I possibly can, like literally adjacent teams, stakeholders, senior leaders, way up high. I once contacted the entire director of an entire business to see if they'd heard about my product, heard about my team. When you start to get a picture, you can start doing an agile maturity assessment. There are templates online. They're not perfect. Some of them are absolutely awful, but they do create a structure for you to kind of go through what I try and do. And I wrote this once for an organization. Reports sound very anti agile. They're not. I wrote a two pager, and it basically had four, four sections. Number one, Team description, you know, is it a team of eight people working on this domain trying to solve this problem, and it went through right? This is the this is the resource profile. This is the cost spend. And then at the bottom, if you want us as an organization to get better, these are the things we need support with. Because when you have chats with your team, they are going to call out stuff that they need help with. So it will be typically a category. So whether it's resourcing, organizational restraints, hardware and tooling, state the problem, state of potential, action, state and impact stay a priority. Once you've got that kind of stuff, you make all your problems transparent to an organization. And number one, you're going to light a fire under some people's bottoms, because all you're doing is holding a mirror up to all this stuff that has previously been hidden. Okay, so the first thing I will do is I will try and rattle the organization a little bit and just see what falls out. Yeah, agile maturity. Start initiating one small change. That one small. Change needs to succeed, because you need to be able to the team. Need to see you as someone who's identified a problem and come up with a solution and make things better for them. If you can prove to them really early on that you can make things better for them, you will have buy in forever. Okay, so something going back to the question, person who asked that really honest question about courage, just go back to basics. What's your problem, and then I work my bottom off to try and fix it for you. Okay, so I do have a playbook, but it's very ad hoc.

Lindsay Velecina  45:30  
Okay, thank you. Yeah, every organization is a little bit different, so let's see. So we all work together on multiple products and have singles, a single sprint goal that incorporates all the tasks we have to happen in that time, the work is split into smaller groups who complete each part. This actually works for us, and we do all the usual scrum related features. It was just a comment. This is back to an earlier question. I think I actually made a mistake here and read the wrong question,

Ryan Brook  46:07  
but thank God, because I'd lost you.

Lindsay Velecina  46:11  
Yeah, this was actually a follow up comment to, I believe, an earlier question, or maybe it was just a random comment. So to the person who commented that, if you can provide a little more context, that would be awesome. Sorry about that. I meant to read the question above that, so let me sorry.

Ryan Brook  46:35  
Is that something you want me to comment on? Lindsay,

Lindsay Velecina  46:37  
you can, if you would like, but I was going to pick a different question,

Ryan Brook  46:41  
pick a different question. And guys, my email address is ryan@optiler.co.uk seriously, email me. You can provide more context, and I will read them in my own time.

Lindsay Velecina  46:51  
Okay, all right, so I lost the question. I wonder if the person deleted the question that I was going to ask. Okay, anyway. So I'm guessing this just means agile work in general. But how do we document this type of work without necessarily creating user stories for this type of work? Or is there a better way to track and document this type of work? So do you always need user stories, I'm guessing, is the question, do

Ryan Brook  47:21  
you always need user stories? No user stories are complimentary. I actually find that product owners who just kind of go through an entire backlog and just change everything to user stories because it's what they heard on a podcast, is a stupid idea. User stories are wonderful when you actually have user involvement and you truly understand basically the why, what are they trying the problem? Are people trying to achieve? Most things should come from a user. That's just the fact, right? It shouldn't just have been created in a product owner's head, although sometimes there are exceptions to that, because they're advocating for the user. No, you don't always need user stories, but you need to focus on a nice template that I tend to advocate for when I'm a product owner. Is who raised it, what problem are they trying to solve, and what potential solutions could we discuss as a team? So really important that we talk about potential solutions, because often when people raise product backlog items, they will put how to solve it when it comes to refinement or planning, that looks like a plan to execute, and everyone's creativity has just left the room. So try and keep things at a really high level when you're doing your product backlog refinement, so that it doesn't remove creativity and flexibility. I'm trying to go faster now, Lindsay, because I'm conscious, I've got about seven minutes before you wrap up.

Lindsay Velecina  48:39  
Any questions we do not get to I will share with Ryan, and we will figure out a way to okay to them. So how do you come up with a sprint goal when a scrum team works on different projects during the sprint

Ryan Brook  48:51  
okay, I would say, asked and answered on that one that obviously, if you're working on multiple products, creating one single sprint goal, which is supposed to be on one product, one sprint team, one product goal. You're fighting a losing battle there, and I would encourage you to move to a slightly different framework, something like Kanban. That is an awful lot if you understand enough about why that's a less good idea. I agree with you, but it's a better idea than using Scrum and trying to force it once you are holding a sprint goal because of an organizational requirement or because a PSM BST trainer told you you should you've hit the wrong point. Yes, they are hard to create. We have workshops available on how to create sprint goals. I have a sprint goal hypothesis template. It's a blog I created a while ago. There's a video of me explaining how to use it, but effectively, it's something you give to the product owner a few weeks, but, well, not a few weeks, a week before the sprint planning, go and fill this out, bring it to sprint planning with a coherent idea, and it should connect all the way back up to your organizational vision. It's a nice place to start.

Lindsay Velecina  49:57  
Okay, thank you. I. All right, so we've time for a couple more here. So the head of our department does not want the agile team to bring in emergency, unplanned work into a sprint. He wants us to do the work outside of the sprint, but the team wants to report out to them when they do happen, because it affects the sprint. Today, we bring them into the sprint by hiding them as not an emergency. This is not the practice the team wants to keep doing. How do we handle this? It sounds like

Ryan Brook  50:32  
your team have got a lot of common sense. At the end of the day, your sprint is a bucket of work, a really nice tool to use here, mainly because it resonates with people. Is something called a mental health bucket. Won't go into it in too much detail, but effectively, you have a bucket, and you put big rocks in it, is it full? No, I can pour sand in it. Is it full? No, I can pour water in it, and then it overflows. Show that to the manager about unplanned work and how that impacts. Right? We start off with the rocks. This guy keeps dumping on loads of water because the capacity is fixed. Doing them outside of a sprint is is bonkers, as far as I'm concerned, because then you're arbitrarily creating capacity for almost in sprint work and then out sprint work, it's all work. The one thing I would say that you're perhaps lacking right now is a strong product owner to kind of give that coherence and that idea, because that is the person who should be interfacing with that. I can't remember what you called them, the kind of agile leader, manager, kind of person, because at the end of the day, they are a stakeholder. They do not get to say how you work. Remember, the team chooses their process. So don't be afraid. Get your scrum master to put up a big field and say teamwork, how they want to work. Leverage requirements onto the team, onto the product owner and they will deal with it.

Lindsay Velecina  51:43  
Okay. Okay, thank you. Can you share a time when you made a big mistake as a scrum master and what it taught you?

Ryan Brook  51:53  
I think I've written an entire book on that. Yes, you have actually called solving for value. Yes, on my next one's called the anatomy of a product out in December. Now that was an advert. No big, big mistake I've made as a scrum master. Really quick story. So I had my first child six and a half years ago. Wow, that made me sound old. I had hair then. Biggest mistake for me was seeking to be a hero and solving as a Scrum Master, we constantly want to be visible because our work is so intangible. And I went off on paternity leave for my first child. I was gone for two weeks, and when I came back, the team said, Oh, we didn't do anything on that, Ryan, we were waiting for you to get back. Kudos if I didn't, if I wasn't doing a good job. However, the fact is, you want to be an impediment remover for that team, or at least causing them that kind of connector, that kind of assistant. You know, often we call it servant leadership, but true leadership is a better, better phrase. Biggest mistake I made was being a hero and being able to step back and allow teams to get better. That's when you're good at your job.

Lindsay Velecina  52:55  
Okay, thank you, and I did drop a link to the book as well. Thanks very

Ryan Brook  53:03  
much. Yeah, oh, there's so many here. I want to answer Lindsay,

Lindsay Velecina  53:08  
do you want to pick? Do you want to let

Ryan Brook  53:11  
me try and do quick fire? Okay, so someone asked me what skills I got from when I was a chemistry teacher, the ability to plan schemes and basically forecast deal with stakeholders that are sometimes a pain in my backside, so parents. Sometimes I say that as a parent and children, but most importantly, it's having the confidence to make decisions, something that I find people who haven't been or worked in external industries before are unable to make decisions and just kind of go well if no one can decide that's what we're going for. And that's something I learned as a chemistry teacher. Is safe, really agile, and should I use it? That is not a conversation, a question I'm going to answer in 30 seconds. There is a whole body of knowledge that suggests Yes, and there's a whole body of knowledge that suggests No. I have my own opinions. All I would say is, if something works for you, honestly, great. If it doesn't and it's creating too much structure for you, throw it out the door and find something else. And that is also true of Scrum. That's great advice. No problem. I got recommendations hacking the unconscious, by Rory Sutherland is wonderful. Turn the ship around, by David L Marquet is a fantastic book about a USS Navy submarine commander.

Ryan Brook  54:33  
I think that was good. What else have I got to yeah, that's all

Ryan Brook  54:41  
I'm going to recommend right now, I'm looking, you know, when you look on your bookshelf, but no, that's what I'm going to recommend. Now, if there's any you want me to answer more. Lindsay, but I know we're coming up to time.

Lindsay Velecina  54:51  
Yeah, I think that at this point we should maybe start wrapping up. Up. I know that there are a lot of open questions here. We will figure out a way to address them based on the questions Ryan that you received in this session today, what are some like actionable advice items that you have for this group?

Ryan Brook  55:17  
Do not do an Ask a PST session, because people will ask you hard questions. No. So actionable things for you to do. Don't be afraid of speaking truth to power. That is something I would say, however leader you are, don't be afraid to go. Do you know what? This is how you're making us feel, and this is the impacts and actions you're having. That's something I would say. Don't be afraid to rock the status quo a little bit and see what happens. If you get into a rut, things will never change. So they do. You know what? Guys, we need to try something new. I don't care what it is. So a nice approach is just try it, and then you can either kill it or keep it. And that is a sprint level, organizational level, whatever you want to do. And finally, as an agile leader, you don't need to be the one that solves the problems. I work with a wonderful guy called James, and James is the epitome of never present, always working for you. So you know what? You don't always need to be present. You do need to understand the pain points, and you need to work super hard to solve them. For people, that is good leadership, not being present and making decisions on their behalf. Okay, those would be my wrap up. So someone's put a question here about what, what can I develop on what a good sprint goal could be? A good sprint goal is just something that allows for creativity and flexibility. So things like I have increased the the number of payment methods on our website to include Bitcoin and visa, or we've sold 1000 books. I'm using book examples here it could be, we have created the ability for our for our users, to export PDFs so that they can do X, Y, Z, a user. Story format actually works better as a sprint goal format as a such and such a user they want to be able to do X so that they can do y. That is a nice thing to put into your sprint goal and then solve that. It also makes your sprint reviews easier. Go back to Dennis's question, but there you go. Lindsay, I was working as fast as I can, and I'm now tired.

Lindsay Velecina  57:26  
Fantastic. All right, so there are a few here that we did not get to. I will share those with Ryan. Some of them have a lot of detail in them, so they're probably better to be asked offline, but we will figure out a way to address them for everybody. I want to thank you, Ryan for getting in the hot seat today and answering these questions, and I want to thank our audience for bringing some good ones here for Ryan, and I hope everybody got value out of this today.

Ryan Brook  57:56  
I certainly did. Yeah, guys, in terms of those questions, please do feel free to email me. In fact, I've seen two or three people have emailed me already. Please do that. It's very hard for us to kind of find your name and tie it back to your email. If you really want your question answered, ryan@opcow.co.uk put as much info in as you can, and I'm happy to have a 15 minute call if people prefer that.

Lindsay Velecina  58:15  
Yes, and I dropped Ryan's email in the chat as well. So we've got some nice comments here. Someone said, You were very inspirational. And I Oh, thank

Ryan Brook  58:26  
you very much. Can you tell my wife and children to say that too?

Lindsay Velecina  58:31  
Well, you can tell them that today that you I will they will not believe me. All right. Well, thank you so much, Ryan. And I hope everybody has a great rest of your day or evening, wherever you're located, and Scrum on

Ryan Brook  58:44  
scrum on you. Later, guys, have a wonderful afternoon. Bye, bye.

Unknown Speaker  58:47  
You.

Transcribed by https://otter.ai