With regards to turning on the camera: What about introverts (lots of them in IT I think?) who are more comfortable to speak up when they are not looked at by everyone. In my experience I have noticed introverted colleagues speaking up more using the chat or voice in a meeting when people don't see their face. A lot of camera meetings are also exhausting for introverts. I think this is an often overlooked benefit. It's a small one but having the camera on so you can detect that someone is not focused or see a facial expression is also a small one. I leave the choice for each individual in my team and that seems to work fine. Sometimes they turn on the camera and sometimes they don't.
If conversations get heated it should be mandatory to switch camera on. People tend to pull back and become professionally conscious when talking to a face and exposing their face. Suddenly you see a human on the other side. For all other times, no need to switch it on.
If people in the Meeting are too shy to share their opinion, the manager has the figure out why that is and what needs to change for them to feel comfortable too. Not participating is not working
I see your point about letting the team decide, but my job as a facilitator is very difficult if I cannot see people's reactions. Plus what do people do in meetings IRL? There is no option to hide in them.
I leave my camera off, and my microphone, and I’m usually doing something else… because retros are usually a waste of time for me. Usually because we’re doing them just because we feel we should, not because there’s much actionable stuff to discuss. Maybe I should bring this up in my next retro ;)
@@ainocorry3004 and this is why retros are a waste of time. "hey, we want the cameras off" "i don't prefer it and in another context, you'd have no choice, so too bad" "umm, ok, lets spend the next half hour talking about what we 'want to change' i guess"
Recently overhauled how my team did retros after watching your vid from few weeks ago on the topic and reading your book. Some really good stuff in there. I’ve discovered it’s not easy being a good facilitator, but using the round robin technique helped a ton in getting team more engaged
I have to hold my tongue in retrospectives. One of my obvious things we should stop doing is retrospectives. But I cannot put that on the list. If there is a problem, fix it. If you need to chat with others about it, do so. But having it on the calendar every sprint shows a low value for people's time.
I agree with you. If you’re doing agile then agile applies to itself, which means learn and adapt quickly. A well integrated team, and I see it daily, changes whenever a problem arises they can influence. They raise the other ones with me, and I will try to solve those.
100% agree. 90% If it can be solved or there's will to solved then management would have solved it already. Also, Retros every 2-weeks is way too much as there's not to much to learn from and absorb in a 2 week period and too much overhead around it. But Agilists are unwilling to apply Agile to their own rituals and therefore not willing to learn and adapt
For the retrospectives I've been in, there are two core problems: 1. The changes that would have a significant impact is outside of the control of anyone in the team. If it was controllable by the team, it would have been changed already. Don't need to wait for a retro for that. 2. Process-related changes have a very minor impact on team progress. Individual contributors make a large difference. Organization and managerial decisions make a large difference. Tweaking some team process every 2 weeks generally doesn't make a difference. It is not that they are a waste of time; they are counterproductive. It causes the team to be more frustrated than anything.
Yes, sometimes outside the team but if you bring it up on the retro you are supposed to get help reaching and affecting the teams that could change it.
@@krumbergify Generally, the problems that impact the development team are caused by management. And generally, this is considered non-negotiable. So either it is a meeting complaining about management or a meeting talking about things that don't matter. Not that there ever isn't a problem the team can address. They just are less frequent than every sprint and something people work out without a ceremony.
Thanks for sharing. I can largely relate. Individual contribution is often far more impactful than process changes unless your process is extremely inefficient. Small incremental improvements should still be possible though.
Retro effectiveness depends 50% on how well the scrum master / manager is, 20% on team's openness to feedback, 20% on trust and 10% on the individual's motivation to improve themselves and the team.
@@zshn You're putting percentages on 'retro effectiveness'. I'm a software engineer, I would rather focus on real work than nonsense used to justify useless job positions.
@@Pat315 I'm a software engineer and % are not meant to be taken literally. We know agile exists only so that managers feel important and look intelligent. Read again and you'll understand what I mean. Because it depends heavily on the manager, retros effectiveness is a coin toss.
That mirrors my experience of retrospectives very well, and the difference between a successful and an indifferent or even destructive retrospective rests in the hands of the moderator, especially if there are conflicts within the team. Moderating a retrospective well is hard work and just reading a book and going through the motions won´t cut the mustard. The best moderator I had was an agile coach who gave everyone had a chance to speak, helped us work towards measures everyone could agree on, and most importantly asked the pointed and sometimes painful but necessary questions. The worst ones I have had were either effectively unmoderated and in which two team members had opposing view, and it became an argument between the two of them with nobody else getting a word in edgeways, or they were moderated by a team member who had their agenda and used the retrospective to push that through. Neither meeting deserves the title "respective" in any way. The other thing that a successful retrospective requires is a team in which most if not all of the team has a genuine desire to improve themselves and their teamwork. Most people I've worked with in software development have this desire, and even if one team member thinks they're perfect, they still have to "explain" their views in a retrospective which will at least lead to a discussion. And finally there have been retrospectives in which all present team members have been genuinely happy with the team. In that case we just cut the meeting short, and got on with our work, but a regular "check-in" is still necessary to make sure we haven't missed something that is bothering a particular team member. Thanks a lot!
Yes, indeed. It is simple, but not easy to do well. And a lot of people have only tried a retrospective that was not facilitated well, and those ARE a waste of time.
I learned that you didn't use a script for that video from your LinkedIn post. Well. I can see the difference, and it's for good. You move more naturally and look like you're talking to us on a casual conversation, which is great to create connection. Congratulations on doing an amazing job and showing mastery of the subject even using minimal scaffolding.
This all works very well in practice if you have an engaged team...the buy in needs to be by everyone. Reading the comments, I feel I'm in a rare situation where this is the case. Thank you for this video, this will really help to keep improving.
Use a wade matrix and create simple action points either to do or to escalate. If it's too big for an action point, put it in a jira ticket and prioritise it like normal work.
I am not yet sure there are any learnings from retrospectives unless the team’s output is a repetitive labour. Usually the sprint work changes, the complexities change, the effort required changes, the requirements should change. Programmers should switch their brains from being stubborn creatures into very flexible humans where no changes are actually an issue. If you need a retrospective you lost it. The goals should be appealing enough to make everybody speak up, adapt and be pragmatic all the time.
Great thinking and advice. I was talking with an agile coach yesterday that there was frustration at the end of retro. 1 things we were frustrated with but didn’t not know how to word as action to change it (as eg “how do you write better def of done” rather than know what is not) 2 that the team needs to know what they can change and often it is so small that it does need maybe 3+ sprints to start to see change when if a project is not long enough you don’t see effects- plus issues team can not the scrum master should raise higher up I believe
Not good! Take the section on pull requests, for example. If people do not want to do pull requests, more training is not the answer. As Farley showed in a previous video, pull requests are a horrendously bad idea. I have measured how much time work spend waiting for pull requests, and it can easily be 50% of the total cycle time. There are far better ways to review code. Pair-Programming, for example. The advice to have cameras on all the time, also not great. Videoconferencing is tiring for the human brain. Check out neuroscientist John Medina's book Brain Rules for Work. People hate the cameras for good reason, so do not force them to use them. Also, the content does not match the title. The title is just clickbait.
Well, I am using the examples that people talk about in the retrospectives, and they mention these issues. I am trying to make a point about whether people solve the underlying cause or remove the symptoms. Also, yes to the fact about being on video all day in meetings. But don't let it become an excuse for never being on video in meetings. Retrospectives work best if people can see each other, in my experience.
What does he say specifically in his book about cameras? I am very curious on this... Can you pinpoint the exact quote or page n. where the subject is approached, please?
@@Sergio_Loureiro besides the fact cameras meeting consume lots of bandwidth, therefore lousy voice quality and resulting in poor communication having to ask many times to repeat. Cameras are draining for the human brain. You are too self aware of the posture, face etc. Besides that is very difficult to stop looking at others and yourself on a small frame. This doesn't happen in a natural real life interaction because and the others don't have to keep on that small frame, don't have to pretend to smile all the time and have room for natural movements and manners
@@errrzarrr Thanks for your input. But I am really interested on what that book says. I am natural averse to being filmed or photographed, and I want to check from credited researchers whether my intuition it does more harm than good is correct or not. I value your comment, but I need some scientific source for this, not just a random comment on TH-cam.
Waiting on pull requests? Sounds like form of gatekeeping, a nice tool for people who want to exaggerate how busy they are. Just run automated regression testing on your local development machine and merge it. it's not like you're irrevocably crossing the Rubicon with no way to undo things.
Expressing our concerns about issues beyond our control is beneficial for enhancing our psychological safety. While we cannot eliminate these issues entirely, we can openly discuss our frustrations and seek workarounds. That is not a waste of time 😊
I find all of the agile ceremonies a bit boring, but retrospectives are the best part of Scrum. A specific window purely for systemic and continuous improvement. What’s not to love?
Perhaps the most important one should be 'Be open to feedback.' Most teams and individuals especially non-technical managers & hands-off technical leaders don't know how to handle feedback. Secondly should be 'Pick your battles'. Acknowledge that part of team work and trust building is when people compensate for the short comings of others. If you stop acknowledging that or taking it for granted, you will have a very disengaged and silent retro.
Just like anything we do a retro needs to justify its value, if it's not creating a measurable impact on the company then stop doing it until you have a reason to do it. Also why wait for a retro if you can change and realise the impact right now, surely this is the essence of agile.
To me retrospectives have become a waste of time when it's just either a session where people pat each other on the back saying what great work they did on this and that, or if they keep listing items they would like to change, but the individuals or team doesn't have the power to change them. Or if they just complain about things that happened on the last sprint, but nobody wants to do anything about it. Our team has a pretty good retrospective, but I can't recall a single thing that the team has done in the name of continuous improvement. It's just been about "Well this should change, but we can't change the entire process because others rely on it too". Retrospectives require the team to actually work as a team, and to have autonomy to dictate how they work.
13 - Add an extra retro (squared) session for reviewing the last 3 or 4 retros. Sort of meta retro. 14- Add an extra retro (cubed) session for reviewing the last 3 or 4 retro-squared. Sort of meta meta-retro. 15, 16..... do you get it?
@@ainocorry3004 I'm not handing out advice but nothing against the individual in the video, I just have problems with the role itself for the obvious reason of wtf do they know
Do other non-software industries uses Agile really? Is it possible that Agile (and so called agilists) make a living thanks to the lack of standards in software development, even promoting the idea that each team must design its own methodology and find its own way?
Retrospectives are used outside of agile. They were used in medicine and in military long before the term "retrospective" was coined in software development. They idea was initially taken from those fields and made to fit in, first in long-term projects with waterfall and later in agile settings. In other fields they are called something else, but they are non-blaming, cause-finding, learning together sessions. If by "agile" you mean "Scrum" then I think people have started using it outside software, I am currently using it in a hardware research and design setting. If by "agile" you mean the principles, and things like pair work and daily interactions it is used in many industries. Healthcare, between pilots, etc. Basically "inspect and adapt", which is useful everywhere I think.
@@ainocorry3004 Yeah but thats not what the title says. I expected a video, where you point out why a retrospective is not necessary or a waste of time. But you only said, that it could be a waste of time under some circumstances. Everything can be a wast of time, if its not facilitated well: sprint planning, daily, programming, .. Your video was good, also the listed points in the video. But the title is misleading, which is not necessary.
retrospectives are only to conclude that we need make our communication better, because is the only thing that will not make anyone look bad for pointing, and everyone agrees with it, every 2 weeks an hour lost to conclude this hahahahahah
Also, every 2 weeks is too much overhead. There's not too much to happen from on a 2-week basis, let time pass and absorb the experience and *LEARN.* Every 2 weeks is obsessive , more like being a control freak.
Wow this video is really terrible to watch. The words "allow them," used repeatedly is exactly what's wrong with this SCRUM thing. Businesses wanting all these ways to control their staff who never needed controlling. And calling people "loud mouths" repeatedly is incredibly disrespectful. Saying they "contaminate the others." What is this and why is it on Dave Farley's channel? Hard no.
I the Army we did after action reviews. AAR is opportunity to learn. Not a waste of time. Reflective thinkers need to speed up, or just kick them from the team. No time for slow pokes.
Turn the camera on? But how will I multitask? Meetings are the only time I'm not interrupted and can get work done.
😂
LOL so true my friend
Then schedule meetings that are intended to do your focus time work. I literally call them important Focus Time Meetings.
True!
With regards to turning on the camera: What about introverts (lots of them in IT I think?) who are more comfortable to speak up when they are not looked at by everyone. In my experience I have noticed introverted colleagues speaking up more using the chat or voice in a meeting when people don't see their face. A lot of camera meetings are also exhausting for introverts. I think this is an often overlooked benefit. It's a small one but having the camera on so you can detect that someone is not focused or see a facial expression is also a small one. I leave the choice for each individual in my team and that seems to work fine. Sometimes they turn on the camera and sometimes they don't.
If it works fine for you then by all means keep it up! In my experience a retrospective is better if people can see each other's reactions.
If conversations get heated it should be mandatory to switch camera on. People tend to pull back and become professionally conscious when talking to a face and exposing their face. Suddenly you see a human on the other side.
For all other times, no need to switch it on.
If people in the Meeting are too shy to share their opinion, the manager has the figure out why that is and what needs to change for them to feel comfortable too. Not participating is not working
@@Duskdown They are less shy to share their opinion when their camera is off, that's the point.
Unfortunately people abuse the fact people can't see them and they do work rather than listening
Don't be super obsessed about the camera. If people feel interrogated, this meeting has failed its purpose. Let the team decide on this topic.
I see your point about letting the team decide, but my job as a facilitator is very difficult if I cannot see people's reactions. Plus what do people do in meetings IRL? There is no option to hide in them.
I leave my camera off, and my microphone, and I’m usually doing something else… because retros are usually a waste of time for me. Usually because we’re doing them just because we feel we should, not because there’s much actionable stuff to discuss. Maybe I should bring this up in my next retro ;)
@@ainocorry3004 and this is why retros are a waste of time.
"hey, we want the cameras off"
"i don't prefer it and in another context, you'd have no choice, so too bad"
"umm, ok, lets spend the next half hour talking about what we 'want to change' i guess"
@@ainocorry3004 Why be so inquisitive about it?. Acting like that You are turning a _MEANS_ into an _end._
No doubt why they call it a *Cult.*
Recently overhauled how my team did retros after watching your vid from few weeks ago on the topic and reading your book. Some really good stuff in there. I’ve discovered it’s not easy being a good facilitator, but using the round robin technique helped a ton in getting team more engaged
Great! Happy to hear it helps:)
I have to hold my tongue in retrospectives. One of my obvious things we should stop doing is retrospectives. But I cannot put that on the list. If there is a problem, fix it. If you need to chat with others about it, do so. But having it on the calendar every sprint shows a low value for people's time.
I agree with you. If you’re doing agile then agile applies to itself, which means learn and adapt quickly. A well integrated team, and I see it daily, changes whenever a problem arises they can influence. They raise the other ones with me, and I will try to solve those.
100% agree. 90% If it can be solved or there's will to solved then management would have solved it already.
Also, Retros every 2-weeks is way too much as there's not to much to learn from and absorb in a 2 week period and too much overhead around it.
But Agilists are unwilling to apply Agile to their own rituals and therefore not willing to learn and adapt
For the retrospectives I've been in, there are two core problems: 1. The changes that would have a significant impact is outside of the control of anyone in the team. If it was controllable by the team, it would have been changed already. Don't need to wait for a retro for that. 2. Process-related changes have a very minor impact on team progress. Individual contributors make a large difference. Organization and managerial decisions make a large difference. Tweaking some team process every 2 weeks generally doesn't make a difference. It is not that they are a waste of time; they are counterproductive. It causes the team to be more frustrated than anything.
I am sorry to hear that...
Yes, sometimes outside the team but if you bring it up on the retro you are supposed to get help reaching and affecting the teams that could change it.
@@krumbergify Generally, the problems that impact the development team are caused by management. And generally, this is considered non-negotiable. So either it is a meeting complaining about management or a meeting talking about things that don't matter. Not that there ever isn't a problem the team can address. They just are less frequent than every sprint and something people work out without a ceremony.
@@username7763 I understand. In that case I suggest some radical engineering th-cam.com/video/ady2mUIQpt4/w-d-xo.htmlfeature=shared
Thanks for sharing. I can largely relate. Individual contribution is often far more impactful than process changes unless your process is extremely inefficient. Small incremental improvements should still be possible though.
Retro effectiveness depends 50% on how well the scrum master / manager is, 20% on team's openness to feedback, 20% on trust and 10% on the individual's motivation to improve themselves and the team.
Such a boring comment you must be a scrum master or just good at sarcasm.
@@Pat315 And you must be unemployed or really "fun" to work with.
@@zshn You're putting percentages on 'retro effectiveness'.
I'm a software engineer, I would rather focus on real work than nonsense used to justify useless job positions.
@@Pat315 I'm a software engineer and % are not meant to be taken literally. We know agile exists only so that managers feel important and look intelligent. Read again and you'll understand what I mean. Because it depends heavily on the manager, retros effectiveness is a coin toss.
That mirrors my experience of retrospectives very well, and the difference between a successful and an indifferent or even destructive retrospective rests in the hands of the moderator, especially if there are conflicts within the team.
Moderating a retrospective well is hard work and just reading a book and going through the motions won´t cut the mustard. The best moderator I had was an agile coach who gave everyone had a chance to speak, helped us work towards measures everyone could agree on, and most importantly asked the pointed and sometimes painful but necessary questions. The worst ones I have had were either effectively unmoderated and in which two team members had opposing view, and it became an argument between the two of them with nobody else getting a word in edgeways, or they were moderated by a team member who had their agenda and used the retrospective to push that through. Neither meeting deserves the title "respective" in any way.
The other thing that a successful retrospective requires is a team in which most if not all of the team has a genuine desire to improve themselves and their teamwork. Most people I've worked with in software development have this desire, and even if one team member thinks they're perfect, they still have to "explain" their views in a retrospective which will at least lead to a discussion.
And finally there have been retrospectives in which all present team members have been genuinely happy with the team. In that case we just cut the meeting short, and got on with our work, but a regular "check-in" is still necessary to make sure we haven't missed something that is bothering a particular team member. Thanks a lot!
I love this input. As you said, you need people with a desire to improve.
Yes, indeed. It is simple, but not easy to do well. And a lot of people have only tried a retrospective that was not facilitated well, and those ARE a waste of time.
I learned that you didn't use a script for that video from your LinkedIn post. Well. I can see the difference, and it's for good. You move more naturally and look like you're talking to us on a casual conversation, which is great to create connection. Congratulations on doing an amazing job and showing mastery of the subject even using minimal scaffolding.
Thank you!
This all works very well in practice if you have an engaged team...the buy in needs to be by everyone. Reading the comments, I feel I'm in a rare situation where this is the case. Thank you for this video, this will really help to keep improving.
I think many teams enjoy retrospectives, but probably do not feel the need to write here :-)
@@ainocorry3004 This is very true!
Use a wade matrix and create simple action points either to do or to escalate.
If it's too big for an action point, put it in a jira ticket and prioritise it like normal work.
lol. JIRA.
I am not yet sure there are any learnings from retrospectives unless the team’s output is a repetitive labour. Usually the sprint work changes, the complexities change, the effort required changes, the requirements should change. Programmers should switch their brains from being stubborn creatures into very flexible humans where no changes are actually an issue. If you need a retrospective you lost it. The goals should be appealing enough to make everybody speak up, adapt and be pragmatic all the time.
Yeah, when that is the reality I agree that we might not need retrospectives.
😮 It's always programmers fault eh?
Great thinking and advice. I was talking with an agile coach yesterday that there was frustration at the end of retro.
1 things we were frustrated with but didn’t not know how to word as action to change it (as eg “how do you write better def of done” rather than know what is not)
2 that the team needs to know what they can change and often it is so small that it does need maybe 3+ sprints to start to see change when if a project is not long enough you don’t see effects- plus issues team can not the scrum master should raise higher up I believe
Very interesting tips. Thank you! Now on to trying to apply them 😊
Not good!
Take the section on pull requests, for example. If people do not want to do pull requests, more training is not the answer.
As Farley showed in a previous video, pull requests are a horrendously bad idea. I have measured how much time work spend waiting for pull requests, and it can easily be 50% of the total cycle time. There are far better ways to review code. Pair-Programming, for example.
The advice to have cameras on all the time, also not great. Videoconferencing is tiring for the human brain. Check out neuroscientist John Medina's book Brain Rules for Work. People hate the cameras for good reason, so do not force them to use them.
Also, the content does not match the title. The title is just clickbait.
Well, I am using the examples that people talk about in the retrospectives, and they mention these issues. I am trying to make a point about whether people solve the underlying cause or remove the symptoms. Also, yes to the fact about being on video all day in meetings. But don't let it become an excuse for never being on video in meetings. Retrospectives work best if people can see each other, in my experience.
What does he say specifically in his book about cameras? I am very curious on this... Can you pinpoint the exact quote or page n. where the subject is approached, please?
@@Sergio_Loureiro besides the fact cameras meeting consume lots of bandwidth, therefore lousy voice quality and resulting in poor communication having to ask many times to repeat.
Cameras are draining for the human brain. You are too self aware of the posture, face etc. Besides that is very difficult to stop looking at others and yourself on a small frame.
This doesn't happen in a natural real life interaction because and the others don't have to keep on that small frame, don't have to pretend to smile all the time and have room for natural movements and manners
@@errrzarrr Thanks for your input. But I am really interested on what that book says.
I am natural averse to being filmed or photographed, and I want to check from credited researchers whether my intuition it does more harm than good is correct or not.
I value your comment, but I need some scientific source for this, not just a random comment on TH-cam.
Waiting on pull requests? Sounds like form of gatekeeping, a nice tool for people who want to exaggerate how busy they are. Just run automated regression testing on your local development machine and merge it. it's not like you're irrevocably crossing the Rubicon with no way to undo things.
Expressing our concerns about issues beyond our control is beneficial for enhancing our psychological safety. While we cannot eliminate these issues entirely, we can openly discuss our frustrations and seek workarounds. That is not a waste of time 😊
Very informative. Thank you very much !
I find all of the agile ceremonies a bit boring, but retrospectives are the best part of Scrum. A specific window purely for systemic and continuous improvement. What’s not to love?
I agree, obviously :-)
hahahahahahahahahahah very good mate!!
Perhaps the most important one should be 'Be open to feedback.' Most teams and individuals especially non-technical managers & hands-off technical leaders don't know how to handle feedback.
Secondly should be 'Pick your battles'. Acknowledge that part of team work and trust building is when people compensate for the short comings of others. If you stop acknowledging that or taking it for granted, you will have a very disengaged and silent retro.
Great tips! Thank you
Make sure you identify problems with the work you are doing, discuss them, then take them away actions to complete
Great content, as always. Thanks
Just like anything we do a retro needs to justify its value, if it's not creating a measurable impact on the company then stop doing it until you have a reason to do it. Also why wait for a retro if you can change and realise the impact right now, surely this is the essence of agile.
They are a waste of time. Just makes everyone frustrated.
In summary, 'Retrospective should be meaningful and productive"
To me retrospectives have become a waste of time when it's just either a session where people pat each other on the back saying what great work they did on this and that, or if they keep listing items they would like to change, but the individuals or team doesn't have the power to change them. Or if they just complain about things that happened on the last sprint, but nobody wants to do anything about it.
Our team has a pretty good retrospective, but I can't recall a single thing that the team has done in the name of continuous improvement. It's just been about "Well this should change, but we can't change the entire process because others rely on it too". Retrospectives require the team to actually work as a team, and to have autonomy to dictate how they work.
13 - Add an extra retro (squared) session for reviewing the last 3 or 4 retros. Sort of meta retro.
14- Add an extra retro (cubed) session for reviewing the last 3 or 4 retro-squared. Sort of meta meta-retro.
15, 16..... do you get it?
To be honest I don't trust the advice of an 'Agile Coach' on anything
To be honest I don't trust the advice of people who choose to be anonymous 🙂
@@ainocorry3004 I'm not handing out advice but nothing against the individual in the video, I just have problems with the role itself for the obvious reason of wtf do they know
Do other non-software industries uses Agile really? Is it possible that Agile (and so called agilists) make a living thanks to the lack of standards in software development, even promoting the idea that each team must design its own methodology and find its own way?
Retrospectives are used outside of agile. They were used in medicine and in military long before the term "retrospective" was coined in software development. They idea was initially taken from those fields and made to fit in, first in long-term projects with waterfall and later in agile settings. In other fields they are called something else, but they are non-blaming, cause-finding, learning together sessions. If by "agile" you mean "Scrum" then I think people have started using it outside software, I am currently using it in a hardware research and design setting. If by "agile" you mean the principles, and things like pair work and daily interactions it is used in many industries. Healthcare, between pilots, etc. Basically "inspect and adapt", which is useful everywhere I think.
Agile is pretty much based on lean, from the manufacturing industry
To turn cameras on? Never have seen that on the Agile Manifesto
Oh I dread when rituals becomes the end on itself instead of a means to an end😢
All great points. Also you can still have democracy just use an Alternative Vote system rather than First Past the Post.
Wow so where is the video title elaborated? Great clickbait.
Well, maybe I was too subtle in the video. I meant to say that retrospectives easily can become a waste of time. If you don't facilitate them well.
@@ainocorry3004 Yeah but thats not what the title says.
I expected a video, where you point out why a retrospective is not necessary or a waste of time. But you only said, that it could be a waste of time under some circumstances.
Everything can be a wast of time, if its not facilitated well: sprint planning, daily, programming, ..
Your video was good, also the listed points in the video. But the title is misleading, which is not necessary.
I see your point. I will make our marketing aware of the issue. Thank you for your nice words about the video:)
Yes all hail the algorithm and all, but the clickbait titles on this channel are getting out of control.
Read it more like "if they are a waste of time for you, here's how you can make them a good use of time".
Agile is a cult
retrospectives are only to conclude that we need make our communication better, because is the only thing that will not make anyone look bad for pointing, and everyone agrees with it, every 2 weeks an hour lost to conclude this hahahahahah
Also, every 2 weeks is too much overhead. There's not too much to happen from on a 2-week basis, let time pass and absorb the experience and *LEARN.*
Every 2 weeks is obsessive , more like being a control freak.
9:07 You can use what?
12 steps? Lol youre asking a lot of me
i'd rather die than turn on my camera.
lol
Summary @ 11:54 .
Wow this video is really terrible to watch. The words "allow them," used repeatedly is exactly what's wrong with this SCRUM thing. Businesses wanting all these ways to control their staff who never needed controlling. And calling people "loud mouths" repeatedly is incredibly disrespectful. Saying they "contaminate the others." What is this and why is it on Dave Farley's channel?
Hard no.
I like to be opinionated.
I the Army we did after action reviews. AAR is opportunity to learn. Not a waste of time. Reflective thinkers need to speed up, or just kick them from the team. No time for slow pokes.
Love me some AAR's! Like the acronym "AAR" better than the phrase "post mortem".