[HN Gopher] We cancelled standups and let the team build
___________________________________________________________________
We cancelled standups and let the team build
Author : thellimist
Score : 55 points
Date : 2020-09-24 17:52 UTC (5 hours ago)
(HTM) web link (www.usehaystack.io)
(TXT) w3m dump (www.usehaystack.io)
| [deleted]
| sabellito wrote:
| A bit click baity.
|
| The team experimented with cancelling stand-up AND started doing
| a version of 20% time with a strict rule about "fun projects
| only".
|
| As with any process experimentation, mixing two initiatives at
| the same time makes it impossible to understand the results.
| larrik wrote:
| And only for a week! What does that prove?
| violetgarden wrote:
| Exactly! I can enjoy a vacation somewhere for a week, but
| living there might be a whole different thing.
| darrinmn wrote:
| "our standups are growing and spend alot of time chatting /
| designing new features". So your standups are inefficient and
| your solution is to cancel them? Talk about a false equivalency.
| Fix your standups, dont cancel them.
| lovedev wrote:
| I think the point of the article was to empower changing
| processes and ACTUALLY listen to the suggestions coming from
| your team.
|
| It's odd that you're bashing that
| Kednicma wrote:
| That heatmap calendar was upside-down from the typical calendar
| UIs which I've used; it showed time flowing bottom-to-top rather
| than top-to-bottom. Is this the typical style for Haystack or
| related tooling?
| carterklein13 wrote:
| I've found standups to be probably the biggest waste of time of
| all Agile ceremonies (and I'm really not a fan of Agile as-is,
| but I'm too young to have experienced anything else so I can't
| say it's definitively bad).
|
| I think the one caveat, though, is that standup is useless IF the
| team is high-performing, close with one another, and self-
| motivated. The team I'm currently on probably does not need any
| sort of formal Agile workflow at all besides setting our current
| sprint's worth of stories at the beginning of each sprint. But,
| that's because everyone on the team is very self-motivated and
| even remotely we're still very close with one another.
|
| I've been on other teams where, without standup, people would go
| for days without working on or talking to anyone.
|
| I think, if anything, this is proof that no company should have
| one method of delivering software. I work at a massive company,
| and forcing each team into Agile is probably easy at a top-down
| level, but can be very frustrating at a bottom-up level.
| hinkley wrote:
| Standups are Scrum (possibly XP), not Agile, but Agile is dead
| and Scrum is wearing its skin as a macabre disguise. It puts
| the lotion on its skin...
|
| Standups are the first time I ever noticed that "X is ableist"
| without someone else having to point it out to me. My
| introduction to standup meetings was a bit after I screwed up
| my ankle. I spent a lot of time thinking in that meeting about
| all the injuries and disabilities that would make the forced
| standing still for 15 (or let's be honest, 30) minutes an
| imposition. Spines, knees, hips, ankles, toes. In our industry
| you have to be able to manage sitting at a keyboard for 8
| hours, until 'Agile' came along.
|
| Writing this out, I'm beginning to wonder if standups (the
| "Stand Up" part) aren't in fact illegal under US and/or EU law.
| mellosouls wrote:
| Yeah a peeve of mine as well, I've always thought the name is
| insensitive at best.
|
| However, I would have thought it's taken as given that you
| only stand if you are able and the real goal is to keep the
| meetings short and focused; with physical "discomfort" being
| an inspired motivator.
| nicoburns wrote:
| > My introduction to standup meetings was a bit after I
| screwed up my ankle. I spent a lot of time thinking in that
| meeting about all the injuries and disabilities that would
| make the forced standing still for 15 (or let's be honest,
| 30) minutes an imposition
|
| We have "standups" without physically standing up. I've
| worked places where actually standing was the norm, but they
| definitely wouldn't have made someone stand if they had a
| medical reason not to (use some common sense!)
|
| The basic premise of a quick meeting to make sure everyone is
| aligned, and that any blockers are communicated seems sound
| to me.
| jurassic wrote:
| Cancelling standups during a "fun projects only" hackweek doesn't
| say a single thing about the efficacy of the standup meeting. The
| costs of cancelling it, will only show up over the medium to long
| term.
|
| Also, it makes me cringe a bit to see there are people who think
| number of pull requests are a good measure of productivity. It
| incentivizes blasting out a lot of quick, easy changes at the
| expense of doing more challenging tasks that may be essential for
| long term code health.
| waylandsmithers wrote:
| As someone who has worked mostly in a consulting context, "Fun
| projects ONLY" is... interesting
| BrandonM wrote:
| I vaguely recall research about process changes reliably boosting
| productivity temporarily but eventually reverting to the mean.
| Does anyone recall if that effect has a name or a canonical
| study?
| JimDabell wrote:
| You may be thinking of the novelty effect:
| https://turnedtwenty.com/productivity-isnt-related-technolog...
| BrandonM wrote:
| That's exactly what I had in mind. Great article. Thanks!
| blatherard wrote:
| They stopped regular work and had a hack week and morale
| improved. Now they're back to the regular work and having
| standups again. What does this show other than taking a break is
| fun?
| cassieramen wrote:
| I thought the productivity data was interesting but then it
| stopped right after hack week... Definitely agree, the long
| term implications are a lot more interesting.
| vannevar wrote:
| Yeah, the "we stopped having standups!" is good click-bait, but
| simply letting people work on their own projects is always
| going to improve morale and productivity (if you assume the fun
| projects are aligned with the organization).
| Beldin wrote:
| With JavaScript turned off, the link goes to an empty page.
| There's some template stuff, but no content.
|
| Which could be taken as a rather funny take on "here's what
| happened" ;)
| li4ick wrote:
| I mean, it's time to accept that JS is everywhere. Or, you can
| do something like Stallman, and have a remote machine send
| screenshots to you, so you don't have to run non-free JS.
| rudasn wrote:
| I know that the whole "it doesn't work without javascript"
| story sounds like "get off my lawn", but content authors, esp
| on HN, need to realise that quite a few of us refuse to browse
| the Web with JS enabled esp on mobile devices.
|
| With JS the experience on the mobile web is garbage. It's
| difficult enough to find quality content as it is, we don't
| need all the added "benefits" of JS.
| carlosdp wrote:
| > but content authors, esp on HN, need to realise that quite
| a few of us refuse to browse the Web with JS enabled esp on
| mobile devices.
|
| They kind of don't though, given this is such a tiny fraction
| of visitors
| gridlockd wrote:
| I realize it, I just don't care.
| m3kw9 wrote:
| Stand ups are supposed to be good if it has a focused purpose but
| eventually it morphs into a "I'm continuing to work on X and no
| blockers". Then everyone resents what a waste of time it is
| because the team basically knows 80% of what everyone is already
| doing. Or the blockers/issues/new features they have won't be
| sufficiently explained in the stand up, and everyone pretends to
| understand or care for it.
| gervwyk wrote:
| Since lockdown started, we switched to 3-Ps - everyone post 3
| micro tasks they are working on today on a team discord channel
| before the meeting starts, at 9 we all hop on a team call and go
| over all the 3ps.
|
| short and sweet.
|
| and gives enough insight for people to ask for help or just get a
| feeling of progress...
|
| tricky sometime not to list macro tasks, which takes more than a
| day to complete. but other than that. its also nice to force
| every on to think about and commit to a few small things they
| want to work on for the day.
| amgreg wrote:
| https://uploads-ssl.webflow.com/5ed57622ee14fb96d022d544/5f6...
|
| Is this list representative of the entire scope of the sprint?
| Unclear from the article. If so, while the sprint was arguably
| successful in that the engineers felt good about it, it didn't
| really succeed in improving the customer experience directly.
| dmitriid wrote:
| There are so many things that are not FUN, but have to be done
| anyway. And more often than not the not-fun things are the direct
| consequence of the "FUN" projects.
| BrandonM wrote:
| This article, as with much tech discussion I've seen in the past
| 5-10 years, seems to take sprints as a given. Are most devs here
| working in a sprint model? It sounds a bit soul crushing to me to
| be "continually sprinting".
|
| I'm so glad that our company doesn't have them--I think it's a
| significant factor in me grinding it out for 9+ years. We have
| feature releases every 4 weeks. If your feature is merged before
| QA, it goes out in that release. Otherwise, it gets delayed till
| the next release, and we don't make a big deal about it--several
| other features will still be in the release.
|
| I feel like it gives me a lot more agency and ownership of my
| work. I think it's the right amount of subtle deadline pressure,
| relying on my intrinsic motivation to get my feature shipped and
| move onto the next one. Or to have the freedom to determine that
| it's not ready yet and spend a little more time to avoid shoving
| out a pile of technical debt.
|
| I'm curious to see what I'm missing, though. Anyone love sprints?
| Anyone working in a non-sprint model and hate it?
| illogico wrote:
| Bob Martin put it best: "Software projects are marathons, and
| in a marathon you don't want to sprint."
|
| I do think it's useful to have some cadence for important
| meetings, but the arbitrary timeframe should not be treated as
| a goal or even something worth dignifying in and of itself.
| It's simply a tool, nothing more and nothing less, and we
| should expressly state its purpose and discard it in situations
| where it ceases to be useful.
|
| I actually do like the default Agile meetings, but I think
| they're usually implemented haphazardly. I would prefer
| standups at the end of the day so that they run no risk of
| destroying the context of a programming task or block me from
| starting my work day. I like IPM/sprint planning to refine
| stories and make sure they're ready to work. I like having a
| "definition of done" to create a shared agreement of what my
| commitments are and whether I've met them. I like retro to
| evaluate how we're doing as a team and to improve processes and
| working culture. I like technical retros to share learning and
| troubleshoot architectural problems and identify useful areas
| of research.
|
| All of these things are great when done well and for the right
| reason. All of them can be sources of misery when they are done
| ineptly or as mere formalities, with no underlying sense of
| purpose.
| majormajor wrote:
| I think you might be assuming "sprint" to be some always-the-
| same-thing that it doesn't have to be.
|
| On one recent team, we did 2 week sprints with a couple
| releases per week (basically, one per feature that finishes and
| makes it through QA).
|
| The 2 week cycle was our planning/work prep cadence. If a
| feature isn't fleshed out by its owners and stakeholders prior
| to the start of the sprint, we're not going to ask any devs to
| pick it up during that sprint. If it is ready, we'll start to
| plan it, and estimate how long it will take, talk about debt-
| vs-speed tradeoffs, etc.
|
| I think I might dislike the model you describe because it seems
| potentially isolated around "my feature" vs "the rest of the
| team's feature," and because I think making the planning cycle
| 4 weeks instead of two might cause more planning pain for each
| release.
| BrandonM wrote:
| That's interesting, thanks. So a dev can be working on a
| feature over an open ended number of sprints? What is the
| significance of the sprint, then?
|
| We don't have "planning cycles" except for quarterly
| prioritization to realign on which features matter the most
| (exceptional features occasionally get prioritized outside
| the process). When you finish one project, you pick another
| that's interesting to you that's near the top of the priority
| list, with support from our Product team and Engineering
| Operations.
| nicoburns wrote:
| Yes, absolutely. It's supposed to be a happy medium between
| everything being planned out months in advance with no
| flexibility on one hand, and constantly changing priorities
| such that developer workloads change beneath their feet
| before they get a chance to make significant headway. Your
| model sounds like it could be reasonably described as
| 4-week sprints.
| alfalfasprout wrote:
| My team doesn't do sprints and honestly thank god. HN is pretty
| "product eng" focused and sprints do work better there... but
| for infra projects where the units of work often tend to
| involve more R&D, exploration, etc. I've found that weekly
| check-ins work best (scheduling ad-hoc sync when needed). You
| still get the benefit of a heads-up on what people are working
| on but you're not trying to shove tasks into arbitrary 2-3 week
| sprints.
|
| At the end of the day, "agile" wasn't originally the
| monstrosity that scrum-fetishists have turned it into. It was
| simply these few lines:
|
| "Individuals and interactions over processes and tools Working
| software over comprehensive documentation Customer
| collaboration over contract negotiation Responding to change
| over following a plan"
| cpeterso wrote:
| Sprints that don't ship something (i.e. "deliver user value")
| are just arbitrary timeboxes. They probably can just be
| progress checkins without all the overhead of Scrum ceremony.
| Sodman wrote:
| 1000% this! The key takeaway of Agile that a lot of people
| lose sight of, is that you should be doing whatever works for
| your team, not whatever you did at a previous company or read
| from a trendy blog post. By all means - try out anything you
| think will work _for your team_.
|
| If you're trying to plan out which individual stories your
| eng team will be working on 6 months from now, or you have a
| half-dozen "Sprint Retrospectives" with the same complaints
| every sprint from your team with no changes being made -
| you've probably made a wrong turn somewhere.
| lovedev wrote:
| +1
| danjac wrote:
| Unfortunately "agile" is one of those lovely sounding ideas
| that were never going to survive contact with the real world
| of company politics and management. Perhaps in some places,
| in some small agencies and startups with strong tech-focused
| leadership it might yield some successes for a short time,
| until they start growing and hiring from the bigger
| companies. Then you end up with the same-old-same-old with
| more meetings and Jira.
| boublepop wrote:
| Honestly, if you think spending 15 minutes (we're closer to 10
| though) talking to your team to ensure that you know what others
| are working on and they know what you are working on, then I
| don't want to work with you.
|
| It's not wasted time, and even if you don't care what I'm working
| on I still care that you know so that we don't spend two weeks
| building something only for you to go "Oh, that won't work after
| the changes I made to the core.... why didn't you come by my desk
| and ask me "are you intending to change the core code in a way
| that invalidates all assumptions we had two weeks ago when we
| started working on this?" And do so like clockwork every day,
| even though I'd answer no 6 times before suddenly answering yes?
|
| "But we already communicate in the team outside of the Stand-up!"
| You say. Ok then, tomorrow at your standup, have everyone go
| though someone else's points, I'll say what you did yesterday, if
| you have blockers and what you'll do today. If everyone does this
| flawlessly, then yes the daily is wasted time, but for every
| mistaken assumption you hear, that is a potential mistake or
| missed opportunity or just general annoyance you avoided simply
| by talking 10 minutes together.
|
| Now don't get me started on the number of bad excuses that you
| avoid by having daily stand ups that's a whole other subject, but
| also an extremely valuable element. "I'm waiting on Kevin to
| finish X" "Does Kevin know this?" "Yes of cause! " Kevin: "Wait
| what? Err what am I supposed to be doing? That's not on the
| board". Etc.
| machinelearning wrote:
| Except that a stand up doesn't actually solve the problem you
| are referring to. People don't pay much attention to what
| you're working on in stand ups since it's most probably not
| relevant to what they're working on at the time. It is
| unreasonable to expect people to have perfect foresight that
| what you're working on is going to be relevant to them 2 weeks
| down the line. There are better ways to solve that problem but
| stand ups is not one of them.
| jVinc wrote:
| > It is unreasonable to expect people to have perfect
| foresight that what you're working on is going to be relevant
| to them 2 weeks down the line.
|
| I would understand if you said 2 years or 2 months. But if
| your road-maps and plans change so rapidly that you can't
| even assume that features coordinated one day will still be
| relevant 2 weeks after... then how on earth do you have a
| functioning team without daily communication? And if you do
| have daily communication, why not concentrate that to a
| single max 15 min period to reduce being interrupted in flow?
| ozim wrote:
| In my opinion standups are waste of time when they are mandated
| by some boss. When they are used as head count moment to see
| everyone is in the office working on things. Then it turns into
| status report for that manager and maybe he starts even micro
| managing people by handing them tasks and asking questions to
| each person.
|
| If standup is needed by the team and it feels natural then it
| probably is useful. Nowadays with remote work I kind of like to
| have at least 10 mins to see people that I am working with each
| day.
| IOT_Apprentice wrote:
| Imagine having to speak and say what you are doing in about 2
| minutes. The horror. Part of your job is communicating what
| you are doing to others. It is common courtesy and a social
| skill. Cultivate it.
|
| Stand Ups by nature are to be quick. It is why YOU DON"T SIT.
|
| You can do them over Teams, Zoom, Slack.
|
| Companies allocate millions to billions of dollars for
| projects and have a need to know how things are progressing
| and if there are issues and resources that can be brought to
| bear to solve them.
|
| If your manager or "Boss" is micro-managing you to death,
| then leave. The culture is toxic and a 10 minute stand up is
| the least of your issues.
| jVinc wrote:
| Found the bug in your process in line 1. Managers shouldn't
| be attending your daily stand-up.
| bird_monster wrote:
| I think the disparity is that, for most organizations, Standup
| isn't "talking to your team to ensure that you know what others
| are working and and they know what you are working on", but
| instead "A person gives vague generalizations about a
| story/ticket number, the rest of the team pretends to listen."
|
| And yes, sure, that is objectively not the point of the meeting
| and blaming the meeting for people misbehaving isn't right. But
| it's a cowpath argument to me. If the meeting is in service of
| a team and their collaboration, collaborate in the ways the
| team finds most meaningful. Do not force a team to pretend to
| be collaborating.
| li4ick wrote:
| We occasionally spend 20 min on Tuesday and Thursday, at around
| 14:00. That's enough for us. But then again, we're in a very
| unusual position as a team.
| JSavageOne wrote:
| I completely disagree. As a developer, standups have always
| ended up devolving into the bane of my existence, and now I
| only work for companies that don't do them (or at a minimum,
| allow them to be async).
|
| Not all of us enjoy being micromanaged.
| hinkley wrote:
| I think spending 15 minutes is great.
|
| But in 15 years, any time a standup was below that target,
| people commented on how unusual it was to be done already.
|
| The standup is either early enough in the morning that it
| becomes a passive aggressive way to get people to show up 15
| minutes early to work (because if you try to show up on time,
| you'll be late for a short meeting, essentially missing it), or
| it is late enough that early risers have to avoid flow state
| tasks early in the morning or also miss the meeting.
|
| If you are in the middle of something, a 15 minute meeting
| clears working memory every bit as much as a 3 hour meeting. So
| if you're going to lose your spot, you might as well get
| something else out of it. Which contributes to the "but it's
| never 15 minutes" phenomenon.
| jVinc wrote:
| Have you forgotten to have retrospectives? Yes, the first 2
| weeks, the stand-ups is badly place, then the team talks
| about it and chose a different time. (Remember the team
| decides the time, not management or Product owner),
| management only gets to decide that you are doing scrum,
| which means you need to have the daily stand-up.
|
| If you've goon 15 years without any stand-up being under 15
| min, then you are doing something wrong. Is your team
| absurdly large? Is your scrum-master not fluent in scrum?
| Does no-one in your company understand how a time-box works?
| Or do you insist on bringing up lengthy technical discussions
| that you could perfectly well take with the 1-2 people
| involved outside of the stand-up? There are tons of ways to
| do it wrong, and pretty much every single one comes back to
| people not understanding what the stand-up is and isn't for.
|
| It's popular to shit on scrum, but a lot of the criticism
| comes out like someone going "Programming in C is rubbish, it
| always throws segfaults, and it's impossible to create good
| software in a programming language that isn't pure
| functional" It's an opinion sure, but it's based off of being
| bad at coding C and preferring to code in Haskell, where you
| might ask the person if they had considered actually learning
| C before shitting on it.
|
| > If you are in the middle of something, a 15 minute meeting
| clears working memory every bit as much as a 3 hour meeting.
|
| Getting interrupted for a 5 min talk with a colleague is just
| as interrupting to your flow. Don't pretend to claim that
| everyday in your 15 years of scrum you have accomplished
| absolutely nothing on a day if there was both a daily
| standup, lunch, and a person asked you question.
|
| Yes interruptions are bad and should be minimized.. which is
| why having 15 min condensed to get everyone aligned is better
| than having 5 people dropping by randomly to ask "did you
| commit the feature yet?" "Was it me or you who was supposed
| to do X" "You do know that I'm waiting for you to finish Y
| right?" "Are you waiting on me to do Z, cause I prefer doing
| X first, but no-one needs that yet". And again, if a team has
| more than 15 min total of those kinds of interactions during
| a day, you need to reflect and improve. If you have less than
| 15min, then great, everything is cleared up after the daily
| scrum.
| ardy42 wrote:
| > Have you forgotten to have retrospectives? Yes, the first
| 2 weeks, the stand-ups is badly place, then the team talks
| about it and chose a different time. (Remember the team
| decides the time, not management or Product owner),
| management only gets to decide that you are doing scrum,
| which means you need to have the daily stand-up.
|
| Sure, that's the orthodoxy, and assumes the team is
| actually empowered to do that, but agile-as-practiced often
| doesn't actually address the problems that it was supposed
| to solve. In many ways it just replaced one set of
| ceremonies with another, leaving the fundamentals
| unchanged.
| ep103 wrote:
| I just got out of my team's standup. MY team has 8 people.
| The standup lasted 6 minutes. I think the people who complain
| about this, are the ones who have a reason to complain. You
| don't hear the success stories.
| jVinc wrote:
| There are many templates for failure, and the funny part is
| that often the people who contribute to the failure are the
| ones complaining. But in all cases a good scrum master
| should be picking up on this and fixing it.
|
| Most typical one is that a team member wants to go deep
| into details about a task which isn't important and not the
| case. And after explaining for 10 mins about how they where
| brilliant in so many ways, they complain when the rest of
| the team "wastes" their time spending 5 min in total
| explaining why that brilliant feature was actually not
| needed which is why it wasn't on the board and no-one asked
| for it etc. The solution here is to repeat time and time
| again what the purpose of the meeting is, and cutting
| people off mid explanation when they go outside their
| timebox Note though, don't do individual timeboxes unless
| you are facing this specific issue, it's not good overall
| but sometimes you need to correct behavior.
|
| Then there are cases where team members aren't paying
| attention to others and complain the stand-up is wasteful
| because they never learn anything new anyways, but when you
| talk to other team members that person spends the rest of
| they day asking questions that where already answered at
| the daily. Obvious here you need to do some coaching for
| that specific member, but I've found it also helps to let
| them not do their own points, either skip them completely
| or do them for them. My experience is that it's often
| coupled to that person going through what they need to say
| and forgetting to listen.
|
| And on and on. There are so many cases where teams need to
| correct bad habits rather than complain about the stand-up
| being there. But sadly the retrospective is often the first
| thing to go out the window on teams, and they never get to
| discussing overall how the process is going, and then the
| daily stand-up gets changed into a 30 min status meeting,
| and people start hating it.
| ardy42 wrote:
| > I just got out of my team's standup. MY team has 8
| people. The standup lasted 6 minutes. I think the people
| who complain about this, are the ones who have a reason to
| complain. You don't hear the success stories.
|
| I'm not sure if I'd count a 6 minute standup as a success
| story. My guess is the only person deriving any value from
| it is some kind of manager who's tracking status, and
| pulling everyone into a meeting room to do that is mainly
| just a convenience for that person.
|
| The kind of information that can be conveyed in less than 1
| minute per person is likely information that can be
| collected less disruptively in other ways.
|
| From my perspective as a developer, the best "standups"
| were the ones that actually deviated from orthodoxy, where
| we talked about some technical issue or something.
| curun1r wrote:
| LPT: schedule your standup for the 15 min before lunch. It's
| an almost automatic way to ensure that it finishes quickly.
| No one wants to be the one that's making teammates hangry. It
| also means the meeting never interrupts a developer's flow
| since they were going to break for lunch anyways.
| jbob2000 wrote:
| This also means your team's day does't start until lunch.
| jVinc wrote:
| Why do you think the daily stand-up should be the days
| starting point? That's not a requirement and not at all
| practical. If you have to skip a stand-up some day
| because of a dentist appointment or other meeting, do you
| just not do anything for the rest of the day?
| ZainRiz wrote:
| This suggests a fun exercise:
|
| Once a week, maybe right after each person says what they did,
| everyone gets randomly assigned a person and they have to
| explain what _that_ person did last week.
|
| The goal of this exercise: Make people actually pay attention
| to what others are doing and ensure they really understand it
| (and feel empowered to ask questions if they don't)
| ardy42 wrote:
| > It's not wasted time, and even if you don't care what I'm
| working on I still care that you know so that we don't spend
| two weeks building something only for you to go "Oh, that won't
| work after the changes I made to the core.... why didn't you
| come by my desk and ask me "are you intending to change the
| core code in a way that invalidates all assumptions we had two
| weeks ago when we started working on this?" And do so like
| clockwork every day, even though I'd answer no 6 times before
| suddenly answering yes?
|
| I thought the whole point of orthodox standups (and one of the
| brain-dead things about them), was that you _weren 't_ supposed
| to have discussions at that level of detail.
| lovehashbrowns wrote:
| You are absolutely correct and people not knowing this
| results in a "standup" that balloons into a one-hour verbal
| trash bin. This is the issue my company has. Daily "standups"
| that can take 30-60 minutes.
|
| BUT WAIT HOLD ON, it's 15 minutes of "standup" and 45 minutes
| of "parking lot." _eye-roll_
|
| This is every single day, by the way. Our previous manager
| got the picture and reduced these to three times a week with
| hard time limits. Then a new manager came on and put daily
| "standups" back on, _after_ apologizing that he was adding a
| meeting to our no-meeting day, lol.
|
| I'm dead inside.
|
| It also psychologically feels bad when you have the same
| update every day (e.g. working on a long-term project) or if
| you have no update. It's also really fucking stupid to have a
| "standup" on Friday morning and another on Monday morning.
|
| I'm dead inside. I'm dead inside. I'm dead inside.
|
| Also I take any opportunity to vent about these stupid
| "agile" methods, sorry.
| jVinc wrote:
| I know this isn't your place to fix, but honestly align
| with your scrum master and just stage a walk-out of the
| "parking-lot" meeting for you and the team. You should not
| be required to attend this.
|
| After doing this a couple of times people will realize that
| there is something wrong if you have to spend 45 minutes a
| day digging deeper into issues. Poorly planned spring
| backlog? A non-existing product backlog? There could be
| many issues, but trying to "patch" them by doing things
| wrong.
|
| > Also I take any opportunity to vent about these stupid
| "agile" methods, sorry.
|
| So I'm sure you've raised these concerns at the end of
| every iteration at the retrospective right? Please tell me
| that you didn't throw out the retrospective and the process
| for venting frustrations to facilitate change and then
| start changing the process completely and then end up being
| bad at this thing you are doing which definitely wouldn't
| be scrum then.
| lovehashbrowns wrote:
| Currently, a lot of the members on our team just miss
| standup entirely. For example, I missed the last 3 days
| of standup. Showed up today to re-iterate that I'm making
| some prod changes. Our sprint backlog and sprint planning
| meetings are a disaster, too. Watching our manager
| struggle every single time with jira is just.... mind-
| numbing. We complained about those and did get some
| changes made. For example, our sprint planning "meeting"
| went from two 1.5 hr meetings (one before lunch, one
| after) to one 1.5 hr meeting before lunch. I sometimes
| miss those, too.
|
| I raised these concerns with this manager when they first
| started (specifically about the number of meetings AND
| the daily standup). I raise them in the retrospective
| every time we have one. I raised them with my engineering
| team manager. I raised them in those anonymous feedback
| things.
|
| We're currently in the process of getting this manager
| out of our team. Our manager went on vacation and our
| productivity went up by some crazy amount, lol. The only
| thing keeping us stuck at this point is the current covid
| situation (long story). But normally, I'm pretty sure
| they would have been gone as of a month ago or so.
|
| It's an organizational thing, though, not just that
| manager specifically. Half the battle is getting upper
| management to listen to our concerns and do something
| about it.
|
| But the reason our last manager was so good about these
| things is because he had clout within the company and the
| assertiveness to say "no, that isn't ok."
| BrandonM wrote:
| Standups (weekly, not daily) worked pretty well for us at 5-20
| people: maybe 5-12 devs and 2-8 other stakeholders. Smaller
| than that, and communication was so easy and natural we didn't
| need standups. Bigger, and it became tedious and low signal
| (everyone didn't need to know everything).
|
| We now have more than 50 devs, and we've remained quite flat
| and autonomous. It would be literally impossible for me to
| track what all the other devs are working on, never mind going
| over it every day in 15 minutes. It probably works better for
| siloed dev/product teams that stay under 30 people, but that's
| not how we work.
|
| I share all this to give perspective on a pretty bold
| statement: "If you [don't like standups], then I don't want to
| work with you." Ten people is a good size for standups, and I
| think you may be overgeneralizing your experience when judging
| people who don't like standups.
|
| Even still, I'm curious how much is changing daily to warrant
| daily standups? We have a rotating "release team" who runs QA
| and ultimately performs releases, and they check in daily. But
| daily checkins for feature development seem very frequent to
| me.
| hw wrote:
| Our team doesn't do daily standups as everyone pretty much
| knows what other people are working on. There's communication
| on Slack. There's a list of issues and/or roadmap items that
| are assigned.
|
| Then again, we have a small and high functioning team where
| there's no "waiting for X to finish Y" or blockers that aren't
| resolved immediately via communication on Slack. There's never
| a lack of issues to work on. Nothing assigned to you? Well,
| pick something from the list of issues or something on the
| roadmap, communicate to the team that you're working on it,
| communicate when you're done.
|
| For a team of 6, 15 minutes a day is 90 minutes of
| productivity. That's 7.5 hours a week, pretty much almost a
| whole day of productivity for a person.
|
| Whether standups are great for your team or not depends on the
| makeup of your team and personnel, the size of your team as
| well as the nature of the work and how work is divvy-ed up.
| I've found success on teams with and without standups, and I'll
| say that not having 15 minutes of the start of your day spent
| on being in a meeting is absolutely refreshing
| alfalfasprout wrote:
| There's an in-between here. Daily standups just aren't a great
| fit in many cases... weekly standups will tend to work better
| in these cases. At the end of the day it boils down to the
| difficulty of the tasks to be executed and how much R&D and
| design work there is. The more R&D heavy your workload the more
| impractical daily standups tend to be.
| bobwall wrote:
| Yea, we did stand-ups Mon, Wed, Fri, which tended to be a
| good balance. Still able to let people know what you are
| doing, but not having to be forced to do it everyday as if
| you are children.
| camgunz wrote:
| Standups aren't the place to hash this out, sprint/epic
| planning is.
|
| Standups are for managers and 99% of the time can be done
| asynchronously. If you have to know what everyone else is doing
| in order to be effective at your job, your planning process
| needs fixing.
| jVinc wrote:
| How would the standups be for managers? They don't attend.
| Even the scrum master is not required to attend, only
| required to ensure the meeting happens (which for most teams
| often means the scrum master has to attend, but still.)
| hw wrote:
| Standups are also for people who like the illusion of control
| that comes with knowing what everyone is working on and
| having a say in every single decision/work.
| lemmsjid wrote:
| It's interesting--I completely and utterly agree with out
| intellectually. But when I look back on many teams I've been on
| in many companies, daily standups achieve this sort of
| psychological weight of monotony. Even when they're below 15
| minutes they take on a dread.
|
| I don't think this is exclusive to standups: any type of
| process done repetitively over time can get this upward curve
| of increasing monotony, even if it doesn't lose its inherent
| usefulness.
|
| The very act of changing or intervening in a monotonous process
| might be a boost for people, and to your point is not an
| argument against the usefulness of the process. I've equally
| had teams not doing standups get a boost from starting to do
| standups.
|
| Coming from doing a lot of recommendation systems work, it's
| similar to how just changing algorithms around often leads to a
| temporary boost in engagement which then regresses back to the
| mean (same in general A/B testing).
|
| When I'm managing a process and someone comes to me with a
| process change suggestion, and I feel like I am well-stocked
| with evidence as to why the existing process makes sense and is
| efficient, I now have a meta-assessment where I consider the
| change because it will at the very least mix things up and
| introduce changes to thinking. Obviously that is not to be done
| willy nilly, but my younger self would have pushed back on
| process changes that were not inherently superior to the
| existing ones.
| cj wrote:
| Major caveat: they were never doing stand ups to begin with. From
| the screenshot, the feedback from the team was "standup are
| becoming very long, a lot of chatting and designing features"
| (paraphrased)
|
| It sounds like they had a 45-60 minute daily meeting that was not
| a standup. Rather than cancel the meeting, shorten the meeting
| with a 15 minute hard stop.
|
| I run a 10 person remote SaaS company. We have daily morning
| stand ups. The standup takes no more than 10-15 minutes, but it
| sometimes goes 20-25 minutes since we often chat for a few
| minutes before jumping in to standup. (I can't imagine us doing
| feature design during that meeting, as they were in the article)
|
| The chatting / socializing is something I encourage before
| standup starts. As a remote team, it's necessary to have some
| group interactions to maintain the group's working relationship.
| lovedev wrote:
| I think the point of this article was not to bash standups but
| to give an example of empowering your team to make decisions.
|
| Be bold. Make change. Improve the way you work.
|
| Was cancelling standups going to far? Maybe. But that's not the
| point.
| golemiprague wrote:
| I don't understand why it needs to be formalised like this,
| what if people are working on something for a bit longer than
| one day and got no news to tell or talk about? I think each
| company and product got its own rhythm and meetings should be
| adjusted to match that, we are human beings, not robots.
| syntaxing wrote:
| As hardware engineer that does a hybrid software/hardware role on
| a team that uses sprint/scrum planning, I find it a terrible idea
| for a lot of applications. It is great for certain situations but
| I find the discussions more about what task we should do rather
| than what problems we should solve and the value added. If things
| are breaking on a product/project because you didn't know about
| some upstream or downstream interface, the company itself has an
| underpinning issue on transparency and ownership. I have rushed
| hardware projects (expensive mistakes) involving capital
| equipment (expensive) and everything interfaced correctly given
| the fact that the ownership and responsibilities were transparent
| with decent planning in the beginning.
| jkingsbery wrote:
| On the teams I've been on that are actively doing software
| development (not in some pre-coding phase where we're still
| figuring out requirements or something like that), if there
| wasn't a stand-up individuals created an identical coordination
| mechanism in an ad hoc manner. This tells me that there is
| something valuable to stand-ups, even if we don't always love
| them. If a team's stand-ups are not effective, there are lots of
| things you can try: refocusing the team's attention, have someone
| other than the normal "stand-up leader" guide the conversation,
| or change the time so that it's next to another interruption (for
| example, right before most people get lunch... this has the added
| bonus of incentivizing people not to ramble).
___________________________________________________________________
(page generated 2020-09-24 23:01 UTC)