Tips to Overcome Agile Skepticism
The idea of self-managing teams who have flexible scope and timelines can be perceived as daunting to some executives and senior leaders. In this session, Professional Scrum Trainer, Mary Iqbal talks about some of the common misconceptions about Scrum and Agile in general from a leader’s perspective and how to overcome them.
Transcript
Lindsay Velecina 0:00
Good morning. Good afternoon. Good evening. Wherever you are located today. Welcome to today's scrum pulse. Just give folks a couple seconds here to trickle in. Thank you all for joining today. My name is Lindsay Velecina with Scrum.org. I will be moderating today's session, overcoming agile skepticism with professional scrum trainer Mary Iqbal. Welcome, Mary. So happy to have you today. And let's get started with some logistical information so that we know how this works. So your microphones will be muted throughout the session. But we do encourage you to ask questions, so please utilize the q&a feature at the bottom of your screen. And if you have any technical questions, please utilize the chat. You will be able to access me there for any technical questions that you have. But if you have questions for Mary, please drop them in the q&a so that they are captured. And this session will be recorded and the recording will be available within 24 hours. So keep an eye out for that you will get an email with a link to the webcasts page on the scrum.org website. And let's go to the next slide Mary and then we'll dive into the content. So really quick about scrum.org. We are the home of Scrum we were founded by Ken Scwaber in 2009. Our mission is to help people and team solve complex problems. We offer training and certification and professional Scrum. We also offer a lot of free learning opportunities on our website like this webinar, and also videos, our blog, our forums, lots of ways to learn Scrum. So with that, I hope that this session plays a part in your learning journey. And I will hand this over to Mary to introduce herself and kick us off.
Mary Iqbal 1:50
Thank you so much, Lindsay, and thank you for having me. But those of you who don't know me, my name is Mary Iqbal. I am a professional scrum trainer with Scrum.org. And I have experience as an Agile transformation manager for over 60 teams. I've trained over 1000 people in Agile frameworks and have over 20 years in Project program management. And I'm also the organizer for scrum day, which is scheduled for September 14 2023 in Madison, Wisconsin. So you can learn more at scrum de.org. The purpose of today's presentation is to talk about some of the misconceptions which can hold back successful agile adoption, and can even hold back individuals from fully fully embracing the concepts underlying agile frameworks. So to get started today, I'm going to start off with what is agile. And then once we've gone through some introductory content, we're going to ask you to choose your own scrum venture, which means we're going to have a poll about in about a couple minutes here. And you're going to choose which of the topics do you most want to hear about today. And then we'll discuss those topics. And with each topic, we'll allow time for questions and comments. And then finally, we're going to wrap up and give you some information that you can take with you. So starting off today, what is agile revenue, I think it's important to start off by defining our terms. So Agile is an umbrella term. And it's used to refer to really an unlimited number of frameworks, complementary practices, that all are used to deliver incremental value, which means frequent, usable value to our customers and to the organization. Agile works best in complex environments where more is unknown, the unknown. So if you could write work instructions to deliver that thing that you're delivering, agile may not be a great fit. But if you require some creativity, if you're not sure exactly how you're going to do that thing, if outputs are different, every time right with every, every every deliverable is a little bit different than the way before. And the problem is just a little bit different. And maybe requirements are a little bit different technology or solution approach a little bit different. That's where agile really makes sense and agile frameworks and complementary practices. Because Agile is a framework is an umbrella term of a different many different frameworks that can be used to guide teams to work together to deliver creative solutions to complex problems. Agile is, as I said, a framework and it starts with a mindset, a mindset of focusing on the benefit that we're trying to achieve. Agile also is described in the Agile Manifesto, agile manifesto.org. And in that manifesto, there were four values that were identified, including individuals and interactions, over processes and tools. We value individuals and interactions over processes and tools. There were 12 principles that were included in the manifesto satisfied satisfy the customer working software, frequent delivery. And then there really are an unlimited number of frameworks that people use to deliver value in an agile approach. by far and away the most popular of those frameworks is Scrum. And that's what we're going to be talking about today. In addition to the Agile frameworks, there are an unlimited number of complementary practices that you can sort of bolt on and use with each of the different frameworks. For example, teams who are using the scrum framework. Frequently write product backlog items is a format of user stories, it's a compliment. In practice, you don't have to do that. So you can decide which of these complementary practices work best for you in your environment. As I said Scrum is far and away the most popular of all the Agile frameworks. This information was taken from the digital ai 16th annual State of agile report. And as of that report, 87% of teams who are using Agile are using Scrum. So it's far and away the most popular of all the Agile frameworks. I think of Scrum personally as the Goldilocks of agile frameworks, that has just enough structure, but not too much. Spam allows teams to work together within five events, three accountabilities and three artifacts to develop, discover the best way to deliver value for them. So what we're gonna do now is I'm gonna pass the ball over to Lindsay, and she is going to be bringing up a poll. And using this poll, we're gonna decide what are we going to talk about today, we're gonna put the put the ball in your court as the listeners to decide which of the topics are most valuable to you. So let's see, if you want to bring up that poll. That would be fantastic.
Lindsay Velecina 6:46
Okay, I'm gonna go ahead and launch this, you all can go ahead and choose the one that resonates most with you.
Unknown Speaker 6:47
Mary Iqbal 7:00
And these are all common misconceptions. For example, we can't use Scrum, because we have to hit a date. If you want to hear more discussion on that topic, because I choose that if you want to hear we can't use Scrum. It's too risky. Let's talk about that. If you want to talk about this is too important. We need to a real plan to get there. Right. These are all common misconceptions that we're going to talk about. And if you have one that resonates most with you, or you're hearing this from your stakeholders, select that. And then we'll we'll talk about the most, the most popular voted items are what we're going to talk about, management will never go for it. We can't deliver working software invest in one month. Agile is hard to adapt to many meetings, we don't have the time. We work on multiple projects. At the same time. We can't use agile, there's a lot of rework in Agile, I hear that a lot. Struggle work for us, we have to customize it. Right. These are all some very common misconceptions about Scrum, and when he'll hear these debunked and vote for your misconception, and we'll talk about it.
Lindsay Velecina 8:07
Okay, it looks like there's still a few more trickling in. I'm gonna give this another be 15 seconds here. Like it's slowing down. If you have just hopped on, please participate in our poll. This is how we're going to determine our content for today. So you're choosing the statement here that you want to hear more about.
Unknown Speaker 8:34
Okay.
Mary Iqbal 8:37
Great, after all of these at different points, and they're not people who, who raised his objections or are concerned, right, we're trying to do what's best for the organization. Right. So, right, the meaning well, so that's why we're going to talk about
Lindsay Velecina 8:56
okay, I
think pretty much everyone has participated. So I'm gonna end the poll here.
And then I'm going to share our results. Okay. So it looks like we work
on multiple projects at the same time.
Is the top one, then? Yeah, I have a lot that are kind of neck and neck. So we have some ties here, Mary. Yeah, I'm gonna like, yeah, there's three that are at 12%.
Mary Iqbal 9:35
All right, let's see what we can do. Let's, I might go with too many meetings. Okay. That's an interesting one as an agile,
Lindsay Velecina 9:43
agile is hard to adopt and management will never go for it.
Mary Iqbal 9:47
Management will never go for it is our third. Okay.
Lindsay Velecina 9:52
All right. All right. I'm going to stop sharing.
Mary Iqbal 9:58
We will work on multiple projects. At the same time, so we get that we're going, okay. All right.
All right.
All right. So here we go. We work on multiple projects at the same time. So I often hear this objection from organizations who are already using waterfall to deliver projects, or they may be using Agile on some projects. But they're, they're using it only to deliver the project, they haven't established prob products, teams through which value can flow. So I'm going to talk a little bit about this, this this topic, this idea. So let's take a moment and imagine an organization. And the organization has maybe a project management office, which is fantastic. But the Project Management Office is working on projects in a way where they're bringing the teams together. And the teams are brought together to deliver this project, which is a temporary nature. And then the team disbands once the project is over. And so what happens frequently in that kind of environment is, even if you're bringing the team together, and they're using Agile to deliver value, there may be situations where individuals on the team are working on more than one initiative. So this, this visual is really from the professional Scrum Product Owner class, which is created by scrum.org. And it talks about the the impact when you have individuals working on more than one project at a time. So you can see in the very first year when an individual is on a single project, they can spend 100% of their time on that project. But when they're on two projects, that first bar represents the amount of time they're spending working on that project. And the second bar, or I should say, on working on each project. And the second bar, the black bar represents the amount of time that's lost to context switching. So you can see from this chart, and when somebody is working on two projects, they may spend 40% of their time on the first project and 40% of their time on the second project. But they're losing 20% of context switching. And this only gets worse the more projects an individual is on, the more time is lost to context switching. And that's a result of working on projects that are temporary in nature, where you're bringing a team together to deliver that project and the disbanding the project team. A better way to approach this, if you do need to run projects would be to run those projects, but work with product teams. So for example, if you have a product product that has a website, for example, and you have a website, then put together a team that delivers that website and have them work on it. And if there's work that needs to be done for the website, you put that work on a product backlog. So you would create a scrum team to deliver this product and their scrum team would have a product owner, the scrum team would have a scrum master and the scrum team would have developers and developers would include all the individuals that are necessary to deliver value for that product, be it a website, or, or human resources or whatever that product is. But bring together the team and get them working together. Right? form that team, give them training, make sure they understand their product, and enable them to deliver value by ensuring that they understand what are their goals, what's their goal, and what are they trying to accomplish with their product and have that defined and then work with the product owner to make sure the product owner creates a single to do list for that team. And that to do this is called a product backlog. And then any work that needs to be done for that product should be put on the product backlog and ordered by the product owner. So rather than having this context switching that can happen when you have multiple initiatives going on at the same time and people context switching and trying to figure out what am I working on today? And what's the deadlines for this, this project in that project, put it put all of your requests on a single to do list which is known as the product backlog. And then knock those out one at a time. Because the best way to deliver value is to focus on the highest priority work first, finish that and then move on to the next thing when you try and do everything at once. When you have three number one priorities, then nothing's important. So establish that product backlog Order, order that product backlog and then unleashed your teams to deliver value. It really is a better way of working together. But it does require that the organization makes some decisions around what are our products. What are we trying to accomplish here? What's most important who Who are our customers, and then establishing teams that are able to work together to deliver value. For the one or more products that may be established for that organization, it's a much better way to deliver value, it's much more efficient. And it focuses on the customer rather than focusing on dates, dollars and deliverables are focused around outcomes, are we reaching the outcomes the organization needs? And if not, let's adjust. That makes changes to our direction, let's just a roadmap. Let's adjust our product backlog. But it really is a better way to deliver value. So I'm going to pause here and asked, Are there questions on that particular topic?
Lindsay Velecina 15:43
There is a question that came in talking about multiple projects. How can we create a sprint goal that will unite the team if we are working on three projects at a time?
Mary Iqbal 15:58
Did you have a sprint goal? Okay, yes. The sprint goal that were you guys a team if you're working on three projects at a time. So I'm assuming, right that you have a product team, and that product team has worked that's associated with projects that may be created on their single product backlog. So in that case, if you're ordering your your product backlog, according to what's most important to the product owner, then the team will be working on the highest priority first. And if if they are, they may just be working on one project at a time, right. And so it depends on how large your team are. But if you have, let's say three projects that have made it into the sprint right work for three projects, then the team has to determine what's the most important thing in the sprint, right, because you can't have three number ones. And that should be their sprint goal. The sprint goal doesn't have to incorporate every single thing that's in the sprint. But instead what it should do is what's our most important thing in this sprint. So if I have product backlog, item one, two, and three, right, and product backlog item one is much more important that I will probably build my sprint goal around that. Rather than trying to be inclusive of every single thing that's included in the sprint, really ask yourself what's the most important thing if we were to choose an objective for the sprint? Right, in terms of what's the most important thing for us to get done? What would it be? That is your sprint goal?
Lindsay Velecina 17:28
Okay, great. Thank you.
And there are a lot of questions on this topic. I will ask you just one more just to clarify something Patrick asked. So are you suggesting that you centralize all work items from the various projects into one product backlog?
Mary Iqbal 17:48
So what I'm suggesting actually, is the organization take a step back and ask what are our products, and then form teams around those products. And then if there if there are projects that remain in the organization, then those project managers would approach the product owners and ask, Hey, can we get on your product backlog?
Lindsay Velecina 18:10
Okay, thank you. Okay. All right. All right. You want to keep going, Mary?
Mary Iqbal 18:19
Let's do that. So let's go into our next topic, which is to meeting meetings. All right, here we go to meeting meetings, we don't have the time. All right. So this is a common misconception associated with Scrum teams. So I want to start off by by talking about the events in Scrum. There are five events in scrum that can seem like a lot when you first when you first see these, right? The five events in scrum are first the sprint, which is a container for all the other events. And the duration of the sprint is one month or less. So this time box, which means there's a maximum duration. And the sprint is the term sprint length is determined by the scrum team within that time box. So a sprint could be one week, it could be two weeks, it can be three weeks, anything that is one month or less can be the sprint. But there's no meeting for the sprint. So that's really just a container. So within them, there are four events within the sprint. There's sprint planning, which happens once at the beginning of the sprint. So if you have a two week sprint, there's a one time sprint planning events. And that event is timebox at eight hours or less. Now that sounds like a lot, right? You sound like Oh, am I saying that? We're going to have an eight hour meeting once every one week or two weeks? No, that's the maximum amount of time for the sprint planning events. I've only ever been to one that actually took that maximum timeouts. So depending on the length, duration of your spreads, that event is usually shorter, shorter. So for example, for a two week sprint, it could be around two hours. Next you have the daily scrum, which is 10 bucks at 15 minutes or less, regardless of the duration of the sprint. 15 minutes. It's a day We touch base with the developers. And the purpose of that is to increase the likelihood of delivering a done increment, which meets the sprint goal, at least once by the end of the sprint is really important. But it is only 15 minutes. And it's just a touch base, right? What's going on? How's it going? Are we on track, right? We're not going to problem solved, we're just going to identify do we have problems. The next event is the Sprint Review, which again, is timebox to four hours, but it is usually shorter or shorter events. I've never been to one that was four hours. But usually, they're two hours or less depends on your product depends on how long your sprint is. And then finally, you have the sprint retrospective, which happens again once at the end of the sprint. And it's time boxed at three hours. So the purpose of the sprint retrospective is to improve the scrum team's effectiveness. This is where we talk about how are we going to do better as a team. So when you lay those out on a calendar, let's look at a sample. What does that look like for one week's rent? What might that look like? If you have a one week sprint, Monday to Friday, that might look like a one hour sprint planning. Now I'm not saying it's my boss, I'm saying that this could look but this is what it could look look like. I have a one hour Sprint Planning Day, then you might have your 15 Minute daily scrum. And then at the end of the sprint, you might have your one hour sprint review. And let's say 30 minute one hour veterans, that's about three and a half or four hours in a week. That is not a lot. There is definitely not a lot. And the thing about these events is these events are going to reduce the need for other meetings, if you're touching base every day. And you're asking, how's it going? Do we have the impediments, and you're you're you're taking those impediments as they come and resolving them outside of the daily scrum, you actually save a lot of time. Excuse me. Now, those, this time doesn't actually show, let's say refinement. So you might add another one hour of refinement on top of that we're looking at for for four and a half hours a week if you include refinement, so it's not a huge time commitment. And these events, the way they're structured, are going to save you other meetings. Let's imagine now that you have a two week sprint, but what might that look like? If you do not include refinement, then that's about seven hours and two weeks. Again, not a huge time commitment as these events do save the team. Other meetings, I can tell you from experience, right? And it feels very light, right? You're meeting to every two weeks for a two hour sprint planning, meeting every two weeks with your customers and showing here's what we did, right? What do you think? What's your feedback? Let's adapt the product backlog based on that feedback. And your meeting every two weeks to ask the team members? How are we working together? Is it working out? Do we need to change the way that we're working? How can we improve the way that we're working? So it is a very lightweight framework as a scrum guide said it's lightweight. There's there's just enough, but not too much. And that's why I'd like to think of this as the Goldilocks of all the Agile frameworks. So as I mentioned a couple of times, right? These events, these lightweight events, do save the need for other meetings, right? We're identifying impediments sooner that daily scrum, the team members are not suffering in silence. You're creating a plan every two weeks, you're figuring out how are we going to approach this and you're renewing that plan every two weeks because we as human beings really, really can't plan in detail really longer than a month. So we're reviewing that plan, at least once a sprint so it could be two weeks, whatever your sprint duration is. And we're getting feedback sooner from our customers, at least once per sprint, whether that's a one week sprint or two weeks since we're asking our customer. What do you think? What do you think of what we're delivering? Here's what we've got? What do you think of this, and we can adjust course earlier, if needed. So these together are invaluable and do save the scrum team time, a tremendous amount of time, when those events are used. Well, the events need to embody the idea of empiricism, empiricism, which means we're transparent. This is how it's going. Everybody knows how it's going. We're inspecting the work frequently. Those who are closest to the work are inspecting it frequently. And we're sharing that inspection. We're talking about that inspection at the sprint review. And then we're adapting, we're adjusting course based on what we learned. So when the scrum events really embody embody the idea of empiricism, that's where we're really going to use the events most effectively. And that's where we're going to really save the most time and make that truly a lightweight framework. So I want to pause and ask questions, comments. Okay,
Lindsay Velecina 24:48
so let's see. So there are a lot of questions that came in here.
A lot of them are still on the different projects. So
there's a cut. There's a comment here. The reason for too many meetings is that there are a lot of meetings outside of the scrum events as well.
That does happen
Mary Iqbal 25:17
that does happen. And my advice to that is, if there are a lot of meetings happening outside of the scrum events, I would suggest discuss that in the retrospective. Why are we having so many meetings outside of those sprint events? Is it because we're not doing a good enough job of refinement? So that we don't know what is in the product backlog? Or what is being asked for for each product backlog item? Or is it because we're not planning well enough? So that's a very common issue that newer Scrum teams tend to face, which is not using the sprint planning event to its, its its highest level, right? So ask yourselves, when we go into the sprint planning event? Are we really doing the three things we need to do there? Which is, are we selecting the product backlog items we're delivering? And furthermore, are we creating a plan for how we're going to deliver those product backlog items? We can't just select them and say, you know, that's it, we need it. We did a little bit more than that we may need to plan how are we going to approach this? Who's going to do what, what are the things that we're going to do so at the sprint planning meeting, you're selecting product backlog items, you're creating a plan for delivering. And then of course, as we discussed earlier, you're creating a sprint goal, which provides focus for the sprint. So if you're spending a lot of time outside of the scrum events, in meetings, you may not be making proper use of the events. Take Take a look and discuss that in your in your retrospective. Again, the most common cultural culprits there are, refinement may not be doing enough to identify the details, order, and size of product backlog items. Sprint Planning may not be getting into the town as much as it needs to be doing. And also your daily scrum. Are you being transparent? There are developers talking about what what, what is our plan for the sprint and how is it going. And really using that time to plan for the next 20 to 24 hours in a very streamlined fashion. If you're not using the events properly, you may be spending too much time in those additional meetings outside of the scrum events trying to catch up. Okay,
Lindsay Velecina 27:35
thank you. And another question here. I find that during sprint planning sessions, it is hard to keep developers engaged when not discussing their work, is there any way to avoid this?
Mary Iqbal 27:47
I would wonder if your team's too large. So a lot of times, Scrum teams are typically you know, 10 or fewer. When you get a larger scrum team, it can be hard to stay engaged with with that larger team. So that's one suggestion that I might have for you. And then I might also think about when you're putting together your plan, do you have a whiteboard, a shared whiteboard, or something that the team can really use to center their discussion around that. Okay, thank you. I want to add one final thought on on the previous question about engagement planning events, you might consider different techniques around facilitation. So the professional scrum facilitation skills course, which is recently released from scrum.org is a great option. We do talk about some different facilitation techniques that can be used specifically in sprint planning event. So take a look at that course that might be something that you're considering or that you might be interested in. I would also recommend liberating structures as some great tools around facilitation that you might consider and apply to sprint planning as well.
Lindsay Velecina 28:57
Okay, thank you. Great, okay. Looks like we can move forward.
Mary Iqbal 29:08
Alright, so let's go to our next topic then which is, okay, management will never go for it. So let's head on over there. If we go. And okay. All right, management will never know for it. So when engaging leadership, right, as as an implementation for Scrum or I would say a new implementation for Scrum. So things that you can do is focus on what Agile does best, which is the delivery of value sooner, in smaller increments. So when when the 16th annual State of agile report came out that the number one reason that organizations adopted agile was to deliver value sooner. And the second was to increase predictability and these are things that that scrum does particularly as well is we're going to deliver value sooner, and we're going to deliver just what you need the highest the highest priority work. And then get training for the leadership team so that they understand how best to empower those agile teams. There can be a lot of uncertainty with these with a new Agile transformation, leaders not understanding how to engage with the team. What is what is the best way to empower those teams? How do we support agile teams? So a lot of that can be cleared up with with training, and then focus on promoting self management with guardrails. Right? What are the guardrails for our organization in terms of how we're going to use Scrum? When you're adopting agile, consider this as a change initiative. I like to consider this as a change initiative. So identify and communicate, why are we doing this? What are we trying to achieve with an Agile transformation? And then communicating, right communicating the why to to all those stakeholders who are engaged in the Agile transformation? And then talk about what's in it for me, why, why? What are the benefits that I am trying to get from an Agile transformation. So from a senior executive standpoint, it made me deliver value sooner. From the team members standpoint, it may be a more sustainable pace, right, a more logical approach to the way I work, more empowerment for how I deliver value day to day within the organization. And then focus on change management, communication, communicating that, wasn't it for me getting stakeholder feedback, and adjusting course, based on how is this going, and then empower your teams with training and coaching. So again, right, that 16th annual State of agile report, I think, is really intriguing accelerating time to market, the number one reason organizations switch to Agile, and then predictability, making sure that we know we can forecast where are we going to be, where are we gonna be in six months, we're going to be nine months. So that predictability, it's not that we're, we're sticking to a plan, it's that we're adjusting to a plan. And we're smoothing out the flow of our work by using an agile approach. And then my personal favorite, lowering risk because of the way that we're approaching our work, because we're delivering more frequently and in a more incremental approach to smaller batches that are done and usable functionality, we're lowering risk for the organization by identifying technical issues earlier. So we're not waiting till the end to try and integrate everything together. And only to find out that it doesn't work. But we're finding we're finding those issues sooner. And we're able to adapt much more quickly because we don't have a lot of half baked works. And what we're delivering is done. And we can change direction as more becomes known. So taking advantage of that approach for incremental delivery to take advantage of Positive Risk right, and to reduce the impact of negative risks. When you're talking to managers, right? Think about, from their perspective, what is it? How is it? What is the manager's role in Scrum? I think that that frequently is something that comes up from the managers perspective, what do I do here, right? When we're in an agile environment, you hear a lot. Like there's no such thing as a manager in scrum what? That can certainly make me a little bit hesitant. But there that there is a need for leadership to support agile teams, right? Leaders can promote self management, promote self organization. That doesn't mean that the leaders go away right, but their role is different. Leadership can reinforce clear accountabilities, they can create that culture of trust, making sure that the team is really, really living and supporting those scrum values supporting the scrum master and making sure those Scrum, Scrum values are adopted and really lived by the scrum team. Fostering problem solving, asking open ended questions being servant leaders. That's what we need from our leadership team. Ensuring that Scrum teams are able to work effectively making sure that they have the tools that they need, removing impediments. This is critical this is where leadership really can focus on what is holding the team back, do they need another test environment? Do they need more training? Do they need additional resources? What is it that they need and then helping to to get that for them and ensuring that people are able to innovate within the scrum team they feel empowered. So there is a place for leadership and making sure that they understand that place can be very important to an agile adoption. Okay, questions on that topic.
Lindsay Velecina 34:48
So, this question that came in, try to summarize as best that I can, how can we increase the participation of our management in reviews? We It created a public calendar where interested people can join the reviews. We work with a published project canvas, but it doesn't seem to be enough. Less participation of management and stakeholders makes the team think that their work is not worth it.
Mary Iqbal 35:17
Yes. Okay. Yeah, that's that's a that's a difficult question. So number one, I worry about the idea of having an open calendar for reviews. I think in my opinion that the product owner, this is their most valuable event, and they need to determine who they want to invite to those events. So rather than having just a free for all, which may make managers unsure which one, they should go to ask the product owners to do some stakeholder analysis. And when I look at stakeholder analysis, I think about interest level, right. And I also think about influence over the product. So those individuals who have a high interest and a high influence level, those are individuals that the product owner needs to closely monitor to reach out to them to make sure that they're, they're proactively invited to that sprint review, that the product owner should talk to those stakeholders, and including managers and talk to them about what do I need from you? What are the expectations, when you go to a sprint review meeting? It's not just the presentation. This is an opportunity. We're asked to show what we've done, yes, but also to get feedback. And we're looking for that feedback. That's what guides us. So I think setting those expectations, and asking either the scrum master, the product owner to talk to those individuals, about what are the expectations? How do we engage in this sprint review. But I'm concerned with this idea of just having an open calendar, I'd rather see much more proactive outreach to those managers, from the product owners perspective, to make sure that they know that their attendance is requested at these events. And then also from the Scrum Masters perspective to make sure that they understand that these are not just reviews, these are important events, where we're engaging and getting feedback. And that feedback is what guides us. And we can't have a productive event if we're not inspecting and adapting. And part of that adapting is getting that feedback. So setting those expectations upfront. See, I think the other thing I would do is ask yourself, are those events engaging. And what I mean by that is, you don't have to, you don't have to go through every single product backlog item that was delivered in the sprint, right? Make sure you're hitting the highlights, you don't want to you don't want to get done. And then make sure that during the event, you're using facilitation techniques that request that feedback. So some some that I'll just share with you some ideas you might have, you might have after every every product backlog item or everything that you're presenting in the seat feature or whatever you're presenting at Staples. What do you think, is that helpful? Right? Ask as you go through the review, don't have to wait till the end, give us a thumbs up, thumbs down? What do you think about this one? And then present? The next one? What do you think about this one? That'd be one one way to get stakeholder feedback. You could also ask them for feedback on your roadmap, right? At the end of the sprint review. What do you think of this roadmap? Would you would you would you, you know, vote on upcoming features, make sure that those those events are actually engaging. So I have a great article on this topic. If you go to scrub that org forward slash marry dash kickball, I do have an article about ways that you can get stakeholder feedback in the sprint review. And there's lots of different options. There are five feature a different things that you can consider at this sprint review, to make sure that those are engaging. So summing that up, right, do some outreach, don't just passively say, here's the calendar, do some outreach, and identify those stakeholders whose feedback that you would most like to have. Make sure that they understand that this is not just a review, it's an inspect and adapt event. And then make sure your events is engaging, right, that you're you're talking about the most important things and you're asking for feedbacks, because you need to ask, right? It doesn't just happen by itself. So those are just a couple of steps in the chat, check out my article person facilitation techniques and tools that you can use for more engagement. Other questions?
Lindsay Velecina 39:29
Um, someone asked for clarification. You mentioned guardrails earlier. Can you give some examples of those guardrails?
Mary Iqbal 39:36
Absolutely. Actually, we're gonna hit up my next I think we will have do you think we have time for one more topic after this? Because I think we could
Lindsay Velecina 39:44
probably squeeze in that last topic. Yes. And that topic
was, it was
Agile is hard to adapt. Yes.
Mary Iqbal 39:53
Okay. So let's go to that because that that is in part of that topic. I discussed that. So here we go. Let's go over to that slide. All right, agile is hard to adopt. So we're going to talk about guardrails. As part of this, I here is one way that you can go now every Agile transformation is different. Okay? On every transformation is different. But I think when we say that Scrum is hard to adopt, what we're really saying is, I don't know how to go about this, right? This is, this is intimidating for me. So I have laid out a little roadmap that you might consider now be keep in mind here that every transformation is different. So you are absolutely going to need to adapt this based on your own needs. But when I'm thinking about Agile transformation, I think about these sort of roadmap steps. And each time it's going to adjust. I think about first asking the question is Frommer is agile? Really the right fit for your business problem? Is this really a complex problem? And then, if the answer is yes, making sure that you talk to leadership and get some buy in for this, we want to use Scrum. We want to use agile and getting that buy in, is this the right fit? And this is the right fit for your business problem. And part of that includes is their support for this. Once you have that, then you're going to define your products, as I mentioned earlier, start with your customer, right, what are our products? What are we what are we trying to do here? And then once you've done that, identifying the resources that that are needed to deliver that product. So for example, if my product is a website, then maybe I need content writers and developers and testers and maybe DBAs and designers and the different types of folks that you're going to need to deliver that product, bring them together, and then prepare to allow that product team that those individuals that are beyond the product Scrum teams prepared to allow them to self organize by setting guardrails, guardrails within which they're going to be allowed to self organize. And so some sample guardrails might be, we want to make sure that every team is cross functional. We want to make sure that every team is round 10 or fewer. We want to make sure that every team is let's see, whatever those guardrails are organization wants to set. Now, some of them may be restatements of the scrum framework. Some of them may be more right. Those guardrails are set by the management typically. So some some common law rules. I mentioned a few but some organizations will say we need a mix of senior and junior developers on a team, we need a mix of senior and junior testers on a team. Whatever those guardrails are, that's what I'm talking about my sacred Grails and then scrum training for everyone making sure that everybody understands how do I use Scrum. And then a self organization session can be helpful, and then we start sprinting. So I'm gonna walk through those steps very briefly, because I know that we are a little bit shorter, I guess we are a little time for it. So when considering is agile, the right fit? You ask again, is this a complex business problem? Scrum is the best fit when requirements are somewhat far from agreement and technology is a little bit uncertain. That's when Agile is a great fit. When you define your product, start with the customer. As a customer as a car manufacturer in the Navy, the product is of time that the customer is a commuter. Maybe the product is a car, identifying those resources that we talked about a little bit earlier. It's pretty good. It's kind of fit capacity and then setting your guardrails. Some of these guardrails can be simple restatements of the scrum framework to make sure that folks understand and that we're reinforcing that framework from the beginning. Some of those frameworks can be some of those guardrails, maybe budgetary, the product owner will have a budget of XYZ for the product, it just depends on the organization. Identifying the right scrum training, so for those who are new to Scrum, applying professional scrum can be really fantastic training for those who are just going just beginning their transformation journey. That's just a great class. And then you have professional scrum master for the Scrum Masters of the team. Or for those who are interested in this one master accountability leadership can take that, and a professional Scrum Product Owner class for product owners or those who are interested in that product owner accountability. So lots of training options. Let them self organize, right? And that's where they determine what teams how many teams are we going to have, who's going to be on each team and then start sprinting. So those are some simple steps that you can take for for adopting agile and that I think addresses your question around guardrails. So I'm gonna pause for a second and ask, are there other questions that we want to talk through that have come up? Oh,
Lindsay Velecina 44:47
so this question I have experienced with some companies that after their training said that the culture of their company is too rigid and based on waterfall project management, what do you suggest asked to do to start working on the company's culture.
Mary Iqbal 45:04
Okay, fantastic question. So culture is extremely important. Without a culture that is promoting self organization, it really limits the ability of Scrum teams to live deliver value. So the first thing I'm gonna do is start talking to the leadership team about this, I think I would consider asking some executives to attend that professional, agile leadership show that they understand. A lot of times this has to do with a mismatch, right? A lot of leaders and executives and managers have have have become very successful using a certain leadership style. And that leadership style may be command and control, it may be a little bit more task oriented a task management, and they've been successful with that. And it can be hard for them to change their leadership style that can be a ship a scary thing. And so talking to them about this idea that the business problem determines the right leadership style. And when we are working in complex products, we need that creativity. And so changing the leadership style is going to be important, moving more towards a servant leadership style, and making sure that they understand that, you know, it's a mismatch, when you're trying to have command and control and at the same time asking for creativity and problem solving from your teams. It's a mismatch. So if simply start by talking about it, and then direct some of them to touch on that professional, agile leadership class, where we really talked about why is this necessary? Why do we need to change from a command and control style to a servant leadership style? And how do I do that? Right? What are some? What are some tools that I can use to make that adjustment? And what is my what is my role? If I'm not doing task management? What am I doing? How do I provide value? I think starting with a little bit of empathy. For for for leaders who are struggling with that change can really go a long way.
Lindsay Velecina 47:13
That's great advice. Empathy is definitely important. So there's another question, can you give more examples about how to achieve more self organized teams? The problem that I face in my team is that the work during the sprint is not transparent enough for the other team members. In the daily scrum, every member says that the work is on track and everything is fine.
Mary Iqbal 47:39
Okay. Okay. So that's, that's a great question. I love that you're asking it. So. So during the daily scrum, it can, if it's turned into damn fine, no impediments? Yeah, I'm fine. No impediments? I think, discussing that in the retrospective first as well, for starters, right? And identifying this as an area that needs improvement in the first place, I think, really is step one. And talking about the impact that this is having, why is this a problem? Well, it's limiting our creativity. Right? It's, it's totally a scrap from really working together as a team. So number one, spotting that as a problem discussing that in a retrospective, and then asking the team members to be more open. It's a little bit scary, right? It's a little bit scary to say, I'm struggling with something or this is taking longer than I expected. But normalizing that and saying, yes, it's okay. And reinforcing this idea that if one person is struggling with a product backlog item, it's not just their problem, it's the team's problem, and therefore we need to talk about it. And then setting that expectation. The daily Scrum is not just a checkpoint, it's not just a, a, a percent complete are Yep, I'm fine. Yep, I'm fine. It's supposed to be a collaboration meeting. So I think they may not know that. And so discussing, the retrospective to me is really a great place to start setting that expectation that this is not supposed to be just a checkpoint, and here's why. It's because we all own this problem. And we all need to work together and unlock that creativity as a team, and setting that expectation and discussing about it. And then hopefully, the team will agree and adopt that as their improvement ideas item, right for the next sprint. We're going to use that meeting for a little bit more than just a checkpoint. Another thing you can do if that doesn't work, you can you can embrace this idea of tasking out your work creating on the sprint backlog making the plan more transparent by adding additional tasks that may be associated to deliver each product backlog item so that individuals can at least see them on the board. And that can be an entry point for further discussion. Right so your if you've got your tasks on the product backlog on items that are visible on your sprint backlog, then that could be an opening for further discussion on how are those tasks coming along? Can I help you with that task? Or right? If none of that works, you might try pair programming and actually pairing up developers so that from the get go, you don't have just one person assigned to each product backlog item, you may have to assign to that individual product backlog item. And that really encourages them to work together. So those are some some different options that you may try. All of those need to be discussed in the sprint retrospective so that you can set that expectation of spirits what I see as a problem. And here's some ideas that maybe we could use to address that problem. Here's why should that have a problem? What do you think team and discuss it?
Lindsay Velecina 50:52
Okay, thanks, Mary. And I had mentioned pair programming and I actually dropped the link to your most recent blog on that into the chat for everybody as well.
Okay, so how do you
handle the pressure and deadlines for management for deliveries that hamper scrum team output?
Mary Iqbal 51:13
Okay, deliveries that handles hampers grunting output like I I'm getting pressure from deadlines. Okay. All right. So pressure from deadlines. So what I would do there is make sure that the product owner is creating a forecast, right. So the product owner owns the product backlog, which is the plan for the team, this is what we're doing, here's our list of things that we're going to be doing, the product owner owns the content and ordering of product backlog, and the developers own the sizing of the product backlog. And that product backlog is the plan. And that plan has everything that you need to forecast when you combine it with you know, previous work pace, right. So making sure that the product owner is creating some kind of forecast, it can be in the form of a roadmap, which shows, here's what we're gonna do. And here's the here's our current forecast for when we're going to be there. So communicating that out, putting together some kind of forecast, a roadmap, a burn up to loose little diagram, whatever it is, but communicating that out. So that rather than having leadership coming in saying, here's our deadlines, which is just fine. But making sure that the product owner takes that information, puts together a roadmap and says, here's my plan, here's where we're going to be. And here's when we're going to be there and communicating that out much more frequently. And then inspecting that forecast for that roadmap at the sprint review. So that leadership has that, that predictability and then adjusting it as more information is becoming known. My tip there is Communicate, communicate, communicate, put together that forecast and make sure that that is made accessible to your stakeholders.
Lindsay Velecina 53:03
Great, thank you.
Okay, this question. We have time for maybe one or two more questions here. Five minutes left. So when a backlog item enters the product backlog, how do we ensure that the item is placed correctly? Do we have a meeting for each entered item? So stories subtasks are created accurately. And once ready for Sprint? It is actionable ASAP, mindful meeting template for this type of meeting would be beneficial. Thanks, Alex.
Mary Iqbal 53:40
All right. So number one, I would say the product owner decides what is really accountable for the content and ordering of the product backlog. So the product owner is the one that decides what gets added to that product backlog. And they may delegate that they may empower someone, business analyst or developers or testers to add work to the product backlog item. But I want to make sure that when we say we're gonna have a meeting to add to the product backlog item, that it's clear that there is one person who's accountable for that, and they're able to decide what goes on the product backlog, or the product backlog. They may delegate but they're the ones who are accountable. So want to make sure that when we say we're having a meeting, it's not that I want to make sure that it's clear who owns that, right. So it's the product owner. And then number two, right if you if you do need to refine and add details and order in size to items and the product backlog item, I would earn the product backlog I would suggest a refinement meetings. refinement is the act of adding content order and size to items in the product backlog and that can be a meeting right where we're going to meet once a week with with certain all or some of the scrum team and we're going to size we're going to review we're going to add detail we're going to discuss items in the product backlog or it can be individuals going out there and refining the product. backlog on their own. But I just want to clarify, right, that refinement meeting would be a great way to add that content detail and size once it's been added to the product backlog item or even to brainstorm new individual new items from the product backlog that makes sense that I answer your question.
Lindsay Velecina 55:17
If that if we did not answer your question, please let us know Alan. Okay, so we are about at time and there are a lot of unanswered questions. So I'm going to share all those with Mary and then she can address them with you separately, if you did give your contact information when you signed up. So with that, I think we should move to our close.
Mary Iqbal 55:45
Okay, and that's it. All right. I want to say we go any.
All right. Okay. So Lindsay, I'm going to pass the ball to you.
Lindsay Velecina 55:57
Okay, so each accountability has clear learning path. So take a look at our website, you can check out the learning paths for some additional learning and resources there. And I do want to drop a quick link here for everyone. If you wouldn't mind, I am dropping a link to a survey that scrum.org has out there. Right now. This survey is focused around content and content topics, levels of content, the different medium that we deliver our content for you. So please share your inputs there, we would really appreciate that. Then, next slide, Mary. Hey, please stay connected with us through our social media channels or forums, attending more webinars like this one. And yeah, don't be don't be strangers. So with that, I'll hand this back over to Mary for some final words. And then we hope to see you next time.
Mary Iqbal 57:00
All right, thank you so much, Lindsay. I'm gonna say thank you everybody for joining. I just want to share with you my website if you want to have a follow up or sign up for my weekly email, it would be fantastic sign up at rebel scrum dot site. And I want to also remind you about Scrum day. This is a one day conference scheduled for September 14 2023. I certainly hope to see you all there at scrum date. If you are interested in signing up, I'm dropping a link www.scrum.org For more information or to sign up. Thank you so much and have a fantastic rest of your day.
Lindsay Velecina 57:32
Okay, thank you everyone and Scrum on