12 ms·

The good, the bad and the ugly standup

84 points by kristoff_it 7y ago

tvanantwerp 7y ago
Once had a daily standup with 30-35 employees, all different teams and projects, and no one enforcing brevity (going down the rabbit whole was common). The whole exercise felt like taking attendance. After the one senior person who insisted on them left, we dropped them immediately with no negative consequences.
- brutt 7y ago
  Standups are for small teams, e.g. less than 10 members. IMHO, your 30-35 employees meeting with members of different projects is "all hands meeting", not a standup.
  - tvanantwerp 7y ago
    I agree--the only thing these meetings had in common with an effective standup was the standing part.
    - JimmyAustin 7y ago
      I remember the exact moment I decided to leave a job. It was when, without a trace of irony, the project manager said “Alright everyone take a seat, it’s time for the standup”.
- mrbrowning 7y ago
  > The whole exercise felt like taking attendance. In my experience, almost anyone who insists on synchronous, in-person standups is doing so because they want them to function this way, whether consciously or unconsciously. I also suspect that standups with no active brevity constraint frequently come about not because of a lack of leadership but because they're actually a means for disordered thinkers to feel productive, which I think goes part of the way towards explaining why you see such irrational attachment to standups even among ICs.
  - pieterhg 7y ago
    What is an IC?
    - jiofih 7y ago
      Individual Contributor. Manager euphemism for a cog in the machine.
      - baroomba 7y ago
        SV-speak for labor, really, as in "the interests of capital/management and labor are, at times, opposed".
        redis_mlc 7y ago
        I think it was originally a Microsoft acronym. But, yeah, IC = prole.
      - dasKrokodil 7y ago
        Never heard this before, reminds me of Idiocracy's 'Particular Individuals'
      - MockObject 7y ago
        What is the alternative to being an Individual Contributor? An...individual non-contributor? Or a non-individual contributor?
        jiofih 7y ago
        Management and leadership roles.
        MockObject 7y ago
        And they aren't said to contribute? Odd terminology.
    - 7y ago
- GordonS 7y ago
  You can't have a meaningful stand up with so many people (TBH, I seldom find them meaningful regardless, but that's a tangent...) In large agile projects I've worked in before, we've split into teams of 5-10 and had separate stand ups, with leads from each team having a weekly "scrum of scrums" separately.
  - TheGallopedHigh 7y ago
    I guess a good name would be a meta scrum
santoshalper 7y ago
I have been an engineer or in engineering leadership most of my life. Now CTO of a large company. Nobody wants to say it out loud, but what we really need to do is treat engineers with respect. Give them a quiet place to work and leave them the fuck alone. Agile is just a watered-down compromise. We still get to have project managers, we just call them scrummasters and they get to bother the engineers slightly less.
- Consultant32452 7y ago
  I go back and forth on whether I should even call what we do a scrum. My understanding of a developer scrum is that it's supposed to benefit the developers by encouraging communication about status and issues. What we do is more like a round robin status update for the project manager who runs the meeting. The only discussions that ever come out of it are at the project management/schedule level, not the technical level. Calling it a scrum checks a box on someone's review for implementing agile practices, so at work I just let it go.
- kristoff_it 7y ago
  In my case what made the difference was holding the meeting without any management in it. To be fair to the agile movement, self-orgainizing teams and the value of individuals are all themes expressed quite clearly. Maybe you could try a small pilot and see where it goes.
  - bradknowles 7y ago
    IMO, no standup should have anyone attend that is not a direct member of the one specific team in question. At least, not without really good reason. So, the project manager/Scrum Master for the team, plus the technical members of the team. That's it. You can have guest attendees, if there is a good reason. You can have temporary members, if they're working with the team for a short period of time. But the basic rule should be just the engineers plus their project manager/scrum master. And no one should be in multiple standups without a really good reason. Maybe the PMs or Scrum Masters should be in a Scrum of Scrums, but that's about it.
js8 7y ago
Remember, it's a called a standup because it's a comedy. (I genuinely thought the article was gonna be about comedy. I was disappointed.)
jbob2000 7y ago
His Ugly and Bad aren't that bad! I'd be happy if those were my standups. Right now for me, the project managers own the whole event. You are asked for an update on a task that is on the project managers list, you give your update, and then he moves on to the next guy. There is only one developer in the meeting (me). The rest are QA, BA, Product Management, Delivery Management, and Change Management staff. The developers who work under me will get prodded randomly throughout the day by various other project managers for their updates. This is what happens when your company is "project oriented".
- kristoff_it 7y ago
  That's unfortunate. The silver lining is that you now know one (of the many) reason why a meeting can go wrong, and hopefully implement better procedures in a future job where you have the right leverage.
- brutt 7y ago
  It's called "status meeting". Usually, manager is not present at standup meeting at all, unless team asked him to participate.
  - baroomba 7y ago
    I've seen a lot more status meetings going by the name "standup" than I've seen actual standups. A good clue is when there are people on totally different projects in the same "standup". If a lot of the people in the room are very unlikely to give a shit what most of the other people say for their part of the standup because they're not even working on the same things, that's a good sign you're actually in a status meeting. If someone's likely to get on your ass for being more concerned about surfacing blockers and communicating usefully with your actual team members than strictly following "yesterday I... today I will..." format, or folks are often getting "OK, but where are you at on X?" or "how much longer on Y?" follow-up questions from a PM or manager, not a direct contributor for whom X or Y is relevant, you're likely in a status meeting.
    - erik_seaberg 7y ago
hnrodey 7y ago
I'm in a software leadership role. I'm currently involved in several, what I like to call, "dead standups". Zombie's could give an update and no one would bat an eyelash. Stand up can be useful if there is an effective leader. I'm actively trying to identify these characteristics and implement on the teams for where I am involved with the goal to cultivate/develop/train people to make these stand up meetings useful. Because we all know a dead standup is where productivity goes to die. I'll have to share my results. Tomorrow, I hope someone asks me for an update on my progress ; )
- baroomba 7y ago
  If the teams themselves don't want a standup, you're probably gonna get a "dead standup". The actually-useful-to-the-team part of the standup is something a team that's been exposed to such will probably self-organize without some not-on-the-team leader or manager telling them to, if they feel they need it for their situation/project. I'd say imposed standups are only useful for teams that aren't already familiar with them (the done-right version of them, that is) so may need an introduction to understand that it might be something they want to do, or as a simple micromanaging status meeting under a trendier name.
  - alexbanks 7y ago
    In my experience, if a team doesn't _want_ a standup (or some status update from their team members), they probably need rotated to something new. No process, or person, or tool can make a team member care about their project or peers.
    - outworlder 7y ago
      Or maybe as part of their normal interactions they already get all the status updates they could possibly need? Or maybe these updates are tracked in some other way (tickets and the like)? That's not the same as "not caring about their project". I care about my project, but I don't want to hear 30+ status updates for tasks which are progressing nominally.
ginko 7y ago
I generally find that the duration of standups scales O(n^2) with the number of participants.
29athrowaway 7y ago
How can you verify that your standups are effective? After the standup, take 2 random members and ask them to describe each other updates. You will be surprised with the results.
- clarry 7y ago
  Could you spoil us? I'm not in a position to run this experiment.
  - 29athrowaway 7y ago
    For non-stakeholders paying attention can be optional, so they may be caught not paying attention.
    - randomdata 7y ago
      But where is the surprise? I really could not care less about what other people are working on. Of course I am not going to pay attention.
- poulsbohemian 7y ago
  This is at the root of my stink with standups - I've been on many teams where each individual is working on some part of the system and has essentially no overlap on a daily or even weekly basis, yet here we are all meeting because cargo cult development practices says we should. So it's irrelevant to me what Jane is working on anymore than it is to her what I'm working on. The naysayers will say that that's the whole point of us meeting, because there might be some esoteric overlap that will only come to light due to our over-communication, but for my money there are other ways to solve that without a lengthy daily meeting.
  - 29athrowaway 7y ago
    In the restaurant industry, they do similar meetings called pre-shift meetings, aka lineups. The purpose of those is to check everyone is on time, check their uniform, talk about current promotions/deals/offers, discuss potential goals/bonuses, etc. And it makes sense. In software, standups make it easier for stakeholders to track that people go to the office, and do so at a reasonable time, although most people will not admit it because it sounds bad. Of course, making sure that team members are making progress and they're not blocked is very important, but that might not be relevant for non-stakeholders. Sometimes it's all unintelligible mumbling and serves no purpose other than cargo cult.
goatinaboat 7y ago
The only workable way to do stand ups is not to stand at all, but make everyone hold the plank position. The meeting ends when the scrummaster collapses.
- Kinrany 7y ago
  In a meritocratic organization the strongest programmers are rewarded!
  - paulmd 7y ago
    with sick gains and a rocking core!
fourmyle 7y ago
I'd honestly take a pay cut for a private office and maybe 1x standups.
- GreenJelloShot 7y ago
  For a private office and minimal meetings, I'd probably never interview for another job again.
geoelectric 7y ago
Excluding QA wasn't a plus. Quality works better when there's an advocate from the beginning. Problem is a lot of companies only engage QA for post-build integration testing. They try to phase it as a mini-waterfall within the agile cycles, which doesn't play well with agile and drags the process. At that point, leaving them to their own horizontal meetings seems like a plus, but there's a ton of opportunity cost for not having them in the primary conversation. Other companies try to leverage QA for unit tests, but those really should be written by whoever wrote the interface as part of ensuring their intended contracts are fulfilled. That makes unit test writing not really a good QA role, other than making sure they're there. The exception would be if you're going to pull QA in and pair-program/test TDD style--which is its own potential boondoggle. But you need real SDETs at that point, as opposed to scripters. Real SDETs aren't terribly common, and are not terribly cheap as they're niche specialists. The best solution I've seen is to split the advocacy/short-term roles and the test/architecture/long-term development roles (even if it's two hats on one person), have them in the meeting for the former and have the horizontal run their own projects with milestone syncs for the latter. At that point you can treat the short-term role as a team member, and the long-term roles as an internal vendor or external dependency (i.e. no expectation of control). Any sort of one-size-fits-all approach won't work.
- qa_guy 7y ago
  Just curious - when you say "(real) SDET" can you expand on what that means for you? I ask because I started out as SDET, but my title is now QA Automation Engineer. I sort of see myself as a developer working in a QA role - I work on testing frameworks and the architecture of that framework and then write integration tests against whatever a company's product is - whether it be an internal API, an external-facing API, a single page website, or a complicated multi-page website. I was just curious if there were additional responsibilities or techstacks I could be learning that other companies' "real" SDETs do as well. In my near 6 years of work in this niche, I've only been at two companies and they let me do my thing, so I'm not really sure if I'm "missing out" on knowledge or something. I am also curious as to what you mean by "Quality works better when there's an advocate from the beginning." In my experience, even when (or if) I am invited to an agile Sprint Grooming or Planning sessions, I am more there to report on how a bug works and how severe I think the issue is - no matter how well I document some bug I found or whether product is there (as they should be deciding severity). I'm not sure how to meaningfully leverage my QA experience into helping developers drive their design and architecture to create more bug-free, quality code. I do notice that once I join a company and find/report zillions of bugs, their code slowly gets better over time, but isolating an incident and then measuring my impact is nigh impossible. Anyway, I know this has nothing to do with the topic, I just wanted to see what you thought because SDET/QA talk is rare to find on this website.
overgard 7y ago
I never understood why the standup cant just be an asynchronous chat room. The information is easier to review and follow up on, and people can check in when its not a disruption. My gut feeling is, at most places, 90% of the purpose is for the pm to feel like the captain of the ship, and 10% is an attendance check.
- poulsbohemian 7y ago
  I did a project this time last year where that's exactly how it was handled - there was a Slack bot to which you sent a daily update. Everyone in the team could view everyone else's status so was easy to see what was going on.
  - overgard 7y ago
    How did people feel about it?
    - poulsbohemian 7y ago
      Personally I felt it was a little silly because the team manager didn't seem to review it ever and each team member was working on completely different systems. When there was a need for actual communication/coordination, we used slack or set up meetings. That stated - I liked it better than when I was in teams where there was the same dynamic (IE: very little necessary coordination across the team) but we met daily (or in some cases, twice daily shudder).
- dylan604 7y ago
  My favorite is when the PM uses Slack to cancel the daily standup on a daily basis because their schedule didn't allow for it, yet have no problem with the standup interrupting your day
- nilkn 7y ago
  We've experimented with both in-person and purely digital standups through Slack. The latter was exceptionally convenient, but we found it almost never led to any meaningful conversations. It became 100% a status report. In-person standups for us, on the other hand, follow the template of a status report, but every once in a while lead to a really important exchange happening between a few team members that really unblocks someone or course corrects something early on. So we've went back to only in-person standups.
himynameisdom 7y ago
The whole point of a stand up (daily scrum) is to discuss how work is progressing towards a sprint goal. If it devolves into a card-by-card status update meeting, it loses its value. It is nothing more than the dev team coming together to discuss how to move forward towards the goal. No one else should be at the meeting. If further detailed discussion is needed, save it for afterwards.
- SpicyLemonZest 7y ago
  How many teams are actually organized in this way, though? I've never been on a dev team where there was a single, unified sprint goal that all developers were working towards in an interrelated way.
adamzapasnik 7y ago
Standups ain't that bad when they are short and to the point and honest. Being honest that something may take longer than it was estimated for should be okay. But people make it a big deal, that if it takes even a few days more, you are incompetent. So participants chose not to share that details and there is miscommunication or bugs or both. Also, an important note. Even if there was a standup, it's ok to talk more in detail about the tasks/tickets after it, during a day. People seem to forget it and make the stantups far too long for everyone to hold one's attention until the end.
kube-system 7y ago
I think that the people who don't like standups, are the people who have never been a part of one that works well. This isn't surprising, because most don't work well. There are two critical things that a leader must do to run an effective standup: 1. You must have a leader who is willing to enforce the rules in order to effectively extract the right information to support managerial tasks (and not arbitrarily, but through team buy-in), and 2. They must be willing and able to understand most of the technical intricacies of the tasks taking place. In my experience, most organizations' standups are run by people who fail at one or both of these. Maybe they'll put in a PM who enforces the rules, but doesn't understand (or doesn't care to understand) the tasks the developers are doing with enough detail to be an effective facilitator. They act as a note-taker, letting the developers manage themselves ad-hoc, and don't ask questions unless someone specifically brings up a blocker. This can work with a team 100% full of self-starters who are comfortable with asking hard questions of each other, but that's your only hope. Or on the opposite side of the spectrum, you have organizations that put more senior developers in that role. Then, you often end up going down design rabbit holes until you've run out of time, and you never end up doing the tasks that you actually needed to do: planning everyone's time effectively, and recording/communicating progress so that stakeholders expectations are correctly managed. In both of those failure cases, you end up failing to deliver a quality product on time and/or fail to communicate expectations to stakeholders. In the first case, you made a plan, but it wasn't a full picture. In the second failure case, you had all of the right tasks figured out, but you failed to plan and communicate it.
- WJW 7y ago
  If most people are unable to do it right, the act is too difficult. Saying "it works fine if everyone does as they should" just ignores that people don't usually do as they "should" and is not very useful.
  - kube-system 7y ago
    I disagree. Most new ideas implemented in the workplace come with generational learning curves, even when history has shown them to be good ideas. This is just a cyclical skills gap. Few people running software projects have formal study that spans both management and software. Many have neither, in my experience. Sure, formal study is not a requirement for good performance, it sure helps to get everyone in an organization on the same page.
lunias 7y ago
As with anything "agile", it pays to stop and take stock of how your processes actually address the 4 key agile principals: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan I personally interpret "individuals and interactions over processes and tools" as a warning against the snake oil and magic bullets that agile consultants sold / are selling to corporations. Standups are not at all a bad idea, but I feel like most implementations are simply a response to a prescription rather than a symptom. Nor do I feel like the prescription is particularly effective: rather than using the structure of a standup you could just, of your own volition - when useful; take an interest in your teammates' work, talk to them, and collaboratively come up with a solution.
- 29athrowaway 7y ago
  This website has an interesting response to the agile values: http://programming-motherfucker.com/ http://programming-motherfucker.com/ Excuse the profanity, btw.
  - lunias 7y ago
    Haha. Love it! The satire; not the fact that it's largely in alignment with my experience in enterprise...
fourmyle 7y ago
Yesterday I did a thing, Today I am doing a thing and currently I am or not able to do that thing. For me the main problem with stand-ups, especially when they are more than 2 times a week, is that they make it impossible to do lengthy unstructured work. It's embarrassing to say that you worked on something and didn't get anywhere. My theory is that max task size becomes the length of time between standups in most orgs.
- soinus 7y ago
  Same here. After working in academia with no agile process (worked well), in a startup or around 20 engineers using OKRs (worked great) and a big company following SCRUM (nightmarish) I could not agree more with you. I believe weekly OKRs are the best of two worlds: they are restrictive enough to feel the peer pressure for ones committed goal and descriptive enough for any manager to get a grip on the current situation, while at the same time relaxed enough for engineers to not feel like they are trapped in a cage. One week is plenty of time to either finish some work that just needs to be done or write a small prototype. In fact I liked it so much, that I brought the idea of OKRs back to my research lab and everybody loves it! Scrum is the worst of this for me. We've rotated through a couple of daily formats and it always feels micromanaged and pointless. In addition to that it takes away the personal feeling of achievement. My best work in this framework has been done when I ignored the framework as the whole...
sumanthvepa 7y ago
The primary purpose of a standup seems to be a forcing function. It forces developers to make progress. The embarrassment factor of having to admit you did not finish your tasks for the day is what drives these meetings. I've been through the grind on both sides: as a developer and as a manager. I thoroughly detest stand-ups. When I started my company, I decided not to do them. I have a one-on-one with each developer everyday to understand progress. I don't ask for progress reports, since I can see their commit history. This seems to more effective than wasting their time and mine in a pointless meeting. I still do stand-ups with sales people though. They seem to like the camaraderie of the big meeting.
geebee 7y ago
Good post, nice roundup of some of the ways standups can go wrong and right. I do think it skipped a common severe corruption of the daily standup, which is a daily application of micromanagement and deadline pressures. I’ve heard about successful daily scrum meetings but I now believe the inherent chemical instability of this practice makes it too dangerous for all but a few very disciplined teams and only when absolutely necessary. To me, scrum is the nitroglycerin of management methodologies. People who think they can handle it safely probably can’t. It’s wildly tempting for managers or stakeholders who are concerned with deadlines to hijack the meetings

84 points by kristoff_it 7y ago

Once had a daily standup with 30-35 employees, all different teams and projects, and no one enforcing brevity (going down the rabbit whole was common). The whole exercise felt like taking attendance. After the one senior person who insisted on them left, we dropped them immediately with no negative consequences.

brutt 7y ago
Standups are for small teams, e.g. less than 10 members. IMHO, your 30-35 employees meeting with members of different projects is "all hands meeting", not a standup.
- tvanantwerp 7y ago
  I agree--the only thing these meetings had in common with an effective standup was the standing part.
  - JimmyAustin 7y ago
    I remember the exact moment I decided to leave a job. It was when, without a trace of irony, the project manager said “Alright everyone take a seat, it’s time for the standup”.
mrbrowning 7y ago
> The whole exercise felt like taking attendance. In my experience, almost anyone who insists on synchronous, in-person standups is doing so because they want them to function this way, whether consciously or unconsciously. I also suspect that standups with no active brevity constraint frequently come about not because of a lack of leadership but because they're actually a means for disordered thinkers to feel productive, which I think goes part of the way towards explaining why you see such irrational attachment to standups even among ICs.
- pieterhg 7y ago
  What is an IC?
  - jiofih 7y ago
    Individual Contributor. Manager euphemism for a cog in the machine.
    - baroomba 7y ago
      SV-speak for labor, really, as in "the interests of capital/management and labor are, at times, opposed".
      - redis_mlc 7y ago
        I think it was originally a Microsoft acronym. But, yeah, IC = prole.
    - dasKrokodil 7y ago
      Never heard this before, reminds me of Idiocracy's 'Particular Individuals'
    - MockObject 7y ago
      What is the alternative to being an Individual Contributor? An...individual non-contributor? Or a non-individual contributor?
      - jiofih 7y ago
        Management and leadership roles.
        MockObject 7y ago
        And they aren't said to contribute? Odd terminology.
  - 7y ago
GordonS 7y ago
You can't have a meaningful stand up with so many people (TBH, I seldom find them meaningful regardless, but that's a tangent...) In large agile projects I've worked in before, we've split into teams of 5-10 and had separate stand ups, with leads from each team having a weekly "scrum of scrums" separately.
- TheGallopedHigh 7y ago
  I guess a good name would be a meta scrum

santoshalper 7y ago

I have been an engineer or in engineering leadership most of my life. Now CTO of a large company. Nobody wants to say it out loud, but what we really need to do is treat engineers with respect. Give them a quiet place to work and leave them the fuck alone. Agile is just a watered-down compromise. We still get to have project managers, we just call them scrummasters and they get to bother the engineers slightly less.

Consultant32452 7y ago
I go back and forth on whether I should even call what we do a scrum. My understanding of a developer scrum is that it's supposed to benefit the developers by encouraging communication about status and issues. What we do is more like a round robin status update for the project manager who runs the meeting. The only discussions that ever come out of it are at the project management/schedule level, not the technical level. Calling it a scrum checks a box on someone's review for implementing agile practices, so at work I just let it go.
kristoff_it 7y ago
In my case what made the difference was holding the meeting without any management in it. To be fair to the agile movement, self-orgainizing teams and the value of individuals are all themes expressed quite clearly. Maybe you could try a small pilot and see where it goes.
- bradknowles 7y ago
  IMO, no standup should have anyone attend that is not a direct member of the one specific team in question. At least, not without really good reason. So, the project manager/Scrum Master for the team, plus the technical members of the team. That's it. You can have guest attendees, if there is a good reason. You can have temporary members, if they're working with the team for a short period of time. But the basic rule should be just the engineers plus their project manager/scrum master. And no one should be in multiple standups without a really good reason. Maybe the PMs or Scrum Masters should be in a Scrum of Scrums, but that's about it.

js8 7y ago

Remember, it's a called a standup because it's a comedy. (I genuinely thought the article was gonna be about comedy. I was disappointed.)

jbob2000 7y ago

His Ugly and Bad aren't that bad! I'd be happy if those were my standups. Right now for me, the project managers own the whole event. You are asked for an update on a task that is on the project managers list, you give your update, and then he moves on to the next guy. There is only one developer in the meeting (me). The rest are QA, BA, Product Management, Delivery Management, and Change Management staff. The developers who work under me will get prodded randomly throughout the day by various other project managers for their updates. This is what happens when your company is "project oriented".

kristoff_it 7y ago
That's unfortunate. The silver lining is that you now know one (of the many) reason why a meeting can go wrong, and hopefully implement better procedures in a future job where you have the right leverage.
brutt 7y ago
It's called "status meeting". Usually, manager is not present at standup meeting at all, unless team asked him to participate.
- baroomba 7y ago
  I've seen a lot more status meetings going by the name "standup" than I've seen actual standups. A good clue is when there are people on totally different projects in the same "standup". If a lot of the people in the room are very unlikely to give a shit what most of the other people say for their part of the standup because they're not even working on the same things, that's a good sign you're actually in a status meeting. If someone's likely to get on your ass for being more concerned about surfacing blockers and communicating usefully with your actual team members than strictly following "yesterday I... today I will..." format, or folks are often getting "OK, but where are you at on X?" or "how much longer on Y?" follow-up questions from a PM or manager, not a direct contributor for whom X or Y is relevant, you're likely in a status meeting.
  - erik_seaberg 7y ago

hnrodey 7y ago

I'm in a software leadership role. I'm currently involved in several, what I like to call, "dead standups". Zombie's could give an update and no one would bat an eyelash. Stand up can be useful if there is an effective leader. I'm actively trying to identify these characteristics and implement on the teams for where I am involved with the goal to cultivate/develop/train people to make these stand up meetings useful. Because we all know a dead standup is where productivity goes to die. I'll have to share my results. Tomorrow, I hope someone asks me for an update on my progress ; )

baroomba 7y ago
If the teams themselves don't want a standup, you're probably gonna get a "dead standup". The actually-useful-to-the-team part of the standup is something a team that's been exposed to such will probably self-organize without some not-on-the-team leader or manager telling them to, if they feel they need it for their situation/project. I'd say imposed standups are only useful for teams that aren't already familiar with them (the done-right version of them, that is) so may need an introduction to understand that it might be something they want to do, or as a simple micromanaging status meeting under a trendier name.
- alexbanks 7y ago
  In my experience, if a team doesn't _want_ a standup (or some status update from their team members), they probably need rotated to something new. No process, or person, or tool can make a team member care about their project or peers.
  - outworlder 7y ago
    Or maybe as part of their normal interactions they already get all the status updates they could possibly need? Or maybe these updates are tracked in some other way (tickets and the like)? That's not the same as "not caring about their project". I care about my project, but I don't want to hear 30+ status updates for tasks which are progressing nominally.

ginko 7y ago

I generally find that the duration of standups scales O(n^2) with the number of participants.

29athrowaway 7y ago

How can you verify that your standups are effective? After the standup, take 2 random members and ask them to describe each other updates. You will be surprised with the results.

clarry 7y ago
Could you spoil us? I'm not in a position to run this experiment.
- 29athrowaway 7y ago
  For non-stakeholders paying attention can be optional, so they may be caught not paying attention.
  - randomdata 7y ago
    But where is the surprise? I really could not care less about what other people are working on. Of course I am not going to pay attention.
poulsbohemian 7y ago
This is at the root of my stink with standups - I've been on many teams where each individual is working on some part of the system and has essentially no overlap on a daily or even weekly basis, yet here we are all meeting because cargo cult development practices says we should. So it's irrelevant to me what Jane is working on anymore than it is to her what I'm working on. The naysayers will say that that's the whole point of us meeting, because there might be some esoteric overlap that will only come to light due to our over-communication, but for my money there are other ways to solve that without a lengthy daily meeting.
- 29athrowaway 7y ago
  In the restaurant industry, they do similar meetings called pre-shift meetings, aka lineups. The purpose of those is to check everyone is on time, check their uniform, talk about current promotions/deals/offers, discuss potential goals/bonuses, etc. And it makes sense. In software, standups make it easier for stakeholders to track that people go to the office, and do so at a reasonable time, although most people will not admit it because it sounds bad. Of course, making sure that team members are making progress and they're not blocked is very important, but that might not be relevant for non-stakeholders. Sometimes it's all unintelligible mumbling and serves no purpose other than cargo cult.

goatinaboat 7y ago

The only workable way to do stand ups is not to stand at all, but make everyone hold the plank position. The meeting ends when the scrummaster collapses.

Kinrany 7y ago
In a meritocratic organization the strongest programmers are rewarded!
- paulmd 7y ago
  with sick gains and a rocking core!

fourmyle 7y ago

I'd honestly take a pay cut for a private office and maybe 1x standups.

GreenJelloShot 7y ago
For a private office and minimal meetings, I'd probably never interview for another job again.

geoelectric 7y ago

Excluding QA wasn't a plus. Quality works better when there's an advocate from the beginning. Problem is a lot of companies only engage QA for post-build integration testing. They try to phase it as a mini-waterfall within the agile cycles, which doesn't play well with agile and drags the process. At that point, leaving them to their own horizontal meetings seems like a plus, but there's a ton of opportunity cost for not having them in the primary conversation. Other companies try to leverage QA for unit tests, but those really should be written by whoever wrote the interface as part of ensuring their intended contracts are fulfilled. That makes unit test writing not really a good QA role, other than making sure they're there. The exception would be if you're going to pull QA in and pair-program/test TDD style--which is its own potential boondoggle. But you need real SDETs at that point, as opposed to scripters. Real SDETs aren't terribly common, and are not terribly cheap as they're niche specialists. The best solution I've seen is to split the advocacy/short-term roles and the test/architecture/long-term development roles (even if it's two hats on one person), have them in the meeting for the former and have the horizontal run their own projects with milestone syncs for the latter. At that point you can treat the short-term role as a team member, and the long-term roles as an internal vendor or external dependency (i.e. no expectation of control). Any sort of one-size-fits-all approach won't work.

qa_guy 7y ago
Just curious - when you say "(real) SDET" can you expand on what that means for you? I ask because I started out as SDET, but my title is now QA Automation Engineer. I sort of see myself as a developer working in a QA role - I work on testing frameworks and the architecture of that framework and then write integration tests against whatever a company's product is - whether it be an internal API, an external-facing API, a single page website, or a complicated multi-page website. I was just curious if there were additional responsibilities or techstacks I could be learning that other companies' "real" SDETs do as well. In my near 6 years of work in this niche, I've only been at two companies and they let me do my thing, so I'm not really sure if I'm "missing out" on knowledge or something. I am also curious as to what you mean by "Quality works better when there's an advocate from the beginning." In my experience, even when (or if) I am invited to an agile Sprint Grooming or Planning sessions, I am more there to report on how a bug works and how severe I think the issue is - no matter how well I document some bug I found or whether product is there (as they should be deciding severity). I'm not sure how to meaningfully leverage my QA experience into helping developers drive their design and architecture to create more bug-free, quality code. I do notice that once I join a company and find/report zillions of bugs, their code slowly gets better over time, but isolating an incident and then measuring my impact is nigh impossible. Anyway, I know this has nothing to do with the topic, I just wanted to see what you thought because SDET/QA talk is rare to find on this website.

overgard 7y ago

I never understood why the standup cant just be an asynchronous chat room. The information is easier to review and follow up on, and people can check in when its not a disruption. My gut feeling is, at most places, 90% of the purpose is for the pm to feel like the captain of the ship, and 10% is an attendance check.

poulsbohemian 7y ago
I did a project this time last year where that's exactly how it was handled - there was a Slack bot to which you sent a daily update. Everyone in the team could view everyone else's status so was easy to see what was going on.
- overgard 7y ago
  How did people feel about it?
  - poulsbohemian 7y ago
    Personally I felt it was a little silly because the team manager didn't seem to review it ever and each team member was working on completely different systems. When there was a need for actual communication/coordination, we used slack or set up meetings. That stated - I liked it better than when I was in teams where there was the same dynamic (IE: very little necessary coordination across the team) but we met daily (or in some cases, twice daily shudder).
dylan604 7y ago
My favorite is when the PM uses Slack to cancel the daily standup on a daily basis because their schedule didn't allow for it, yet have no problem with the standup interrupting your day
nilkn 7y ago
We've experimented with both in-person and purely digital standups through Slack. The latter was exceptionally convenient, but we found it almost never led to any meaningful conversations. It became 100% a status report. In-person standups for us, on the other hand, follow the template of a status report, but every once in a while lead to a really important exchange happening between a few team members that really unblocks someone or course corrects something early on. So we've went back to only in-person standups.

himynameisdom 7y ago

The whole point of a stand up (daily scrum) is to discuss how work is progressing towards a sprint goal. If it devolves into a card-by-card status update meeting, it loses its value. It is nothing more than the dev team coming together to discuss how to move forward towards the goal. No one else should be at the meeting. If further detailed discussion is needed, save it for afterwards.

SpicyLemonZest 7y ago
How many teams are actually organized in this way, though? I've never been on a dev team where there was a single, unified sprint goal that all developers were working towards in an interrelated way.

adamzapasnik 7y ago

Standups ain't that bad when they are short and to the point and honest. Being honest that something may take longer than it was estimated for should be okay. But people make it a big deal, that if it takes even a few days more, you are incompetent. So participants chose not to share that details and there is miscommunication or bugs or both. Also, an important note. Even if there was a standup, it's ok to talk more in detail about the tasks/tickets after it, during a day. People seem to forget it and make the stantups far too long for everyone to hold one's attention until the end.

kube-system 7y ago

I think that the people who don't like standups, are the people who have never been a part of one that works well. This isn't surprising, because most don't work well. There are two critical things that a leader must do to run an effective standup: 1. You must have a leader who is willing to enforce the rules in order to effectively extract the right information to support managerial tasks (and not arbitrarily, but through team buy-in), and 2. They must be willing and able to understand most of the technical intricacies of the tasks taking place. In my experience, most organizations' standups are run by people who fail at one or both of these. Maybe they'll put in a PM who enforces the rules, but doesn't understand (or doesn't care to understand) the tasks the developers are doing with enough detail to be an effective facilitator. They act as a note-taker, letting the developers manage themselves ad-hoc, and don't ask questions unless someone specifically brings up a blocker. This can work with a team 100% full of self-starters who are comfortable with asking hard questions of each other, but that's your only hope. Or on the opposite side of the spectrum, you have organizations that put more senior developers in that role. Then, you often end up going down design rabbit holes until you've run out of time, and you never end up doing the tasks that you actually needed to do: planning everyone's time effectively, and recording/communicating progress so that stakeholders expectations are correctly managed. In both of those failure cases, you end up failing to deliver a quality product on time and/or fail to communicate expectations to stakeholders. In the first case, you made a plan, but it wasn't a full picture. In the second failure case, you had all of the right tasks figured out, but you failed to plan and communicate it.

WJW 7y ago
If most people are unable to do it right, the act is too difficult. Saying "it works fine if everyone does as they should" just ignores that people don't usually do as they "should" and is not very useful.
- kube-system 7y ago
  I disagree. Most new ideas implemented in the workplace come with generational learning curves, even when history has shown them to be good ideas. This is just a cyclical skills gap. Few people running software projects have formal study that spans both management and software. Many have neither, in my experience. Sure, formal study is not a requirement for good performance, it sure helps to get everyone in an organization on the same page.

lunias 7y ago

As with anything "agile", it pays to stop and take stock of how your processes actually address the 4 key agile principals: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan I personally interpret "individuals and interactions over processes and tools" as a warning against the snake oil and magic bullets that agile consultants sold / are selling to corporations. Standups are not at all a bad idea, but I feel like most implementations are simply a response to a prescription rather than a symptom. Nor do I feel like the prescription is particularly effective: rather than using the structure of a standup you could just, of your own volition - when useful; take an interest in your teammates' work, talk to them, and collaboratively come up with a solution.

29athrowaway 7y ago
This website has an interesting response to the agile values: http://programming-motherfucker.com/ http://programming-motherfucker.com/ Excuse the profanity, btw.
- lunias 7y ago
  Haha. Love it! The satire; not the fact that it's largely in alignment with my experience in enterprise...

fourmyle 7y ago

Yesterday I did a thing, Today I am doing a thing and currently I am or not able to do that thing. For me the main problem with stand-ups, especially when they are more than 2 times a week, is that they make it impossible to do lengthy unstructured work. It's embarrassing to say that you worked on something and didn't get anywhere. My theory is that max task size becomes the length of time between standups in most orgs.

soinus 7y ago
Same here. After working in academia with no agile process (worked well), in a startup or around 20 engineers using OKRs (worked great) and a big company following SCRUM (nightmarish) I could not agree more with you. I believe weekly OKRs are the best of two worlds: they are restrictive enough to feel the peer pressure for ones committed goal and descriptive enough for any manager to get a grip on the current situation, while at the same time relaxed enough for engineers to not feel like they are trapped in a cage. One week is plenty of time to either finish some work that just needs to be done or write a small prototype. In fact I liked it so much, that I brought the idea of OKRs back to my research lab and everybody loves it! Scrum is the worst of this for me. We've rotated through a couple of daily formats and it always feels micromanaged and pointless. In addition to that it takes away the personal feeling of achievement. My best work in this framework has been done when I ignored the framework as the whole...

sumanthvepa 7y ago

The primary purpose of a standup seems to be a forcing function. It forces developers to make progress. The embarrassment factor of having to admit you did not finish your tasks for the day is what drives these meetings. I've been through the grind on both sides: as a developer and as a manager. I thoroughly detest stand-ups. When I started my company, I decided not to do them. I have a one-on-one with each developer everyday to understand progress. I don't ask for progress reports, since I can see their commit history. This seems to more effective than wasting their time and mine in a pointless meeting. I still do stand-ups with sales people though. They seem to like the camaraderie of the big meeting.

geebee 7y ago

Good post, nice roundup of some of the ways standups can go wrong and right. I do think it skipped a common severe corruption of the daily standup, which is a daily application of micromanagement and deadline pressures. I’ve heard about successful daily scrum meetings but I now believe the inherent chemical instability of this practice makes it too dangerous for all but a few very disciplined teams and only when absolutely necessary. To me, scrum is the nitroglycerin of management methodologies. People who think they can handle it safely probably can’t. It’s wildly tempting for managers or stakeholders who are concerned with deadlines to hijack the meetings