I've not recognised the significance of the 'moment of glory' until now. I've been one those in the camp that the board should always be up to date. You finish a task, you update the task. If it's left till stand up then people become lazy and it's *always* left till stand up. Every time a card needs to be updated it disrupts the flow while the team wait for the person to update the board. Daily stand up becomes a status meeting of what we did yesterday leaving too little time to talk about what we need to get done today and collaborate on moving things forward. Definitely a balance here. I've been in some teams that established a pattern of glory - if a card has moved columns from where it was yesterday everyone in the team gave a quiet round of applause. No massive celebration, but a celebration nonetheless. It was a little awkward but the team often made a joke or fun out of it, the applause was often started by a different team member each time. An audible recognition of progress may distract other teams in close proximity - even though the applause is kept to a quiet applause as possible - however it's a nice signal to nearby managers and other leaders that the team made progress today. I've also observed teams that had a visual celebration, perhaps stamping the owners hand with a smiley face ink stamp so they have a visual reminder. These mini celebrations may disrupt the flow of the stand up just as much as moving the cards does, but I like that they involve the team celebrating the glory of the person that moved the card, rather than the person moving the card feeling like they are stealing a moment of glory for their own personal ego. My key takeaway was the raising of hands to signal that I am bored and want to move on to the next card. It's too easy for a conversation on blockers to go on too long and nobody wants to interrupt the conversation (because its clearly an important and useful conversation) particularly if one of the speakers is the scrum master or team lead. Raising of hands is a great visual signal to defer the conversation without feeling rude or unsafe by interrupting. Love this tip :-)
@@Developmentthatpays I'm late to the party! One thing we've found is a balance between the two: the Team member updates the story / card before standup to say "hey i'm done" .... with the actual moving of the card to get that SWEET Moment of Glory happening during stand-up .... Also, the raising of hands is a fun and non-threatening way to interrupt the side conversations. Usually the talkers feel kinda sheepish instead of annoyed.
Hi Gary, Thanks for great videos. I have a problem with developers moving cards to 'test' column. This is typical to a push system and not to a pull system... If the 'dev' column will be split to two sub columns: 'dev wip' and 'dev done', then when a developer completes a card he/she will move it from 'dev wip' to 'dev done' and a tester (or any other team member) will be able to pull it when he/she are available to actually work on it. In this case, if the board is a digital board, the team will also have the ability to calculate how much time the cards were in 'wip' lanes versa 'done' lanes and potentially identify areas to improve.
This is a great subject area! The very first Kanban board I every saw was (a) drawn on a role of paper, and (b) had a "buffer zone" in each column. This came oh-so-close to being a solution to the problem you are describing... but the "zone" was on the LEFT of each column: it should have been on the RIGHT of each column - for exactly the reason you stated. It always struck me as unfair that Developers were able to PULL tasks (from the backlog), but Testers weren't given the same courtesy. I think we need an episode on this, don't you?
🎯 Key Takeaways for quick navigation: 00:00 *🛣️ Walking the Board Overview* - Introduction to the concept of "Walking the Board" or "Walking the Wall" in Agile stand-up meetings. - Explanation of the importance of starting stand-up at the top right of the board. - Discussion on the financial and practical reasons for starting at the rightmost side of the board. 01:27 *📊 Stand-Up Progress Review* - Detailed walkthrough of the stand-up process, starting with discussions about specific cards on the board. - Illustration of how team members provide updates on the status of tasks and address any issues or blockers. - Emphasis on the importance of keeping discussions focused and brief during stand-up meetings. 02:48 *🌟 Moments of Glory* - Reflection on the satisfaction of moving cards across the board during stand-up meetings. - Discussion on the significance of allowing team members to move their own cards, adding to their sense of accomplishment. - Exploration of the impact of acknowledging individual achievements and fostering a positive team dynamic. Made with HARPA AI
At 4:44? The fact that they're unassigned means they are not being worked on... which is not ideal. - If testing (for the assigned ticket) doesn't take too long, then the board will soon look better. - If testing (for the assigned ticket) turns out to be lengthy, it would good for the devs to get involved with testing.
I'm with Emtiaz - everything else about your process is really slick, but this either creates a gap or rework discussing who tests it... which undermines the moment of glory a little... could there be a stage to move and applaud progress before starting on the far right? would it work? not sure ... a really great video as always, thank you :)
Yeap, first thing that stroke me. I was really considering using the video with my teams, but I would confuse them with that Test column! You have two people finishing development. Those two should switch tasks and stand up to test, before picking anything else. www.innolution.com/resources/glossary/swarming
Pass the baton (or three question format) is definitely poor. Walking the board is an improvement. However a true discussion is ideal. Having a Development Team member "lead" the Daily Scrum and "moments of glory" are tricky areas. The former is less an issue if the team simply discusses the work to achieve the purpose of the event. The later is a matter of team versus group of individuals and collaboration. What if a team member is unexpectedly absent? Who/How/When is that card moved? By communicating and updating the board frequently, the team is encouraged to share the knowledge and collaborate on activities throughout the day. If the Daily Scrum is the primary (or ONLY) internal update, then there are serious problems. Development Teams may need gestures to signal pausing a detailed conversation, but a mature team should easily be able to quickly identify and communicate that need.
Good comments all. 1. You're not the first to question "moments of glory": I think it's one I need to reconsider. As you said, bad things can happen when the board is out of date. 2. Can you say more about having a "true discussion" during standup? I would have thought that this would (a) be boring for the rest of the team, and (b) lead to over-long standups. Would be keen hear how you're managed this in your teams.
Personal achievement and satisfaction as a human need cannot be ignored. If the Development Team can appropriately manage the work in a collaborative manner then it might not be an issue. I'm certainly not saying it is wrong to update a board at that time only, just that as a coach one needs to be aware of the risk of doing so. It is important to have a team attitude over personal ego. Recognition and feed-forward need to be issued in the same manner. In the Scrum framework, the Daily Scrum is for the Development Team; observers welcome but it is not for others' desires. Since they are the ones performing the work and collectively accountable for the increment, it is generally easy for them to simply discuss progress and make their plan for the day. I am uncertain who you think would be bored. If there are small groups talking or individuals feeling outside of the conversation, then it is indication of sub-teams and/or a lack of collaboration which would need to be addressed via the Sprint Retrospective. Keeping the discussion focused on its purpose to maintain the time-box is important. Initially Development Teams may have issues with it; in my experience, they quickly learn how to identify and curtail excessive discussions. There is no management of the Daily Scrum by the Scrum Master. Violations, concerns, ideas for improvements, etc. are shared in order for the Development Team to improve. However, if they effectively achieve the purpose of the event and deliver Done increments consistently, there is no need for inserting oneself.
Think you're just written the script for three (or more!) future videos! Very interested on what you said about team members being bored during standup. It reminded me of something I read recently about the importance of creating "end to end" features; the idea being that such features would require multiple skills (e.g., front end, back end)... which would require the "alignment" that Daily Stand-up could provide. Have you come across that notion before?
Glad to watch and collaborate! "Vertical slicing" is a common term for stories (or whatever method used) to make items as small as possible and provide complete functionality. Don't separate based on technical layers (API, UI, BL, DB, etc), but rather small end-to-end features. A Team shouldn't Review persistent storage or a button without function or business rule enforcement alone. At the end of each Sprint a complete, usable, tested Increment is created. Boredom, or other lack of conversation (i.e. status reports), are often indicative of a lack of collaboration. If each Development Team member is working in isolation, there are multiple opportunities missed including shared knowledge and peer review. Pair programming is good technique to help promote collaboration and a Daily Scrum which is more conversation driven.
About walking the done column... When walking the done column every day do you just only talk about the done stuff that was not already talked about or do you rehash every done task every day?
I love this and we have been using it to great effect however, it does seem to make the teams focus more on the work on the board, to the detriment of focussing on the Sprint Goal and the tickets/Stories as secondry in importance. I wonder what other peoples views are on this?
@@Developmentthatpays No replies yet - fingers and toes still crossed. Amazing videos by the way - are so useful for helping people undertand concepts and ideas as everyone is happy to watcha 5min fun animated vid
@@WHEATLEY007 - Okay, I'll dive in! A criticism leveled at the approach is that it puts work ahead of the individual. But I haven't heard this particular criticism. I would have thought that the Sprint Goal is best served by getting the work done? Can you say more about your concerns?
According to the Scrum Guide (2020 version), the purpose of the Daily Scrum is to inspect progress towards the Sprint Goal, while allowing to adapt the Sprint Backlog, adjust the upcoming planned work, and produce an actionable plan for the next day of work. This model is indeed missing some important points for the Daily Scrum: - We do not inspect the Sprint Goal, and thus cannot know whether the work in progress and the work done is taking us to it, and we certainly do not adapt. - We do not have as well an actionable plan for the next day of work, even though each person has an assigned ticket at the end of the meeting. Something I figure could be added to improve this model is to add a "non-actionable ticket," which contains the Sprint Goal and the delivery plan, both made at the Sprint Planning event, to the Sprint Backlog. We can then begin the meeting by grabbing the item and quickly revisiting the Sprint Goal. We then proceed with the meeting as stated in the video, but after revising each ticket, we also check the plan and verify which step of the plan this ticket is getting done. We mark each completed step as "done," each step in progress as "In progress," and each pending step as "to do." After revising all the items on the board and assigning work to those that do not have it, we can revise the plan and see how far are we from the Sprint Goal, and make modifications to the plan accordingly. At the end of the meeting, each team member has to come up with a plan for his/her work for the day. The meeting should end with the "What else?" question. Regarding "putting work ahead of the individual," I think this is a "good thing", as this model allows to remove responsibility from the individual and put it on the Team, as everyone can hear the progress of the item and allow the Team to help the individual in case of a problem, which is one thing Scrum aims to facilitate. I am new to Scrum, and still trying to figure out how it works, and which tools I can use and could work the best. So, thanks for the videos, they are really helpful.
Why did Tim wait until the standup to talk to Kevin about the problem with testing? Those kind of discussions should happen in real-time, not waiting until the next day to bring it up.
You're right: the conversations should happen real time. But just because something should happen doesn't mean that it does. Especially where developers are concerned. PS: I'm a developer.
How do suggest to approach walking the board when all your tickets are in Jira or VSTS (digital board) do you recommend having two versions? digital & physical?
The answer is... it depends: - If all members of the team are co-located, having both a physical board and a digital board is... possible. - If the members of the team are distributed, it's more difficult to have both a physical board and a digital board But even if you're "stuck" with a digital board, it's still possible to "walk the board". A large TV display helps (and yes, I do put my finger prints all over it!).
@@Developmentthatpays Even without the "doing"/"done" inner columns for Dev/Test/Release? And it seemed like things were being "pushed" instead of "pulled" in their 'moment of glory'. I'm also confused how the 'blocked task' fits in with a Kanban board. Are we allowing more cards beyond our 'limit' in a column then? is the "Blocked" task a bonus slot? How many can we have 'Blocked'? Why did we pull it into "DEV" if it was blocked? Or are we just saying the DEV priority changed after we started on it and got stuck?
I've not recognised the significance of the 'moment of glory' until now. I've been one those in the camp that the board should always be up to date. You finish a task, you update the task. If it's left till stand up then people become lazy and it's *always* left till stand up. Every time a card needs to be updated it disrupts the flow while the team wait for the person to update the board. Daily stand up becomes a status meeting of what we did yesterday leaving too little time to talk about what we need to get done today and collaborate on moving things forward.
Definitely a balance here. I've been in some teams that established a pattern of glory - if a card has moved columns from where it was yesterday everyone in the team gave a quiet round of applause. No massive celebration, but a celebration nonetheless. It was a little awkward but the team often made a joke or fun out of it, the applause was often started by a different team member each time. An audible recognition of progress may distract other teams in close proximity - even though the applause is kept to a quiet applause as possible - however it's a nice signal to nearby managers and other leaders that the team made progress today.
I've also observed teams that had a visual celebration, perhaps stamping the owners hand with a smiley face ink stamp so they have a visual reminder.
These mini celebrations may disrupt the flow of the stand up just as much as moving the cards does, but I like that they involve the team celebrating the glory of the person that moved the card, rather than the person moving the card feeling like they are stealing a moment of glory for their own personal ego.
My key takeaway was the raising of hands to signal that I am bored and want to move on to the next card. It's too easy for a conversation on blockers to go on too long and nobody wants to interrupt the conversation (because its clearly an important and useful conversation) particularly if one of the speakers is the scrum master or team lead. Raising of hands is a great visual signal to defer the conversation without feeling rude or unsafe by interrupting. Love this tip :-)
I go back and forth on the whole Moments of Glory thing. As you said, bad things can happen when a board is out of date...
@@Developmentthatpays I'm late to the party! One thing we've found is a balance between the two: the Team member updates the story / card before standup to say "hey i'm done" .... with the actual moving of the card to get that SWEET Moment of Glory happening during stand-up .... Also, the raising of hands is a fun and non-threatening way to interrupt the side conversations. Usually the talkers feel kinda sheepish instead of annoyed.
Hi Gary,
Thanks for great videos.
I have a problem with developers moving cards to 'test' column. This is typical to a push system and not to a pull system...
If the 'dev' column will be split to two sub columns: 'dev wip' and 'dev done', then when a developer completes a card he/she will move it from 'dev wip' to 'dev done' and a tester (or any other team member) will be able to pull it when he/she are available to actually work on it.
In this case, if the board is a digital board, the team will also have the ability to calculate how much time the cards were in 'wip' lanes versa 'done' lanes and potentially identify areas to improve.
This is a great subject area!
The very first Kanban board I every saw was (a) drawn on a role of paper, and (b) had a "buffer zone" in each column. This came oh-so-close to being a solution to the problem you are describing... but the "zone" was on the LEFT of each column: it should have been on the RIGHT of each column - for exactly the reason you stated.
It always struck me as unfair that Developers were able to PULL tasks (from the backlog), but Testers weren't given the same courtesy.
I think we need an episode on this, don't you?
🎯 Key Takeaways for quick navigation:
00:00 *🛣️ Walking the Board Overview*
- Introduction to the concept of "Walking the Board" or "Walking the Wall" in Agile stand-up meetings.
- Explanation of the importance of starting stand-up at the top right of the board.
- Discussion on the financial and practical reasons for starting at the rightmost side of the board.
01:27 *📊 Stand-Up Progress Review*
- Detailed walkthrough of the stand-up process, starting with discussions about specific cards on the board.
- Illustration of how team members provide updates on the status of tasks and address any issues or blockers.
- Emphasis on the importance of keeping discussions focused and brief during stand-up meetings.
02:48 *🌟 Moments of Glory*
- Reflection on the satisfaction of moving cards across the board during stand-up meetings.
- Discussion on the significance of allowing team members to move their own cards, adding to their sense of accomplishment.
- Exploration of the impact of acknowledging individual achievements and fostering a positive team dynamic.
Made with HARPA AI
Wow. That might be the first AI-assisted comment on the channel :)
So much helpful information for today.
Thank you so much
You're most welcome!
Thanks, Gary for this insightful video
Really clear. Fun video. Thanks.
You're welcome!
Great vid as always. Very useful technique and an enjoyable presentation styje
was Sarah fired from the previous video?
hey Gary,
what about the 2 other unassigned cards in Test column?
At 4:44? The fact that they're unassigned means they are not being worked on... which is not ideal.
- If testing (for the assigned ticket) doesn't take too long, then the board will soon look better.
- If testing (for the assigned ticket) turns out to be lengthy, it would good for the devs to get involved with testing.
I'm with Emtiaz - everything else about your process is really slick, but this either creates a gap or rework discussing who tests it... which undermines the moment of glory a little... could there be a stage to move and applaud progress before starting on the far right? would it work? not sure ... a really great video as always, thank you :)
I think you're both right. I'm going to have to re-visit this one.
Yeap, first thing that stroke me. I was really considering using the video with my teams, but I would confuse them with that Test column! You have two people finishing development. Those two should switch tasks and stand up to test, before picking anything else. www.innolution.com/resources/glossary/swarming
Pass the baton (or three question format) is definitely poor. Walking the board is an improvement. However a true discussion is ideal.
Having a Development Team member "lead" the Daily Scrum and "moments of glory" are tricky areas. The former is less an issue if the team simply discusses the work to achieve the purpose of the event. The later is a matter of team versus group of individuals and collaboration.
What if a team member is unexpectedly absent? Who/How/When is that card moved? By communicating and updating the board frequently, the team is encouraged to share the knowledge and collaborate on activities throughout the day. If the Daily Scrum is the primary (or ONLY) internal update, then there are serious problems.
Development Teams may need gestures to signal pausing a detailed conversation, but a mature team should easily be able to quickly identify and communicate that need.
Good comments all.
1. You're not the first to question "moments of glory": I think it's one I need to reconsider. As you said, bad things can happen when the board is out of date.
2. Can you say more about having a "true discussion" during standup? I would have thought that this would (a) be boring for the rest of the team, and (b) lead to over-long standups. Would be keen hear how you're managed this in your teams.
Personal achievement and satisfaction as a human need cannot be ignored. If the Development Team can appropriately manage the work in a collaborative manner then it might not be an issue. I'm certainly not saying it is wrong to update a board at that time only, just that as a coach one needs to be aware of the risk of doing so. It is important to have a team attitude over personal ego. Recognition and feed-forward need to be issued in the same manner.
In the Scrum framework, the Daily Scrum is for the Development Team; observers welcome but it is not for others' desires. Since they are the ones performing the work and collectively accountable for the increment, it is generally easy for them to simply discuss progress and make their plan for the day.
I am uncertain who you think would be bored. If there are small groups talking or individuals feeling outside of the conversation, then it is indication of sub-teams and/or a lack of collaboration which would need to be addressed via the Sprint Retrospective.
Keeping the discussion focused on its purpose to maintain the time-box is important. Initially Development Teams may have issues with it; in my experience, they quickly learn how to identify and curtail excessive discussions.
There is no management of the Daily Scrum by the Scrum Master. Violations, concerns, ideas for improvements, etc. are shared in order for the Development Team to improve. However, if they effectively achieve the purpose of the event and deliver Done increments consistently, there is no need for inserting oneself.
Think you're just written the script for three (or more!) future videos!
Very interested on what you said about team members being bored during standup. It reminded me of something I read recently about the importance of creating "end to end" features; the idea being that such features would require multiple skills (e.g., front end, back end)... which would require the "alignment" that Daily Stand-up could provide. Have you come across that notion before?
Glad to watch and collaborate!
"Vertical slicing" is a common term for stories (or whatever method used) to make items as small as possible and provide complete functionality. Don't separate based on technical layers (API, UI, BL, DB, etc), but rather small end-to-end features. A Team shouldn't Review persistent storage or a button without function or business rule enforcement alone. At the end of each Sprint a complete, usable, tested Increment is created.
Boredom, or other lack of conversation (i.e. status reports), are often indicative of a lack of collaboration. If each Development Team member is working in isolation, there are multiple opportunities missed including shared knowledge and peer review.
Pair programming is good technique to help promote collaboration and a Daily Scrum which is more conversation driven.
About walking the done column... When walking the done column every day do you just only talk about the done stuff that was not already talked about or do you rehash every done task every day?
I don't walk the Done column: I start at the last column _before_ the Done column.
@@Developmentthatpays Ok good to know. Thanks
I love this and we have been using it to great effect however, it does seem to make the teams focus more on the work on the board, to the detriment of focussing on the Sprint Goal and the tickets/Stories as secondry in importance. I wonder what other peoples views are on this?
That is a great question - I hope others reply.
@@Developmentthatpays No replies yet - fingers and toes still crossed. Amazing videos by the way - are so useful for helping people undertand concepts and ideas as everyone is happy to watcha 5min fun animated vid
@@WHEATLEY007 - Okay, I'll dive in! A criticism leveled at the approach is that it puts work ahead of the individual. But I haven't heard this particular criticism. I would have thought that the Sprint Goal is best served by getting the work done? Can you say more about your concerns?
According to the Scrum Guide (2020 version), the purpose of the Daily Scrum is to inspect progress towards the Sprint Goal, while allowing to adapt the Sprint Backlog, adjust the upcoming planned work, and produce an actionable plan for the next day of work. This model is indeed missing some important points for the Daily Scrum:
- We do not inspect the Sprint Goal, and thus cannot know whether the work in progress and the work done is taking us to it, and we certainly do not adapt.
- We do not have as well an actionable plan for the next day of work, even though each person has an assigned ticket at the end of the meeting.
Something I figure could be added to improve this model is to add a "non-actionable ticket," which contains the Sprint Goal and the delivery plan, both made at the Sprint Planning event, to the Sprint Backlog. We can then begin the meeting by grabbing the item and quickly revisiting the Sprint Goal. We then proceed with the meeting as stated in the video, but after revising each ticket, we also check the plan and verify which step of the plan this ticket is getting done. We mark each completed step as "done," each step in progress as "In progress," and each pending step as "to do." After revising all the items on the board and assigning work to those that do not have it, we can revise the plan and see how far are we from the Sprint Goal, and make modifications to the plan accordingly. At the end of the meeting, each team member has to come up with a plan for his/her work for the day. The meeting should end with the "What else?" question.
Regarding "putting work ahead of the individual," I think this is a "good thing", as this model allows to remove responsibility from the individual and put it on the Team, as everyone can hear the progress of the item and allow the Team to help the individual in case of a problem, which is one thing Scrum aims to facilitate.
I am new to Scrum, and still trying to figure out how it works, and which tools I can use and could work the best. So, thanks for the videos, they are really helpful.
Why did Tim wait until the standup to talk to Kevin about the problem with testing? Those kind of discussions should happen in real-time, not waiting until the next day to bring it up.
You're right: the conversations should happen real time. But just because something should happen doesn't mean that it does. Especially where developers are concerned. PS: I'm a developer.
How do suggest to approach walking the board when all your tickets are in Jira or VSTS (digital board) do you recommend having two versions? digital & physical?
The answer is... it depends:
- If all members of the team are co-located, having both a physical board and a digital board is... possible.
- If the members of the team are distributed, it's more difficult to have both a physical board and a digital board
But even if you're "stuck" with a digital board, it's still possible to "walk the board". A large TV display helps (and yes, I do put my finger prints all over it!).
so true
👍
Best ways to do this with larger teams?
Split the team! Agile - in my experience - doesn't really work when the team count exceeds 7 or so.
Where can I find the previous episode?
Here's a link: ua-cam.com/video/H02BlTXpcto/v-deo.html
Thank you, so much! I really, really like your videos - fun, light, but informative - great for beginners like me! Keep up the good work :)
Thank you very much!
is this different than a kanban board?
No: identical to a kanban board.
@@Developmentthatpays Even without the "doing"/"done" inner columns for Dev/Test/Release?
And it seemed like things were being "pushed" instead of "pulled" in their 'moment of glory'.
I'm also confused how the 'blocked task' fits in with a Kanban board. Are we allowing more cards beyond our 'limit' in a column then? is the "Blocked" task a bonus slot? How many can we have 'Blocked'?
Why did we pull it into "DEV" if it was blocked? Or are we just saying the DEV priority changed after we started on it and got stuck?