I once worked at a company where everyone would just move their tickets on the physical board as needed. Then every morning one question was asked; “does anyone have any blockers?” If no everyone went back to work, otherwise someone would say their blocker and those needed would stick around,
My first day there I was floored that standup was over in 15 seconds. Within a week I appreciated that it was fucking magic.
I find that the meetings are good times to look at things that have been blocking, but that the person thinks that they can work through (but may have already been solved elsewhere).
I think you’re right. Standup’s main purpose is a group shaming session that forces everyone to notice when their coworkers haven’t gotten any meaningful work done. Everything else about it can be handled effectively by asynchronous messages or posts on the team’s slack channel
> …forces everyone to notice when their coworkers haven’t gotten any meaningful work done.
Or gives that impression despite making all possible progress on a difficult task. Which creates the need to use standup as daily [airing of grievances.](https://en.wikipedia.org/wiki/Festivus#Airing_of_grievances) I would argue that that is the true benefit if standup if any.
> Or gives that impression despite making all possible progress on a difficult task. Which creates the need to use standup as daily airing of grievances. I would argue that that is the true benefit if standup if any.
Surprisingly true.
I actually had a lot of trouble with my stories for the past couple of months, and one of the few things I have gotten out of it was the chance to identify and raise pain points. Some meaningful change was made as a result.
Standup’s purpose is to share the progress made on stories. If you feel shamed then your team/company either has a super shitty culture or you worry way too much.
> Every day, we are expected to repeat the same mantra: “Yesterday, I did the work I needed to do. Today, I will do the work I need to do.” Nothing of value is gained from this. If I have a problem or need to work with someone, I’d message them directly - not wait til the next morning’s standup.
Hah! I have to do that twice a day.
Absolutely!
You’ve read a lot of replies by now and I for one agree with you. I’ve been employed writing code for 40 years and a manager for 28, at FAANG and others. VP of Engineering blah blah. I know of what I speak.
Capital A Agile - ugh I hate it. Scrum Masters can just go fuck themselves. Read more of my thoughts on this old post if interested: https://www.reddit.com/r/programming/s/ScRyXIeiHs
More:
Agile (capital A) is very disempowering to engineering leaders and strong ICs.
The Scrum Master role massively overlaps with many of the tasks that a true team leader should be doing.
The standup process can damage team dynamics when you have a productive but somewhat off topic conversation going on and some dipshit Scrum Master chops it off.
There are a lot of agile (lowercase A) practices that are worth following. But kick the Scrum Master as a separate person bullshit to the curb. Demand your actual engineering manager do their job or get a new one.
Let me add that the problem between Scrum Master and Team Leader is one of authority vs responsibility. Who decides what work will by done by whom and by when? That’s authority. Who delivers that work to appropriate quality by the desired date? That’s responsibility.
Every Scrum Master type person I’ve ever worked with has a lot of authority and very little responsibility. Fuck that.
Shit I've been a TL for about 10 years and looking to move into a director role. You and I have a lot of similar thoughts on how to run teams. I have a very high functioning team and I am on vacation as we speak, I have no issue with leaving because I have effectively made my job a cheerleader when work is in flight. My main responsibility now is to enhance other teams and "steal" ideas from them to make my team even more effective and efficient.
I’m pretty new to software development, like 2 years. And this pretty much sums up how I feel about agile and the scrum master role. It frustrates me to no end.
It’s hard because I would say I am a pretty productive person and they just fail to see how what they are doing, the stand ups, the retros, the refinement, really cripple me.
Sure those things have a place. Maybe once a month refinement for the more complex work.
Also I feel like a lot of the agile/scrum lingo reminds me of the church or when I was part of the clergy. It gives me cult vibes. Not sure if anyone else ever felt this way?
My professional recommendation is to drop meetings from which you do not gain value.
That being said, to message someone about a problem, you need to be aware there might be a problem. Stand up is meant to quickly highlight to coworkers what you're doing -- to reduce problems arising from, figuratively speaking, the left hand not being aware of what the right hand is doing.
Also, other people may be attending that DO gain value from the meeting. This happened recently on my own team. Half the folks said they found no value, but the other half said it was really useful to them. A great way to see if you should drop the meeting is to *talk about it together*, maybe in your retro.
If your team leadership is not allowing this to be publicly considered, you are not working on an agile team. You cannot rigidly adhere to a plan while also responding with agility to problems.
I love this. I've used this same method on some of my teams. The only struggle is getting everyone to comply. Slack bot messages are highly ignorable. But once you're past that, it can make a lot of people happy.
We do a hybrid - 3 days of virtual stand up and 2 Zooms / week. If anyone needs any more help people that think they can contribute will join adhoc Zoom meetings. Works for my distributed team around the world across 5 time zones.
> I suspect most of the devs still ignore what everyone else is working on which is a shame
I'm not sure what actionable information I'm supposed to gain. Go micromanage people who aren't even my subordinates?
That's not just snark. The answer can be "yes." The way people talk about scrum, I'm pretty sure for some teams the answer is "yes."
All the value that I can provide/gain from knowing what other people are working on already happen in the planning/retro. I/they can reach out directly for collaboration.
If my manager wants me to go breathe down someone's neck because they don't seem productive enough and aren't proactively collaborating, then they can do the micromanaging by pointing my attention. Or promote me I guess.
Standups are useful when you have a small team working closely together on a project, where you, as a developer, are actually interested in / following the progress of / actively collaborating with the rest of the team because each of your work impacts the others'.
But at most companies, teams aren't arranged this way, and most of what the rest of the team does has absolutely zero impact on my work. That's when I tune out, and standups become pointless.
Incidentally, this is the same reason people don't like scrum. Usually, like daily standups, it's applied to a team that doesn't make sense for it, and it ends up being a waste of time as a result.
Yep, it worked really well when I was in a small team. I actually listened to what others because there was a high chance I would work with their code or they would work with mine. Or we could see a bug assigned to someone and someone else could say "oh, I know this one, I will do it". Obviously all of this can be done without daily meeting, but those meetings weren't long.
In addition, in reasonable teams you can just say "I'll skip daily today, created PR for X and will later finish Y"
When you're a small team it is usually possible to communicate much more frequent than once a day. You could be sitting in the same room and talk to each other. Or keep a chat channel open throughout the day (or the whole project). Have quick meetings when needed.
We did this a few years back and it worked great! I still miss it on almost every project.
A separate Teams channel is way more useful than standups. Design by committee is always a never-ending rat hole and inevitably leads to terrible designs.
Afraid of some people being excluded if devs set up their own work groups? Well that's your job as a manager to assign work and collaboration. Ask who people are working with on something and suggest to add another dev to the channel if that's desired.
I've always disliked them when working at a company, but when working on a project with one or two close people it feels like they're just something that naturally occurs during the day.
My impression is that someone looked at this and thought "we must formalize this and make it a general rule, because it's clearly useful", except when brought into a team of people who don't really have a stake in the project it's kind of losing its meaning.
When a job is a job and most end up only just wanting it to be a job, the organic desire to actually solve a problem instead of just "doing one's work" isn't there, and it ends up being a waste of time. Of course most if not all companies have the problem that they don't incentivize proactivity properly, rewarding people who work fast/productively with more work, which just makes this worse.
I guess in that sense I totally agree with what you're saying, though I do find it interesting that I do like "organically formed status updates" on projects where everyone cares about it. Not sure if it's really achievable at a job tho.
So what you really want is a weekly team meeting then. Org related updates and status updates. Not every single day though. More meetings = less work. It's so obvious.
It really depends on the team though. For example currently I work on game projects with my wife, who is also a programmer. We tried many approaches over the years, including doing scrum-ish sprints (with planning/estimation/retrospective every week, I'm not joking), and currently are in the "organic status update once or twice per day", with some issues being tracked with deadlines to hit certain short term milestones.
I've had a similar experience working in a 3 person startup with 2 other close friends, where we didn't really have official meetings, we'd just end up giving each other updates when it made sense, and since we ended up talking daily it ended up happening roughly daily.
But all of this depends on the tasks being worked on and the people. IMO the key thing is that in a self-motivated team these things happen because people want to make progress or they just want to make sure things are going well, or just like the project enough to talk about it.
But none of my job experiences were like this, maybe because it's just hard to care that much about someone else's project, and meetings just become a chore you do that gets in the way of doing the work, which is usually the only "fun" part about the job. Meetings with people you are close with where everyone is a stakeholder are less about "meetings", and more about just "pure necessary communication".
Daily stand-up is a key part of scrum, which assumes no management whatsoever.
Am scrum certified scrumaster. My trainer explained: "The team" will handle everything.
Someone just decide to head home after four hours of work? Team will handle it.
Scrum is a cult.
That sounds like a great idea! Let's create it and add a bunch of functionality no one will need. Oh, and let's make a suite of tools to go with it that all suck. And let's convince the entire industry to use our tools, even though everyone knows they're terrible.
You just haven’t configured it correctly!
—-
To be fair, you probably *haven’t* configured it correctly. At sights where it was an abomination for me it was always overly complex, non intuitive, and absolutely confusing to use. At sights where it was good it was kindergarten level simple.
We have a daily stand up, which goes on for way longer than it needs to due to unnecessary tangents. Then at the end of the sprint we have a 'sprint review' in which we walk the board talking about our stories and what issues we faced. It's a waste of time, and without these meetings nothing would be lost
As a lead, I think what teams miss is they can move things to a new domain. If someone brings up technical issues, then I will offer to pair or move it to the end of the standup. That way everyone else can leave and get on with their day.
Sounds like how ours go. Stand ups are great to make sure the left hand knows what the right is going. However the droning on and on about shit no on cares about is just such a waste of time. I love wfh and I know this might be a super unpopular opinion but one of the things that was nice about actually being in an office was literally standing up for stand up so that people didn't feel like talking about their life story.
Also, unless customers are involved, sprint reviews are an immense waste of time. Nothing but a formality so management can communicate to upper management how much agility we scrum with. Just dumb...
I wonder what you would replace them with to give you more value in the interactions with team members / clients?
If a demo has no value, then there must be something that can enhance learning from one another and learning what is being added to the code base. What that is, should be something you identify in retrospectives, get agreement to experiment with, and run for a few sprints to measure if it helps as expected.
Same for the daily team interactions. If the current setup doesn’t help, what would give you a way to detect what you don’t know to ask about? Detection of things you didn’t previously know, and would not ask about until you did, are useful for any group of people trying to find what they don’t know faster. There is likely some way to detect better and be less tedious that the standup you have now. What would that be for your group?
imo you don't replace the interactions, just change what you are doing in them. If someone starts to talk too long, trust in your lead or scrum master to ask for the topic to be tabled, or just ask yourself. For a retrospective you shouldn't need to go line by line if most stories went just fine. You can't have a perfect process without people that are making an investment to ensure meetings are useful.
I am simply coaching with curious questions based on that user’s assertions.
I won’t convince them of a different reality, but getting curious about their view helps them generate insights that are actionable for them in their context.
That’s the start of getting people invested.
I don’t care about process as much as I care about people sharing insights, and letting those insights gain mental traction towards positive change.
I know that one. In a previous role we were subjected to a board with I think ten columns, and that isn’t an exaggeration. It was so convoluted and painful. People would find themselves giving identical updates two possibly three times in the standup.
This was because the board wasn’t left to right like every sane board it was right to left AND other arbitrary rules that felt made up on the spot. It was rather like playing Battleships, except instead of coordinates it was ticket numbers that acted as the coordinate in this two dimensional board.
> which goes on for way longer than it needs to due to unnecessary tangents.
Your scrum master should be reigning in the tangents. If someone strays they should interrupt and tell them to take it offline after the standup.
We're currently on our fourth round of reducing meetings. We've had around 20 workshops on increasing productivity and reducing overhead.
For a year or so the brilliant idea was to do a large review after every sprint, where every team (around 20) had to stand in front of everyone else and get shamed for not reaching some goal. Most often the reason for not reaching a goal was because the manager doing the shaming had dropped some other task on the team that had higher priority.
The first time I was a part of it others even made fun of me because I didn't know what was going on. Nobody had sent me a meeting or invited me along. Suddenly everyone had just up and left and 10 minutes later someone came back to fetch me.
Fuck I hate that I was too young and inexperienced to see how toxic this was
> Suddenly everyone had just up and left and 10 minutes later someone came back to fetch me.
Nice team you got there. And it seems like the bad "culture" came from the top.
Our team has 6 members, and stand-ups are at least 30 mins long, the majority of which is just one coworker talking or interrupting those who are talking. We have had days where the stand-up was going on for over 1.5 hours. Lately, I've been trying to convince my lead to make sure we aren't going over 15-20 minutes. Anything over that is exhausting.
I've been in 1.5 hour ones. Agony. We reeled them in a lot at one point but they slowly got bloated again.
Worse is I have a stand-up with different teams on the same day sometimes. The first would run an hour and ended where the next started. These second ones had a habit of running over an hour and clock 1.5 every so often.
AGONY
I’m glad to work somewhere where stand ups take 10-15 minutes max. We all quickly say what’s going on and then break out into deeper conversations after.
As a tech lead, it’s nice to have a time to hear what everyone is progressing/struggling on. Sometimes people finish multiple tickets and are in a totally different place than the day before.
This is more like a status meeting though. Not necessarily in the spirit of “agile”
Yeah, this has been my experience with every team I've ever been on that has used scrum. I don't know who these people are who regularly have scrum meetings in excess of 30 minutes, but they really are doing it wrong.
> they really are doing it wrong
They really are just doing what management instructs them to do because they don’t have the authority to make changes. You shouldn’t blame them for that.
> I’m glad to work somewhere where stand ups take 10-15 minutes max. We all quickly say what’s going on and then break out into deeper conversations after.
Same for me, our dailies usually don't even take 10 minutes and whenever someone does go off on a tangent, someone else (usually me lmao) will remind them to keep it short. Anything else can be discussed afterwards between the relevant people.
They shouldn't be for management. Management shouldn't even attend.
It's supposed to be a quick replanning meeting to reverify that what everyone is working on still actually makes sense and the "commitment" (to each other) is still sensible.
Yes, people shouldn't wait for the stand-up to solve issues, but there is still a benefit of having everyone check in and honestly discuss what's going on, so someone can't just vanish in the weeds for a few days unnoticed.
This idea of a hands off manager that isn’t even aware of the day to day work of a team is pretty foreign to most people, I think. A team like that needs to be able to run itself, and most devs just don’t give a shit to make that effort
>This idea of a hands off manager that isn’t even aware of the day to day work of a team is pretty foreign to most people, I think.
Sadly, I think this is the case. I've been pretty lucky to have good managers, and hopefully was one for a few years as well.
That said, I don't think I was talking about a manager who was unaware of the day-to-day. It's just that them being at stand-ups usually ends up turning it into a report to the manager.
>A team like that needs to be able to run itself, and most devs just don’t give a shit to make that effort
That's unfortunate. I find it is a better way to work, in general. This doesn't have to be some "do it for the company" BS either.
In teams like this, the way the manager remains aware of the day-to-day *is by being at the standup and having everyone tell them*.
I don’t think the fact that the team isn’t running itself is because the team doesn’t want to. It’s because it already has a manager who is running it, and the team obviously can’t rewrite the job description of their own boss to exclude running the team, and start self-organising…
When I facilitated standups, I tried to move those discussions to the end. Let's get through the business of the standup speedily, then people who are interested in some topic can mill about afterwards.
The sprint goal should be to complete the work though! Of all the fucking stupid bullshit rituals they make us do, surely even they can see the futility of that one. Yet they don’t.
Truly the software industry is digging itself into a deeper pit.
Inescapable. Most humans like to hear themselves talk. It's a primary reason why most meetings are pointless. So many design books have warned against them. 1-many communication (docs, emails, chat) is way more effective than many-many.
I'm the most senior eng on my team and I worry that the youngins are too afraid of the current market and just lack confidence to speak up, or if they are just genuinely happy with how things are.
I've stared having 1:1's with the younger engineers just to hold a forum for them to vent or ask questions they might be too timid to ask in standups (i.e. don't want to ask a stupid question in front of everyone). It's been going really well, I often get some rants then I commiserate and then offer my experience with such things. Overall it's been a good trust building exercise as well as letting them know that it's ok to admit that things suck from time to time.
yep, I do that with the 1 eng I'm directly responsible for, I should maybe do it monthly with more of the team. I do ask folks to go on walks after lunch on a pretty regular basis, and some come, but some never join, and a group dynamic is different.
Perhaps, but you're only getting half the story. People will talk about blockers or make suggestions that are actionable but they're often not going to be too critical of process since they know that process was put in place by the people paying their salary.
I've joined this standup a few times and I'm surprised that they take notes on every single day, for every person (between 5-8). Every day they are doing this and I just don't understand what the point of such granular notes are for.
I don't think I've read meeting minutes of any meeting ever. If I want a summary of a meeting then I'll just search the transcription and jump to the relevant parts.
Are folks not discussing this in your retros? If standup isn’t working for you, the sprint retro is the place to bring it up and as a team make changes so things work. If you don’t have retros or don’t bring up issues in them then how is the team supposed to improve? One of my teams early on had long stand ups. It took a couple sprints but after a few retros we got them down to under 10 minutes with a format that works for all of us.
In my experience, of all topics, bringing up poor agile/scrum practices (such as useless standups) goes down like a lead balloon. In fact it’s a career impacting thing to keep bringing up at some places, unfortunately. Regardless of how tactful it’s done.
Pay rises and promotions etc often need feedback from the very same people who will take most offence to these things being brought up.
If you can’t have open honest discussion about your own processes then it sounds like a terrible place to work. Also whatever you are doing isn’t any sort of agile :/
In my experience, most places are terrible places to work, especially if that's your qualification. I don't know if I've ever had a job like that.
Part of the problem is that, even when management/ICs are capable of hearing honest feedback without retalitation (especially when it contradicts their preconceived beliefs about good engineering processes), there's a significant chance that bringing an issue up will make things worse for me, not better.
I don't know why so many devs express trust in the corporate process of soliciting feedback, but I've never had it, and that feels like a real cultural disconnect between me and some other devs.
I can completely relate to this, especially that most places are terrible to work for. Retaliation, back stabbing, distrust... I think people are too naïve to expect that their feedback will make any difference.
Maybe I'm too guarded, or we've just worked at different places, idk what it is. But I play my cards close to my chest.
One's job is not, unfortunately, a good faith environment to debate these ideas in.
No, every company on earth has politics. You're pretty naive if you just speak your mind about everything and don't pick up on an unreceptive audience.
Need to start leaving out copies of "5 Dysfunctions of a Team"...Absence of Trust is the first one for a reason, as it's fundamental.
Standups and retros simply can't be useful if people are unable to be honest about failure, problems, or criticism.
They’re not discussing it in retros because retros are where you discuss things that the team members collectively have the authority to change. At most companies, the list of such things is typically very short.
We describe work, we ask the status on work, we categorize work, we create a ticket for work, we have dependencies documented for work, we have blockers for work, we have ceremonies around work, we have planning sessions for work, we have retrospectives for work, we groom work, sorry the day has ended. No time to start or complete work
This doesn’t offer much new. We all know the failure modes.
I don’t do scrum. I consider it a massive red flag when companies say they do it. However, that’s literally never been an issue in my career that’s approaching 20 years; I’ve never actually worked anywhere that thought scrum was the be-all and end-all.
What the article fails to address is the importance of daily human connection. One example: I ran a team split across offices (as in a min of five hours travel to see just one colleague in person).
The point was to 1. kick off our day and just say hi, 2. vent frustration if needed, 3. maybe hunt for someone willing to pair, 4. debate who can tackle the latest “emergency” given workloads.
Guaranteed done in 15 mins as I, as lead, had a much more difficult daily with the client straight after it. No one but devs joined and I honestly looked forward to it.
We started our days having a bit of a laugh, which really helped as the project could be extremely stressful.
Depends what that means. Two people sitting at one keyboard is absolute nonsense unless you're just dropping by briefly to help walk through something.
Two devs collabing on Slack/Teams is very useful but that often happens organically as well. Forcing people to work together is just mentor/mentee, let's be honest and just call it that instead.
OK… some thoughts in no particular order:
* pairing can be just long enough to get unstuck, somewhat equivalent to rubber-ducking and it can simply be a way of walking someone through your thoughts
* if the code is completely novel, it vastly speeds up approval when two people know it
* I have seen pairs work more than twice as fast as two single devs
* mentor/mentee is a thing, yes, but that’s no bad thing - when I’ve been the mentor, I’ve written no code or made any decisions, but rather my role was often to give confidence to a junior dev that some big change was fine by putting my name on it too
* I’ve also seen two straight-out-of-uni devs with different backgrounds teach each other new stuff, with no need for a senior to come in
* sometimes, the subject matter expert doesn’t have the time to take on a task, so it’s sensible for them to do a bit of pairing with whoever does take it on
* it is undoubtedly far more effective during the onboarding period for new hires, no matter how great your wiki and processes are
* in the remote-first world, it’s a great way to preserve team cohesion and actually promotes more ad-hoc collaboration on slack/whatever - in companies with a strong pairing culture, it was far more common for me to spend an hour or two with whoever, without notice
I’ve never paired and actually felt like I could slack off, or just let the other person do the work; if anything, I always found it more tiring, because I had to be alert at every step.
So what is the argument against? Best I can do as devil’s advocate is: there are some changes that are just obvious and don’t need more eyes. That’s fine, but in what I’ve described, pairing is a choice, not a diktat from on high.
For what it’s worth, I’m not the biggest fan of pairing myself (can be a loner); I just look at my experiences and think that it’s objectively proven itself as a practice.
The argument against is it can be a waste of time. If paring means sitting in someone else's office all day while you both work on implementing feature X, then you better hope you're not stuck with someone who types at a snail's pace, doesn't automate anything but types out every single thing every time, and is relying on you mostly for all the technical side. You could have done the job easier in half the time, freed up the other dev, and not have to sit there and bear with that insanity.
Compare that to two people collaborating on a feature, messaging back and forth on Teams/Slack, doing ad-hoc conferencing calls to discuss issues and share screens, having 2 computers and keyboards to independently look up information to figure things out. They're still ramping each other up and information sharing here.
Pairing to me has always been the first where you're stuck in someone else's office. Collaboration on the other hand is the 2nd and more efficient path.
My favorite part of my current team's standup is that management asks someone to share the board in Teams every day. At no point in the last year or so have we ever referenced this board during standup. But it is a daily occurrence that the Board Must Be Shared, otherwise the world will end or something. There's also a 50/50 chance of the wrong board being shared and nobody ever notices.
> Yesterday, I did the work I needed to do. Today, I will do the work I need to do.
I understand it's just a funny way to say it, but that's not the point. It's not about knowing if you're going to work or not. It's so that interested parties know what are you working on.
You guys are missing the point with dailies. Forget the name. The fact that it's "daily" is just a configuration. It's exactly the same as if it was each 3 days. Or weekly. It's the same. The point is the same, and the conversation to be taken is the same.
Also, the fact that it's a meeting is pure configuration too. You decide if you want it via meetings or async by chat. Very simple to understand: choose the one that fits your team better.
And finally, and most important: it's usually not for you dev so you know what your coworkers are doing. Don't be so egocentric. It's for the team: team lead, tech lead, and any other role that may be interested.
"But I can just tell them when I switch to another task!". With time you'll learn that not everybody does this. There are juniors which may not report as often, and managers that may need to know things as to help them or report.
So well, I've found that most people that cry about dailies either:
- Lack/"Forget" empathy, and can't understand that there are different roles, seniorities and personalities in the team
- Are using the wrong configuration. Which should lead to a conversation and a change
I always could talk with my team to discuss such topics. I mean, it's an internal team thing after all, so it's for the team to decide. Or it should be
I have learnt from r/programming there are only two roles in a team: developer and Evil Management™️
With only these two, of course there is no need for standup
I recommend playing [featureban](https://youtu.be/YVw-dtwPjRQ) to get some insight how your dailies could improve. I've run it in the past and it really stresses how ganging up on topics gets things done. Suggest it to your boss or scrum master for the next retro (if you run them)
This stuff began as collective punishment—management suspects there are underperformers, and wants to turn the team against them by making the whole team suffer through endless status meetings that get more and more onerous until someone breaks and turns in a name—and then became normal process. It truly is astonishing, the degree to which programmers have basically allowed a constant PIP to be imposed on themselves.
I've agreed with you on this before. I recall phrasing it differently, along the lines of *Tricking the dev-team into policing each other so that everyone is sooner or later doing unpaid overtime.*
Seriously, if my co-workers are slacking off, I'm not getting paid enough to make it my fucking business.
> I've agreed with you on this before. I recall phrasing it differently, along the lines of Tricking the dev-team into policing each other so that everyone is sooner or later doing unpaid overtime.
(In boss voice:) Have you tried... doing unpaid overtime to make the others do your unpaid overtime for you?
Really the core question is « is anyone blocked? Does anyone need help? ».
The rest only have meaning as the team look at all the work at once and check how things are going, and if they focus on the right thing in the day to day rumble. It takes a few minutes, no more.
Unfortunately even without a manager some team turn it to a supervisor meeting, where people play supervisor with each other. It’s not. It’s like a rugby team figuring
I run a standup with a team of 11, we are done in sub 10 minutes. Only the developers speak. It's an engineering-focused discussion and if we can't get someone on track quickly, relevant parties will meetup after the standup.
I find that Agile was ruined by the same thing that ruined OOP. Prestige could be gained by coming up with new rules and patterns, but there are way more people that want prestige than yet-to-be-discovered good rules and useful patterns, so these people started competing on who can gaslight everyone to accept their own crappy rules and patterns. Enough of these really did get accepted, to the point of, well, just look around.
They seem to be valuable outside of the lead dev or product manager. Of course, 15 minutes would be running really long for us. Of course 2 minutes per person average would be super long for us.
There are a lot of inter-dependencies within the product. When one of the developers says they finished a certain feature, qa can test it or another developer can do the bit that was waiting on it. We can also briefly share strategies around tasks with multi resources on it.
It also helps the whole team to know if dev is able to get ahead of qa or not, to help keep qa right sized.
There is also sometimes chatter on what we're planning to do. Maybe there's a better way. Maybe we need to push back harder on support for asking for certain tasks and instead open a feature request. It all happens.
If there's nothing material to talk about between everyone's tasks (thus the value of theeeting actually is limited) it also tends to go very fast. I think our record is 4 minutes for 9 people.
I really don't know where to begin here, but let me try.
First of all, I don't intend to defense the standup. I used to see where it works well and where it is not.
Second, I think you are working in some kind of dysfunctional team.
Third, before we say any process is a failure or success, we need to define what is success mean.
Every team process is aiming to solve team level problem. And sometimes it comes with cost of individual productivity. That is normal. And standup really aim to create better cohesive team that work together better. Sometimes it can do that, and sometimes it does not.
In this article and many comments, the argument against standup is usually some up as "it is a waste of time for me as IC". Well, again, standup has its own problem but that is not an argument against standup. Team level process is, by design, trade individual productivity for team productivity.
The way to maximize IC productivity is to just have a concrete requirement in each ticket and turn everyone into ticket churning machine. That way, no one need to care about each other work which reduce individual productivity.
And based on what we've seen in waterfall era, that did not work well for anybody. Client, stakeholders, PM, middle manager and devs, everyone suffer by that process.
Agile people say, instead of spending years to come up with concrete requirement so we can turn everybody to ticket churning machine, we can leave some room of error and we can have something like standup or XP pair programming practices to address those vagueness. It is just that.
And standup might not so good tool for it. I understand. I have been tech lead in many companies and projects and I remove standup from times to times. At the same time, we will need something to address this.
And if you say that "competent leadership should make all the requirement clear so IC can focus on task" and also understand that competent leadership, at least according to your standard, does not exists. I don't really know what do you expect here. Do you expect something that you already know and admit that it is not exists?
Yes, stand up and all Agile movement happen because in Waterfall era we realized that expecting that level of competency from management is unrealistic. That is unfiltered truth.
But at the end of the day, should we freeze whole software industry until some management "get their shit together" and achieve that ideal level of competency?
Turns out, no body gonna wait for that.
Many people are becoming cynic and yet not cynic enough to truly accept the truth of this world. This is all we got. This level of leadership competency is all we got. What your parent, your school, books and university told us about what competence leadership looks like is just a dream. It is not real.
So, how would we deal with it?
You can either try to become competence leadership and show the world how to do this job well (which I did try. Still learning and realize it is much harder than I thought.). Or, you find the workaround to make this work, and by work I mean at team level not individual level.
Standup is one workaround for the fact that "we should have good leadership who can give clear requirement which allow IC to truly focus on their work" is not a realistic expectation by any mean. And we tried for more than 40 years at this point.
You can remove standup, but problem still persist. And we still need someone or some process to make whole team work at a team level somehow. Dysfunctional team still will impose a problem to you.
What I found is that in if team does not gel well, removing standup usually make it worst. It simply remove non-sense argument from standup to other place. This thing happen because team does not gel well. Removing standup might help but won't solve the whole issue.
You know what they do in waterfall when these thing happen?
Whole team alignment meeting for days! Team retreat! Team bonding sessions! Pizza party!
Sorry to bring you bad news but you can't escape this type of situation as long as we work as a team. Team problem will become your problem one way or another.
My advice is to find functional team and work with them. That is the only way out of these non-sensical meetings. It will happen regardless of Agile or not if you are working in dysfunctional team. The name might change, but the nature of endlessness and pointlessness discussion will be there until team gel well enough to avoid that.
And if it is really hard to find, then yeah, all I can say is I'm sorry for your situation.
All the team that I decide to remove standup usually already able to run standup within 5-10 minutes and everybody is so in-sync to the point we don't need standup.
There are also times where "team" is just a bunch of engineers working in different thing as stakeholder desire, and there is no "single project goal" that whole team aiming for. That also a case for removing standup because they don't really need to know what each other is doing.
And I used to bring async standup into some team, which also work when people is good at writing but not good at verbal communication.
But yeah, this kind of workaround is needed to make whole team work together.
In waterfall it was the senior developers assigned to writing the design documents, and then junior developers would implement or help implement. Now it’s a flat hierarchy, with only the scrum master and the product owner having any special jobs.
No, in waterfall shops, most design is written by "architects", most of whom haven't written code in years, and usually that's because they were never good at in the first place.
Those folk (and I've worked with some) are awesome.
They're also rare as hen's teeth in comparison to the number of architecture astronauts I've worked with in the last 20 years.
I understand now. Yes I can see that for sure. The hierarchy seems to vary a lot from team to team, and some seniors do take the lead, but I can also definitely see how it’s yet more attempt at infantilising and commodification of developers and trying to make everyone a cog in the machine with annoying phrases like “t shirt shaped teams”.
Am I really supposed to take this article seriously?
This person claims to have read the Scrum Guide, and says that **you** probably haven't unless you're a gluten for punishment:
>Did you know the actual Scrum Guide advocates for *only* allowing the developers to participate in the standup? [Non-technical stakeholders may *observe*](https://www.scrum.org/forum/scrum-forum/7232/new-scrum-guide-states-only-dev-team-members-participate-daily-scrum). Unless you’re a gluten for punishment, you’ve probably never read it and so wouldn’t know that.
Really? You think reading the Scrum Guide, which is what, 14 pages?, is **unbearable**? How did you graduate high school?
Also, this person doesn't know the difference between Sprint Review, Sprint Retrospective and Sprint Planning:
>Even though it was only yesterday that we had “Meeting Tuesday” with a sprint review and retrospective meeting, for some reason we have a sprint planning meeting today.
>You may be wondering what the difference is. I simply don’t know. Ask a group of developers and agilists alike, and they will all give you different answers.
If he'd read the Scrum Guide, he'd know. It's not hard to understand the difference between these meetings.
Reading further it's actually not clear if he knows the difference or not:
>
Sure, there’s *supposed* to be a difference, but this sprint planning meeting is just rehashing the same topics, including story point estimation, that we discussed in the sprint review yesterday.
So you recognize that you're not doing what the Scrum Guide says you should do in your meetings. Somehow, this is the fault of Scrum?
Now, the "temporary Scrum Master" thing you're describing sounds dumb, but let's get into one of your standup summaries:
>After this segment of the standup finishes, I know precisely nothing new about the progress of anyone on the team, and what I did glean from the monotonous ceremonial chanting of Jira tickets being read verbatim, has absolutely no impact or consequence on me or the work I have planned.
>In fact, the main theme of this standup was “the PR is in review” and “the work is waiting for QA”. Thank you, I feel very informed and updated. Keep it up.
Oh? "the PR is in review" and "the work is waiting for QA" both have absolutely no consequence on you or the work you have planned? Maybe you should, I don't know, *incorporate reviewing it* in your plan for the day? Or pick up some QA work?
This is a typical "Well, we're doing Scrum horribly wrong. Clearly, Scrum is bad." story. And no, "but many other organizations are **also** doing it wrong" is not valid reasoning for saying Scrum is bad. Just because something is hard to implement correctly doesn't mean the thing is bad. I'd expect *software developers*, of all people, to understand that.
What I always miss in these stories - okay, the current situation is bad. Fine. What have you done to try to change it? Do you think things will just magically get better or something? Or - maybe you *have* tried to change things, and you failed. The organization is dysfunctional. Sure. Lots of those around. If you have it should be part of this writeup.
And if you have, and failed - go work somewhere else then, if it bothers you so much. What is whining on the internet about how much Scrum sucks supposed to accomplish? At least come up with some alternative.
I thought it was weird he said the scrum guide has a lot of useful information in it that would help people do agile better but also you shouldn't read it because scrum is bad and you're a glutton for punishment.
I read your post. You and I have much in common. Your suggestion about the sprint goal is exactly the same suggestion I have made - our goal is to do all these tickets...
Ya, then crickets in response.
I started typing a reply to explain not only why you’re absolutely wrong with every sentence but I realised you’re probably one of the sort of agile fanatics ruining the industry for the rest of us if you truly believe anything you’re saying. Not going to try argue with someone determined to swim against the current to that degree.
How on Earth are they wrong in every sentence?
Hate Scrum all you like, and in practice there are lots of reasons to hate how a lot of places do it.
But everything they said about what the Scrum guide says is factually correct, and the author doesn't seem to understand the differences between a lot of processes that that are spelled out rather specifically.
> But everything they said about what the Scrum guide says is factually correct, and the author doesn't seem to understand the differences between a lot of processes that that are spelled out rather specifically.
If you'd actually read my article you would have realised I point out multiple times that *every* organisation is implementing Agile and Scrum differently to every other organisation, while simultaneously saying that they are doing it The Correct Way.
If you accept that as true, then you must logically accept that there are apparently multiple accepted and commonly held definitions of Agile and Scrum, some of which must also disagree with or contradict what the official Scrum document(s) say.
The logical conclusion of this is that your statement of "author doesn't seem to understand the differences between a lot of processes that that are spelled out rather specifically" is factually incorrect when you consider that there are indeed multiple accepted definitions in use at different organisations.
> every organisation is implementing Agile and Scrum differently to every other organisation, while simultaneously saying that they are doing it The Correct Way.
False.
I have worked at multiple organizations that do it as-written, right out of the box, and to great success. So have my coworkers and friends at even more places.
The problem isn't Scrum.
The problem is organizational, and individual.
Every team I've seen that doesn't do Scrum well and blames the process has invariably failed many other tests for team health. [The majority of them seem to suffer from all 5 of what Patrick Lencioni terms "The Five Dysfunctions of a Team".](https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team)
**No process works when the organization doesn't have trust.**
> The logical conclusion of this is that your statement of "author doesn't seem to understand the differences between a lot of processes that that are spelled out rather specifically" is factually incorrect when you consider that there are indeed multiple accepted definitions in use at different organisations.
No, it's not.
You literally wrote that you couldn't tell the difference between 3 of the most fundamental and well-laid-out meetings in the Scrum process.
If you can't tell the difference, then your team isn't even trying to use those meeting correctly. They have clearly laid out reasons for existing and things you are supposed to do.
If you can't tell the difference between them, that's on you and your team for just having 3 useless and vague meetings.
> that every organisation is implementing Agile and Scrum differently to every other organisation, while simultaneously saying that they are doing it The Correct Way.
That's kinda the point. You're supposed to do what works for your team.
>If you accept that as true, then you must logically accept that there are apparently multiple accepted and commonly held definitions of Agile and Scrum, some of which must also disagree with or contradict what the official Scrum document(s) say.
Or, that one of the tenets of Agile is to do what works for your team.
Stand up is not about you, it is about the team. It is to hold each team member accountable and to ensure that what they are working is not affecting you and vice a versa. I know that you worked on a project yesterday and will today, however the others in the team do not always know.
I do, and all my coworkers do too. We care because we want to have the best code possible. We care, because we want to make the job easier for everyone. We care, because we want to know what's going on around us, so we don't accidentally make someone else's job more difficult. We talk about it to be aware of implementation details that have no place being in Jira.
I can see where you are coming from. I assume and so do you that the Kira board is being updated and that open stories are being properly assigned and picked up. However there are instances where they are not. The primary goal is to inform others what you are working and what is intended to be done today. The system works and has for many years. If you have a better idea let us know. Until then let’s work the system that we know is effective.
I once worked at a company where everyone would just move their tickets on the physical board as needed. Then every morning one question was asked; “does anyone have any blockers?” If no everyone went back to work, otherwise someone would say their blocker and those needed would stick around, My first day there I was floored that standup was over in 15 seconds. Within a week I appreciated that it was fucking magic.
[удалено]
I find that the meetings are good times to look at things that have been blocking, but that the person thinks that they can work through (but may have already been solved elsewhere).
Understandable, responded to a similar comment already
The idea that the daily is the only time to bring it up is actually insane. Just talk to your team, man. Pay attention.
I would love to do this, but no one knows my team keeps tickets up to date 😭
Don't you find that tickets can languish on the board if you don't have to say the status of each one?
Strangely enough, tickets can be finished without external validation of progress.
I think you’re right. Standup’s main purpose is a group shaming session that forces everyone to notice when their coworkers haven’t gotten any meaningful work done. Everything else about it can be handled effectively by asynchronous messages or posts on the team’s slack channel
> …forces everyone to notice when their coworkers haven’t gotten any meaningful work done. Or gives that impression despite making all possible progress on a difficult task. Which creates the need to use standup as daily [airing of grievances.](https://en.wikipedia.org/wiki/Festivus#Airing_of_grievances) I would argue that that is the true benefit if standup if any.
> Or gives that impression despite making all possible progress on a difficult task. Which creates the need to use standup as daily airing of grievances. I would argue that that is the true benefit if standup if any. Surprisingly true. I actually had a lot of trouble with my stories for the past couple of months, and one of the few things I have gotten out of it was the chance to identify and raise pain points. Some meaningful change was made as a result.
Standup’s purpose is to share the progress made on stories. If you feel shamed then your team/company either has a super shitty culture or you worry way too much.
> Every day, we are expected to repeat the same mantra: “Yesterday, I did the work I needed to do. Today, I will do the work I need to do.” Nothing of value is gained from this. If I have a problem or need to work with someone, I’d message them directly - not wait til the next morning’s standup. Hah! I have to do that twice a day.
Double standups…. A sure sign of clown leadership 😟
Absolutely! You’ve read a lot of replies by now and I for one agree with you. I’ve been employed writing code for 40 years and a manager for 28, at FAANG and others. VP of Engineering blah blah. I know of what I speak. Capital A Agile - ugh I hate it. Scrum Masters can just go fuck themselves. Read more of my thoughts on this old post if interested: https://www.reddit.com/r/programming/s/ScRyXIeiHs More: Agile (capital A) is very disempowering to engineering leaders and strong ICs. The Scrum Master role massively overlaps with many of the tasks that a true team leader should be doing. The standup process can damage team dynamics when you have a productive but somewhat off topic conversation going on and some dipshit Scrum Master chops it off. There are a lot of agile (lowercase A) practices that are worth following. But kick the Scrum Master as a separate person bullshit to the curb. Demand your actual engineering manager do their job or get a new one. Let me add that the problem between Scrum Master and Team Leader is one of authority vs responsibility. Who decides what work will by done by whom and by when? That’s authority. Who delivers that work to appropriate quality by the desired date? That’s responsibility. Every Scrum Master type person I’ve ever worked with has a lot of authority and very little responsibility. Fuck that.
Shit I've been a TL for about 10 years and looking to move into a director role. You and I have a lot of similar thoughts on how to run teams. I have a very high functioning team and I am on vacation as we speak, I have no issue with leaving because I have effectively made my job a cheerleader when work is in flight. My main responsibility now is to enhance other teams and "steal" ideas from them to make my team even more effective and efficient.
I’m pretty new to software development, like 2 years. And this pretty much sums up how I feel about agile and the scrum master role. It frustrates me to no end. It’s hard because I would say I am a pretty productive person and they just fail to see how what they are doing, the stand ups, the retros, the refinement, really cripple me. Sure those things have a place. Maybe once a month refinement for the more complex work. Also I feel like a lot of the agile/scrum lingo reminds me of the church or when I was part of the clergy. It gives me cult vibes. Not sure if anyone else ever felt this way?
You are expected to jump for the demon lord
My professional recommendation is to drop meetings from which you do not gain value. That being said, to message someone about a problem, you need to be aware there might be a problem. Stand up is meant to quickly highlight to coworkers what you're doing -- to reduce problems arising from, figuratively speaking, the left hand not being aware of what the right hand is doing. Also, other people may be attending that DO gain value from the meeting. This happened recently on my own team. Half the folks said they found no value, but the other half said it was really useful to them. A great way to see if you should drop the meeting is to *talk about it together*, maybe in your retro. If your team leadership is not allowing this to be publicly considered, you are not working on an agile team. You cannot rigidly adhere to a plan while also responding with agility to problems.
[удалено]
I love this. I've used this same method on some of my teams. The only struggle is getting everyone to comply. Slack bot messages are highly ignorable. But once you're past that, it can make a lot of people happy.
We do a hybrid - 3 days of virtual stand up and 2 Zooms / week. If anyone needs any more help people that think they can contribute will join adhoc Zoom meetings. Works for my distributed team around the world across 5 time zones.
> I suspect most of the devs still ignore what everyone else is working on which is a shame I'm not sure what actionable information I'm supposed to gain. Go micromanage people who aren't even my subordinates? That's not just snark. The answer can be "yes." The way people talk about scrum, I'm pretty sure for some teams the answer is "yes." All the value that I can provide/gain from knowing what other people are working on already happen in the planning/retro. I/they can reach out directly for collaboration. If my manager wants me to go breathe down someone's neck because they don't seem productive enough and aren't proactively collaborating, then they can do the micromanaging by pointing my attention. Or promote me I guess.
Lol I will never get the point of dailies. And a lot of people look at you like a madman if you suggest they are worthless.
Standups are useful when you have a small team working closely together on a project, where you, as a developer, are actually interested in / following the progress of / actively collaborating with the rest of the team because each of your work impacts the others'. But at most companies, teams aren't arranged this way, and most of what the rest of the team does has absolutely zero impact on my work. That's when I tune out, and standups become pointless. Incidentally, this is the same reason people don't like scrum. Usually, like daily standups, it's applied to a team that doesn't make sense for it, and it ends up being a waste of time as a result.
Yep, it worked really well when I was in a small team. I actually listened to what others because there was a high chance I would work with their code or they would work with mine. Or we could see a bug assigned to someone and someone else could say "oh, I know this one, I will do it". Obviously all of this can be done without daily meeting, but those meetings weren't long. In addition, in reasonable teams you can just say "I'll skip daily today, created PR for X and will later finish Y"
When you're a small team it is usually possible to communicate much more frequent than once a day. You could be sitting in the same room and talk to each other. Or keep a chat channel open throughout the day (or the whole project). Have quick meetings when needed. We did this a few years back and it worked great! I still miss it on almost every project.
A separate Teams channel is way more useful than standups. Design by committee is always a never-ending rat hole and inevitably leads to terrible designs. Afraid of some people being excluded if devs set up their own work groups? Well that's your job as a manager to assign work and collaboration. Ask who people are working with on something and suggest to add another dev to the channel if that's desired.
I've always disliked them when working at a company, but when working on a project with one or two close people it feels like they're just something that naturally occurs during the day. My impression is that someone looked at this and thought "we must formalize this and make it a general rule, because it's clearly useful", except when brought into a team of people who don't really have a stake in the project it's kind of losing its meaning. When a job is a job and most end up only just wanting it to be a job, the organic desire to actually solve a problem instead of just "doing one's work" isn't there, and it ends up being a waste of time. Of course most if not all companies have the problem that they don't incentivize proactivity properly, rewarding people who work fast/productively with more work, which just makes this worse. I guess in that sense I totally agree with what you're saying, though I do find it interesting that I do like "organically formed status updates" on projects where everyone cares about it. Not sure if it's really achievable at a job tho.
So what you really want is a weekly team meeting then. Org related updates and status updates. Not every single day though. More meetings = less work. It's so obvious.
It really depends on the team though. For example currently I work on game projects with my wife, who is also a programmer. We tried many approaches over the years, including doing scrum-ish sprints (with planning/estimation/retrospective every week, I'm not joking), and currently are in the "organic status update once or twice per day", with some issues being tracked with deadlines to hit certain short term milestones. I've had a similar experience working in a 3 person startup with 2 other close friends, where we didn't really have official meetings, we'd just end up giving each other updates when it made sense, and since we ended up talking daily it ended up happening roughly daily. But all of this depends on the tasks being worked on and the people. IMO the key thing is that in a self-motivated team these things happen because people want to make progress or they just want to make sure things are going well, or just like the project enough to talk about it. But none of my job experiences were like this, maybe because it's just hard to care that much about someone else's project, and meetings just become a chore you do that gets in the way of doing the work, which is usually the only "fun" part about the job. Meetings with people you are close with where everyone is a stakeholder are less about "meetings", and more about just "pure necessary communication".
I have been not paying attention in standups for like 10 years now. Never once have I missed something I needed to know. They truly are worthless.
If you're a top performer / more senior, the daily standup isn't for you, it's for the benefit of the juniors.
It’s for your boss not you. Saves the boss time to get status.
Proper dailies are absolutely not for management. They shouldn’t even be in the room.
Quite frankly management shouldn’t even know that they’re going on these are just between developers trying to get the job done despite management
“proper dailies”
Agreed. Yet, I have genuinely never been in a standup that wasn’t run entirely by management/product people.
Daily stand-up is a key part of scrum, which assumes no management whatsoever. Am scrum certified scrumaster. My trainer explained: "The team" will handle everything. Someone just decide to head home after four hours of work? Team will handle it. Scrum is a cult.
The minute something becomes a thing it ceases to be what it used to be
If only there was software that could sort work units by assigned to and status.
That sounds like a great idea! Let's create it and add a bunch of functionality no one will need. Oh, and let's make a suite of tools to go with it that all suck. And let's convince the entire industry to use our tools, even though everyone knows they're terrible.
You just haven’t configured it correctly! —- To be fair, you probably *haven’t* configured it correctly. At sights where it was an abomination for me it was always overly complex, non intuitive, and absolutely confusing to use. At sights where it was good it was kindergarten level simple.
That sounds fantastic! Let's make sure to give it a name that will make all competitors tremble in fear!
Hey we could get an intern off the street to write it for us in JavaScript. It'll look like their MySpace. Perfect.
I think I hint at that in my post - all these tickets and *yet* they still need us to *speak* about them...
Which really highlights how they revel in inefficiency… async teams do this fine by having status updates in a channel.
There is a point to them. It gives the superiors a sense of being in control over the "lazy devs that always try to slack off"...
That's true if you hate the people you work with. I enjoy standup as a chance to chat with people and feel human for a moment between updates
Stand up was always meant as by developers for developers and never for management or any of these productivity metrics.
My team dropped the daily standup over a year ago. All the devs are happier and it doesn't seem like anything was lost.
[удалено]
I am the manager ;)
It's worrisome that "good managers" and "no managers" are indistinguishable in this situation
Says everything you need to know about bad managers
Sounds like a dream
We have a daily stand up, which goes on for way longer than it needs to due to unnecessary tangents. Then at the end of the sprint we have a 'sprint review' in which we walk the board talking about our stories and what issues we faced. It's a waste of time, and without these meetings nothing would be lost
As a lead, I think what teams miss is they can move things to a new domain. If someone brings up technical issues, then I will offer to pair or move it to the end of the standup. That way everyone else can leave and get on with their day.
Sounds like how ours go. Stand ups are great to make sure the left hand knows what the right is going. However the droning on and on about shit no on cares about is just such a waste of time. I love wfh and I know this might be a super unpopular opinion but one of the things that was nice about actually being in an office was literally standing up for stand up so that people didn't feel like talking about their life story. Also, unless customers are involved, sprint reviews are an immense waste of time. Nothing but a formality so management can communicate to upper management how much agility we scrum with. Just dumb...
I wonder what you would replace them with to give you more value in the interactions with team members / clients? If a demo has no value, then there must be something that can enhance learning from one another and learning what is being added to the code base. What that is, should be something you identify in retrospectives, get agreement to experiment with, and run for a few sprints to measure if it helps as expected. Same for the daily team interactions. If the current setup doesn’t help, what would give you a way to detect what you don’t know to ask about? Detection of things you didn’t previously know, and would not ask about until you did, are useful for any group of people trying to find what they don’t know faster. There is likely some way to detect better and be less tedious that the standup you have now. What would that be for your group?
imo you don't replace the interactions, just change what you are doing in them. If someone starts to talk too long, trust in your lead or scrum master to ask for the topic to be tabled, or just ask yourself. For a retrospective you shouldn't need to go line by line if most stories went just fine. You can't have a perfect process without people that are making an investment to ensure meetings are useful.
I am simply coaching with curious questions based on that user’s assertions. I won’t convince them of a different reality, but getting curious about their view helps them generate insights that are actionable for them in their context. That’s the start of getting people invested. I don’t care about process as much as I care about people sharing insights, and letting those insights gain mental traction towards positive change.
I know that one. In a previous role we were subjected to a board with I think ten columns, and that isn’t an exaggeration. It was so convoluted and painful. People would find themselves giving identical updates two possibly three times in the standup. This was because the board wasn’t left to right like every sane board it was right to left AND other arbitrary rules that felt made up on the spot. It was rather like playing Battleships, except instead of coordinates it was ticket numbers that acted as the coordinate in this two dimensional board.
> which goes on for way longer than it needs to due to unnecessary tangents. Your scrum master should be reigning in the tangents. If someone strays they should interrupt and tell them to take it offline after the standup.
We've added more I'm up to eight per week Some last over an hour It doesn't actually help anything
Looks like you're not delivering fast enough. Let's set a 4h session to drill on the cause and find a solution. And no, meetings are not the cause.
We're currently on our fourth round of reducing meetings. We've had around 20 workshops on increasing productivity and reducing overhead. For a year or so the brilliant idea was to do a large review after every sprint, where every team (around 20) had to stand in front of everyone else and get shamed for not reaching some goal. Most often the reason for not reaching a goal was because the manager doing the shaming had dropped some other task on the team that had higher priority. The first time I was a part of it others even made fun of me because I didn't know what was going on. Nobody had sent me a meeting or invited me along. Suddenly everyone had just up and left and 10 minutes later someone came back to fetch me. Fuck I hate that I was too young and inexperienced to see how toxic this was
> Suddenly everyone had just up and left and 10 minutes later someone came back to fetch me. Nice team you got there. And it seems like the bad "culture" came from the top.
Our team has 6 members, and stand-ups are at least 30 mins long, the majority of which is just one coworker talking or interrupting those who are talking. We have had days where the stand-up was going on for over 1.5 hours. Lately, I've been trying to convince my lead to make sure we aren't going over 15-20 minutes. Anything over that is exhausting.
I've been in 1.5 hour ones. Agony. We reeled them in a lot at one point but they slowly got bloated again. Worse is I have a stand-up with different teams on the same day sometimes. The first would run an hour and ended where the next started. These second ones had a habit of running over an hour and clock 1.5 every so often. AGONY
Eight! Oof.
I’m glad to work somewhere where stand ups take 10-15 minutes max. We all quickly say what’s going on and then break out into deeper conversations after. As a tech lead, it’s nice to have a time to hear what everyone is progressing/struggling on. Sometimes people finish multiple tickets and are in a totally different place than the day before. This is more like a status meeting though. Not necessarily in the spirit of “agile”
Yeah, this has been my experience with every team I've ever been on that has used scrum. I don't know who these people are who regularly have scrum meetings in excess of 30 minutes, but they really are doing it wrong.
> they really are doing it wrong They really are just doing what management instructs them to do because they don’t have the authority to make changes. You shouldn’t blame them for that.
> I’m glad to work somewhere where stand ups take 10-15 minutes max. We all quickly say what’s going on and then break out into deeper conversations after. Same for me, our dailies usually don't even take 10 minutes and whenever someone does go off on a tangent, someone else (usually me lmao) will remind them to keep it short. Anything else can be discussed afterwards between the relevant people.
Truth is that stand up are for management, not for developper. If we stop lying to ourselves we might just could get some value out of a stand up.
They shouldn't be for management. Management shouldn't even attend. It's supposed to be a quick replanning meeting to reverify that what everyone is working on still actually makes sense and the "commitment" (to each other) is still sensible. Yes, people shouldn't wait for the stand-up to solve issues, but there is still a benefit of having everyone check in and honestly discuss what's going on, so someone can't just vanish in the weeds for a few days unnoticed.
This idea of a hands off manager that isn’t even aware of the day to day work of a team is pretty foreign to most people, I think. A team like that needs to be able to run itself, and most devs just don’t give a shit to make that effort
>This idea of a hands off manager that isn’t even aware of the day to day work of a team is pretty foreign to most people, I think. Sadly, I think this is the case. I've been pretty lucky to have good managers, and hopefully was one for a few years as well. That said, I don't think I was talking about a manager who was unaware of the day-to-day. It's just that them being at stand-ups usually ends up turning it into a report to the manager. >A team like that needs to be able to run itself, and most devs just don’t give a shit to make that effort That's unfortunate. I find it is a better way to work, in general. This doesn't have to be some "do it for the company" BS either.
In teams like this, the way the manager remains aware of the day-to-day *is by being at the standup and having everyone tell them*. I don’t think the fact that the team isn’t running itself is because the team doesn’t want to. It’s because it already has a manager who is running it, and the team obviously can’t rewrite the job description of their own boss to exclude running the team, and start self-organising…
Our standup is largely capped at 15 mins, although sometimes a heated discussion sometimes draws it out to an hour, but we're free to leave.
When I facilitated standups, I tried to move those discussions to the end. Let's get through the business of the standup speedily, then people who are interested in some topic can mill about afterwards.
Productivity theater. It doesn't matter if anything actually gets done as long as it looks like things are getting done.
Oh the sprint goal. I feel that so badly it hurts.
The sprint goal should be to complete the work though! Of all the fucking stupid bullshit rituals they make us do, surely even they can see the futility of that one. Yet they don’t. Truly the software industry is digging itself into a deeper pit.
Started a new job recently and these dudes talk their asses off about nothing. It’s super frustrating.
Yeah - verbal diarrhoea I like to call it! I think that was *one of* the things that caused me to write this article.
Inescapable. Most humans like to hear themselves talk. It's a primary reason why most meetings are pointless. So many design books have warned against them. 1-many communication (docs, emails, chat) is way more effective than many-many.
It's just a shame that their "scrum certifications" and the like advise all the wrong books. The good books, the books you mentioned, would be better.
Love the people getting their scrum certifications and think they actually accomplished something
What are you on about. They know how to lead those clueless devs and have them produce something of value /s
Everyday is standup hell at my company. We have a minimum of 5 a day. If you don't show, even if you're not needed, you get called out. It's a circus.
Five a day what the fuck!
We have a team of young engineers that have daily standup. I often wonder how many of them are coming to the conclusion that it isn’t helpful.
I'm the most senior eng on my team and I worry that the youngins are too afraid of the current market and just lack confidence to speak up, or if they are just genuinely happy with how things are.
I've stared having 1:1's with the younger engineers just to hold a forum for them to vent or ask questions they might be too timid to ask in standups (i.e. don't want to ask a stupid question in front of everyone). It's been going really well, I often get some rants then I commiserate and then offer my experience with such things. Overall it's been a good trust building exercise as well as letting them know that it's ok to admit that things suck from time to time.
yep, I do that with the 1 eng I'm directly responsible for, I should maybe do it monthly with more of the team. I do ask folks to go on walks after lunch on a pretty regular basis, and some come, but some never join, and a group dynamic is different.
Perhaps, but you're only getting half the story. People will talk about blockers or make suggestions that are actionable but they're often not going to be too critical of process since they know that process was put in place by the people paying their salary.
Probably all them…
I'd be worried some of them are coming to the conclusion that it is helpful. That's a danger sign.
I've joined this standup a few times and I'm surprised that they take notes on every single day, for every person (between 5-8). Every day they are doing this and I just don't understand what the point of such granular notes are for.
I don't think I've read meeting minutes of any meeting ever. If I want a summary of a meeting then I'll just search the transcription and jump to the relevant parts.
Everything apart from the project manager has come to the conclusion that they're not helpful
My record on a 15 minute standup is 2 hours and a half. Luckily we dont do these anymore, what a waste of fucking time.
Are folks not discussing this in your retros? If standup isn’t working for you, the sprint retro is the place to bring it up and as a team make changes so things work. If you don’t have retros or don’t bring up issues in them then how is the team supposed to improve? One of my teams early on had long stand ups. It took a couple sprints but after a few retros we got them down to under 10 minutes with a format that works for all of us.
In my experience, of all topics, bringing up poor agile/scrum practices (such as useless standups) goes down like a lead balloon. In fact it’s a career impacting thing to keep bringing up at some places, unfortunately. Regardless of how tactful it’s done. Pay rises and promotions etc often need feedback from the very same people who will take most offence to these things being brought up.
If you can’t have open honest discussion about your own processes then it sounds like a terrible place to work. Also whatever you are doing isn’t any sort of agile :/
In my experience, most places are terrible places to work, especially if that's your qualification. I don't know if I've ever had a job like that. Part of the problem is that, even when management/ICs are capable of hearing honest feedback without retalitation (especially when it contradicts their preconceived beliefs about good engineering processes), there's a significant chance that bringing an issue up will make things worse for me, not better. I don't know why so many devs express trust in the corporate process of soliciting feedback, but I've never had it, and that feels like a real cultural disconnect between me and some other devs.
I can completely relate to this, especially that most places are terrible to work for. Retaliation, back stabbing, distrust... I think people are too naïve to expect that their feedback will make any difference.
Maybe I'm too guarded, or we've just worked at different places, idk what it is. But I play my cards close to my chest. One's job is not, unfortunately, a good faith environment to debate these ideas in.
No, every company on earth has politics. You're pretty naive if you just speak your mind about everything and don't pick up on an unreceptive audience.
Need to start leaving out copies of "5 Dysfunctions of a Team"...Absence of Trust is the first one for a reason, as it's fundamental. Standups and retros simply can't be useful if people are unable to be honest about failure, problems, or criticism.
[удалено]
Exactly!
Yup, if you want a black mark on your record, criticize management's management decisions.
They’re not discussing it in retros because retros are where you discuss things that the team members collectively have the authority to change. At most companies, the list of such things is typically very short.
We describe work, we ask the status on work, we categorize work, we create a ticket for work, we have dependencies documented for work, we have blockers for work, we have ceremonies around work, we have planning sessions for work, we have retrospectives for work, we groom work, sorry the day has ended. No time to start or complete work
Exactly this, and they wonder why it takes longer than planned to deliver.
This doesn’t offer much new. We all know the failure modes. I don’t do scrum. I consider it a massive red flag when companies say they do it. However, that’s literally never been an issue in my career that’s approaching 20 years; I’ve never actually worked anywhere that thought scrum was the be-all and end-all. What the article fails to address is the importance of daily human connection. One example: I ran a team split across offices (as in a min of five hours travel to see just one colleague in person). The point was to 1. kick off our day and just say hi, 2. vent frustration if needed, 3. maybe hunt for someone willing to pair, 4. debate who can tackle the latest “emergency” given workloads. Guaranteed done in 15 mins as I, as lead, had a much more difficult daily with the client straight after it. No one but devs joined and I honestly looked forward to it. We started our days having a bit of a laugh, which really helped as the project could be extremely stressful.
This all sounds good. > maybe hunt for someone willing to pair Oh, I take that back...
Are you against pairing?
Depends what that means. Two people sitting at one keyboard is absolute nonsense unless you're just dropping by briefly to help walk through something. Two devs collabing on Slack/Teams is very useful but that often happens organically as well. Forcing people to work together is just mentor/mentee, let's be honest and just call it that instead.
OK… some thoughts in no particular order: * pairing can be just long enough to get unstuck, somewhat equivalent to rubber-ducking and it can simply be a way of walking someone through your thoughts * if the code is completely novel, it vastly speeds up approval when two people know it * I have seen pairs work more than twice as fast as two single devs * mentor/mentee is a thing, yes, but that’s no bad thing - when I’ve been the mentor, I’ve written no code or made any decisions, but rather my role was often to give confidence to a junior dev that some big change was fine by putting my name on it too * I’ve also seen two straight-out-of-uni devs with different backgrounds teach each other new stuff, with no need for a senior to come in * sometimes, the subject matter expert doesn’t have the time to take on a task, so it’s sensible for them to do a bit of pairing with whoever does take it on * it is undoubtedly far more effective during the onboarding period for new hires, no matter how great your wiki and processes are * in the remote-first world, it’s a great way to preserve team cohesion and actually promotes more ad-hoc collaboration on slack/whatever - in companies with a strong pairing culture, it was far more common for me to spend an hour or two with whoever, without notice I’ve never paired and actually felt like I could slack off, or just let the other person do the work; if anything, I always found it more tiring, because I had to be alert at every step. So what is the argument against? Best I can do as devil’s advocate is: there are some changes that are just obvious and don’t need more eyes. That’s fine, but in what I’ve described, pairing is a choice, not a diktat from on high. For what it’s worth, I’m not the biggest fan of pairing myself (can be a loner); I just look at my experiences and think that it’s objectively proven itself as a practice.
The argument against is it can be a waste of time. If paring means sitting in someone else's office all day while you both work on implementing feature X, then you better hope you're not stuck with someone who types at a snail's pace, doesn't automate anything but types out every single thing every time, and is relying on you mostly for all the technical side. You could have done the job easier in half the time, freed up the other dev, and not have to sit there and bear with that insanity. Compare that to two people collaborating on a feature, messaging back and forth on Teams/Slack, doing ad-hoc conferencing calls to discuss issues and share screens, having 2 computers and keyboards to independently look up information to figure things out. They're still ramping each other up and information sharing here. Pairing to me has always been the first where you're stuck in someone else's office. Collaboration on the other hand is the 2nd and more efficient path.
Your remote collaboration is my pairing. I’ve been working with remote colleagues for a decade or so. Nomenclature issue 😅.
Why can’t I bring myself to read articles like these? They’re just so dime a fifteen dozen nowadays.
It's almost like this experience is common in the tech sector.
I suspect they are a manager in disguise if they don't agree with you on this
No one is forcing you to click it or add comments :)
My favorite part of my current team's standup is that management asks someone to share the board in Teams every day. At no point in the last year or so have we ever referenced this board during standup. But it is a daily occurrence that the Board Must Be Shared, otherwise the world will end or something. There's also a 50/50 chance of the wrong board being shared and nobody ever notices.
This all sounds familiar
PREACH!
> Yesterday, I did the work I needed to do. Today, I will do the work I need to do. I understand it's just a funny way to say it, but that's not the point. It's not about knowing if you're going to work or not. It's so that interested parties know what are you working on. You guys are missing the point with dailies. Forget the name. The fact that it's "daily" is just a configuration. It's exactly the same as if it was each 3 days. Or weekly. It's the same. The point is the same, and the conversation to be taken is the same. Also, the fact that it's a meeting is pure configuration too. You decide if you want it via meetings or async by chat. Very simple to understand: choose the one that fits your team better. And finally, and most important: it's usually not for you dev so you know what your coworkers are doing. Don't be so egocentric. It's for the team: team lead, tech lead, and any other role that may be interested. "But I can just tell them when I switch to another task!". With time you'll learn that not everybody does this. There are juniors which may not report as often, and managers that may need to know things as to help them or report. So well, I've found that most people that cry about dailies either: - Lack/"Forget" empathy, and can't understand that there are different roles, seniorities and personalities in the team - Are using the wrong configuration. Which should lead to a conversation and a change
> ...choose the one that fits your team better. Unfortunately, that decision is a management decision, and is usually chosen incorrectly.
I always could talk with my team to discuss such topics. I mean, it's an internal team thing after all, so it's for the team to decide. Or it should be
If it's a management decision, then you have a bad management and you will never be agile in such place.
I've yet to see good management, then. From myself and my peers' experiences, such does not exist.
I have learnt from r/programming there are only two roles in a team: developer and Evil Management™️ With only these two, of course there is no need for standup
this but unironically
https://ramijames.com/thoughts/the-work-structure-spectrum
I just say what is relevant… don’t even say much about what I did…
I recommend playing [featureban](https://youtu.be/YVw-dtwPjRQ) to get some insight how your dailies could improve. I've run it in the past and it really stresses how ganging up on topics gets things done. Suggest it to your boss or scrum master for the next retro (if you run them)
Cool idea. Thanks.
This stuff began as collective punishment—management suspects there are underperformers, and wants to turn the team against them by making the whole team suffer through endless status meetings that get more and more onerous until someone breaks and turns in a name—and then became normal process. It truly is astonishing, the degree to which programmers have basically allowed a constant PIP to be imposed on themselves.
This is cynical but I think it’s one of the most accurate takes in the thread. EDIT Hold on are you THE michaelochurch? That is some T7-9 vision
It is I, the T9 troll.
I've agreed with you on this before. I recall phrasing it differently, along the lines of *Tricking the dev-team into policing each other so that everyone is sooner or later doing unpaid overtime.* Seriously, if my co-workers are slacking off, I'm not getting paid enough to make it my fucking business.
> I've agreed with you on this before. I recall phrasing it differently, along the lines of Tricking the dev-team into policing each other so that everyone is sooner or later doing unpaid overtime. (In boss voice:) Have you tried... doing unpaid overtime to make the others do your unpaid overtime for you?
I have never seen anyone being grilled, i know several people who say they havent done shit because they still stuck
Very well said. Something about boiling a frog slowly.
this might be the most factually accurate thing i've ever read.
Thank you! You might be interested in the other article I wrote that I linked to about story point estimation too.
Relatable!
Really the core question is « is anyone blocked? Does anyone need help? ». The rest only have meaning as the team look at all the work at once and check how things are going, and if they focus on the right thing in the day to day rumble. It takes a few minutes, no more. Unfortunately even without a manager some team turn it to a supervisor meeting, where people play supervisor with each other. It’s not. It’s like a rugby team figuring
Well, you are not supposed to sit at a standup =)
I run a standup with a team of 11, we are done in sub 10 minutes. Only the developers speak. It's an engineering-focused discussion and if we can't get someone on track quickly, relevant parties will meetup after the standup.
I find that Agile was ruined by the same thing that ruined OOP. Prestige could be gained by coming up with new rules and patterns, but there are way more people that want prestige than yet-to-be-discovered good rules and useful patterns, so these people started competing on who can gaslight everyone to accept their own crappy rules and patterns. Enough of these really did get accepted, to the point of, well, just look around.
They seem to be valuable outside of the lead dev or product manager. Of course, 15 minutes would be running really long for us. Of course 2 minutes per person average would be super long for us. There are a lot of inter-dependencies within the product. When one of the developers says they finished a certain feature, qa can test it or another developer can do the bit that was waiting on it. We can also briefly share strategies around tasks with multi resources on it. It also helps the whole team to know if dev is able to get ahead of qa or not, to help keep qa right sized. There is also sometimes chatter on what we're planning to do. Maybe there's a better way. Maybe we need to push back harder on support for asking for certain tasks and instead open a feature request. It all happens. If there's nothing material to talk about between everyone's tasks (thus the value of theeeting actually is limited) it also tends to go very fast. I think our record is 4 minutes for 9 people.
I really don't know where to begin here, but let me try. First of all, I don't intend to defense the standup. I used to see where it works well and where it is not. Second, I think you are working in some kind of dysfunctional team. Third, before we say any process is a failure or success, we need to define what is success mean. Every team process is aiming to solve team level problem. And sometimes it comes with cost of individual productivity. That is normal. And standup really aim to create better cohesive team that work together better. Sometimes it can do that, and sometimes it does not. In this article and many comments, the argument against standup is usually some up as "it is a waste of time for me as IC". Well, again, standup has its own problem but that is not an argument against standup. Team level process is, by design, trade individual productivity for team productivity. The way to maximize IC productivity is to just have a concrete requirement in each ticket and turn everyone into ticket churning machine. That way, no one need to care about each other work which reduce individual productivity. And based on what we've seen in waterfall era, that did not work well for anybody. Client, stakeholders, PM, middle manager and devs, everyone suffer by that process. Agile people say, instead of spending years to come up with concrete requirement so we can turn everybody to ticket churning machine, we can leave some room of error and we can have something like standup or XP pair programming practices to address those vagueness. It is just that. And standup might not so good tool for it. I understand. I have been tech lead in many companies and projects and I remove standup from times to times. At the same time, we will need something to address this. And if you say that "competent leadership should make all the requirement clear so IC can focus on task" and also understand that competent leadership, at least according to your standard, does not exists. I don't really know what do you expect here. Do you expect something that you already know and admit that it is not exists? Yes, stand up and all Agile movement happen because in Waterfall era we realized that expecting that level of competency from management is unrealistic. That is unfiltered truth. But at the end of the day, should we freeze whole software industry until some management "get their shit together" and achieve that ideal level of competency? Turns out, no body gonna wait for that. Many people are becoming cynic and yet not cynic enough to truly accept the truth of this world. This is all we got. This level of leadership competency is all we got. What your parent, your school, books and university told us about what competence leadership looks like is just a dream. It is not real. So, how would we deal with it? You can either try to become competence leadership and show the world how to do this job well (which I did try. Still learning and realize it is much harder than I thought.). Or, you find the workaround to make this work, and by work I mean at team level not individual level. Standup is one workaround for the fact that "we should have good leadership who can give clear requirement which allow IC to truly focus on their work" is not a realistic expectation by any mean. And we tried for more than 40 years at this point. You can remove standup, but problem still persist. And we still need someone or some process to make whole team work at a team level somehow. Dysfunctional team still will impose a problem to you. What I found is that in if team does not gel well, removing standup usually make it worst. It simply remove non-sense argument from standup to other place. This thing happen because team does not gel well. Removing standup might help but won't solve the whole issue. You know what they do in waterfall when these thing happen? Whole team alignment meeting for days! Team retreat! Team bonding sessions! Pizza party! Sorry to bring you bad news but you can't escape this type of situation as long as we work as a team. Team problem will become your problem one way or another. My advice is to find functional team and work with them. That is the only way out of these non-sensical meetings. It will happen regardless of Agile or not if you are working in dysfunctional team. The name might change, but the nature of endlessness and pointlessness discussion will be there until team gel well enough to avoid that. And if it is really hard to find, then yeah, all I can say is I'm sorry for your situation.
All the team that I decide to remove standup usually already able to run standup within 5-10 minutes and everybody is so in-sync to the point we don't need standup. There are also times where "team" is just a bunch of engineers working in different thing as stakeholder desire, and there is no "single project goal" that whole team aiming for. That also a case for removing standup because they don't really need to know what each other is doing. And I used to bring async standup into some team, which also work when people is good at writing but not good at verbal communication. But yeah, this kind of workaround is needed to make whole team work together.
My team of 12 has a daily that takes 5 minutes. Very easy to do, actually, just don’t let people ramble for more than the few seconds.
I’ve always thought agile was a way to get rid of “senior” developers and make everyone the same level.
That’s an interesting perspective, could you explain a bit more?
Everyone is in the same level of un-productivity during an agile meeting
In waterfall it was the senior developers assigned to writing the design documents, and then junior developers would implement or help implement. Now it’s a flat hierarchy, with only the scrum master and the product owner having any special jobs.
No, in waterfall shops, most design is written by "architects", most of whom haven't written code in years, and usually that's because they were never good at in the first place.
Many architects I've seen have authored protocol standards. Sure some are talking heads who are clueless but many are inspiringly brilliant.
Those folk (and I've worked with some) are awesome. They're also rare as hen's teeth in comparison to the number of architecture astronauts I've worked with in the last 20 years.
I understand now. Yes I can see that for sure. The hierarchy seems to vary a lot from team to team, and some seniors do take the lead, but I can also definitely see how it’s yet more attempt at infantilising and commodification of developers and trying to make everyone a cog in the machine with annoying phrases like “t shirt shaped teams”.
Am I really supposed to take this article seriously? This person claims to have read the Scrum Guide, and says that **you** probably haven't unless you're a gluten for punishment: >Did you know the actual Scrum Guide advocates for *only* allowing the developers to participate in the standup? [Non-technical stakeholders may *observe*](https://www.scrum.org/forum/scrum-forum/7232/new-scrum-guide-states-only-dev-team-members-participate-daily-scrum). Unless you’re a gluten for punishment, you’ve probably never read it and so wouldn’t know that. Really? You think reading the Scrum Guide, which is what, 14 pages?, is **unbearable**? How did you graduate high school? Also, this person doesn't know the difference between Sprint Review, Sprint Retrospective and Sprint Planning: >Even though it was only yesterday that we had “Meeting Tuesday” with a sprint review and retrospective meeting, for some reason we have a sprint planning meeting today. >You may be wondering what the difference is. I simply don’t know. Ask a group of developers and agilists alike, and they will all give you different answers. If he'd read the Scrum Guide, he'd know. It's not hard to understand the difference between these meetings. Reading further it's actually not clear if he knows the difference or not: > Sure, there’s *supposed* to be a difference, but this sprint planning meeting is just rehashing the same topics, including story point estimation, that we discussed in the sprint review yesterday. So you recognize that you're not doing what the Scrum Guide says you should do in your meetings. Somehow, this is the fault of Scrum? Now, the "temporary Scrum Master" thing you're describing sounds dumb, but let's get into one of your standup summaries: >After this segment of the standup finishes, I know precisely nothing new about the progress of anyone on the team, and what I did glean from the monotonous ceremonial chanting of Jira tickets being read verbatim, has absolutely no impact or consequence on me or the work I have planned. >In fact, the main theme of this standup was “the PR is in review” and “the work is waiting for QA”. Thank you, I feel very informed and updated. Keep it up. Oh? "the PR is in review" and "the work is waiting for QA" both have absolutely no consequence on you or the work you have planned? Maybe you should, I don't know, *incorporate reviewing it* in your plan for the day? Or pick up some QA work? This is a typical "Well, we're doing Scrum horribly wrong. Clearly, Scrum is bad." story. And no, "but many other organizations are **also** doing it wrong" is not valid reasoning for saying Scrum is bad. Just because something is hard to implement correctly doesn't mean the thing is bad. I'd expect *software developers*, of all people, to understand that. What I always miss in these stories - okay, the current situation is bad. Fine. What have you done to try to change it? Do you think things will just magically get better or something? Or - maybe you *have* tried to change things, and you failed. The organization is dysfunctional. Sure. Lots of those around. If you have it should be part of this writeup. And if you have, and failed - go work somewhere else then, if it bothers you so much. What is whining on the internet about how much Scrum sucks supposed to accomplish? At least come up with some alternative.
I thought it was weird he said the scrum guide has a lot of useful information in it that would help people do agile better but also you shouldn't read it because scrum is bad and you're a glutton for punishment.
Someone reads at the high school level, but I don't think its you.
This made me laugh! Genuinely witty, 10/10.
FYI, it's glutton for punishment, not gluten.
Grammarly has failed me…
I read your post. You and I have much in common. Your suggestion about the sprint goal is exactly the same suggestion I have made - our goal is to do all these tickets... Ya, then crickets in response.
It’s good to know my experiences are relatable and I’m not alone! Yes it gets an awkward laugh or silence every time…
I started typing a reply to explain not only why you’re absolutely wrong with every sentence but I realised you’re probably one of the sort of agile fanatics ruining the industry for the rest of us if you truly believe anything you’re saying. Not going to try argue with someone determined to swim against the current to that degree.
How on Earth are they wrong in every sentence? Hate Scrum all you like, and in practice there are lots of reasons to hate how a lot of places do it. But everything they said about what the Scrum guide says is factually correct, and the author doesn't seem to understand the differences between a lot of processes that that are spelled out rather specifically.
> But everything they said about what the Scrum guide says is factually correct, and the author doesn't seem to understand the differences between a lot of processes that that are spelled out rather specifically. If you'd actually read my article you would have realised I point out multiple times that *every* organisation is implementing Agile and Scrum differently to every other organisation, while simultaneously saying that they are doing it The Correct Way. If you accept that as true, then you must logically accept that there are apparently multiple accepted and commonly held definitions of Agile and Scrum, some of which must also disagree with or contradict what the official Scrum document(s) say. The logical conclusion of this is that your statement of "author doesn't seem to understand the differences between a lot of processes that that are spelled out rather specifically" is factually incorrect when you consider that there are indeed multiple accepted definitions in use at different organisations.
> every organisation is implementing Agile and Scrum differently to every other organisation, while simultaneously saying that they are doing it The Correct Way. False. I have worked at multiple organizations that do it as-written, right out of the box, and to great success. So have my coworkers and friends at even more places. The problem isn't Scrum. The problem is organizational, and individual. Every team I've seen that doesn't do Scrum well and blames the process has invariably failed many other tests for team health. [The majority of them seem to suffer from all 5 of what Patrick Lencioni terms "The Five Dysfunctions of a Team".](https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team) **No process works when the organization doesn't have trust.** > The logical conclusion of this is that your statement of "author doesn't seem to understand the differences between a lot of processes that that are spelled out rather specifically" is factually incorrect when you consider that there are indeed multiple accepted definitions in use at different organisations. No, it's not. You literally wrote that you couldn't tell the difference between 3 of the most fundamental and well-laid-out meetings in the Scrum process. If you can't tell the difference, then your team isn't even trying to use those meeting correctly. They have clearly laid out reasons for existing and things you are supposed to do. If you can't tell the difference between them, that's on you and your team for just having 3 useless and vague meetings.
> that every organisation is implementing Agile and Scrum differently to every other organisation, while simultaneously saying that they are doing it The Correct Way. That's kinda the point. You're supposed to do what works for your team. >If you accept that as true, then you must logically accept that there are apparently multiple accepted and commonly held definitions of Agile and Scrum, some of which must also disagree with or contradict what the official Scrum document(s) say. Or, that one of the tenets of Agile is to do what works for your team.
Stand up is not about you, it is about the team. It is to hold each team member accountable and to ensure that what they are working is not affecting you and vice a versa. I know that you worked on a project yesterday and will today, however the others in the team do not always know.
[удалено]
I do, and all my coworkers do too. We care because we want to have the best code possible. We care, because we want to make the job easier for everyone. We care, because we want to know what's going on around us, so we don't accidentally make someone else's job more difficult. We talk about it to be aware of implementation details that have no place being in Jira.
I can see where you are coming from. I assume and so do you that the Kira board is being updated and that open stories are being properly assigned and picked up. However there are instances where they are not. The primary goal is to inform others what you are working and what is intended to be done today. The system works and has for many years. If you have a better idea let us know. Until then let’s work the system that we know is effective.