We cancelled standups and let the team build

Be bold. Make change. Improve the way you work.

Was cancelling standups going to far? Maybe. But that's not the point.

that's true, but it just turns the question into the one of "is it possible to do real standups?". My experience is that I've never managed to do real standups. It's just not possible to relay complex information about what you're doing in 1 minute. You either do it so superficially it's worthless or you it in depth and it takes longer than a standup should.

Compare that to hourly <n>-people's time is profligately spent and it has advantages for everyone.

If something needs more discussion, then the interested parties - only - can have their own meeting.

Why? Because no matter when you schedule a daily meeting, it will be in the middle of someones deep work hours, and they will have to context switch for 15 minutes just to tell “No impediments”.

My ex-LM is now working for major finance processing company. They went trough major agile transformation everyone in the city was talking about how big success it was. He's a tech-lead. He has to estimate feature development in man-hours to the board and investors. Everyone below him (SM, PO, devs, QAs) estimate in story points. He gets shit for features being late by days (eg. sprint finishes on Thursday next week, board meeting is on Tuesday this week).

They cancelled something they were doing completely wrong, because they never reached for quality material how to do it right. Good for them, it was a waste of time to begin with.

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"

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.

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.

That's what a sprint is.

Um, yeah, that's a sprint. That's exactly how it's supposed to work. Like you say, it's a good way to work. What do you think a sprint is?

I've worked in non-sprint models - i.e. no regular time-based cadence - and found them harder. It's very easy for a feature to scope creep if you've not got any regular schedule, and it's harder to feel a sense of achievement if you're not releasing regularly.

Having a two week period with a decided set of work allows you to peacefully do this work isolated from incoming requests - unless they are critical, they will always be delayed to the next sprint. Without sprints, our direction and priority changed daily, with no ability to say "we haven't planned for this, please wait". The result was it was incredibly hard to get anything done, and attention was always scattered.

I am happily back at a place that is doing sprints, and I am sure the problems at my previous organization were far bigger than not having them, but sprints do seem like a great tool to isolate the developer from exterior fluctuations. Granted, a great project manager can probably do the same thing.

Disclaimer: These are subjective opinions, and I recognise that some developers thrive in this environment. Also, this is a comment on Agile in the wild, rather than in principle.

And not the work adapt to a mechanistic interaction style.

When we need frequent feedback we do frequent feedback. When we need deep group planing we do group planing periods. When we need intensive coding we do intensive coding with occasional follow ups. We track progress, we monitor workforce. When someone hit the wall that person cries for help and we do something about it - depends on the trouble what and how. In one position we used it but was sooo mechanistic and insufficient to address the varying needs that it died off quickly.

I believe it cold be great for certain situations. Simple repetitive ones? But otherwise looks like yet another holy grail management method people hype for a while and might join the club of all other holy grail management techniques being praised to the heavens in their time throughout the history so the world was adjusted to those not the other way around. Then found yet another holy grail out of disappointment.

Not to mention that seemingly no one knows what it is exactly and how it should be used, some do this was, some do that way. And so we are back to the adaptive management now. : )

It must be good for a certain set of situations but it is odd that this is a crucial bit in interviews if someone have experience in it or not, like if it was impossible to adapt to the management style of the task at hand and it would require special skills or capabilities requiring preexisting abilities or formal training....

I don't have a great opinion of sprints for a couple of reasons. I used to have a job that did sprints. Development was often rushed to fit the sprints which led to a high rate of defects. And now I'm working with a vendor that does development in sprints. When we ask them for changes, it adds a large amount of lag to actually getting them because we have to wait up to 2 weeks for them to reprioritize, and then at least 2 weeks for release.

Then there is also the side effect of our monkey brains to give importance to people you see often. Stand-ups cultivate the feeling of "this is a team". It's important to show members what the team is.

Stand-ups however are not a requirement for a good functioning team. I'm leading a small team of senior devs and, despite my praise above, I decided against daily stand-ups. There is sufficient intelligence and communication, and just general professionalism in everyone in the team, that daily stand-ups are not worth the hassle and corporate feeling.

As a rule of thumb, if there are junior devs on the team, I would insist on having daily stand-ups on that team.

I used to enjoy meetings when I first started there because it felt good to have a break from staring at a screen all day but I quickly got tired of being invited to 90 minutes long meetings on project X where my input was only needed for one point out of the 12 on the meeting agenda.

"Agile mandates post-it notes" kinda stuff

Standups could be very well replaced by a chat channel, for example. This way it's broadcast, recorded and can be a bit async as no-one needs their turn to speak

However it's also nice to discover if work done by other devs interact with what I might be working on. Maybe I'm working on changing some logic in a module, and some other dev is about to make an integration for a customer which will involve that module indirectly.

He might not be aware of this indirect dependency, so I can give him a heads-up and now we know we must keep in touch over this work.

It's also good in case someone else has any good ideas for solving an issue. Maybe someone knows of a tool or a service which can do the job. Maybe someone has experience on that sort of stuff, so the dev doing the work knows who to ask for advice.

This is the only regular internal meeting I have though. There might be a case-specific one or similar once or twice a month, the rest is just ad-hoc with 1-2 others as needed via Teams or dropping by the office (pre-pandemic).

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.

I'm not too young. Agile is definitely bad. It's a cancer on software development.

If you're having issues with your work fitting into a sprint, have you dug into why? Are you breaking down the task into small enough units that make them more digestable in a sprints worth of time?

We also punted on standups, I never found them to be valuable and past experiences felt like they were more of a mechanism to get people into the office at a certain time. We do a once a week team meeting with an agenda that you can add to before hand. We discuss anything that needs to be discussed as a team and unblock anyone then. I trust everyone is doing work daily and I can check our sprint board without having everyone tell me what they worked on daily.

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.

Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. Exception: when the author is present. Then friendly feedback might be helpful.

It's very hard to make the call about when it's worth interrupting another team member. You're potentially setting back their work a significant amount, and it tends to feel like an admission of failure. Having a regular scheduled time to do it takes a lot of the sting out of it.

Fortunately my current team does 11:15 which works great, especially from home.

Means there is a blocker and the person is stuck or meandering and can't or won't explain it. Major yellow flag.

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.

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)

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.

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.

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.

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.

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

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.

Not all of us enjoy being micromanaged.

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.

Software can achieve this, and it's what my startup is trying to make happen. The key is to unify status-as-in-state with status-as-in-active-communication so the two can inform each other.

1) Standups are for knowing what your team is up to. 2) Standups are for removing blockers.

If (1) is correct, then let’s just call them what we always did before the SW Project Management Industry decided to buzzword it. Status updates.

And if they are status update meetings, then the simple question becomes why they should be daily. Their cadence should be dependent on the type of work the team is doing. If the type of work you’re doing means the majority of your work items are done in a day or less, then by all means have a daily status update meeting. However, if like many teams, the majority of your work are items which take 2-3 days, if not weeks, to complete, then why not just do 1-2 status update meetings a week?

And when it comes to removing blockers, why have a daily meeting at all. Why not do it in an async format using mailing lists (or Instant message/Teams/Slack/etc) instead. That ensures you’re not blocked waiting for the standup, and everyone is aware of your blocker as soon as is convenient for them.

In practice, however, Standups tend to be a mixture of both (and that’s how they are usually defined...what you did yesterday/what you will work on today is status updates, and blockers is about removing impediments). And that makes even less sense from a purely theoretical perspective (never mind the scores of practical experiences where it’s been a disaster), because those 2 tasks have different ideal cadences. Blockers are something that should be shared immediately, as they happen. Status updates, however, should have a far slower cadence, where you need to balance the need to keep the team informed about your work, and share progress towards goals, with the fact that each update is an interruption, and so the ideal cadence would be dependent on the nature of the work the team does.

The idea of a daily standup is a good fit only for teams whose work happens to be such that once a day happens to be an appropriate cadence for their status updates. And even then it’s not a good solution for the blockers removing aspect.