You don’t need standups

You describe a better way of doing standups than simply status reports, but I'm finding it hard to distil into a couple of sentences. Could you help me understand what a better standup would look like?

Line by line:

> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t.

My team offloaded this to the PM.

> Stand-ups ENCOURAGE plans to change daily.

The sprint plan is the plan, stand-ups make sure the execution is coordinated.

> Standup forces every team member to be productive at a set place and a set time

Timing around standups is interesting. 11am and everyone will be there, but it interrupts a lot of people's flow. Earlier and people no show, later and the point of a morning stand up is lost.

> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem.

How are extroverts and tech debt related?

> Developers shouldn’t have to PUSH for tech debt to be addressed.

Have a sustainable plan for addressing tech debt. My team had 3 week sprints, 2 weeks code, 1 week on debt. Developers who had just finished a major feature would be cycled on to tech debt for the entirety of the next sprint.

> Why do we encourage problems to be discussed once a week?

You can talk about problems whenever, but having a set place to have larger planning discussions means that you waste less time smaller meetings about them.

> Sprints encourage features over tech debt.

Plan tech debt into your sprints. Put bug fixing onto your task board. Put writing tests onto your task board. If your task board is full of tech debt, then you can't add any more features, because that is how a task board works, it gets filled up eventually and you have to go through it completing stuff.

> It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt

Tech debt sounds like a cultural problem on team's he has been on. Not surprising, it is a cultural problem on a lot of teams, independent of dev methodology.

> Developers communicate more

Why? Developers are always free to communicate outside of stand-ups.

> Tech debt gets addressed

If promotions are based upon feature completion, as they often are, tech debt being completed isn't a natural outcome of freeing up 10 minutes a day.

One goal of stand-ups is for people to say outloud what they are working on, so if someone else has knowledge in that area, that person can overhear and chip in.

Without a public forum, how is Developer A supposed to know Developer B is knee deep in code that Developer A wrote a year ago? Keep up to date on everyone's assigned tasks?

> It’s my role to “steer the ship” (e.g. decide what we work on).

I find that giving developers input on this is important. In fact, that is how the tech debt gets addressed...

> If I’m changing my mind about this on a daily basis that’s problematic.

Yeah, don't do that. Daily standups are not for PMs to give feedback, or talk much for that matter. They are for devs to coordinate the day's tasks.

> Stop planning every sprint

Sprints are super useful to chunk up work and allocate resources. For companies that have infinite investor money and ship a fancy JS app that can be updated at any time without impacting customers, sure, go sprint less.

Have a hard deadline that you need work done by? Does shipping your product have an actual impact on end users? You need to be able to estimate how long work will take, and figure out what people will be doing.

Historical task completion rate, bug fix rates, and burn down charts let teams accurately estimate how much work they can get done before that real life deadline hits.

IMHO weekly planning is too much. My team experimented with a bunch of different sprint schedules, we settled on 3 weeks as a good balance between time spent planning and time spent getting stuff done.

Sprints had a rhythm, developers assigned to multi-sprint features ignored the rhythm for the most part.

For everyone else, 2 weeks feature work, 1 week tech debt, and coordinating with test for sign off.

> Tasks are added to the backlog as needed,

Stand-ups have no impact on this being possible. The add task button is always available, 24/7.

> Developers are trusted to be working on the correct things

Stand-ups have no impact on this. You can still trust people to pull of the tasks they feel are important.

> Stop doing retros

Retros are how the devs tell everyone else that tech debt needs to be addressed. It is where they can make a solid numerical argument that more time needs to be taken to fix bugs. On multiple occasions I used retros to get the larger org to buy off on my team spending an entire sprint on just bug fixes and tech debt. We were able to show previous burn down charts, show how our productivity had decreased as tech debt went up, and use hard numbers to estimate our improved velocity after taking time off to address out debt.

tl;dr: Stand-ups are a nice way for developers to catch up on what is being worked on by their team mates, and to know if they can help each other out.

If you use them for anything more than that, well, sure, simplify it.

Standup just before lunch might work better. That’s my experience.

I've run my team's stand-ups for several years now. I find without going person by person there is less communication. I still restrict each person's comments to blockers and their agenda for the time until the next standup (not daily). It's not uncommon for "no blockers, tickets X, Y, Z for next day or two" to be it for a report. It's not common but occasionally this will remind someone else of a blocker they have which they can chime in with during their update or else at the end if they've already gone.