Это видео недоступно.
Сожалеем об этом.
The Daily Scrum is NOT a Status Meeting
HTML-код
- Опубликовано: 3 авг 2024
- As part of the Scrum Tapas video series, Professional Scrum Trainer Stephanie Ockerman explores the myth that a Daily Scrum is status meeting. Through her discussion, she dives into several areas as to why it the Daily Scrum is much more than a status meeting and how they differ.
Not clear enough for me. Frases like "The daily Scrum helps to promote organization." are to general and end up being empty if there are no concrete examples.
Please tell me if they are there and I missed them.
I understand every word, but in total they don't provide any clear information to me
This sounds too artificially complicated. Just changing the status word to progress doesn't justify the difference.
Stephanie, thank you for this critical message! This is so often overlooked (as you can see in previous replies). The daily scrum has one critical output: an adjusted plan for the next 24 hours. The reason it is not a status update is all of the team members should already know each other's status, because they have been collaborating and working together since the last scrum. I equate it to an NFL team's huddle: after a play they players don't gather in the huddle to report back what just happened, instead they reflect on what happened ("I was open but you missed me") and re-plan for the next down. If we need to update other team members on our 'status' then it's a sign that true collaboration is not happening during the other 23 hours and 45 minutes of the day.
you just made my day... simple, wholly understandable and relatable
wow, great example; hope you don't mind if I use this for my team's !!!
You imagine a development team as a group of people fighting against someone where one of the members works (has the ball) and the others are waiting (for a perfect pass) to be able to achieve the goal, otherwise it's a loss and you have to retry. Whichever team has more successes in a the whole game (sprint) wins.
That's not how SW development works. Sprint backlog tasks are clearly defined and prioritized in advance. Care is taken to put only those tasks into the sprint, that do not block each other (to a level that imposes a risk). Then a team of developers take tasks from a sprint backlog and start working in parallel. Whoever finishes a task takes another one until they are done. There is no enemy to fight. The time needed to finish all tasks has been set based on previous experience (velocity) in a fair manner (unavailability and complexity has been thoroughly analyzed and reflected).
If one of the tasks fails because of impediments there is no failure. The progress towards goal has still been made but has been hampered a little.
The only reason why you'd need to organize developers on a daily basis would be if each task would depend on another and single failure would result in halt in progress, Yet still depends on when it happens it still might mean some progress has been done. Failure to finish a task means spillover to another sprint, however by working on another task from product backlog one can mitigate the negative impact of failed task during a sprint. If each member of the team understands this game there's no need to have scrum meetings unless you neeed to report impediments and I assume waiting until the other day to talk about your problems to the rest of the team is not productive in comparison to immediate discussion and hopefully solution using some team communication tools.
awesome analysis
"give an update on their progress on the tasks they have been working on".
Which is exactly what happens in every daily scrum/standoff/daystart/name your poison I've ever been involved in over the last decade or so, which mostly every day.
What the daily scrum is in theory is a meeting for developers to better work together. What it is in practice is a daily status meeting and the scrum master is usually also the project manager or team lead who uses the information he receives there to judge the individual developers' performance on a daily basis.
The collaboration part is usually shunted off to extra meetings, either daily or weekly, often scheduled well in advance.
It in fact is so bad in many organisations and teams that team members are mortally afraid to report slowdowns and other problems because they almost inevitably lead to sanctions against the team member, anything up to losing their jobs.
I don't get why daily is even needed to be fair. If developers work together during the day and communicate with each other and use project management systems there is no need for one special event where you discuss possible risks for achieving sprint goal. You see risk so you discuss it asap, not during special event. You write it down in the project management system where it makes sense and that's all.
Feels like daily is just a bandaid to fix bad processes
This is a ridiculously common problem in organizations and it's one of the core ideas essential to running scrum effectively. As a result of this, most scrum-based project are highly troubled.
Exactly why this needs to be discussed and shared. It is also why this video has been watched so many times.
Great thoughts...love this shift of mindset from status to collaborative planning session!!
0:50 purpose of daily scrum (from scrum guide)
1:11 what is status meeting
1:40 their differences - daily scrum promotes self organization
2:18 if daily scrum becomes status meeting - accountability and empowerment to make decision falls aside
2:38 daily scrum maximize transparency - adapt info from daily scrum to work towards the sprint goal. vs status meeting - no full story of the progress, not emphasizing the adaptation.
4:00 achieving valuable outcomes - status meeting focuses on what was done (I interpret this as following the planned plan without active thinking), daily scrum focuses on are we achieving the sprint goals and how to adapt to achieve that goal
4:51 daily scrum promotes collaboration - promote situation awareness to focus on shared accountability, in turn increase collaboration. while status meeting focuses on individual contribution.
umm... they sound really similar. part of the elements in status meeting has to be there to achieve what daily scrum aims for
Thanks
Daily scrum meetings are the bane of my existence.
I am sorry to hear that. They don’t have to be they can even be fun and entertaining. It sounds like it may be a facilitation problem not a meeting one.
Not to burst any lingo bubbles here, this sounds like a status meeting in a safe space where the team honestly reports to each other. Beyond the buzzwords there seems to be no difference. Having a status meeting doesn’t eliminate accountability, and I’ve never been in a status meeting where collaboration towards an end goal doesn’t happen. A question this video brings up for me is in what way does the team own and control goals? Goals are set by the business, top down and teams plan accordingly. Teams are always being guided by changes of plan and schedule by business partners or department heads and rarely, if ever able to dictate changes upwards. The general response will be “that’s the due date, get it done.” Maybe someone can clarify what is meant by “ownership.”
The Product Owner is truly enabled and empowered to make decisions by the business. If that doesn't happen, then they do not have ownership. The Scrum Team and specifically the Development Team meet daily to talk about their progress toward the Sprint Goal and their ability to achieve it. They discuss ways to improve/change the process to getting there and anything getting in the way. If "the business" is not bought into the process, the Product Owner and Scrum Master need to work with them to enable them and coach them on why they are working the way that they are working and help them.
You are correct that a "status meeting" doesn't eliminate accountability. The key here is not just talking about the "status" but actually collaborating to update our plan based on our current progress towards the Sprint Goal.
Goals may be set by leadership in the business, however, Scrum Teams themselves determine their Sprint Goal with the greater product vision/ business goals in mind. So it's taking that big picture and determining what is the small thing they can do in the next 1-4 weeks.
Setting deadlines is fine, as long as the business is willing to accept the uncertainty and complexity inherent in software development. If you set a deadline, you must be willing to accept that scope (i.e. the specifics of the features/ functionality delivered) will need to flex. And the business should involve the people who are doing the work in forecasting what's possible in a timeframe. Otherwise, there is likely to be a sacrifice in quality (often without transparency). As a PMP with experience in waterfall project management, I remind leadership of the iron triangle.
This is why Scrum is so often still a traditional status meeting. "The Scrum Team and specifically the Development Team meet daily to talk about their progress toward the Sprint Goal and their ability to achieve it." is not what The Scrum Guide says, or used to say since it continues to shift in this direction with the 2017 November update. A response on a video, regarding the Daily Scrum, despite the first sentence in that section: "The Daily Scrum is a 15-minute time-boxed event for the Development Team", becomes about the Product Owner, and how that role is the key to improving the Development Team. I sincerely believe that since Scrum is not easily embraced in the corporate world, Scrum.org is following the paths of Scrum Alliance and Mountain Goat Software to transform the Scrum framework into another technologist-demeaning methodology.
One key difference here is that a Daily Scrum is not a meeting where the Dev. Team is reporting to a manager what they've done and didn't do. In fact, it's a common mistake for folks both in and outside the Scrum Framework to see the Scrum Master as the manager of the team - they are not. Scrum is about agility and removing impediments to achieve a Sprint Goal, aand of course ultimately, agile product development. Managers are more often impediments than helps. I know, because I used to be one. :)
For example, in Daily Scrums, I coach teams to focus on any impediments to User Stories which may cause the team to miss the Sprint Goals. If there are no impediments, the meeting can close early. Nothing says we must be there for 15 minutes. Alternatively, if there are no impediments, we may discuss BRIEFLY how we can attack one larger User Story as a team over the next 24 hours to move us closer - possibly ahead - of achieving our Sprint Goals.
Remember, Scrum is a Framework within which we can employ various tools to make us leaner (continual Kaizens) in achieving Sprint Goals and supporting Products. It is NOT a process which must be adhered to by the letter of the law confining us to steps which do not bring value to the Product.
in my experience many status meetings (and thus daily scrums or whatever you choose to call them) are more about mudslinging and fingerpointing for delays and problems than anything else, and often (either directly or indirectly) resort in people losing their jobs, being reassigned to lesser tasks, or otherwise punished for "failings", whether they are indeed their failings or the failings of the entire team or organisation for which a black sheep was sought and found.
it’s not a “status” meeting, it’s “inspecting the progress” 🤣🤣🤣🤣
yup, instead of "reporting the status of your progress" it's "reporting the progress of your status".
Thanks for the sharing, it is benefitial to our workflow.
Thanks Stephanie. we started our daily scrum meetings and our meetings are more like daily status meetings. I do see the value of the daily scrum once we are more clear on our goals working as a team instead of individual accomplishments.
Who on the team is in charge of writing users and then who puts it all together
Do both the SM and PO attend the DS?
@@cutflow2yes they all attend
Thanks for this video. great explanation. I liked how you tied the activities back to transparency, inspection and adaption. Will definitely help me guide the teams better!
that is something you should be doing all the time and address it ASAP not until tomorrow at 10:00 am
@@laughingvampire7555 errr thanks ?
all the points of self-accountability and adjustment should be automatic, as soon as you realize you need ti change something & this should be reported to affected people immediately, not wait until next time box for the meeting.
and for status meetings, is meaningless with modern tools because the status should ne kept in software, both the ticket manager and keep a detailed log there of any findings and action items. Or creating new tickets etc.
The concept of a specific moment in time, the appointment is pointless in a daily basis. It should be done for the sprint planning, then per ticket as the team members find something new, and can be done in slack in text format
Well done Stephanie!
Thank you for the message
I see this the other way around ... "Debunking" is not needed. clarification if scrum is "possible" beforehand is often times more needed.
My team does not mind following the stickers on the board, on the basis of which they formed a goal for the sprint with the product owner and everyone tells what progress they have in this matter and whether they need help. Thus, there is both transparency and collaboration. And how to understand if this is a status meeting or a daily scrum?
Great insights.
It is a very important difference. However, the only appearance of the word "accountable" in The Scrum Guide is the Product Owner being accountable for the Product Backlog.
"Individual Development Team members may have specialized skills and areas of focus, but
accountability belongs to the Development Team as a whole".
True that accountability is a noun, and not an adjective.
Thank you so much
Hi Stephanie, great video. If I may make a suggestion, I find on-screen visual cues help me follow along. Just a few persistent bullet points or diagrams to help me reflect.
It is working towards the sprint goal and identifying impediments towards reaching the goal. You do not adapt the sprint backlog as a result of the daily stand ups. The rest of the statements you made are agreeable to me
It is a clear sign when the team does not care about the others, they just give status && they say what will they work on. But everybody does different things. So this is not working for us.
It may not necessarily mean they don't care for the others but rather they are not seeing how their work is connected (as you say they are doing different things). Maybe explore the use of a Sprint Goal to help encourage a shared focus and collaboration. Maybe explore the understanding of the Development Teams shared accountability to create the "Done" Increment.
Why can't I add subtitles?
Thanks. Can I ask a question? As a Scrum Master, what should I be asking development team? "Progress" and "any change of plan" rather than "Status"? Any help will be appreciated. Thanks again.
I like to offer a variety of questions THEY can discuss as a Dev Team during the Daily Scrum, so it doesn't become robotic or as if they are reporting their answers to me. And sometimes different questions will be more relevant for them. Here are several examples: What have we learned since yesterday about our ability to meet the Sprint Goal? What outcomes have we achieved since yesterday that move us towards the Sprint Goal? What can we accomplish in the next 24 hours that will move us towards our Sprint Goal? What do we want to learn in the next 24 hours? What is slowing us down and/ or may put us at risk of meeting the Sprint Goal? On a scale of 1-10, how likely do we feel we are going to meet the Daily Scrum? (And if anyone is less than a certain number - maybe 8 - perhaps that should warrant further discussion).
@@TheSockerman Thank you so much. Let me think about these questions to use them in coming days.
@@TheSockerman those are great questions!
“The daily scrum is an internal meeting for the scrum team”
examples would be great
Guess I'm the only one who noticed "how are THE different" in the transition slides
Great catch, that was a test to see if you were paying attention LOL
Hi there currently working as project coordinator, before I was working in different domain, I am struggling in agile methodologies and scurm can you help out, can you able to guide me how to perform in front of product owner and development team...
Hi Varghese, this question requires a lot more than a single response on RUclips. I would suggest you look at the hundreds of resources available at www.scrum.org/www.scrum.org/resources/what-is-a-scrum-master and look into Scrum Master Training at www.scrum.org/courses/professional-scrum-master-training
Hi @varghese, I formerly worked within a Scrum Team close with the Scrum Master, Product owner and Development team as a Interactions Analyst. I too struggled in the beginning and to me now it probably was due to the fact that I was new to understanding the Development Team's Processes and tools including QA, even at a high level. As an agilist you do not need to understand how to code but rather be a master in the framework as well as having the characteristics of a confident leader who is a servant not a boss. I would suggest focus on assisting the Scrum Master on Agile Scrum Metrics and create data that can support the team's performance sprint by sprint. This means Velocity, Story Cycle Time, Churn, Story Readiness and discuss results with the the team during retrospective as a way of improving your team's performance . I would also suggest chasing down dependencies, impediments and bring results to the team to collaborate during the daily stand up.
Also, I would suggest, spend more time with a Scrum Team to understand the framework
I hope this helps! PS I'm now a Scrum Master for 2 Scrum Teams.
But how do you do it? Please provide an example. Thank you!
There's no one right way, and I encourage people to experiment and change it up. I can offer a few examples. I like the "walk the board" technique because you focus the conversation on the progress of the work/ achieving the Sprint Goal versus individuals taking turns talking. You start on the right side of your Sprint Backlog, assuming you are visualizing on a Scrum Board (i.e what's gotten to Done or made the most progress towards Done) and work your way to the left.
It's also helpful to use guiding questions to stay on purpose, increase transparency to progress, emphasize our shared ownership of the plan and our outcomes. You can make these questions visible, so the Developers can have them in mind as they conduct their Daily Scrum. Examples... What did we learn in the past 24 hours that's important to achieving our Sprint Goal? What is a tangible outcome we can achieve in the next 24 hours that will get us closer to the Sprint Goal? What is our level of confidence we will meet the Sprint Goal? I really like this last question, as it helps us see where Developers may not all be in alignment and can bring up risks that impact what they focus on.
I hope that helps.
@@agilesocks It does. Thank you very much Stephanie.
Does the daily scrum take place in a room that has the boards and all the sticky notes on the board?
typically yes. Or ever more often a room with a large screen showing the digital scrum board.
With the scrum master frowning over every ticket "why isn't this done yet"...
Why can't managers just look at the backlog?
Each issue is set for the day/week.
I don't get this.
They may not know any better. They may be lazy. They may be 'used to' status meetings. They might misunderstand scrum. At my company, it's just inertia. "We've always had status meetings".
These comments are just like my “respond to a students post” when i went to school. PS it blows my mind how many scrum masters shouldn’t actually be scrum masters... like forreal these concepts are that foreign to you? Its not a difficult concept. If your employees are crap thats another thing, other than that the only thing you should be looking for are tasks that are set at high priority and address those. Not difficult to comprehend... its not about what their working on half as much as who ends up getting hired in all honesty. There are some lesser minds who give their 100% and some brilliant minds who give their 20%. Find out which one will end up making a difference... ps it will always be anyone who gives their 100%... every time
This is such a great way to ruin mental health
5 days a week is way too much,..... that's micromanaging. 2 -3 times per week is the right amount
This is not a management meeting in any way. It is a way to work together as a team to inspect and adapt how they are making process toward their Sprint Goal. It is a way to address any issues or concerns and improve their way of working. It doesn’t have to take the full 15 minutes as that is a time box. It allows the team to be cohesive by learning, sharing and improving together.
daily scrum is stressful, all you corporate want profit and dont care about employees health.
Agreed 100%