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.
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.
I guess I'm weird because I'm able to have a conversation with someone without standing up in a circle playing whatever games the specific manager wants to play.
I once convinced a team to try going without standups, but instead put it in slack for a week. At the end I was the only one who thought it was a success. I had one guy tell me he didn't like it because he didn't read it if it was in slack.
My jaw kind of hit the floor. That was my point all along about standups, the information being conveyed isn't actually needed for your job.
Agree, status updates are a waste of time on Slack or in a real meeting. Nobody actually cares about others statuses. If there is a real blocker a competent worker should resolve it on their own without waiting until the next status meeting imo.
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.
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).
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
I’m a PM and (perhaps not like the others, but) in my mind the standup is not just the status update, the important bit is to convey any roadblocks or problems you’re facing and the team or the PM can assist to resolve them. I think though, that many teams out there probably do not feel comfortable enough to talk about such things and the standup merely becomes the status update bore.
Team members shouldn't be waiting for a meeting to communicate roadblocks or problems. They can send out a message to the other team members at any time.
If someone has hit a blocker or other problem, surely they would find the help they need to resolve it at the time rather than waiting for a standup, right?
Slack standups were great for us, for a while. When there were ~10 people posting just a few lines, it was easy enough for everyone to skim through it daily. I didn't notice a lack of productive conversation - people made good use of threaded conversation and @-mentions. When the channel started to grow, unfortunately the system broke down. It's onerous for everyone to skim that much material first thing in the morning.
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.
Interesting, and I think a lifelong consideration/debate.
Having been a sysadmin / various kinds of techie for the majority of my career,nevertheless from most of my initial visibility into business & management worlds; and now having been full-time manager for 18 months; my feeling is that absolutely you need to understand, support, and enable your engineers to work on and in the way that makes them productive and satisfied... but last thing you should possibly do is "leave them the fuck alone". Otherwise, very quickly, there would be no salary for anybody :|
That being said, to the topic here, most "standups" I've been to have been a "spoke and hub" model where a PM elicits list of one-on-one status updates, and having done their part, people can doze off for rest of the meeting.
In meetings I own, I try to change that to "Tell us of things that matter / are interesting to everybody here". It's not an easy criteria to fulfill though, for management or techies alike.
I dont think it is that simple. Mostly because I was lucky enough to be in teams that were exactly "quiet place to work and leave them the fuck alone" and did not worked all that great.
First, people got demotivated due to seemingly no one caring what they do and when they are done. Some people were unable to finish tasks or self-organize. And this was the most functional team under the circumstances.
Second, in one team where cooperation was necessary, actual lack of defined responsibilities and leader meant that important tasks were not done. There were fights over how less important tasks should be done. Some controlling people tried to take over leadership, fighting among themselves. Then for a while everyone gave up leading to no one having initiative. Then fights again followed by people not talking to each other.
Third, customer ended up complaining over low performance and having to tell everyone the same thing again and again, cause people did not shared info.
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.
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.
Allow all guests, even announce all times. People will learn to attend where it matters, and simply won't have time for many standups. Format should cut off bad management and time-sinks too. Harder to contain democratization (the opposite of every other suggested model!).
How cute. I tried your suggestion once. What I got was an overengineered, poorly documented delivery that matched the spec about 50%. Oh, it was also a year late.
Sorry, but processes are there for a reason, and the reason is, broadly, that getting an average team of engineers to deliver on time, according to spec and without diving all the way down every overoptimization / navelgazing / random interest / flamewar / framework flavor of the day rabbithole there is is otherwise impossible. With process it becomes at least a tiny bit more akin to herding cats instead of just watching them run amok every which way.
I am going to have conversation on this exact same topic with my boss' boss later this week. I am influenced by Martin Fowler's State of Agile talk from 2018 [1]. Agile has driven all the developers out of the room, and now it is a playpen for all the process mavens.
We do call them scum masters and they are not engineers and not managers. It's like "let the blind lead the way". Same for managers that have no clue about what they are supposed to manage.
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.
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.
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.
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”.
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.
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.
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.
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.
I've been in stand-ups that worked well (rather, teams that had the degree of cohesion necessary for a stand-up to work well). But, even when you do have a good, productive, useful, fluid stand-up with some team it won't last forever. Roles change, people change, teams change, projects change. There are too many things that have to align to make these things provide their stated utility over the long-term. YMMV.
If the leader doesn't even know why they're "standing up", how will anyone benefit from it? Blindly following rules is just sorry-ass incompetent BS. Period.
In my experience, the few periods stand-up works (comedy aside), is when the leader (and noone is gonna do it without one!) understands what is to be gained by the people involved.
Unfortunately, whenever something randomly works, the next random reorg negates that overnight.
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.
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...
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.
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.
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.
Not the parent poster, but I would guess that when they say things like "(real) SDET" they are referring to someone who creates automated tests, creates scripts for testing, possibly uses white box / gray box approaches, creates test cases for sub-components and layers.
Compare to someone who only does black box testing and only tests from the standpoint of manually testing via a user interface.
It's actually more that an SDET has classically been the one who writes the tools and infrastructure that QA Automation Engineers would use to write scripts.
It implies an education/experience background equivalent to any other T&I Software Engineer, but usually with additional experience in QA. Alternately, it could be a QA engineer who would be genuinely qualified as a general SWE in a promotion path, but who chooses to stay in quality as a domain. But either way it implies equivalent qualifications as a SWE at the same level.
The "real" bit is because over the last half decade or so, SDET has been blurred by title inflation. Scripters have been getting the title without any real experience maintaining longer-term or larger software projects, and who aren't qualified enough to be hireable as a SWE generalist.
That's one reason you still get "lesser than SWE" status arguments about SDET, when IME you actually tend to demand a little more in the market because of the need for experience in two separate disciplines.
My response to the comment above you has a lot more detail expanding on that.
I've been in/around QA for about 20 years now, after 5 years as an app dev and doing a career semi-shift during the 2001 downturn. For the last ten years or so, I alternated between SWE and SDET titles depending on the job, and before that between QA and QA Automation Engineer. That history is where I'm coming from here.
In short, there's been a lot of title inflation in QA, in part to avoid the "black box tester" stigma for both the employees and the organizations alike.
One of those inflations has been calling what were QA Automation Engineers--generally people writing scripts--SDETs. I saw it start to rev up in the late 2000s, and saw it accelerate (maybe not coincidentally) in the early 2010s, shortly after a GTAC talk where they claimed SDET makes 30% more on the average than QA. I suspect a lot of people asked for title changes, or a lot of managers realized they'd also look 30% better managing SDETs than QA and advocated for them.
Thing is that SDET as originally conceived was/is supposed to be a Software Engineer who specializes in testing, with the same qualifications and training as any mainline SWE. The normal domain of SDET would not be scripts, per the other response, it'd be tools, infrastructure and harnesses, maybe seeding test frameworks for incremental development during test creation, usually along with some level of QA thought leadership.
The primary difference there would be the ability to scope, implement, and maintain longer-term software engineering projects. A QA Automation Engineer might be as skilled a coder, but test scripts tend to be short bursts of isolated code and don't require as much architectural or lifecycle experience.
But SDETs are also useful in cases where you want to blur SWE and test, since most SDETs have heavy experience in both and can talk shop and build rapport with both sides. That comes in very handy when pairing with a mainline SWE, hence mentioning it as a near-requirement for that process.
No offense to you and your journey, but I'd have never stepped back from an SDET role to a QA Automation Engineer. It really is objectively worth less in the market, for one thing, and there really is a stigma there with QA in the title. It shouldn't be that way, but it is, and inflation has been the natural response.
Re: advocating for quality from the beginning,
Testing is by nature quality control. You can do it early, you can do it late, but at the end of the day it's a screening process.
That's different than Quality Assurance, which is monitoring and influencing the process and decisions when they're made to promote and advocate for quality when determining the good/fast/cheap project management compromises.
That includes arguing for testability as a primary requirement, arguing against overly complex requirements likely to produce emergent bugs you can't easily catch with QC, pointing out gotchas (hey, everyone is on vacation in December, expect crap code rushed checkins in November), basically anything you can do to reduce risk.
So in that role you're not a tester, per se, but a Subject Matter Expert in quality, hopefully influencing a whole team towards testable products, intelligent context-driven processes and good use of test pyramid, use of static analysis and other code quality techniques (think SonarQube), etc.
All this is over and above just testing, because you simply can't test quality into a project, you can only delay it until it's good enough. That type of gatekeeping is an adversarial tension fraught with both process and organization risk, and it should be avoided.
When you're an obstacle, people will have the natural tendency to work around you and resent you when they can't, which makes it an unsustainable dynamic to rely on as your 80% case. Ideally, most testing should just confirm what you already know: you have a solid process that caught all major bugs before you ever did a final pass.
Even if your org is going to just go full QC instead of QA (which is pretty typical, unfortunately) being able to absorb the full architecture and use cases around what you'll be testing is vital for coming up with an efficient and sustainable test strategy.
If you've been in QA any length of time, you know that these qualities--efficient and sustainable--aren't exactly associated with that corner of the process. A lot of that is because QA/test is often relegated to reporting on how a bug repros and how severe the issue is. You could be doing so much more, but that requires cooperation from the people around you.
When I was doing my time as a QA Engineer before swinging back to SDET, I did this by leveraging my SWE experience to talk shop with devs in low level terms until they trusted me. But it's a hard road to climb, particularly if you didn't have a flipflop like I did.
I hope that answered your questions. It does reflect a degree of personal bias, of course, but it's pretty well-informed by a long time in this corner of the industry.
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.
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.
Right - but this gets to my bigger issues with how software development is done these days (and why I’m exiting as fast as possible after a 20+ year career...)... in theory we’ve got advanced degrees, are well-compensated, have to know dozens of technologies from the front end to the database, work twelve hour days, work weekends and nights on call, build systems that generate millions of dollars in revenues that keep the company running... but some project manager thinks they need to take roll call daily because I might not be responsible for myself? Gimmea break!
> making sure that team members are making progress and they're not blocked is very important
If you are blocked, you don't want to wait until the next standup meeting to address the issue anyway. Standups provide no benefit here.
> Sometimes it's all unintelligible mumbling and serves no purpose other than cargo cult.
I've come to the conclusion that standups exist simply to read the commit log to those who do not understand how to use <insert source control system>.
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.
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.
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 ; )
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.
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.
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.
I do not agree with this sentiment but that's okay. As I said, in my experience, what you're saying is absolutely untrue, but I'm speaking purely from my own experience.
> Tomorrow, I hope someone asks me for an update on my progress ; )
Suggestion to take or leave - instead of being asked, volunteer your status and set the tone for how you'd like others to make use of standup (format, brevity) :).
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".
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.
Sure, in a sense, the difference being whether the form of the reporting is aimed at helping team-members coordinate or helping a project manager move a marker on a chart or otherwise send reports upward. Who's it for is the key concern and makes the difference in what your standups are like, and who directly benefits from them.
Strongly agree that with certain teams you don't need a regular standup. That's part of why I think the decision to do a standup should be left to the team themselves, absent some clear dysfunction bad enough to require outside intervention. Otherwise you're probably just wasting everyone's time with 15+ minutes of boring crap that could just as well be a 2-minutes-to-write daily status update message or email to the project manager, assuming they can't get the status info they need out of Jira or git commits and skip the side-channel status updates altogether.
I guess another major tell aside from "multiple unrelated teams are in the same standup" might be whether, if every single non-manager/PM quickly checks in with the rest and they all conclude a formal standup's not needed that day (or the entire week, or whatever), a standup either still happens or else someone (a PM or a manager, probably) gets really bent out of shape if it doesn't. If so, you're likely dealing with a regular ol' daily status meeting. And again, that's what a majority of "standups" I've seen have actually been. They're not for the team, and however they manage to occasionally serve the team members' needs is accidental—they're just micromanagement and "agile" box-ticking.
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.
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.
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.
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
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.
