You don't need standups - <AUTHOR> https://medium.com/@jsonpify/you-dont-need-standup-9a74782517c1 <comment><USER2> One thing I don't like about standups is that they can create a false sense of either blockage or someone being ineffective at their job. For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. There were times I somewhat dreaded standups because I knew that I'd say that I'm doing the same thing I'd been doing for the last several days, like a broken record. I don't want to have to say "Yup, still workin' on those bugs" every morning. When shit's fixed or I've completed a feature, _I 'll let you know_.

In fact, all I like about standups is seeing my team mates once a day. Besides that, there's almost no upside. Literally everyone can read the project board to see what we're up to. If you're really so curious as to what everyone is doing, why not just look at that?

<comment><USER3> "working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with.

"I tried this and this and measured this latency from the application and suspect it's a race condition, I checked this code and feel like I'm on the right track, and if someone wants to take a second set of eyes on my bug I would appreciate it" is a much much better update. Stand ups are about communication with your peers. Having to hunt down tasks you're working on and reading through each task can create an unnecessary mental load that can be solved with a single 1 minute "ESPN sportscenter edition" summary of your current issues.

However, blockers do create a sense of ineffectiveness. Especially on small workload teams where task swarming doesn't net too much benefit. "Hey I am still waiting on $vendor to configure their service" or "Still waiting on netops to tag $port for vlan blah" or "Procurement put in a PO for $hardware, still waiting on it", there are times when we are waiting for something, and there's nothing able to be done currently. Especially when the immediate tasks are already doled out and your leader doesn't want to pull more work into the current sprint. Subsequent tasks could be too large or complex to be pulled in. Current tasks could be unable to be broken up any further, to which I have to say, pair program until your blockers dissipate. We do this at my current job, and it really creates tangible benefit.

As for TFA's bulletpoints on why sprints can be bad, most of their arguments are bunk except for this one:

> 4\. Extroverts thrive at stand-ups, planning, and retros.

Not everyone is great at self-selling, and people who move up in the company are the ones who hype their personal brand, not necessarily those who are the best at their roles. I don't know how to solve this as it's a personality issue, but I do think it can be a problem for a lot of businesses and teams.

<comment><USER4> What if I don't want a team mate to look at something I'm working on? What if I just want to focus on building, not explaining and sharing?

The current trend of "agile" is just another form of micro management. It's not good for the programmers at all, it's only good for product owners and team leads who are coordinating resources. Because it's micro management. We just call it something else now.

It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.

Let's just stop pretending it's good for the programmers, alright?

<comment><USER5> 1\. Agile is not personally great for programmers.

2\. Agile is good for managers.

3\. Managers run the business and make sure it exists.

4\. Programmers need the business in order to have a job.

5\. Agile is therefore good for the business,

6\. And therefore Agile is good for Programmers, though not personally.

<comment><USER6> I would disagree with almost every claim on this list.

<comment><USER5> I don't really have that strong of an attachment to any specific one of these claims. I was just pointing out the logic of the parent comment is very narcissistic (without saying as much).

The logic falls apart when you look at different individuals and different companies. For example, if your company is very political then what is good for managers very likely is not good for programmers. If your company focuses on teamwork and has a strong one-for-all;all-for-one culture, then whats good for managers probably is good for programmers.

</comment></comment></comment></comment></comment></comment><comment><USER7> I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the development community continues to screw it up. It's important to understand how.

According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour.

That may be true, but the purpose of standups is that the team requires one another to get together and talk about how to move the project forward. It's not about what you did. That's a status report. It's about how you can help one another.

If you can self-organize, effectively communicate, and help one another as- needed without standups? Don't do them. Easy. There's no magic requirement that you have to. What we've found over the years is that if you give it a name and a time, at least you have a way to talk about whether it's working or not. Other people can drop by to help out. But if that's too formal for you and you don't need it? Stop!

Standups remind me of brushing your teeth. When they're working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It's when they're misunderstood as something else that they become useless and painful. Had to throw a SM out of his own team room once because he kept using standups as an opportunity to play "What's your status?". Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you're free and then go play tennis the rest of the day or something. It's not a management, outside-in meeting. Just the opposite, in fact.

I love these articles because they remind us that the goal is what's important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team/org experiences.

<comment><USER8> That is just bullshit though. I don't find value in anything that agile offers, can I just throw it out entirely by your argument?

Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer:

"What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal?"

These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically.

I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.

<comment><USER9> If you read the agile manifesto and then you look at scrum, it feels as if scrum has nothing to do with agile. It seems to breaks every rule.

Scrum is processes and tools over individuals and interactions, by its very nature.

Scrum is comprehensive documentation over working software, because you have to map everything out.

Scrum is contract negotiation over customer collaboration, by allowing management to effectively rule scrum, scrum masters are _always_ management or reporting to management, so devolve into contract negotiation by proxy.

Scrum is following a plan over responding to change, again, by its very nature.

It's the most odd thing I've ever seen, that somehow scrum came out of agile and literally got it all backwards. There's even certifications on _how_ to do scrum, which is utterly stupid when you read the 12 principles, some choice scrum oxymorons:

 _trust them to get the job done_ \- nope, we don't trust you, follow these scrum rules you oiks

 _simplicity is essential_ \- but we've got all these formal rules for you to follow

 _working software is the primary measure of progress_ \- no, actually, how many sprints have been successfully completed?

 _the best architectures, requirements, and designs emerge from self- organizing teams_ \- but we're not going to let you self organize, you must follow these scrum rules

<comment><USER10> Scrum is all about implementing a system and then adapting it over time to fit your needs. It's all about having the team figure out for itself how to organize. It's not a rigid set of requirements. It's a set of suggestions about how to begin implementing the system, and then trusting the team to figure out what to adapt and what to cut.

<comment><USER9> That's not how it's presented in real life.

Read something like this:

[https://www.mountaingoatsoftware.com/agile/scrum](https://www.mountaingoatsoftware.com/agile/scrum)

All about what has to be done, with a formal role of scrum master.

Phrases like these brook no adaptability:

 _On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner_

 _on the first day of a sprint and during the planning meeting_

 _Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting_

Management take Scrum as a set of rules to follow and then use it to micro- manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn in to daily justify your worth.

</comment></comment></comment></comment></comment><comment><USER11> Standups always felt to me that they had a core negative message to developers.

It's not about communication at all. Its about control, its about saying:

We don't trust you.

We are going to check on you to see what you are doing, every single day, because you are not a responsible adult and need constant surveillance.

Its also about putting constant psychological pressure on developers, to make sure they complete the tasks as soon as possible, and move on to the next task in the list.

Even if developers know that some refactoring is absolutely needed or this production issue needs a closer look because something strange is going on, developers don't have the autonomy to just do what they know needs to be done.

Everything needs to be pre-approved by a non technical manager and assigned a JIRA or equivalent.

Looking back, to me its clear that I resented standups, they made me feel like I was being treated as an assembly line worker.

<comment><USER12> Not really a fan of standups either, but I want to express a counter point: developers consistently over-estimate their understanding of the problem domain they are working in and the wider context it sits in. That is yes, managers don't "trust" developers - but not in quite as negative a sense as you think. There is a positive aspect of supporting the person, ensuring they are connected to the right resources to succeed and stopping them getting stuck on things that don't matter.

I have a small team of devs and I consistently find that given task X they will get stuck and end up spending a lot of time on small subpart Y. And they really want to solve Y, because they are engineers and doing the "hard" stuff is what often drives them. So without some kind of input, what they will do is spend a week on Y and then report back that X was much harder than expected. When told at that point "Oh, we really actually don't need the Y part, we could just to Z instead" they will be quite disappointed, and wonder why they weren't informed that Y wasn't that important to begin with. So more regular communication of some kind is really important to avoid this. As I mentioned, I don't really like daily standups as the optimal way to achieve it ... but I don't quite accept the "leave your developers alone for weeks at a time" strategy either.

<comment><USER13> I understand that avoiding spending a week on Y is important for business value, but constantly prioritizing shipping features in the cheapest manner possible also means not investing in the long-term growth of your developers. You don't learn much of value by gluing together a handful of framework functions. You become a better engineer by really struggling with and digging into Y for an entire week. If engineers are never given the freedom to do that, they stagnate as framework glue monkeys. "Deep work" is a rare thing in scrum shops.

<comment><USER12> That's a really good point. I know my career has nearly entirely been steered from "non-core" activities that I undertook which never would have been justified on a week to week schedule. Businesses also are actually very poor at understanding technical opportunities which developers at the coalface can see (that is, things that are technically easy or at least feasible, possibly due to the specific skill of the engineer(s) in question, but have very high value).

</comment></comment></comment></comment><comment><USER14> The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time.

I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to me for that sprint and just thinking...really? If I don't complete the second high-priority task before the end of the sprint, so what? I still made progress on it.

It just felt like so much time was being wasted. We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work. If you had 30 hours worth of tasks assigned to you already, and there was a 20-hour high-priority task in the queue, it'd get bumped to the next sprint with 10 points of low-priority tasks assigned instead. It was more important to them to get precisely an estimated 40 hours of tasks completed, rather than getting supposedly high-priority tasks done.

Obviously, this frequently resulted in priority inversion, not to mention the problems from poor estimations of task time.

Management was often clueless. You only earned the points when you completed the task. So if you took on two 20-hour tasks, and just barely didn't finish the second one before the end of the week, but then completed that plus 40 hours the next week, they'd question why your productivity swings so much because you only got 20 hours done one week, but 60 hours the next!

And of course, as mentioned, these "hours" were all estimated hours, not the actual hours done. People started overestimating the hours needed for tasks, but management was apparently smart enough to catch on to that when they noticed everyone was getting 50-60 hours worth of work done, despite everyone only working about 40 hours per week.

I've rambled a bit, but you get the idea. I think the author is spot on. Just use your task tracker.

<comment><USER15> >The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time.

That's because sprints weren't designed for us. They're designed for management. Product managers and VPs need to be able to think of their "resources" in manageable, discrete chunks. Vagaries are an absolute antithesis to their world view. Small boutique firms can avoid this, but mass production means the need for mass conformity.

<comment><USER16> They _should_ be designed for us. The idea is supposed to be that there are limited times that developers are negotiating with the outside world about what exactly they are working on. The rest of the time, nobody gets to interrupt and demand that they drop everything and jump on to their latest crazy idea.

But yeah. I currently have to wear both the PO and dev hats, and, when I'm wearing the PO hat, I also see advantages: It means that I get to have a rhythmic schedule that I can set my calendar to. That makes all the orchestration crap _so_ much easier.

Which, incidentally, I also like from a developer perspective. The less time I have to spend on that stuff, or get randomly interrupted by that stuff, or randomly interrupt people with that stuff, the more time I get to spend on actually building stuff.

</comment></comment></comment><comment><USER17> I'm the scrum master on a team where most members are very geographically spread out, and the standup is great. It's time for everyone to have that direct social connection.

But I don't ask about ticket status. We just ask about what they did yesterday, and what they're up to today. And I mostly ask that if they aren't doing something already captured in a ticket, make another one, so we have a record of issues taking up our time. You want to do some tech debt reduction? OK, but keep it unambiguous - "tech debt" is too generic.

The standup typically exposes important issues, like how team members are siloing off from each other. And then we can easily sit down and notice "hey we need to sync up". A lot of ad hoc conversations appear right after standups, that wouldn't have just happened, because people don't often spend their time reading through the comment section on open tickets.

It's really a gut check that yes, the team is indeed working together. If your team's standup is just some regular robotic process of repeating status already captured in tickets... WTF; I'd say you've got serious leadership problems.

<comment><USER18> Why doesn't everyone just write what they're up to today in a chat channel and people can reply if they want?

It seems kind of silly to me to have everyone dial in or stand around in a circle, to each have one person speak. I'd much rather see a list of what's going on with everyone today and if anything catches my eye, I can talk to them about it.

<comment><USER19> On a mostly-remote team, it may be the only opportunity in a day for everyone to hear everyone else's voices. Social interaction is important.

</comment></comment></comment><comment><USER20> This sounds to me like a team that went through the agile rituals until everyone was familiar with the benefits and methodologies and got rid of the formal structure once that happened. That's fine. But having structure in place around these things is helpful to newcomers, especially when the entire larger organization is trying to transition from a waterfall process or no process at all.

The list of rituals the author got rid of shows that the team has already learned the more abstract values and benefits and is doing them real-time instead of scheduling them as standalone meetings and sessions. It doesn't mean these things have no value; it means the team is a well-oiled machine.

Except standups. Standups are, have always been, and always will be a waste of time.

</comment><comment><USER21> I've been managing engineering teams for a few jobs now, but I think this article suffers from some logical fallacies.

"You don't need stand-ups"

I've actually tried this multiple times with multiple teams in my career. The truth is, is that sure no stand-ups can work... _sometimes_. Some teams some teams we ended up doing 15 minute enforced with a stopwatch stand-ups, we ended up doing a slack standup, and some teams we skipped them altogether.

I too, when I had my first engineering team skip stand-ups and retros felt like I had unlocked some secret in management, as work was indeed getting done.

But the very next team I tried it on it failed miserably. Tons of conflicts, duplicated work, etc. We also tried to "fix them as they went" but what ended up happening is that bringing up and trying to resolve every issue when it happened got difficult. Naturally we kept "tabling" issues to discuss later and we never did until we create monthly meetings to discuss all the issues together. Funny how a "retro" ended up organically forming.

The truth is, every team is different. What works with one team won't work with another. I've found that as a general rule, a regular check in with engineers help align goals and what they are working on. And a somewhat regular cadence of evaluating _how_ you do work makes sense.

I also think the authors marriage analogy is weak. At work, your team isn't a family. It's a team. You can't fire family members. A team you need to stay consistently plugged in because you are trying to complete specific objectives. Marriage is rarely like that.

</comment><comment><USER22> Here's a thought experiment, and a challenge: When was the last time you learned something really important at a standup meeting that you wouldn't have learned otherwise, either by talking to someone directly or in some form of asynchronous communication?

I bet it was a while ago, if you can even think of anything specific.

Standups, in my experience, are a net negative, in that there is a cost, but rarely a benefit. I almost never get anything useful from them. I don't need to know that the product owner is in meetings all day. That's almost every day. I don't need to know what every single other developer is doing every single day. If I have a general idea of what the team is doing that's usually good enough. If I am blocked on something, how is that useful for you to know? If there's anything you can do about it, or need to communicate to somebody else, I've probably already talked to you. And if I haven't talked to you, it's almost certainly irrelevant to you.

Challenge: For the next week, make a note (actually write it down on paper) of something useful and actionable you learned at a standup meeting, and see how many times that happens. Then compare the cost of the time spent in standups to the number of times it was useful.

<comment><USER23> > Here's a thought experiment, and a challenge: When was the last time you > learned something really important at a standup meeting that you wouldn't > have learned otherwise, either by talking to someone directly or in some > form of asynchronous communication?

Twice this sprint, a problem I mentioned at standup was addressed at that moment by a comment or suggestion from a teammate. The standup is really the only venue I have to casually, non-directionally vent frustrations I'm facing. They're great.

</comment></comment><comment><USER24> A team where the Engineering Lead(or any kind of manager) thinks that you don't need retros because there are no problems is exactly the kind of team that needs retros.

<comment><USER25> You may have missed the part where the author says that problems should be addressed as they come up and not just once at the end of the week.

A retro obligates people to find and/or bring up issues. In my opinion an open door policy would push people to bring up things that actually matter.

<comment><USER26> This is a situation that really depends on the team. If your team isn't surfacing issues, then either you're creating an environment where people don't feel comfortable surfacing issues, or your team is mostly just not the type that is proactive about it.

If it's the latter, then "priming the pump" is a useful exercise, and a regular retrospective makes tons of sense.

That's also generally true of processes: every team has its quirks, and you fit the processes to the team's quirks.

</comment></comment></comment><comment><USER26> Posts like this usually have good points, but I feel like they should always come with a massive caveat:

 _Every team is different, and you should tailor your processes to fit the team._

And because of this, I think posts like this one should spend time answering:

 _What conditions were needed for your decision to be a good idea? And when would your decision be a bad idea?_

The author seems aware of this, because he tries to generalize to just not over-complicating things. But his post is pretty much just arguments for removing meetings entirely without really considering when that might not be a good idea. And there are definitely teams and circumstances where that might not be a good idea.

<comment><USER27> Isn't pretty much that caveat right under the title?

 _" Notice: Below represents my PERSONAL beliefs about agile and team organization. Your results may vary."_

<comment><USER26> Not quite. I think there's an important distinction. That caveat says: "I think you should do things this way, it might work for you." But what I'm asking for is: "I think, under these conditions, you should do things this way."

But you're right to point this out. I think I phrased my post badly. The caveat isn't the important part. The second point is the really important one. The decision framework for when to take any specific piece of advice is more important than the advice itself. In general (and this is definitely true with development process advice), advice is plentiful and often conflicting, and most of it gives you ideas of what to do, but doesn't tell you when it's applicable. The really good books, courses, and blog posts I've found do exactly that.

</comment></comment></comment><comment><USER28> Is there any reason to believe that a process that interrupts an entire team every day to make everyone listen to non-critical updates would be necessary?

Standups are (in my experience) usually a symptom of a low-trust environment, where there's an underlying belief that engineers will do less work or let things slip without the fear of being behind at the next standup. In some companies, this is actually true - so in some cases, standups are certainly effective - but I can't think of any argument for why they'd be necessary at all companies.

Our team is distributed and has been going ~eight months without standups or work hours, and I'm extremely happy with the quality and pace of our engineering. This requires a high-trust environment where every person is given large feature areas that they are able (and incentivized) to drive autonomously, but I think this ends up being better both for productivity and for quality-of-life.

<comment><USER29> > Standups are (in my experience) usually a symptom of a low-trust environment

and or a high volatility process and or poor information flow. All of these things occur at different times throughout any company. Standups mitigate these issues and are not supposed to be these hour marathons that I see everywhere.

<comment><USER28> Agreed that those are other common causes.

I think that keeping standups short does very little to mitigate the damage they cause, though. The biggest cost isn't the time they take, it's the act of forcing your entire engineering team out of a flow state (or worse, forcing them to wait until after standup to even start) on a daily basis. That happens regardless of if they're 10 minutes or 30 minutes.

</comment></comment></comment><comment><USER30> I love the fact that none of this exists in open source projects. All communication is done immediately using IRC, mailing lists, and bugs/tickets. Nobody has to follow a development methodology. You volunteer to contribute to the things planned in the roadmap. You get shit done when you get around to it. When it's ready, it's ready.

I hate the fact that if you're _not_ following a bullshit development methodology (and usually poorly) you're treated like there's something wrong with you.

</comment><comment><USER31> It's hard for me to dislike this, because I also find standups and sprint planning meetings to be painful and somewhat less than useful for myself.

On the other hand, when you are with a new team, or a team with a few people that need mentoring, or going in a new direction, I find that it's important to force people to coordinate, because many times people will just run off in random directions you don't want them to. You really have to have the best people, and trust their instincts if you follow what the article suggests. Any weak players on your team will just be lost and potentially set you back (or at best, just waste their time).

<comment><USER32> Exactly. This could work well in teams where the engineers are all competent and really just need the PM to stay out of their way.

In weak teams, this could easily see an end-of-quarter with unmet deliverables and other management messes. A lot of people would take advantage of the hands-off approach as much as they could.

Either way, Agile is ridiculous so I agree with the author about that.

<comment><USER33> > _In weak teams,_

Agile is largely about managing weaker teams.

<comment><USER34> Also, everyone is weak at some point of their careers. Until they aren't.

</comment></comment></comment></comment><comment> luka-birsa We actually massively profited from implementing standups and agile-ish process and we really do not feel the downsides mentioned in the article.

Standups:

1\. The standups are held in very small groups that work on the same thing and where it is important that they are coordinated.

2\. Standups are not a place to discuss priorities. Those were set way before. It's for you to tell everybody what you're working.

3\. Standups take 5-6 minutes per day. It's less than one foosball game. Some teams actually do their standups while doing a plank, so that they're very short.

4\. Standups help us achieve team cohesion. Everybody knows what everybody is doing, so people can help each other when needed + leads can detect issues sooner (especially valid for introverts, since they sometimes lock up and grind away without telling anybody).

5\. If you're bored during standup and not getting any value then you should not be part of the standup. Standups are considered optional, but everybody attends.

Agile process:

1\. 14-day scrums are to sync priorities and discuss the development process. Generally speaking, we set up quarterly goals (and we have a rolling forecast for the next two quarters) so its clear what people need to do. We do not change the quarterly goal, except if external forces force us (example: things failing).

2\. The schedule also gives the leads a clear tool to block any "non-urgent" but important tasks that would meddle in the development process. Instead of caving under the pressure of product teams or high-level management they can clearly state when they will start working on the task. I think the schedule needs to be set so that management can handle the lag between request and start of work on the request. I've heard of 3-day sprints since that was the most effective way of blocking daily priorities changing until management got on board.

</comment><comment><USER35> We do stand ups once a week on Monday morning to get everyone on the same page and focussed for new week.

Each time a different dev runs it, chosen by the person who ran it last.

Our stand ups are one of the most mentioned things in my 1:1s as everyone likes to hear what other people are working on.

We then do a retro on Friday afternoon, sit outside and have a beer and chat about what worked and what didn't.

Not strictly agile, but this works for us and everyone is happy and productive.

<comment><USER36> > Not strictly agile

Sure it is, because agile is precisely supposed to be "whatever works for your team". Awesome that you've been able to find such a good, low-key process!

</comment></comment><comment><USER37> Not going to lie...I like stand-ups, but I am an extrovert. I also like them as a full time remote because it's the only way I regularly see my team.

As long as it doesn't interrupt people. 10am is to late if the work day starts at 8:30am. About 45 minutes after the "beginning" of the day is about as long as can be tolerated. Give people time to arrive, account for traffic, get coffee, check some email, quick stand-up with the team and then get to it.

At the same time, there's not a point where I think stand-ups encourage prioritizing features over tech debt. Usually, that comes from sprints themselves and the planning around sprints. Stand-up shouldn't be anything more than a quick "how's it going" for the team.

I would have no argument as a developer working under this unless the quarterly goals were out of control.

What you're describing is basically Kanban.

I agree with almost every word.

</comment><comment><USER38> I've worked at 5 different companies that did standups. They always sucked. Agree with what others said here: If you need to talk to someone, just do it, don't wait for the next day.

The team that didn't do standups was by far my best team. We still talked frequently as needed and moved quickly. Actually quicker because we didn't get interrupted by standups, hour long retros and planning meetings.

</comment><comment><USER39> I've been beating this drum as it's one of the more frequently cargoculted items about agile.

A standup has 3 questions to report on:

1\. What did you make progress on yesterday?

2\. What are you planning on making progress on today?

3\. Do you have any blockers?

Taking this pulse once every 24 hours is artificially constraining. Relevant stakeholders (product people, other engineers, project managers, etc.) should have perfect, frictionless visibility in to what people recently worked on, and what they are planning to work on at any given time, as self-reported by the team. Additionally, if you have a blocker, you should not wait until the next standup. Unless the blocker was discovered immediately preceding the standup, it should be well known to all who need to know with the same perfect, frictionless visibility. At the time of the standup, blockers should be well-known. I've specifically seen standups backfire as individuals use reserve their blockers until the next morning. It's a great reason to call it an early day when you hit a blocker and get the opportunity to report something of substance at the next day's standup.

Perhaps I just described an unattainable utopia, but I think it's important to start with process idealism and make considered compromises rather than acculturating the status quo.

I lead an entirely remote-first development team, and am adamant that standups often are a crutch at best, and inhibit progress at worst.

<comment><USER40> > _I 've been beating this drum as it's one of the more frequently cargoculted > items about agile._

When most aspects of something have strong cargo cult features, then maybe the whole thing is a fantasy.

</comment></comment><comment><USER41> I really dislike these type of articles. The title is there just to shock you, and so is the content... so much that there's a disclaimer at the end of it. I think I would read it with an open mind if the title was phrased differently... "Maybe you don't need standup" or "how standup slows down our company" something of that sort.

"The natural side effects of not doing standup are:"

"\- Developers communicate more \- Your team becomes more remote-friendly \- Tech debt gets addressed \- Developers feel more in control and less stressed \- Developers know you trust them and that you have their back"

These bullet points are non-sense. Perhaps developers were not communicating properly, and that's why you started having stand-ups in the first place. Perhaps your developers need more guidance and someone overseeing them. Maybe your business is growing too fast and you need to have more meetings to get things back under control. Some people are goal driven and can take care of things on their schedule other people don't even know how to make a proper schedule.

Here's what you should do:

1\. See what works for you 2\. Make adjustments 3\. Evaluate adjustments 4\. Repeat

Meanwhile, read some books on management and learn from more experienced people. There's no reason to drop everything you are doing because a blog post said so.

<comment><USER42> Our team of developers is 100% remote and we do a daily standup each morning that lasts anywhere from 15-30 minutes. Each person runs through anything of note from yesterday, our priorities for the coming day, any roadblocks, and anything we feel like discussing with the team.

Coming from a team that did nothing remotely close to a standup, I highly value our current system. It's not perfect, and I have no idea if it fits the Valley's definition of "standup", but it serves its purpose very well and keeps everyone on the same page. I can't tell you how many times a person from my team has reached out in the afternoon about a roadblock I mentioned during standup. Or how many times a team member wanted to help me out on a tough user story simply because I was open about discussing its difficulty.

This is just my opinion.

</comment></comment><comment><USER15> As someone who hates standups I tend to disagree. I've found that without some kind of forced daily interaction, lines of communication in a team break down very quickly if they aren't already extremely tight knit. Once that happens, your project is toast.

<comment><USER43> That's funny because we recently started doing standups and our communication has fallen off a cliff. I feel like we had that tight knit group you describe, knowing when to get in touch and when to leave things alone.

Now we don't speak to each other except during standups, and even then it feels more like speaking at each other as it is expected that each member put in their voice, even when they have nothing to useful to add, leading to the team quickly tuning out and then not paying attention when something important is mentioned. Not to mention that now there is up to a 24 hour window before anything is addressed, when the previously used ad-hoc meetings would have got everyone on the right track in a much shorter timeframe. And as a result of all that I feel like there is a lot more animosity between members.

It may be possible to do standups well, but we've failed at it horrifically.

</comment></comment><comment><USER44> This approach works really well when you have a great team - like I'd imagine palmerj3 has at Spotify. I've worked in a few of these places and know how well this approach can work. However, I am currently working at a place with people who are very inexperienced and frankly pretty lazy and just generally not very motivated. The manager has to constantly monitor them and make sure everything is being done. In this type of environment you just wouldnt see the end result at the end of the month. But personally I find this approach works super well for me.

</comment><comment><USER45> People should try to think more long term about standups.

Yes, maybe you could remove them and maintain the same productivity for a year, so they appear wasteful.

But removing accountability, can lead you occasional bad decisions, which lead to more frequent bad decisions and then 5 years later you have some REALLY bad habits in place. Standups feel like babysitting, and they are not necessary if everyone is just ready to work, but I think the accountability from publicly stating goals for the day has a subconscious effect that can lead to people getting into a great routine.

I myself, never needed standups to prevent goofing off. But they really helped me get a handle on how bad I was at predicting the results of my work for a day. My optimize makes me perpetually underestimate the time it will take to do a task by a factor of 3-4. With practice in standups I've got that down to more like 2x.

</comment><comment><USER46> I'd really like to hear thoughts on how this applies to remote teams. I find that async standups via slack are pretty damn helpful for keeping everyone appraised of what is going on across 5 timezones.

Process and communication are kind of key, aren't they?

<comment><USER47> 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.

<comment><USER48> This is what everyone does in person too. The people that go last tune out because they're preoccupied about what they'll say and the people that go first stop listening because the value of the information tends to be very low.

</comment></comment></comment><comment><USER49> I've pushed for this model and I've done this with my team over the past year. It's worked out relatively well, but not as well as I expected. Context: I am the lead developer on the team, I am not a people manager.

Our work involves some research which we've managed to do quite well following this model. We've also evolved our product and managed to deliver complex features more efficiently than we would have done if we did sprints, IMO.

A few team members have complained about lack of frequent deadlines (?!?), lack of status meetings/standups etc. The arguments are weak IMO - 'that's how we did it before', 'we hear what other people are doing' (we are pretty good on transparency), 'it's nice to have a forum to discuss how things are going' (we use chat extensively and we should be able to discuss things there). Our manager is great and he helps people choose which things to work on - he's been handling feature prioritization and he's making sure that people are comfortable with their work during 1:1s.

Also, I think it's really important to have a clear vision and steer the product - we've been missing that and it's caused a lot of friction when deciding how to evolve the product. Sprints wouldn't have fixed that, but maybe a more rigid decision making process would have made us fix the problem (or at least complain more) earlier.

</comment><comment><USER50> I work on a team where 3/4 of the team are business people. Yet we have a stand up with the entire team everyday and everyone talks about what they are working on. How is hearing that you are talking to account X about something or just came back from conference Y applicable to the job I've been hired to do? Likewise when it comes to my turn to talk it often turns into "blah blah blah [giggle] I don't know what any of that means! computers!" from the business people. It's so useless.

</comment><comment><USER51> I think you want a culture were people let others know as soon as they are blocked. And were a manager discusses your progress 1 on 1, not in a group setting. Standups are inefficient because most updates of others don't matter and it is needlessly synchronous.

</comment><comment><USER52> While I do agree with the sentiment of reducing meetings and time spent planning, I don't believe that removing all scheduled communication and planning is a good answer. This approach is especially problematic for teams that are working more directly on rapidly changing business concerns. Communication, planning and analysis are quite important for teams with members who need regular guidance or teams with lots of distinct roles.

</comment><comment><USER53> I understand many writers are desperate for views, but I'm looking forward to this nasty spreading imperative title infection to die out (which it will, but not soon enough). "What you need to know about ..." ( _you have no idea what my knowledge requirements are_ ) "You don't need ..." ( _you won 't know what I need until you find out something about me, dolt_). "Why you should ..." ( _until you 've at a minimum skimmed 'Ethics for Dummies', which your 1st-year- uni-essay-think-piece betrays no evidence of, you're not qualified to inform me what I 'should' do_).

This rash is particularly prevalent in the prissy modern etiquette columns that dominate so many alleged newspapers (I'm looking at you, Graun), but the tech sector is also succumbing apace.

Now Kant: _there_ was a guy who knew how to construct titles. He did not write "What you need to know about the categorical imperative", nor "Why you must critique pure reason".

<comment><USER40> Yes, but Kant was not incentivized to write in a certain way by some performance graph in Google Analytics.

<comment><USER53> Indeed. Our intellectual history definitely dodged a bullet there.

</comment></comment></comment><comment><USER54> One of my manager used to say that number of status meetings you must to do is inversely proportional to quality of people you have.

The whole concept of standups and scrum was started to bring highly dysfunctional team back on track. Since then now we have been applying methodology that is required to make highly dysfunctional teams work to _all_ teams.

<comment><USER55> Agile is the management equivalent to electron apps, not very efficient but makes your job easier.

</comment></comment><comment><USER56> I think a lot of the themes in this article I can agree with, but I come away with the overall impression that the author hasn't necessarily worked in a healthy agile environment before. Basically, I agree with many of the conclusions (or solutions) but disagree with a lot of how the author came to them.

Standups aren't inherently bad. Also it sounds like he moved his team to more of a kanban style workflow -- which many people use already. That isn't ground breaking. There is still iterative planning, even if they aren't "sprint planning" sessions.

<comment><USER57> I got the impression that the author of the post had worked in effective agile environments and he came to the conclusion that the cargo-culted trapping of agile were unnecessary.

<comment><USER58> I was a little bit surprised to see this article with him at Spotify. Their Squads framework is shown as an example for larger-scale agile, I heard about it at a place that had just started doing SAFe. The approach mentioned in the article doesn't really match up with my idea of larger-scale more corporate agile.

</comment></comment></comment><comment><USER59> FTA: Say you're in a relationship and it's going amazing. You should totally start going to couples therapy once a week, right? </sarcasm>

Me: Actually yes - that way it stays amazing...

<comment><USER16> I thought the same thing. Not couples therapy, per se - that bit is a blatant straw effigy - but we do have a regularly scheduled chat that is, in effect, a standup meeting.

We've found that it ultimately reduces the amount of time we spend on talking about that stuff. Sit down, take care of business, see what's on Netflix. Without it, we could easily spend the same amount of time per week just figuring out _when_ to talk about XXX thing, let alone actually talking about it.

</comment></comment><comment><USER60> Probably too late to this thread, but anyway - the key to understanding agile tomfoolery is that _processes are most effective if they evolve to meet the needs of the people in the team_.

A process will always feel like a burden (and be less effective for it) unless it is co-created by the people right in the middle of it. Most people like doing a good job if they're permitted to, and like supporting their colleagues if it doesn't prevent them doing a good job. Few people want to make their colleagues' job harder or get in fights - much of this is friction caused by bad processes.

Given a chance to talk over problems faced by each team-member and to discover fair solutions, a team that dislikes agile may themselves choose to adopt parts of agile if it is obvious that _it solves real problems and makes the team more effective_.

The difference between a pointless, painful, morale-destroying standup and a fun, useful, team-building standup is that one is imposed from outside and the other naturally arises from a team allowed to figure out for themselves how best to work together.

</comment><comment><USER61> I think a lot of this depends on the size of the organization and teams involved. Too often I find these kinds of articles (from both sides of the argument) ignore that aspect.

Some aspects of Agile/XP/Scrum etc. obviously have some benefits particularly for larger organizations/teams. On the other hand I've seen smaller companies that are trying to emulate this success really struggle to get real work done, because there are so many standups, retros, kanban and "user stories" etc. In between morning tea and lunchtime, not much breakfix or clearing out tech debt actually gets done, before they are required to pour another bucket of features on top.

I've worked at a company like this that held retros on Friday afternoons and by Monday morning standups, they couldn't remember the things that had been discussed in Friday's retro. It all felt so mindlessly pointless, and playing into the hands of those who make good money selling books about Agile, or talking at conferences about Agile.

IMHO I think the sweet spot is probably somewhere in between.

</comment><comment><USER62> I find myself slowing down or doing tasks that I can easily explain because of standups. Instead of pushing ahead and killing it I find I need to translate what I am doing into english conversation speak so I manage my work around this. Normally I would work on multiple items but standups force me to work on something easily explainable/simple so I do less but explain it well.

</comment><comment><USER63> This should really be taken as an example of a team that got rid of standups and did well. Every team is different and without prior knowledge of the team featured in this article, it's hard to judge if this advice is any useful to me. I would've preferred if the tone was more like "Why we didn't need standups" not "You don't need standups".

</comment><comment><USER64> Good article. If you have a good team, you don't need agile or other methodologies. These frameworks have always been the crutch of bad managers, or MBA types who want to corral "those developer people." Now, can agile/scrum/ninjitsu/rockstarism transform a bad team into a competent one? I don't know - I don't work with bad teams.

</comment><comment><USER65> I really like this advice. One thing I've been taking notice of at my job is just how meaningful the tracker is to our workflow. If things are settled down and well-managed, then no meetings are needed, the tracker is a really good representation of the current state of the project, and Shit Gets Done. For awhile when I first joined the team we pounded through sprints and often had a week or more of downtime that we could use to clean up tech debt or play ping pong.

It was Amazing. So amazing I ended up having to speak up at meetings telling our nervous team leadership that nothing was going wrong. We were kicking ass and playing more ping pong than everybody else in the company.

Now we're still kicking ass, but the management has gone into the shitter. We had a product owner, a team lead, and project manager, then the product owner got pushed out and it's been veritable chaos ever since. If anybody is looking for a Rails ninja, drop me a line.

</comment><comment><USER66> I think standups can be good, but get rid of the mandatory status updates.

Want to talk about something? Knowing you can put it on the agenda for the next standup is great. If the standup isn't the right forum for the topic, then it's still probably the right forum to decide what the right forum is, and let's you include people who are unexpectedly interested.

Talking about incoming tasks and bugs is also helpful, and is an important part of developing a collective understanding of priority and approach.

And of course when there's some specific pressure or deadline, then you'll need to talk status and cover details. The standup is going to change based on needs. It's good to have a well-socialized team that regularly talks and both makes collective decisions and learns how to interpret those decisions when doing their personal work. Daily practice is worth it, and pays off double when something goes wrong.

</comment><comment><USER67> > _I wanted the team to know I trusted them._

This can be very powerful. People will often rise (or sink) to the level corresponding to how much you show you believe in them.

Imagine you hand someone the reigns and say, "Here, take over this for me. I know you're going to do a good job." And you sincerely mean it because you've bothered to understand them well enough to know that they can. In a lot of cases, you'll be amazed at what they will accomplish. They may even be amazed too.

Often, forming good, healthy relationships and building people up is what's really effective at getting people to get stuff done. So many of the other things people do (endless status reports, procedures and methodologies du jour, applying pressure or creating fear, etc.) are really just bandaids to attempt to force productivity to happen when it's really not happening because the basics haven't been covered.

</comment><comment><USER68> One thing that the standup helped me was getting blocked by a senior developer.He would never answer my questions normally. But once we started with scrum and daily standups, there was that I am blocked because of something that can be answered by another developer within 15 minutes. Standups make a team working.

</comment><comment><USER69> To me, standups are most useful for 3 things:

1) When working on a new system, making sure that your work aligns with what others are doing, and you have group consensus that your approach is acceptable (or if not, then getting someone to talk through it with after standing).

2) When working on a legacy system, getting group consensus on the hacky stuff you're doing to solve a problem (and in the process letting others know about that hacky stuff).

3) The group's lighthearted banter while we wait for others to join the meeting, and sometimes at the end, or on a particularly fun day, in the middle.

All of that is about group teamwork, consensus, and a little bit of bonding. All the details should already be on the board, and in slack discussions or calls with the relevant people. The meeting should focus on stuff that needs the group interactions.

</comment><comment><USER70> my 2 cents,

I don't think this post will age well.

The team I am on is currently swinging back towards more traditional agile after going too lax on planning, retro, estimation, etc for a while. These "rituals" are effective ways to ensure a good base level of inefficiency. If you're feeling like the agile rituals are becoming a waste of time, I would try out doing longer sprints before dropping them entirely.

Cutting process relies on good habits from the developers/whoever on the team, and habits can degrade over time. Devs can cut corners without formal process, because creating meetings and facilitating process that doesn't formally exist can feel like just another burden/task switch they have to take on.

</comment><comment><USER71> Let's say you have 2 developers:

\- developer A wants to get promoted as quickly as possible. developer A will try to "ship" as many features as possible.

\- developer B wants features to actually work, not just be "shipped". developer B volunteers to fix the problems developer A created by rushing to close as many tickets as possible.

Now, guess which developer contributes more to the team "velocity"? developer A. But in reality, developer A is just gaming the system and making everyone else _slower_. This is how agile distorts development.

Using velocity as KPI is the same as evaluating leaflet distributors by amount of leaflets distributed. Some will just throw them away in the garbage and claim their money.

<comment><USER72> Or do developer A and developer B make a good team? Looks like you've got a starter and a closer there to me.

<comment><USER71> Sometimes that is indeed the case.

In other cases you need a full rewrite, and that is not good.

</comment></comment></comment><comment><USER73> Why the need for all this formalization of process. We're all adults. As long as we hire people who can communicate well, shouldn't just having conversations here and there when the need feels natural be enough?

</comment><comment><USER74> I'm so in alignment with this. I've always hated standups. As a night owl, it's a morning meeting I have to make every single day and I hate it. I also don't understand how I can't just communicate in Slack to say "hey this is what I'm working on, this is what I worked on. Here are the questions I have." And move on. And if the PM prioritizes the backlog, always pick from the top just _makes sense_. And yes, retros feel like a place for extroverts to own the conversation (and I know, I'm an extrovert).

<comment><USER75> We have some teams that do "slack-ins" but I find few people read the updates and even fewer questions are answered or asked.

At best, this gives micromanagers satisfaction while not doing much, and at worst it's a log of "well I told you so"

<comment><USER22> The fact that everybody tunes out these updates suggests that the things being communicated are of low value.

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

Do they ever. Every day I have no idea what I'll actually be working on. It's almost never what I say I'll be working on because shit comes up in a stand- up. I'm not a manager so it doesn't bother me much, but it does slow progress on larger tasks considerably at times. Sometimes I just avoid saying what I think I'll be working on to save time as it's irrelevant and the meeting is already twenty to thirty minutes anyway.

</comment><comment><USER77> I have done a lot of standups. From my perspective, no one really cares for them. Most of the time, your coworkers are working on something that either doesn't matter to your task or you have no clue what they are doing even when they explain it. So standups are ultimately for the manager to get a sense of where everything is. But good managers should already have a grasp of the situation so standups become redundant.

</comment><comment><USER78> All of this is even worse with a distributed team. Don't get me started on what happens when contractors enter the picture.

Edit: and so-called development managers!

<comment><USER79> I've had some truly great development managers, and some really mediocre ones. It's helpful to have a technical manager that can shield you from certain issues while still understanding your needs enough to actually meet them.

<comment><USER78> You said it man. But when development managers enter the picture, and when they're also your people managers, and they come into the scrum and start enforcing top-down patterns it's about as toxic as you can get.

</comment></comment></comment><comment><USER80> It seems that much of the discussion here can be distilled into not trusting people. Lack of trust that people will work, can do the work, will tell someone when they have a problem or surprise, and mistrust of the effectiveness of the particular Task Management System in use.

Daily standups as largely practiced today, are a means to overcome this lack of trust through micromanagement.

</comment><comment><USER81> This makes me suspicious of Spotify. This is bad advice that could maybe apply temporarily to teams where you're not working on mission critical business work (what is left to engineer at Spotify?)

I also don't like that he prefixed bad advice with "PERSONAL beliefs" as a cop-out for responsibility. This is a tactic used by people skirting ownership of ideas.

</comment><comment><USER82> This article flies in the face of everything. I love articles that fly in the face of everything.

</comment><comment><USER83> Standups is just another example of something that someone had to makeup for the Agile methodology in order to be able to say that "people are communicating"...kumbaya.

It was probably invented by the same guy that invented the demented concept of open office.

</comment><comment><USER84> I'd guess this is probably only possible at a cash flush company where the devs personally use the product and fully understand the cost/benefit trade offs. Also, those sorts of meetings aren't for the sole benefit of the engineers.

</comment><comment><USER85> This is easy to explain. Main premise of agile is spending a lot of effort on improving the process. These are the standups, demos, retrospectives, etc.

It is no wonder you get more done if you cut the effort. You are coasting on past improvements. This is only going to work for a while until your performance starts to slip because the team stopped correcting and improving.

Spending time on improvements is important for other reasons. If your team spends 100% of the time on project work it is inefficient by definition (though not very intuitively, but see constraint theory). Spending time on improvements creates necessary flexible buffer. This is an alternative task when there is shortage of project work or it can be temporarily cut if there is too much project work.

</comment><comment><USER86> I am collecting links to SCRUM-related criticism at [https://againstscrum.tumblr.com/](https://againstscrum.tumblr.com/) Please contribute!

</comment><comment><USER87> 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 :)

</comment><comment> blubb-fish now we don't need stand-ups. couple of months ago they were the best since sliced bread. in job interviews i still get asked every time how often we do stand-ups - right after whether my team is lean, agile or design thinking. good lord have mercy ...

</comment><comment><USER88> I read "You don't need startups" and nodded my head in agreement.

</comment><comment><USER89> Post agile is a thing. Everybody is pretending to be agile these days. So, the word has become utterly meaningless. Every bank, insurerer, etc. is doing agile. And they are just as boring, stupid, and ineffective as 20 years ago. Government IT projects still go spectacularly wrong but they all pray to the church of Agile now.

When the agile manifesto was signed (yes old enough to remember), this was not the case. Agile was a new thing then. People were doing all sorts of stuff at the time and confusing processes and modeling techniques and requirements engineering methodology. Universities taught waterfall then (mostly because academics have no clue how development actually works). Rational Unified Process was something pimped by a company specializing in UML tooling! They ended up in the hands of IBM; probably the least agile company in existence at the time. Blue suits/white shirts were very much still a thing then. RUP was considered modern in the late nineties.

UML itself perpetuated the dogmas of waterfall, which was to first do detailed designs (using UML) after doing requirements specifications and before doing implementation work and before testing would commence. Automated testing was not a thing at the time. With rational unified they added a thin layer of iterative; meaning you got to do waterfall multiple times in a project. Rational's premise was that this required tools, lots of tools. Very complex tools that required lots of consulting. This is why IBM bought them.

Iterative development is of course almost as old as waterfall. The original paper by Royce on waterfall is actually a pretty good read but was soon complemented by papers on spiral and iterative development. Feedback loops are a good thing; every engineer knows this.

What the agile manifesto accomplished was that the UML bubble was burst. Having a lot of design documentation slows you down when iterating and makes it hard to do that. When people figured out that the added value of this typically incomplete and out of date documentation was questionable and that iterating was a good thing the result was that UML became a thing for whiteboards and from there an entirely optional thing. Same with requirements documentation, which was a bit of a black art to begin with. With agile people figured out that it's much easier to specify small deltas of what you want changed then the whole thing up front. Issue trackers empowered this. Bugzilla was the first popular one that got a lot of traction. They turned requirements into a way of working.

In a post agile world, everybody uses similarly capable tools. Typically git, some issue tracker, async commnunication tools like irc or slack, etc. I exclude email here; relative to 20 years ago, I spend a lot less time looking at email. It's rapidly disappearing from my life at least. Async communication is at odds with meetings and empower having distributed teams. The open source world was always distributed and never relied on meetings. They were an early adopted of asynchronous tools.

With post agile people are discovering that the added value of meetings is questionable. Agile initially replaced tools with structured ways to organize teams. An unintended side effect was lots of meetings. Meetings are inherently synchronous in both time and (usually) space. They require heads in a room at a specific moment. Video conferencing sucks and remote attendees are typically at a huge disadvantage in such meetings. So meetings are an obstacle for having remote teams.

With post agile, people are keeping some of the tools but are abandoning meetings. This is similarly liberating as saying goodbye to convoluted out of date UML diagrams, crappy requirements specifications, and the glacial pace of waterfall style development. Other post agile trends are continuous deployment: if it's ready, ship it now, not after the next retrospective in two weeks. And it's key enabler: continuous integration: aka. automatically assess whether you are fit to ship right now and do that after every small change. The former eliminates release management as a role and the latter relieves product managers from having to manually test and approve releases. That cuts down on meetings and eliminates Sprints as a necessity and allows you to iterate in hours instead of weeks. With sprints out of the way, you can delete the associated meetings. Standups are not practical in a distributed team, so those go as well. Post agile is about asynchronous communication and work distribution and getting rid of synchronization bottlenecks in processes (aka meetings).

</comment><comment><USER90> 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.

<comment><USER91> > Plan tech debt into your sprints.

Exactly! Nothing about Scrum or Agile discourages tackling tech debt. Managers and Product Owners encourage features—not sprints.

</comment></comment><comment><USER92> "Extroverts thrive at stand-ups, planning, and retros."

As if to insinuate that extroverts like to increase technical debt and introverts are the quiet ones that toil away. Nah.

</comment><comment><USER93> Sometimes the goal is to slow down work. For example, if your budget is for a year but the project only takes 6 months, sometimes people add extra hurdles that look good to outsiders but slow down work enough so they get paid for the full time.

If a project ends 6 months early it's entirely possible to not get paid as much.

</comment><comment><USER94> Scrum vs Kanban [https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent- they-...](https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-they-the- same-thing/)

</comment><comment><USER95> Bull-fucking-shit; you know why Spotify's engineering team does well? Stripe's? Netflix's? Because they have _money_ , they have _money_ so they can buy the best engineers. You ever see a small business development team compete on their level that isn't a bespoke design firm?

In my world, my team isn't an olympic-performing high-end software engineering pack. They don't lead in particular subfields in FOSS in their spare time. So you know what? They need fucking plans.

This article is a glorified, "Well if you're good you don't need process," piece.

<comment><USER96> Would you please not rant like this to HN? You may have a substantive point in there but you need to make it more thoughtfully.

<comment><USER95> Could you please elaborate? I don't feel like "like this" and "thoughtfully" are constructive pieces of feedback for comments.

<comment><USER97> > Could you please elaborate?

'Bull-fucking-shit' was literally the first word in your comment.

<comment><USER95> And? [https://hn.algolia.com/?q=&query=bull-fucking- shit&sort=byPo...](https://hn.algolia.com/?q=&query=bull-fucking- shit&sort=byPopularity&prefix&page=0&dateRange=all&type=comment)

<comment><USER96> It's basically the online equivalent of spittle flying out of your mouth while berating someone.

</comment></comment></comment></comment></comment></comment><comment><USER98> Funny how there's a Show HN link for a standup app right above this post...

</comment><comment><USER33> ah, gratuitous obscenity. the sign of someone that really knows what they're doing, from whom we should take advice.

it's still worth reading, not for what it says but what is between the lines. "how not to do sprints". admittedly this isn't (must not be, i guess) common, but at my current $JOB we do dedicate entire sprints to tech debt. remote people phone into our sprints and are well included. it actually HELPS remote contact as there is at minimum a daily interaction with the entire team. (@tapvt had a similar comment.) his comments about changing the course on a daily basis is another example of likely abuse of sprints.

<comment><USER87> I am a bit saddened by the fact you are getting downvoted.

Swearing adds nothing to the author's arguments and I believe you are spot-on on the analysis of the blog post.

Edit:

I missed the following from HN's guidelines

 _Please don 't comment about the voting on comments. It never does any good, and it makes boring reading._

Sounds very fair. The more you know... :)

<comment><USER99> Complaining about swearing adds even less to the discussion.

</comment></comment></comment><comment><USER100> The only time anyone cares about a standup is when they are talking.</comment>