My lead is busy 100% of his day. If we don't force him to purposefully have the 15 minute standup inefficiency in his day, I won't get time with him ever. I simply won't ever outrank the other people asking for him.
Sounds like you have an organisational issue outside of that 15 minute window.
In fact, likely, its because people are forcing your lead into meetings that are largely irrelevant (because otherwise if they permit that block to open they feel that wont be able to get time with them) that causes the lack of time in the first place.
At one company (think bank/financial services) I was at as a "software development supervisor" I had to run a daily standup/scrum meeting every day, for 3 years. It really became oppressive over time. That company eventually had layoffs and I left. But they were still doing the daily standup, even when there were only 3 people left.
I find it funny that whenever theres an article lambasting capital-A Agile (which, is usually scrum), people are quick to say “you’re doing it wrong”. Its the best no true scotsman fallacy I’ve ever seen.
Yet, here I am, to say we are all doing it wrong.
The daily standup should have no managers at all in it, its for the team, and its for understanding blockers and progress.
Another issue that pervades is that of organisation: One of the hardest parts of leadership for me has been trying to understand the distinction between team and task/project, because projects require more collaboration than single discipline teams do: but we conduct capital-A Agile across single discipline team boundaries. I’m too shy to break everyones mental model of how they should work because…
It’s always this way in every company I ever worked, as it is with managers/leads in standups.
I have no idea why, we prescribe scrum instead of using our brains, and we don’t listen to the core instructions given even then- of course it doesn’t work.
On the No True Scrummaster point, it's fair to say that this comment actually suggests a fundamentally different alternative. The No True Scrummaster arguments I see typically zoom in to specific details instead of zooming out to examine the whole process.
It's really important to know the history of agile and why it came about. I don't think it's the problem. The root problem, which is true for any other methodology is business's unwillingness to accept uncertainty and change.
Standups were co-opted from a people-working-the-sprint touch point to discuss A 24 hour window and address problem, and turned into a status meeting, a jira hygiene meeting, or an number of unrelated things.
The answer to management's question, 'when will you be done' is, "at the end of the sprint." Don't ask me to report a daily, or god forbid, hourly status.
Exactly, construct a team to tackle a large enough problem, disband the team once the challenge is met. Hopefully the challenge statement concludes that sufficient documentation of the outcome is created.
But, I really don’t have all the answers, I just think cutting across disciplines is fruitless when you put 10 devs in a room and they work on 10 completely different things, which is how Agile is practiced where I have worked.
That can work in some environments, depending on expected support model.
A lot of organisations are doing product (vs project) development though, and personally I find it superior.
Teams that are responsible for running and operating the product they built are generally more incentivised to produce quality software. Nobody likes to be interrupted in the middle of a technical session or, even worse, in the middle of the night, because their application crashed - so they learn to build resilience in. They start optimising for operability, maintainability and extensibility - since they will be the ones operating, maintaining and extending.
The above is not the solution to all software delivery issues, and is not something that works everywhere, every time. Where it does, it produces better outcomes.
I do scrums twice a week. That's more than enough and if somebody has problems in between they are required to get in touch either with me or the person who can help. I think there is not enough going on to justify required daily standups.
If you lack the confidence and the comfort to report "no interesting progress" once a day, I either pity your emotional state or your team dynamic. Daily standups should not be overwhelming, and abolishing them is an avoidance strategy, not a solution.
That works until someone a bit higher up comes in and chews you out for not saying "what you did yesterday and what you plan to do today" with clear and achievable goals for today. People can contort the stand-up quite painfully.
Sure, but that sounds like a culture problem, not a problem with the meeting schedule. If you have abusive higher-ups, avoiding them is not a solution. Honestly, the whole premise of the discussion is kind of silly at that point. If you don't have the power to improve the meeting experience, then you definitely don't have the power to abolish the meeting.
I mean if it doesn't fit the team's or the project's stage, don't do them daily. Simple! I just solved it for you. Not sure why we need tons of articles on scrum to state the obvious :-). Are the engineering teams so dumb that they're following scrum to the letter? Come on!
But I thought the daily scrum is to give an opportunity to communicate and realign.
I'm not a developer (I'm a scientist working in R&D that then needs to be implemented by developers), but I've participated to plenty of daily scrum. I can say that they are sometimes very useful, without them, the devs would just go into whatever useless direction or would spend days trying to solve non-problem.
I never had any problem to say "nothing to report on my side, working on X like yesterday". Maybe the pressure is self-inflicted by a culture that idolized unicorns and 10x coders.
I think that if a dev think that they will not do whatever without guidance, THEY need to be replaced by better devs.
It's just mathematical: the possibility of interpretation of a solution is just very very big. It's not even a matter of precision of the requirements: the same way the dev cannot read the mind of the product owner, the product owner cannot read the mind of the dev and guess that when they use the term X that they always used this way, the dev will understand X' which is slightly different.
Developing a solution is like some point forecasting: you forecast the next point, then use that next point as input to forecast the next point and so on. If you don't realign with observations as soon as possible, you are just deviating. It depends of the uncertainty around your points, but this uncertainty is never totally 0.
Now, it's true that I'm in R&D, which may be dealing with more uncertainties. Maybe the frequency of scrum meeting should be based on that. But, pretty please, do not push to removing scrum meetings if you don't even understand that.
one reason engineers are frustrated with daily rituals is this assumption that they are aimless creatures who need constant instructions from rational beings (product managers and such)
Who don't actually do the work, and likely would not be able execute it no matter how hard they tried.
In that vein, I've sometimes wondered if this projected insinuation (of the developers' myopic tendencies and general haplessness in this regard), far from being an untended byproduct -- is in fact the whole point of Scrum.
Well, humans are humans, and after all, it's very very clear when you scan Hacker News comments that a lot of devs are just having the assumption that managers are useless fakers that bring nothing. It would be very hypocritical to pretend that devs are the victim of managers having a bad opinion of them while at the same time having no problem to have a bad opinion of managers. Live by the sword ...
My position is that it's sad and childish, in both case. Devs are not aimless creatures. But my point is that it is just physically impossible to not deviate if you don't get feedback. And importantly: your biggest deviation occurs when you don't realise there is a mismatch, so when you would NOT call a meeting. Because of that, constant re-alignment that occurs even when people of the team thinks there is no deviation are needed. It is not a judgement on the devs aimlessness, it's just a mathematical reality.
It's a bit like saying: because of this disease, I need to take my pill every morning, but it is frustrating to have this assumption that I'm a aimless creatures who needs constant pill-taking, I should be able to take all the pill in one go and go on with my life.
A lot of devs are just having the assumption that managers are useless fakers that bring nothing.
It's not an assumption. It's reasoned inference obtained through extensive observation.
And it's not "managers" in general, of course. Just the ones who have no idea how to operate other than through Scrum.
But my point is that it is just physically impossible to not deviate if you don't get feedback.
It's not that no one wants "feedback". Rather, the perception has emerged that the rituals of Scrum are a pretty lousy (and basically counterproductive) way of delivering that feedback.
because of this disease, I need to take my pill every morning,
Except it turns out the "pill" in this case is a quack cure, basically. That's why people are resistant to taking it.
What a very balanced opinion that will not at all reenforce my idea that some devs are just idiots blaming managers for everything.
Managers that micromanage are idiots. If they would have been a dev, they would have been a dev that explains that all managers are obviously useless.
> Except it turns out the "pill" in this case is a quack cure, basically. That's why people are resistant to taking it.
The analogy flew very high above your head. I was responding to the logic "if it's daily, it's the proof it's because they believe we are aimless creatures that need to be managed". I just give an example where someone is asked to do something daily, and yet it is clearly not because of that.
I can say that they are sometimes very useful, without them, the devs would just go into whatever useless direction or would spend days trying to solve non-problem.
That looks like an almost total failure of both product management and team leadership. Maybe a daily standup would mitigate those failures in some superficial way but it's surely not aiming at the root causes of the unproductive team or solving the problem efficiently.
The fact that point forecasting deviate from observations the more you go on without readjusting is not a failure of organisation, it's a fundamental and logical law of nature.
It's a bit worrying that people working in this field don't even know that a constant dialogue is not the sign of a failure.
I've seen multiple comments like this, only responding to yours, it's not personal.
I disagree. If your task is simply adding a new feature or refactoring, yes, you're right . If you have to handle new data or worse, launch a new product from scratch, and only sync once every two weeks, good luck. Our dailies can last 2 minutes when nothing new is created (between 30s and 5 minutes), but also one hour, everyday, for months if a new product is on the rails. Syncing is very much needed, especially during the discovery phase. You don't want to redesign your noSQL database every 2 months.
You seem to be reading something in my comment that was not there.
If you have developers following unhelpful paths for days at a time then you don't just need a brief update in a daily standup. You need product managers who can determine and clearly articulate what needs to be built right now. You need technical leaders who can keep their teams moving towards those goals. You need developers and testers who provide feedback on what is or isn't working out promptly to those who need to know. Possibly you also need to provide significant training and/or mentoring to any or all of these people. All of this is likely to require much more frequent and detailed communication between the relevant parties than a quick team chat once per day.
The point is that you need everyone to communicate at a frequency and level of detail that matches the nature of what they're currently working on. Sometimes that might mean several team members collaborating in close to real time for a week. Sometimes it might mean leaving a single person to think uninterrupted for a week so they can figure out a good solution to a difficult problem that is well defined and not going to change any time soon.
So-called Agile processes that try to force real development into chunks of any fixed size and schedule process activities at any fixed frequency are going to get those scales wrong almost 100% of the time in my experience. The strange thing to me is why anyone ever expected any other outcome.
But it was not what I was talking about when I was talking about useless direction and trying to solve non-problem.
The situation you describe is indeed a management and leadership failure.
But if you don't have management and leadership failure, you still have useless direction and trying to solve non-problem. It's just mathematical, it's just a feature of what happens when you work in a collaboration and have a group that implement the product and another group who owns it. It's not a judgement on the capacity of the devs: even the best dev will deviate. It is just because uncertainties always exist and the more you advance without realigning, the more you deviate.
Let's also notice that the devs realign, but the management realign also, refining their understanding of what is possible or not and so on.
The point of dailies should not be to make sure that devs work on the right stuff, that should be part of managing backlog and sprint plannings. Instead the point of dailies should be to avoid devs hitting head on wall and clear out any blockers for progress. Having reserved timeslot for syncing also should reduce random pings during the day which should allow people then to focus more on their tasks instead of getting interrupted all the time.
Agreed, but in practice, I think needing to wait for sprint planning is very time-wasting and in practice not efficient. If a dev has worked 3 days in the wrong direction, they will naturally try to salvage some of the bad things, or even try to pretend that their solution is "the only way". It can be negotiated, with more or less success, but the negotiation itself is a waste of time if it could have been caught earlier.
100% agree with planning the meeting to avoid flow interruption. It's strange to see so many people here saying that you can just "ask whenever" when the argument about avoiding interruption is brought so often.
Why is it that the developers would go into useless directions and solve non-problems? Perhaps they were not given good directions and a well-defined problem in the first place?
It is this attitude toward developers that made stupid shit like Scrum possible. Processes will not solve communication problems if there is no mutual trust to start with.
Cf. my other comments: the developers would go into useless directions and solve non-problems the same way that if you predict tomorrow weather, and then predict after-tomorrow weather, and then predict after-after-tomorrow weather, ... you slowly deviate from the reality unless you readjust with the observations.
> I never had any problem to say "nothing to report on my side, working on X like yesterday".
If daily scrum is essentially a status meeting by-any-other-name and nobody is much bothered by what your status is....then maybe you don't need to be giving a status to begin with? Seems like functionally you are more of an observer than a participant and you just throw in a status as a "when in Rome" token.
For the managers in the room, "uhhhh, lots of meetings yesterday" is a fine status to give day after day.
Watch what happens to a programmer who gives an honest status of "uhhhh lots of meetings yesterday, not a lot of progress on X" though. They're inviting attention. There's an added onus on devs that they need to come up with a way to describe what they did the day before (no matter how small) such that non-dev listeners can hear some epsilon of progress was made. Because if it doesn't sound like progress, it sounds like no-progress. And then people who don't understand how any of it works want to start trying to understand. And now you've got two problems.
Obviously, I don't say "nothing to report" in every meeting.
The reality is that sometimes you need to readjust, and sometimes not, and it is impossible to know before hand and confronting your forecast with the observations.
And, from my experience, devs over-estimate greatly how much non-devs care about them and their "number of line of code written" pissing contest
> And, from my experience, devs over-estimate greatly how much non-devs care about them and their "number of line of code written" pissing contest.
Your experience as a non-dev who doesn't manage devs? Noted. Unfortunately, the people signing our paychecks do care, and so devs have incentives to continue doing the same strange dance every morning.
> Unfortunately, the people signing our paychecks do care
From your experience of a dev, not a non-dev who manage devs? Noted.
My point is that I have observed, with my own eyes, devs BELIEVING they need to do the dance in front of a given manager while I've observed the same manager giving bigger paychecks to another dev that did not do the dance.
They may be several reasons for that, including sometimes the manager's fault, but also sometimes the dev's fault. For example, in the case I think of, the dev who was "doing the dance" was also not getting promoted or being trusted by their promoter. The reason was that they were often unreliable. But the dev in question said few time that if they were not promoted it was because they did not "do the dance" enough. When you are a bad dev, it's easy to blame the lack of promotion on "I'm in fact totally good, it's just that my manager is an idiot who cannot recognize good when they see it".
(PS: I'm not saying you are not good or that you are believing you need to do the dance while you don't need to. But if you are not aware that this happens a lot, then you are indeed missing a big part of the full picture and your opinion on the situation is not at all trustworthy)
> From your experience of a dev, not a non-dev who manage devs? Noted.
Would you take my experience as a dev who went into management, then returned to IC work?
I can't claim to speak for every company. I've only worked at 4 over the past 15 years, but I can only think of one where I'd raise eyebrows in standup if I reported not making progress on my ticket due to meetings, and that's because I'd have to explain how I managed to find that many meetings to attend (they were big on not hitting devs with too many meetings, and were actually good at it). For the rest it'd get an understanding grimace and an expression of hope that today's better.
Not sure of your point. When I read the rest of your comment, it seems like you agree with me: saying you did not progress as a dev is not such a big deal for non-devs (3 in 4), and when it was, it was because the reasons are surprising (having too much meetings when the company tries hard to reduce the meeting invites to ask more questions to understand why there is disconnect between the objective and the reality).
Daily check-ins can be necessary under certain circumstances. (Think all-hands-on-deck quickly evolving situations with a tight deadline and several unknowns. Like a big feature launch.) Sometimes you might even need them twice a day. You cannot do it much more often, though.
So the big problem with scrum is not the daily, but it's ceremonious importance. It's just fixed, it doesn't have any reason. One does it because scrum.
If you look closely, you'll see more of that pattern in scrum. Sprints, for instance, are a given. Yet, why would anybody do them when there are no new features to be developed? When a product is mature and needs maintenance or simply doesn't exist at all, there's no reason to do sprints. Whenever there's no feedback from stakeholders, there's no reason to do sprints.
Breaking news - introverts don't want to have daily stand ups, whilst extroverts think it's fun and useful.
I personally found them quite helpful to ensure I could help out team members who had got stuck. It's sometimes lonely debugging a complex system, and people can appreciate someone else to either confirm it really is what they think is going on, or maybe bounce some ideas off. It's a great way for the more experienced team members to find places where they can make a significant difference by contributing a bit of their day to helping out.
If your team is waiting until the next stand-up to get help to get unstuck I think that's a cultural problem, they should be reaching out at any point during the day.
I feel like the existence of daily standup has influenced this for my team. There's a lot of, "well I could reach out about this now, but I'll just bring it up at standup and then I'm not interrupting anyone"
And reporting up to someone whose sole responsibility in the interaction is to detect stuckness or the hint of stuckness or to offer referrals to someone who might make you go faster is tiring as hell.
It's quite transparent and grating.
I recognize that often there is a good outcome and it helps. People can spin on issues poorly. (And I definitely am a person who from outside appearances sometimes resembles that, although usually it's me becoming the only expert we have in the domain & seeing how systems really work, not just closing the ticket asap.)
I wish we had async/offline systems to follow each others course & suggest some steering rather than being beholden to daily cross examinations where managers get to decide to redirect us off the path we've chosen.
stuck doesn't mean twiddling your thumbs wondering what to do next - i'd certainly expect someone to ask if they were in that situation.
No, stuck can often only be observed by looking in, the person or team may think they are doing useful stuff, but someone coming to it fresh can see that they have missed something obvious, hence why recreating the problem seems to be impossible, or why the fix seems very involved.
So a standup can allow you to see that someone is stuck, even when they don't realise it themselves.
If everybody posts in a shared channel when they get stuck and ignores that channel when they're heads down on something, then you get zero interruptions, flow is preserved, and people get helped when they need it.
An asynchronous daily check in via chat and a weekly meeting is more than enough to cover the important parts.
A virtual or in-person meeting scheduled at the same time every day is mostly performance art for management and is not necessary to get everyone on the same page.
Almost all problems with daily scrum/kanban/whatever can be traced back to inappropriate management.
Most of the time the issue is the daily whatever has been turned into a demotivating status meeting where a PMO trained project manager (PMP) is drilling each person for a status roll-up.
When management is inappropriate, the ignorance is so thick that no rational discussion can penetrate.
While I agree, it is also very common that it's the culture inside the dev team that leads to this situation.
Dev culture tends to idolize unicorns and 10x coders (more than management who has absolutely no reason to care about the status or ego of each dev individually) so they tend to, themselves, find intimidating to admit they are not one.
Yep once we kick the PMP out, then we can work on safety so people will openly share where they are in the battle with the real enemy - the software.
As it turns out 10x isn't enough.
Once the complexity of the solution hits a certain point you really need multiple brains working together to reliably evolve it in a sustainable manner that isn't rife with operational disruption.
I've been an engineer and a PM in Scrum, Spiral, and Waterfall teams.
That daily meeting can either be:
- One where, participants feel as if they are reporting to some person of authority who is there to judge them, but not really help them much, if at all.
- Or, one where everyone feels like the meeting is for their benefit.
One person (usually a manager) that feels too senior / detached to participate will quickly turn the meeting from the latter to the former.
If someone is in a daily Scrum meeting, then they must share with everyone what they did yesterday, how it's going and what they're going to that day. If they don't, then they shouldn't be in the meeting - they can get all the information they need by looking at the story board or meeting notes or reach out directly.
For distributed teams there are some wonderful tools to collaboratively participate in daily meetings. These tools will speed up the whole meeting, making it even less tedious than before!
Once everyone is participating, then it becomes possible to move beyond "worked on bugs" or "worked on AB-24132" to something more descriptive. Personally, I think of the daily meeting as the thread that connects the events of the previous day to the goals of today. It should feel like a story that you are living, and not some dystopian nightmare where everyday is just like the day before.
It pains me to read this because the scrum meetings at my last companies were fluid enough that you could say anything.
So if I worked on a problem which turned out to be more complicated than originally estimated, I would just list out all these sub-problems and so people would realize that I did a lot.
The company I work for now does scrum very differently. During the scrum planning meetings, we must break down all tasks so that they are less than 8 hours. So this means that every day, you MUST be able to point to at least one completed task every day. If new complexity was uncovered (which of course is always the case due to technical bloat which occurs when developers are always pressured like this), then you need to take it upon yourself to cut all the corners necessary to get your minimum of one daily task done. That is unpleasant and unproductive. Though I guess it helps existing devs build a moat of complexity around themselves so that, over time, the work becomes predictable for you but not for others who are less familiar with existing code/constraints.
Daily scrums or meetings are maddening. After a month I just get so stressed even thinking about it. It's such a drag on productivity.He's right, only children should be checked upon daily. Every other day isn't so bad, weekly is totally fine.
73 comments
[ 3.3 ms ] story [ 121 ms ] threadExactly this.
In fact, likely, its because people are forcing your lead into meetings that are largely irrelevant (because otherwise if they permit that block to open they feel that wont be able to get time with them) that causes the lack of time in the first place.
Yet, here I am, to say we are all doing it wrong.
The daily standup should have no managers at all in it, its for the team, and its for understanding blockers and progress.
Another issue that pervades is that of organisation: One of the hardest parts of leadership for me has been trying to understand the distinction between team and task/project, because projects require more collaboration than single discipline teams do: but we conduct capital-A Agile across single discipline team boundaries. I’m too shy to break everyones mental model of how they should work because…
It’s always this way in every company I ever worked, as it is with managers/leads in standups.
I have no idea why, we prescribe scrum instead of using our brains, and we don’t listen to the core instructions given even then- of course it doesn’t work.
Standups were co-opted from a people-working-the-sprint touch point to discuss A 24 hour window and address problem, and turned into a status meeting, a jira hygiene meeting, or an number of unrelated things.
The answer to management's question, 'when will you be done' is, "at the end of the sprint." Don't ask me to report a daily, or god forbid, hourly status.
- It's for cross discipline teams to be able to unblock each other, communicate and feedback progress and updates.
Do you see the teams as temporary? Or longer term? How large or small a team size are you thinking?
For example would your approach be:
- Build a team to tackle a feature or solve a specific area
Just curious to get a bit more understanding about what your envisioning =)...
But, I really don’t have all the answers, I just think cutting across disciplines is fruitless when you put 10 devs in a room and they work on 10 completely different things, which is how Agile is practiced where I have worked.
A lot of organisations are doing product (vs project) development though, and personally I find it superior.
Teams that are responsible for running and operating the product they built are generally more incentivised to produce quality software. Nobody likes to be interrupted in the middle of a technical session or, even worse, in the middle of the night, because their application crashed - so they learn to build resilience in. They start optimising for operability, maintainability and extensibility - since they will be the ones operating, maintaining and extending.
The above is not the solution to all software delivery issues, and is not something that works everywhere, every time. Where it does, it produces better outcomes.
No, their managers are.
I'm not a developer (I'm a scientist working in R&D that then needs to be implemented by developers), but I've participated to plenty of daily scrum. I can say that they are sometimes very useful, without them, the devs would just go into whatever useless direction or would spend days trying to solve non-problem.
I never had any problem to say "nothing to report on my side, working on X like yesterday". Maybe the pressure is self-inflicted by a culture that idolized unicorns and 10x coders.
Perhaps this is a sign you need better devs -- much better devs, in fact?
And that Scrum, while it may appear to help by patching over this problem -- is actually masking it?
It's just mathematical: the possibility of interpretation of a solution is just very very big. It's not even a matter of precision of the requirements: the same way the dev cannot read the mind of the product owner, the product owner cannot read the mind of the dev and guess that when they use the term X that they always used this way, the dev will understand X' which is slightly different.
Developing a solution is like some point forecasting: you forecast the next point, then use that next point as input to forecast the next point and so on. If you don't realign with observations as soon as possible, you are just deviating. It depends of the uncertainty around your points, but this uncertainty is never totally 0.
Now, it's true that I'm in R&D, which may be dealing with more uncertainties. Maybe the frequency of scrum meeting should be based on that. But, pretty please, do not push to removing scrum meetings if you don't even understand that.
In that vein, I've sometimes wondered if this projected insinuation (of the developers' myopic tendencies and general haplessness in this regard), far from being an untended byproduct -- is in fact the whole point of Scrum.
My position is that it's sad and childish, in both case. Devs are not aimless creatures. But my point is that it is just physically impossible to not deviate if you don't get feedback. And importantly: your biggest deviation occurs when you don't realise there is a mismatch, so when you would NOT call a meeting. Because of that, constant re-alignment that occurs even when people of the team thinks there is no deviation are needed. It is not a judgement on the devs aimlessness, it's just a mathematical reality.
It's a bit like saying: because of this disease, I need to take my pill every morning, but it is frustrating to have this assumption that I'm a aimless creatures who needs constant pill-taking, I should be able to take all the pill in one go and go on with my life.
It's not an assumption. It's reasoned inference obtained through extensive observation.
And it's not "managers" in general, of course. Just the ones who have no idea how to operate other than through Scrum.
But my point is that it is just physically impossible to not deviate if you don't get feedback.
It's not that no one wants "feedback". Rather, the perception has emerged that the rituals of Scrum are a pretty lousy (and basically counterproductive) way of delivering that feedback.
because of this disease, I need to take my pill every morning,
Except it turns out the "pill" in this case is a quack cure, basically. That's why people are resistant to taking it.
Managers that micromanage are idiots. If they would have been a dev, they would have been a dev that explains that all managers are obviously useless.
> Except it turns out the "pill" in this case is a quack cure, basically. That's why people are resistant to taking it.
The analogy flew very high above your head. I was responding to the logic "if it's daily, it's the proof it's because they believe we are aimless creatures that need to be managed". I just give an example where someone is asked to do something daily, and yet it is clearly not because of that.
You keep coming back to this caricature. And yet, I've never met anyone with this opinion.
I just give an example where someone is asked to do something daily, and yet it is clearly not because of that.
Right, you said they were being asked to (in reality: made to, not "asked to") do that because they effectively had a "disease".
When management takes that attitude about its rare and precious talent, well, all bets are off.
That looks like an almost total failure of both product management and team leadership. Maybe a daily standup would mitigate those failures in some superficial way but it's surely not aiming at the root causes of the unproductive team or solving the problem efficiently.
The fact that point forecasting deviate from observations the more you go on without readjusting is not a failure of organisation, it's a fundamental and logical law of nature.
It's a bit worrying that people working in this field don't even know that a constant dialogue is not the sign of a failure.
I disagree. If your task is simply adding a new feature or refactoring, yes, you're right . If you have to handle new data or worse, launch a new product from scratch, and only sync once every two weeks, good luck. Our dailies can last 2 minutes when nothing new is created (between 30s and 5 minutes), but also one hour, everyday, for months if a new product is on the rails. Syncing is very much needed, especially during the discovery phase. You don't want to redesign your noSQL database every 2 months.
If you have developers following unhelpful paths for days at a time then you don't just need a brief update in a daily standup. You need product managers who can determine and clearly articulate what needs to be built right now. You need technical leaders who can keep their teams moving towards those goals. You need developers and testers who provide feedback on what is or isn't working out promptly to those who need to know. Possibly you also need to provide significant training and/or mentoring to any or all of these people. All of this is likely to require much more frequent and detailed communication between the relevant parties than a quick team chat once per day.
The point is that you need everyone to communicate at a frequency and level of detail that matches the nature of what they're currently working on. Sometimes that might mean several team members collaborating in close to real time for a week. Sometimes it might mean leaving a single person to think uninterrupted for a week so they can figure out a good solution to a difficult problem that is well defined and not going to change any time soon.
So-called Agile processes that try to force real development into chunks of any fixed size and schedule process activities at any fixed frequency are going to get those scales wrong almost 100% of the time in my experience. The strange thing to me is why anyone ever expected any other outcome.
But it was not what I was talking about when I was talking about useless direction and trying to solve non-problem.
The situation you describe is indeed a management and leadership failure.
But if you don't have management and leadership failure, you still have useless direction and trying to solve non-problem. It's just mathematical, it's just a feature of what happens when you work in a collaboration and have a group that implement the product and another group who owns it. It's not a judgement on the capacity of the devs: even the best dev will deviate. It is just because uncertainties always exist and the more you advance without realigning, the more you deviate.
Let's also notice that the devs realign, but the management realign also, refining their understanding of what is possible or not and so on.
100% agree with planning the meeting to avoid flow interruption. It's strange to see so many people here saying that you can just "ask whenever" when the argument about avoiding interruption is brought so often.
It is this attitude toward developers that made stupid shit like Scrum possible. Processes will not solve communication problems if there is no mutual trust to start with.
If daily scrum is essentially a status meeting by-any-other-name and nobody is much bothered by what your status is....then maybe you don't need to be giving a status to begin with? Seems like functionally you are more of an observer than a participant and you just throw in a status as a "when in Rome" token.
For the managers in the room, "uhhhh, lots of meetings yesterday" is a fine status to give day after day.
Watch what happens to a programmer who gives an honest status of "uhhhh lots of meetings yesterday, not a lot of progress on X" though. They're inviting attention. There's an added onus on devs that they need to come up with a way to describe what they did the day before (no matter how small) such that non-dev listeners can hear some epsilon of progress was made. Because if it doesn't sound like progress, it sounds like no-progress. And then people who don't understand how any of it works want to start trying to understand. And now you've got two problems.
The reality is that sometimes you need to readjust, and sometimes not, and it is impossible to know before hand and confronting your forecast with the observations.
And, from my experience, devs over-estimate greatly how much non-devs care about them and their "number of line of code written" pissing contest
Your experience as a non-dev who doesn't manage devs? Noted. Unfortunately, the people signing our paychecks do care, and so devs have incentives to continue doing the same strange dance every morning.
From your experience of a dev, not a non-dev who manage devs? Noted.
My point is that I have observed, with my own eyes, devs BELIEVING they need to do the dance in front of a given manager while I've observed the same manager giving bigger paychecks to another dev that did not do the dance.
They may be several reasons for that, including sometimes the manager's fault, but also sometimes the dev's fault. For example, in the case I think of, the dev who was "doing the dance" was also not getting promoted or being trusted by their promoter. The reason was that they were often unreliable. But the dev in question said few time that if they were not promoted it was because they did not "do the dance" enough. When you are a bad dev, it's easy to blame the lack of promotion on "I'm in fact totally good, it's just that my manager is an idiot who cannot recognize good when they see it".
(PS: I'm not saying you are not good or that you are believing you need to do the dance while you don't need to. But if you are not aware that this happens a lot, then you are indeed missing a big part of the full picture and your opinion on the situation is not at all trustworthy)
Would you take my experience as a dev who went into management, then returned to IC work?
I can't claim to speak for every company. I've only worked at 4 over the past 15 years, but I can only think of one where I'd raise eyebrows in standup if I reported not making progress on my ticket due to meetings, and that's because I'd have to explain how I managed to find that many meetings to attend (they were big on not hitting devs with too many meetings, and were actually good at it). For the rest it'd get an understanding grimace and an expression of hope that today's better.
So the big problem with scrum is not the daily, but it's ceremonious importance. It's just fixed, it doesn't have any reason. One does it because scrum.
If you look closely, you'll see more of that pattern in scrum. Sprints, for instance, are a given. Yet, why would anybody do them when there are no new features to be developed? When a product is mature and needs maintenance or simply doesn't exist at all, there's no reason to do sprints. Whenever there's no feedback from stakeholders, there's no reason to do sprints.
I personally found them quite helpful to ensure I could help out team members who had got stuck. It's sometimes lonely debugging a complex system, and people can appreciate someone else to either confirm it really is what they think is going on, or maybe bounce some ideas off. It's a great way for the more experienced team members to find places where they can make a significant difference by contributing a bit of their day to helping out.
This is not something that make teams agile.
It's quite transparent and grating.
I recognize that often there is a good outcome and it helps. People can spin on issues poorly. (And I definitely am a person who from outside appearances sometimes resembles that, although usually it's me becoming the only expert we have in the domain & seeing how systems really work, not just closing the ticket asap.)
I wish we had async/offline systems to follow each others course & suggest some steering rather than being beholden to daily cross examinations where managers get to decide to redirect us off the path we've chosen.
No, stuck can often only be observed by looking in, the person or team may think they are doing useful stuff, but someone coming to it fresh can see that they have missed something obvious, hence why recreating the problem seems to be impossible, or why the fix seems very involved.
So a standup can allow you to see that someone is stuck, even when they don't realise it themselves.
So talk to people. You can even do this every day.
But you can't do that on a meeting with close to ten people, all stopped there waiting for you to finish your speech.
I guess different people works differently.
A virtual or in-person meeting scheduled at the same time every day is mostly performance art for management and is not necessary to get everyone on the same page.
Most of the time the issue is the daily whatever has been turned into a demotivating status meeting where a PMO trained project manager (PMP) is drilling each person for a status roll-up.
When management is inappropriate, the ignorance is so thick that no rational discussion can penetrate.
Dev culture tends to idolize unicorns and 10x coders (more than management who has absolutely no reason to care about the status or ego of each dev individually) so they tend to, themselves, find intimidating to admit they are not one.
As it turns out 10x isn't enough. Once the complexity of the solution hits a certain point you really need multiple brains working together to reliably evolve it in a sustainable manner that isn't rife with operational disruption.
That daily meeting can either be:
- One where, participants feel as if they are reporting to some person of authority who is there to judge them, but not really help them much, if at all.
- Or, one where everyone feels like the meeting is for their benefit.
One person (usually a manager) that feels too senior / detached to participate will quickly turn the meeting from the latter to the former.
If someone is in a daily Scrum meeting, then they must share with everyone what they did yesterday, how it's going and what they're going to that day. If they don't, then they shouldn't be in the meeting - they can get all the information they need by looking at the story board or meeting notes or reach out directly.
For distributed teams there are some wonderful tools to collaboratively participate in daily meetings. These tools will speed up the whole meeting, making it even less tedious than before!
Once everyone is participating, then it becomes possible to move beyond "worked on bugs" or "worked on AB-24132" to something more descriptive. Personally, I think of the daily meeting as the thread that connects the events of the previous day to the goals of today. It should feel like a story that you are living, and not some dystopian nightmare where everyday is just like the day before.
So if I worked on a problem which turned out to be more complicated than originally estimated, I would just list out all these sub-problems and so people would realize that I did a lot.
The company I work for now does scrum very differently. During the scrum planning meetings, we must break down all tasks so that they are less than 8 hours. So this means that every day, you MUST be able to point to at least one completed task every day. If new complexity was uncovered (which of course is always the case due to technical bloat which occurs when developers are always pressured like this), then you need to take it upon yourself to cut all the corners necessary to get your minimum of one daily task done. That is unpleasant and unproductive. Though I guess it helps existing devs build a moat of complexity around themselves so that, over time, the work becomes predictable for you but not for others who are less familiar with existing code/constraints.
The 'what did you do' part by default is 'work on the stories, as planned', and should probably just be left out altogether.