You don’t need standups

This is pretty condescending to your team. They might not be rockstar developers, but they are adults and can probably manage their time themselves. You don't need to be the best programmer to manage your time, you just need some common sense. If I were working somewhere where the manager thought I couldn't plan my own schedule, I'd look elsewhere.

Big difference between these things and no process at all.

Async standups do well only if the engineers have the discipline to actually go through them. My past experiences have shown a couple devs paid attention to the standups to look for issues and everyone else just typed their own up without looking at what other people wrote.

> you know why Spotify's engineering team does well?

> Stripe's? Netflix's? Because they have money

No. Some places have too much money, others enough and then there are those that may have to shut down in half a year. Seen them all, and "engineering aptitude" is completely independent of that.

I'm having a hard time agreeing with a lot of the points being made (I mostly skimmed but also read some parts).

The conclusion is relatively sound though: the default agile approach (sprints, standups, planning, grooming, retro) is only a base to start working on a software development project. The team members should optimize it or even throw it out if it works for them.

- Daily standups are a tool for coordinating teams.

- Weekly planning is a tool for iteratively communicating about the progress being done, steering the team and discussing priorities

- Retrospectives are a tool as well; a quorum regarding what goes well and what should be improved.

In a well functioning team, you will always need coordination/communication, progress visibility, continuous improvements, etc.

I picked 2 red flags in how this junior product manager approaches their work:

- the team did not discuss estimations

- he told his boss the team will deliver after 3 months

Basically he just "winged it" for his first project, picked a waterfall approach, and made it. Congrats! That tells me he either has a kick ass team (thank them) or the deliverable was easily achievable (thank the boss), or more likely a bit of both.

Let's take a few of the points being made throughout the post:

> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.

This is spot on. Using a tool to keep in sync is only useful if the members keep it up to date. If the tool is not up to date, the team either has a tool problem or a people problem.

> Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.

I strongly disagree there. Nothing, in each team member speaking daily, for less than 2 minutes, about what they are working on, encourages change of plans.

When the author mentions standups routinely lasting 30+ minutes... well yeah either fix it the soft way (time limit + a judge making sure everybody stays on point) or the hard way (just stop doing standups & send updates through a different channel).

What I've seen is that there are usually 2 team members that come with the 'authority' to make for a great standup: the product owner (in this case our author) or the tech lead (well, seems it's the author again, as a technical. prod. owner?).

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

Yes it can be a problem. That could possibly be reason #1 to get rid of standups. We're lucky in our remote team that everybody is happy starting the day at 9am as standups mid or end of day make not much sense.

> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.

Again, it sounds like standups are being used for the wrong thing. The standup is at 90% a 'passive' communication tool. Listen to the others carefully. Wait for the standup to be finished and FREE PEOPLE FROM THE MEETING to catch up with whomever you want on whichever subject you want.

> Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.

Absolutely, problems that can and should be addressed on the spot MUST be addressed on the spot or taken ownership of by a lead and then addressed timely.

However that approach does not catch everything. Retrospectives are an excellent way to make sure people can flag issues. It is natural that, in the week, someone will be too busy to immediately flag an issue, but make a note of what could be improved. A regular open quorum dedicated to these things helps share these details.

There are 2 critical elements to successful retrospectives:

- trust that everybody can speak up about the most minute detail. Be open about anything that is being said. Leave the ego out.

- trust that what is said is genuinely acted upon. Track improvement and suggestions and ADDRESS THEM. In software development, if you see a bug, you create a regression test and then fix the bug. Well, tske the same approach!

> Sprints encourage iterative development. This sounds really good to people like me who strongly advocate small, concise, pull requests over long-living feature branches. But it’s not the same thing. Sprints encourage features over tech debt. How often have you had to advocate spending an entire sprint tackling tech debt?

I'm eluded by the fact that sprints encourage features over tech debt. It seems that the source of the friction with sprints is not the sprint itself but how it is being used.

Addressing tech debt is part of any new feature. There should be no 'tech debt' in a sprint. DO NOT address tech debt that does not fix a bug(s) or help new a new feature though. It can be useful to write a list of hot spots, for communication and reminder purposes..

For each new feature, the team has many choices for the implementation: from complete hack to full refactor. A constant balance goes a long way, with the occasional 'that is needed in a week' and 'we need to refactor A to K before we do feature XYZ'. These are healthy events in a team that care a lot about delivering the most business value through solid software.

> That said, I’m not against planning, I’m against planning on an interval.

Fair point. Planning on an interval brings a few things on the table:

- it sets a cadence. Some people love stability. Regular planning can be an anchor to someone's organization of their work.

- it allows measuring velocity and therefore longer term planning through past velocity.

- it allows reprioritization sprint after sprint. Usually the product owner role is to gather clients' needs. These needs evolve both with new features and time. Rather than re-prioritizing on the spot (like it seems it was being done at the author's previous projects), it is a compromise between constantly shuffling around what developers do and being flexible about what is being built.

In my modest experience, all of these are very useful tools :)