You don’t need standups

One thing I don&#x27;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&#x27;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&#x27;d say that I&#x27;m doing the same thing I&#x27;d been doing for the last several days, like a broken record. I don&#x27;t want to have to say &quot;Yup, still workin&#x27; on those bugs&quot; every morning. When shit&#x27;s fixed or I&#x27;ve completed a feature, <i>I&#x27;ll let you know</i>.<p>In fact, all I like about standups is seeing my team mates once a day. Besides that, there&#x27;s almost no upside. Literally everyone can read the project board to see what we&#x27;re up to. If you&#x27;re really so curious as to what everyone is doing, why not just look at that?

I always upvote these things, not because they&#x27;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&#x27;s important to understand how.<p>According to the author, standups are something companies require developers to do to report about what they&#x27;re doing. Many times they can take more than a half hour.<p>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&#x27;s not about what you did. That&#x27;s a status report. It&#x27;s about how you can help one another.<p>If you can self-organize, effectively communicate, and help one another as-needed without standups? Don&#x27;t do them. Easy. There&#x27;s no magic requirement that you have to. What we&#x27;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&#x27;s working or not. Other people can drop by to help out. But if that&#x27;s too formal for you and you don&#x27;t need it? Stop!<p>Standups remind me of brushing your teeth. When they&#x27;re working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It&#x27;s when they&#x27;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 &quot;What&#x27;s your status?&quot;. Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you&#x27;re free and then go play tennis the rest of the day or something. It&#x27;s not a management, outside-in meeting. Just the opposite, in fact.<p>I love these articles because they remind us that the goal is what&#x27;s important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team&#x2F;org experiences.

Standups always felt to me that they had a core negative message to developers.<p>It&#x27;s not about communication at all. Its about control, its about saying:<p>We don&#x27;t trust you.<p>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.<p>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.<p>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&#x27;t have the autonomy to just do what they know needs to be done.<p>Everything needs to be pre-approved by a non technical manager and assigned a JIRA or equivalent.<p>Looking back, to me its clear that I resented standups, they made me feel like I was being treated as an assembly line worker.

The entire concept of a sprint to me always felt wrong. Development work can&#x27;t be split up into time slices. And trying to divvy up tasks based on an estimate of how long it&#x27;ll take to complete each one is just a waste of time.<p>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&#x27;t complete the second high-priority task before the end of the sprint, so what? I still made progress on it.<p>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&#x27;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&#x27;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.<p>Obviously, this frequently resulted in priority inversion, not to mention the problems from poor estimations of task time.<p>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&#x27;t finish the second one before the end of the week, but then completed that plus 40 hours the next week, they&#x27;d question why your productivity swings so much because you only got 20 hours done one week, but 60 hours the next!<p>And of course, as mentioned, these &quot;hours&quot; 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.<p>I&#x27;ve rambled a bit, but you get the idea. I think the author is spot on. Just use your task tracker.

I&#x27;m the scrum master on a team where most members are very geographically spread out, and the standup is great. It&#x27;s time for everyone to have that direct social connection.<p>But I don&#x27;t ask about ticket status. We just ask about what they did yesterday, and what they&#x27;re up to today. And I mostly ask that if they aren&#x27;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 - &quot;tech debt&quot; is too generic.<p>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 &quot;hey we need to sync up&quot;. A lot of ad hoc conversations appear right after standups, that wouldn&#x27;t have just happened, because people don&#x27;t often spend their time reading through the comment section on open tickets.<p>It&#x27;s really a gut check that yes, the team is indeed working together. If your team&#x27;s standup is just some regular robotic process of repeating status already captured in tickets... WTF; I&#x27;d say you&#x27;ve got serious leadership problems.

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&#x27;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.<p>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&#x27;t mean these things have no value; it means the team is a well-oiled machine.<p>Except standups. Standups are, have always been, and always will be a waste of time.

I&#x27;ve been managing engineering teams for a few jobs now, but I think this article suffers from some logical fallacies.<p>&quot;You don&#x27;t need stand-ups&quot;<p>I&#x27;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.<p>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.<p>But the very next team I tried it on it failed miserably. Tons of conflicts, duplicated work, etc. We also tried to &quot;fix them as they went&quot; but what ended up happening is that bringing up and trying to resolve every issue when it happened got difficult. Naturally we kept &quot;tabling&quot; issues to discuss later and we never did until we create monthly meetings to discuss all the issues together. Funny how a &quot;retro&quot; ended up organically forming.<p>The truth is, every team is different. What works with one team won&#x27;t work with another. I&#x27;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.<p>I also think the authors marriage analogy is weak. At work, your team isn&#x27;t a family. It&#x27;s a team. You can&#x27;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.

Here&#x27;s a thought experiment, and a challenge: When was the last time you learned something really important at a standup meeting that you wouldn&#x27;t have learned otherwise, either by talking to someone directly or in some form of asynchronous communication?<p>I bet it was a while ago, if you can even think of anything specific.<p>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&#x27;t need to know that the product owner is in meetings all day. That&#x27;s almost every day. I don&#x27;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&#x27;s usually good enough. If I am blocked on something, how is that useful for you to know? If there&#x27;s anything you can do about it, or need to communicate to somebody else, I&#x27;ve probably already talked to you. And if I haven&#x27;t talked to you, it&#x27;s almost certainly irrelevant to you.<p>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.

A team where the Engineering Lead(or any kind of manager) thinks that you don&#x27;t need retros because there are no problems is exactly the kind of team that needs retros.

Posts like this usually have good points, but I feel like they should always come with a massive caveat:<p><i>Every team is different, and you should tailor your processes to fit the team.</i><p>And because of this, I think posts like this one should spend time answering:<p><i>What conditions were needed for your decision to be a good idea? And when would your decision be a bad idea?</i><p>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.

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?<p>Standups are (in my experience) usually a symptom of a low-trust environment, where there&#x27;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&#x27;t think of any argument for why they&#x27;d be necessary at all companies.<p>Our team is distributed and has been going ~eight months without standups or work hours, and I&#x27;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.

I love the fact that none of this exists in open source projects. All communication is done immediately using IRC, mailing lists, and bugs&#x2F;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&#x27;s ready, it&#x27;s ready.<p>I hate the fact that if you&#x27;re <i>not</i> following a bullshit development methodology (and usually poorly) you&#x27;re treated like there&#x27;s something wrong with you.

It&#x27;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.<p>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&#x27;s important to force people to coordinate, because many times people will just run off in random directions you don&#x27;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).

We actually massively profited from implementing standups and agile-ish process and we really do not feel the downsides mentioned in the article.<p>Standups:<p>1. The standups are held in very small groups that work on the same thing and where it is important that they are coordinated.<p>2. Standups are not a place to discuss priorities. Those were set way before. It&#x27;s for you to tell everybody what you&#x27;re working.<p>3. Standups take 5-6 minutes per day. It&#x27;s less than one foosball game. Some teams actually do their standups while doing a plank, so that they&#x27;re very short.<p>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).<p>5. If you&#x27;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.<p>Agile process:<p>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).<p>2. The schedule also gives the leads a clear tool to block any &quot;non-urgent&quot; 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&#x27;ve heard of 3-day sprints since that was the most effective way of blocking daily priorities changing until management got on board.

We do stand ups once a week on Monday morning to get everyone on the same page and focussed for new week.<p>Each time a different dev runs it, chosen by the person who ran it last.<p>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.<p>We then do a retro on Friday afternoon, sit outside and have a beer and chat about what worked and what didn’t.<p>Not strictly agile, but this works for us and everyone is happy and productive.

Not going to lie...I like stand-ups, but I am an extrovert. I also like them as a full time remote because it&#x27;s the only way I regularly see my team.<p>As long as it doesn&#x27;t interrupt people. 10am is to late if the work day starts at 8:30am. About 45 minutes after the &quot;beginning&quot; 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.<p>At the same time, there&#x27;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&#x27;t be anything more than a quick &quot;how&#x27;s it going&quot; for the team.<p>I would have no argument as a developer working under this unless the quarterly goals were out of control.<p>What you&#x27;re describing is basically Kanban.<p>I agree with almost every word.

I&#x27;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&#x27;t wait for the next day.<p>The team that didn&#x27;t do standups was by far my best team. We still talked frequently as needed and moved quickly. Actually quicker because we didn&#x27;t get interrupted by standups, hour long retros and planning meetings.

I&#x27;ve been beating this drum as it&#x27;s one of the more frequently cargoculted items about agile.<p>A standup has 3 questions to report on:<p>1. What did you make progress on yesterday?<p>2. What are you planning on making progress on today?<p>3. Do you have any blockers?<p>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&#x27;ve specifically seen standups backfire as individuals use reserve their blockers until the next morning. It&#x27;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&#x27;s standup.<p>Perhaps I just described an unattainable utopia, but I think it&#x27;s important to start with process idealism and make considered compromises rather than acculturating the status quo.<p>I lead an entirely remote-first development team, and am adamant that standups often are a crutch at best, and inhibit progress at worst.

I really dislike these type of articles. The title is there just to shock you, and so is the content... so much that there&#x27;s a disclaimer at the end of it. I think I would read it with an open mind if the title was phrased differently... &quot;Maybe you don&#x27;t need standup&quot; or &quot;how standup slows down our company&quot; something of that sort.<p>&quot;The natural side effects of not doing standup are:&quot;<p>&quot;- 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&quot;<p>These bullet points are non-sense. Perhaps developers were not communicating properly, and that&#x27;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&#x27;t even know how to make a proper schedule.<p>Here&#x27;s what you should do:<p>1. See what works for you 2. Make adjustments 3. Evaluate adjustments 4. Repeat<p>Meanwhile, read some books on management and learn from more experienced people. There&#x27;s no reason to drop everything you are doing because a blog post said so.

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

This approach works really well when you have a great team - like I&#x27;d imagine palmerj3 has at Spotify. I&#x27;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.

People should try to think more long term about standups.<p>Yes, maybe you could remove them and maintain the same productivity for a year, so they appear wasteful.<p>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.<p>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&#x27;ve got that down to more like 2x.

I&#x27;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.<p>Process and communication are kind of key, aren&#x27;t they?

I&#x27;ve pushed for this model and I&#x27;ve done this with my team over the past year. It&#x27;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.<p>Our work involves some research which we&#x27;ve managed to do quite well following this model. We&#x27;ve also evolved our product and managed to deliver complex features more efficiently than we would have done if we did sprints, IMO.<p>A few team members have complained about lack of frequent deadlines (?!?), lack of status meetings&#x2F;standups etc. The arguments are weak IMO - &#x27;that&#x27;s how we did it before&#x27;, &#x27;we hear what other people are doing&#x27; (we are pretty good on transparency), &#x27;it&#x27;s nice to have a forum to discuss how things are going&#x27; (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&#x27;s been handling feature prioritization and he&#x27;s making sure that people are comfortable with their work during 1:1s.<p>Also, I think it&#x27;s really important to have a clear vision and steer the product - we&#x27;ve been missing that and it&#x27;s caused a lot of friction when deciding how to evolve the product. Sprints wouldn&#x27;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.

I work on a team where 3&#x2F;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&#x27;ve been hired to do? Likewise when it comes to my turn to talk it often turns into &quot;blah blah blah [giggle] I don&#x27;t know what any of that means! computers!&quot; from the business people. It&#x27;s so useless.

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&#x27;t matter and it is needlessly synchronous.

While I do agree with the sentiment of reducing meetings and time spent planning, I don&#x27;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.

I understand many writers are desperate for views, but I&#x27;m looking forward to this nasty spreading imperative title infection to die out (which it will, but not soon enough). &quot;What you need to know about ...&quot; (<i>you have no idea what my knowledge requirements are</i>) &quot;You don&#x27;t need ...&quot; (<i>you won&#x27;t know what I need until you find out something about me, dolt</i>). &quot;Why you should ...&quot; (<i>until you&#x27;ve at a minimum skimmed &#x27;Ethics for Dummies&#x27;, which your 1st-year-uni-essay-think-piece betrays no evidence of, you&#x27;re not qualified to inform me what I &#x27;should&#x27; do</i>).<p>This rash is particularly prevalent in the prissy modern etiquette columns that dominate so many alleged newspapers (I&#x27;m looking at you, Graun), but the tech sector is also succumbing apace.<p>Now Kant: <i>there</i> was a guy who knew how to construct titles. He did not write &quot;What you need to know about the categorical imperative&quot;, nor &quot;Why you must critique pure reason&quot;.

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.<p>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 <i>all</i> teams.

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&#x27;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.<p>Standups aren&#x27;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&#x27;t ground breaking. There is still iterative planning, even if they aren&#x27;t &quot;sprint planning&quot; sessions.

FTA: Say you’re in a relationship and it’s going amazing. You should totally start going to couples therapy once a week, right? &lt;&#x2F;sarcasm&gt;<p>Me: Actually yes - that way it stays amazing...

Probably too late to this thread, but anyway - the key to understanding agile tomfoolery is that <i>processes are most effective if they evolve to meet the needs of the people in the team</i>.<p>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&#x27;re permitted to, and like supporting their colleagues if it doesn&#x27;t prevent them doing a good job. Few people want to make their colleagues&#x27; job harder or get in fights - much of this is friction caused by bad processes.<p>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 <i>it solves real problems and makes the team more effective</i>.<p>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.

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.<p>Some aspects of Agile&#x2F;XP&#x2F;Scrum etc. obviously have some benefits particularly for larger organizations&#x2F;teams. On the other hand I&#x27;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 &quot;user stories&quot; 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.<p>I&#x27;ve worked at a company like this that held retros on Friday afternoons and by Monday morning standups, they couldn&#x27;t remember the things that had been discussed in Friday&#x27;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.<p>IMHO I think the sweet spot is probably somewhere in between.

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&#x2F;simple so I do less but explain it well.

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&#x27;s hard to judge if this advice is any useful to me. I would&#x27;ve preferred if the tone was more like &quot;Why we didn&#x27;t need standups&quot; not &quot;You don&#x27;t need standups&quot;.

Good article. If you have a good team, you don&#x27;t need agile or other methodologies. These frameworks have always been the crutch of bad managers, or MBA types who want to corral &quot;those developer people.&quot; Now, can agile&#x2F;scrum&#x2F;ninjitsu&#x2F;rockstarism transform a bad team into a competent one? I don&#x27;t know - I don&#x27;t work with bad teams.

I really like this advice. One thing I&#x27;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.<p>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.<p>Now we&#x27;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&#x27;s been veritable chaos ever since. If anybody is looking for a Rails ninja, drop me a line.

I think standups can be good, but get rid of the mandatory status updates.<p>Want to talk about something? Knowing you can put it on the agenda for the next standup is great. If the standup isn&#x27;t the right forum for the topic, then it&#x27;s still probably the right forum to decide what the right forum is, and let&#x27;s you include people who are unexpectedly interested.<p>Talking about incoming tasks and bugs is also helpful, and is an important part of developing a collective understanding of priority and approach.<p>And of course when there&#x27;s some specific pressure or deadline, then you&#x27;ll need to talk status and cover details. The standup is going to change based on needs. It&#x27;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.

&gt; <i>I wanted the team to know I trusted them.</i><p>This can be very powerful. People will often rise (or sink) to the level corresponding to how much you show you believe in them.<p>Imagine you hand someone the reigns and say, &quot;Here, take over this for me. I know you&#x27;re going to do a good job.&quot; And you sincerely mean it because you&#x27;ve bothered to understand them well enough to know that they can. In a lot of cases, you&#x27;ll be amazed at what they will accomplish. They may even be amazed too.<p>Often, forming good, healthy relationships and building people up is what&#x27;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&#x27;s really not happening because the basics haven&#x27;t been covered.

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.

To me, standups are most useful for 3 things:<p>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).<p>2) When working on a legacy system, getting group consensus on the hacky stuff you&#x27;re doing to solve a problem (and in the process letting others know about that hacky stuff).<p>3) The group&#x27;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.<p>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.

my 2 cents,<p>I don&#x27;t think this post will age well.<p>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 &quot;rituals&quot; are effective ways to ensure a good base level of inefficiency. If you&#x27;re feeling like the agile rituals are becoming a waste of time, I would try out doing longer sprints before dropping them entirely.<p>Cutting process relies on good habits from the developers&#x2F;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&#x27;t formally exist can feel like just another burden&#x2F;task switch they have to take on.

Let&#x27;s say you have 2 developers:<p>- developer A wants to get promoted as quickly as possible. developer A will try to &quot;ship&quot; as many features as possible.<p>- developer B wants features to actually work, not just be &quot;shipped&quot;. developer B volunteers to fix the problems developer A created by rushing to close as many tickets as possible.<p>Now, guess which developer contributes more to the team &quot;velocity&quot;? developer A. But in reality, developer A is just gaming the system and making everyone else <i>slower</i>. This is how agile distorts development.<p>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.

Why the need for all this formalization of process. We&#x27;re all adults. As long as we hire people who can communicate well, shouldn&#x27;t just having conversations here and there when the need feels natural be enough?

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

&gt; Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.<p>Do they ever. Every day I have no idea what I&#x27;ll actually be working on. It&#x27;s almost never what I say I&#x27;ll be working on because shit comes up in a stand-up. I&#x27;m not a manager so it doesn&#x27;t bother me much, but it does slow progress on larger tasks considerably at times. Sometimes I just avoid saying what I think I&#x27;ll be working on to save time as it&#x27;s irrelevant and the meeting is already twenty to thirty minutes anyway.

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&#x27;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.

All of this is even worse with a distributed team. Don&#x27;t get me started on what happens when contractors enter the picture.<p>Edit: and so-called development managers!

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.<p>Daily standups as largely practiced today, are a means to overcome this lack of trust through micromanagement.

This makes me suspicious of Spotify. This is bad advice that could maybe apply temporarily to teams where you&#x27;re not working on mission critical business work (what is left to engineer at Spotify?)<p>I also don&#x27;t like that he prefixed bad advice with &quot;PERSONAL beliefs&quot; as a cop-out for responsibility. This is a tactic used by people skirting ownership of ideas.

This article flies in the face of everything. I love articles that fly in the face of everything.

Standups is just another example of something that someone had to makeup for the Agile methodology in order to be able to say that &quot;people are communicating&quot;...kumbaya.<p>It was probably invented by the same guy that invented the demented concept of open office.

I&#x27;d guess this is probably only possible at a cash flush company where the devs personally use the product and fully understand the cost&#x2F;benefit trade offs. Also, those sorts of meetings aren&#x27;t for the sole benefit of the engineers.

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.<p>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.<p>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.

I am collecting links to SCRUM-related criticism at <a href="https:&#x2F;&#x2F;againstscrum.tumblr.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;againstscrum.tumblr.com&#x2F;</a> Please contribute!

I&#x27;m having a hard time agreeing with a lot of the points being made (I mostly skimmed but also read some parts).<p>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.<p>- Daily standups are a <i></i>tool<i></i> for coordinating teams.<p>- Weekly planning is a <i></i>tool<i></i> for iteratively communicating about the progress being done, steering the team and discussing priorities<p>- Retrospectives are a <i></i>tool<i></i> as well; a quorum regarding what goes well and what should be improved.<p>In a well functioning team, you will always need coordination&#x2F;communication, progress visibility, continuous improvements, etc.<p>I picked 2 red flags in how this junior product manager approaches their work:<p>- the team did not discuss estimations<p>- he told his boss the team will deliver after 3 months<p>Basically he just &quot;winged it&quot; 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.<p>Let&#x27;s take a few of the points being made throughout the post:<p>&gt; <i>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.</i><p>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.<p>&gt; <i>Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.</i><p>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.<p>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 &amp; send updates through a different channel).<p>What I&#x27;ve seen is that there are usually 2 team members that come with the &#x27;authority&#x27; to make for a great standup: the product owner (in this case our author) or the tech lead (well, seems it&#x27;s the author again, as a technical. prod. owner?).<p>&gt; <i>Standup forces every team member to be productive at a set place and a set time</i><p>Yes it can be a problem. That could possibly be reason #1 to get rid of standups. We&#x27;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.<p>&gt; <i>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.</i><p>Again, it sounds like standups are being used for the wrong thing. The standup is at 90% a &#x27;passive&#x27; 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.<p>&gt; <i>Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.</i><p>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.<p>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.<p>There are 2 critical elements to successful retrospectives:<p>- trust that everybody can speak up about the most minute detail. Be open about anything that is being said. Leave the ego out.<p>- 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!<p>&gt; <i>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><p>I&#x27;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.<p>Addressing tech debt is part of any new feature. There should be no &#x27;tech debt&#x27; 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..<p>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 &#x27;that is needed in a week&#x27; and &#x27;we need to refactor A to K before we do feature XYZ&#x27;. These are healthy events in a team that care a lot about delivering the most business value through solid software.<p>&gt; <i>That said, I’m not against planning, I’m against planning on an interval.</i><p>Fair point. Planning on an interval brings a few things on the table:<p>- it sets a cadence. Some people love stability. Regular planning can be an anchor to someone&#x27;s organization of their work.<p>- it allows measuring velocity and therefore longer term planning through past velocity.<p>- it allows reprioritization sprint after sprint. Usually the product owner role is to gather clients&#x27; 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&#x27;s previous projects), it is a compromise between constantly shuffling around what developers do and being flexible about what is being built.<p>In my modest experience, all of these are very useful tools :)

now we don&#x27;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 ...

I read &quot;You don&#x27;t need startups&quot; and nodded my head in agreement.

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.<p>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&#x2F;white shirts were very much still a thing then. RUP was considered modern in the late nineties.<p>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&#x27;s premise was that this required tools, lots of tools. Very complex tools that required lots of consulting. This is why IBM bought them.<p>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.<p>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&#x27;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.<p>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&#x27;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.<p>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.<p>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&#x27;s ready, ship it now, not after the next retrospective in two weeks. And it&#x27;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).

Line by line:<p>&gt; Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t.<p>My team offloaded this to the PM.<p>&gt; Stand-ups ENCOURAGE plans to change daily.<p>The sprint plan is the plan, stand-ups make sure the execution is coordinated.<p>&gt; Standup forces every team member to be productive at a set place and a set time<p>Timing around standups is interesting. 11am and everyone will be there, but it interrupts a lot of people&#x27;s flow. Earlier and people no show, later and the point of a morning stand up is lost.<p>&gt; Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem.<p>How are extroverts and tech debt related?<p>&gt; Developers shouldn’t have to PUSH for tech debt to be addressed.<p>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.<p>&gt; Why do we encourage problems to be discussed once a week?<p>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.<p>&gt; Sprints encourage features over tech debt.<p>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&#x27;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.<p>&gt; It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt<p>Tech debt sounds like a cultural problem on team&#x27;s he has been on. Not surprising, it is a cultural problem on a lot of teams, independent of dev methodology.<p>&gt; Developers communicate more<p>Why? Developers are always free to communicate outside of stand-ups.<p>&gt; Tech debt gets addressed<p>If promotions are based upon feature completion, as they often are, tech debt being completed isn&#x27;t a natural outcome of freeing up 10 minutes a day.<p>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.<p>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&#x27;s assigned tasks?<p>&gt; It’s my role to “steer the ship” (e.g. decide what we work on).<p>I find that giving developers input on this is important. In fact, that is how the tech debt gets addressed...<p>&gt; If I’m changing my mind about this on a daily basis that’s problematic.<p>Yeah, don&#x27;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&#x27;s tasks.<p>&gt; Stop planning every sprint<p>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.<p>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.<p>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.<p>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.<p>Sprints had a rhythm, developers assigned to multi-sprint features ignored the rhythm for the most part.<p>For everyone else, 2 weeks feature work, 1 week tech debt, and coordinating with test for sign off.<p>&gt; Tasks are added to the backlog as needed,<p>Stand-ups have no impact on this being possible. The add task button is always available, 24&#x2F;7.<p>&gt; Developers are trusted to be working on the correct things<p>Stand-ups have no impact on this. You can still trust people to pull of the tasks they feel are important.<p>&gt; Stop doing retros<p>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.<p>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.<p>If you use them for anything more than that, well, sure, simplify it.

&quot;Extroverts thrive at stand-ups, planning, and retros.&quot;<p>As if to insinuate that extroverts like to increase technical debt and introverts are the quiet ones that toil away. Nah.

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.<p>If a project ends 6 months early it&#x27;s entirely possible to not get paid as much.

Scrum vs Kanban <a href="https:&#x2F;&#x2F;thehftguy.com&#x2F;2017&#x2F;12&#x2F;06&#x2F;scrum-vs-kanban-arent-they-the-same-thing&#x2F;" rel="nofollow">https:&#x2F;&#x2F;thehftguy.com&#x2F;2017&#x2F;12&#x2F;06&#x2F;scrum-vs-kanban-arent-they-...</a>

Bull-fucking-shit; you know why Spotify&#x27;s engineering team does well? Stripe&#x27;s? Netflix&#x27;s? Because they have <i>money</i>, they have <i>money</i> so they can buy the best engineers. You ever see a small business development team compete on their level that isn&#x27;t a bespoke design firm?<p>In my world, my team isn&#x27;t an olympic-performing high-end software engineering pack. They don&#x27;t lead in particular subfields in FOSS in their spare time. So you know what? They need fucking plans.<p>This article is a glorified, &quot;Well if you&#x27;re good you don&#x27;t need process,&quot; piece.

Funny how there&#x27;s a Show HN link for a standup app right above this post...

ah, gratuitous obscenity. the sign of someone that really knows what they&#x27;re doing, from whom we should take advice.<p>it&#x27;s still worth reading, not for what it says but what is between the lines. &quot;how not to do sprints&quot;. admittedly this isn&#x27;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.

The only time anyone cares about a standup is when they are talking.