The Daily Scrum: Does It Have to Be Daily?
rethinkingsoftware.substack.com
rethinkingsoftware.substack.com
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.
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.
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.
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.
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.
Exactly 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.
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.
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.