22 ms·

You don’t need standups

• telltruth 8y ago
  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.
  • username90 8y ago
    Agile is the management equivalent to electron apps, not very efficient but makes your job easier.
• nodefourtytwo 8y ago
  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.
  • lobotryas 8y ago
    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.
    • munchbunny 8y ago
      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.
    • s73v3r_ 8y ago
      Retros are also for bringing up what went well, discussing why it went well, and how to do that in the future.
  • maxxxxx 8y ago
    My experience is that most retros result in a list of things that should get addressed but never get addressed. Especially because they must be addressed by larger organizational changes once the low hanging fruit has been addressed, In teams where we actually addressed these issues we ran out of things to say in the retro after a few times.
    • potatopolis 8y ago
      Things being recognised and never/rarely acted on is better than them going unrecognised entirely. At least in the former scenario, there's a shared awareness of the problem.
      • maxxxxx 8y ago
        There isn't. Raising an issue without ever fixing it is very demotivating and causes a "fuck it" attitude.
        • pythonaut_16 8y ago
          Everyone being aware of an issue without it ever being raised or acknowledged is equally demotivating and results in the same attitude.
          • maxxxxx 8y ago
            Same thing. Issues that are known and don't get fixed are demotivating.
  • s73v3r_ 8y ago
    Meh. A team with a leader/manager like that isn't going to get much value out of retros because either the leader/manager isn't going to listen to what's being said, or everyone won't feel safe enough to be able to say what needs to be said.
• cbanek 8y ago
  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).
  • zebraflask 8y ago
    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.
    • jiveturkey 8y ago
      > In weak teams, Agile is largely about managing weaker teams.
      • koolba 8y ago
        More generally, management is largely about weaker teams.
      • cjalmeida 8y ago
        Also, everyone is weak at some point of their careers. Until they aren’t.
• andrewmcwatters 8y ago
  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.
  • lobotryas 8y ago
    I didn't see it that way. The article argues for a very clear and curated Backlog of tasks. If engineers can't define tasks well and PM lacks understanding to structure backlog well then no amount of Engineering Olympians will help.
    • maxxxxx 8y ago
      Yeah. A well maintained backlog with a disciplined approach to changes does miracles.
  • dang 8y ago
    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.
    • andrewmcwatters 8y ago
      Could you please elaborate? I don't feel like "like this" and "thoughtfully" are constructive pieces of feedback for comments.
      • wgjordan 8y ago
        > Could you please elaborate? 'Bull-fucking-shit' was literally the first word in your comment.
• tapvt 8y ago
  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?
  • KallDrexx 8y ago
    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.
    • bcassedy 8y ago
      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.
  • haltingthoughts 8y ago
    There is a good argument to be made that supporting remote work yeilds gains in processes. See e.g. remoteonly.org
  • jaggederest 8y ago
    I don't think slack standups are a useful way to communicate this. I'd rather have it in the form of trello or pivotal tracker, for example, because those have audit logs and commentary. By all means, have people update those things at the beginning or ending of the day on a routine basis, but doing it in chat is just too ephemeral for me. I think it's often useful to ping people if you know you're going to need their help, for example, but that's not precisely a standup. It's just scheduling and communication.
  • sibmike 8y ago
    Async standups are great even for on-site teams. First, people only spend half a minute to post it; manager needs half a minute to read it to know whats going on. After it is posted, everyone have something to refer to before the weekly meeting, which does not have to be long if it is well prepared. The set up keeps the communications efficient and consistent. As for the original post, the outstanding team does not need the manager, so far. It will need one, after the writer deteriorate the culture and communication channels that have been established before him with own "trust" and f-words.
• CJST_ 8y ago
  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.
• jiveturkey 8y ago
  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.
  • nherment 8y ago
    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... :)
    • s73v3r_ 8y ago
      Complaining about swearing adds even less to the discussion.
  • pavel_lishin 8y ago
    ah, the insistence on PG language. The sign of someone that has a concrete criticism of an author's point, which we should pay attention to.
• nherment 8y ago
  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 :)
• k2xl 8y ago
  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.
• caymanjim 8y ago
  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.
• ravenstine 8y ago
  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?
  • w0m 8y ago
    Sounds like your project is scoped too broadly for daily standup then, though sometimes model just doesn't fit the task and you get the above.
  • kolinko 8y ago
    Besides that, I hate that they took me out of rhytm of work. If a standup is at 10am, and I arrive at 9am to do dev work, there is very little I can do before being interrupted - I need at least 2-4h of interrupted time to do some good work.
    • pletnes 8y ago
      Standup just before lunch might work better. That’s my experience.
      • justaguyhere 8y ago
        In my team, we have it early in the morning, so we can overlap with India. Folks in US have rest of their day for work, whereas folks in India do the standup at the end of the day just before going home.
• DanielBMarkham 8y ago
  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.
  • idts 8y ago
    You describe a better way of doing standups than simply status reports, but I'm finding it hard to distil into a couple of sentences. Could you help me understand what a better standup would look like?
    • DanielBMarkham 8y ago
      Talking about team communication in the abstract is difficult. I wrote a book about it. [1] The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing. If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value. On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible. 1. https://leanpub.com/info-ops https://leanpub.com/info-ops
• munchbunny 8y ago
  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.
  • antris 8y ago
    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."
    • munchbunny 8y ago
      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.
• vinceguidry 8y ago
  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.
• artsyxxx 8y ago
  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!
  • RandallBrown 8y ago
    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.
    • artsyxxx 8y ago
      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.
• mnm1 8y ago
  > 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.
• com2kid 8y ago
  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.
• tzakrajs 8y ago
  "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.
• acconrad 8y ago
  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).
  • smileysteve 8y ago
    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"
    • LargeWu 8y ago
      The fact that everybody tunes out these updates suggests that the things being communicated are of low value.
• rc_bhg 8y ago
  This article flies in the face of everything. I love articles that fly in the face of everything.
• kansface 8y ago
  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.
• vfc1 8y ago
  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.
  • syncerr 8y ago
    I think it's easy for teams to feel this way depending on the mechanics of who's running standup. One of the biggest values I see for standup is talking through what you're working on. This opens communication with other engineers, especially if they default to working in isolation on their projects (even more so for remote engineers). I can't count the number of times we've had actionable changes to direction from just 5 minutes of standup that result in code reuse, uncovering unknown unknowns, etc.
  • Benjammer 8y ago
    It's worse than "assembly line worker." For that, a hyper-specific set of actions is created, and then commoditized workers are inserted into this rigid process. The spec/actions rarely change over time. In "what did you do yesterday?" stand-ups, the worker is expected to establish their own personal direct actions in order to meet outside expectations and goals set by their manager/team. And then every morning someone is analyzing those actions for "blockers." A "blocker" is either a case where the manager didn't communicate effectively and/or didn't set effective scope/milestones, or else it's a code word for "you're doing it wrong" and gives the manager a change to micro-manage the specific actions the worker is taking day-to-day. In any case, I firmly agree with you that the core message is "I don't fucking trust you even an inch." If you want to see a bad engineering manager's brain misfire on cue (if they are of this micro-manager type), ask them why the product manager or designer on your team isn't expected to time-box and pre-estimate his/her spec. writing tasks.
• irrational 8y ago
  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.
• crispinb 8y ago
  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".
  • Florin_Andrei 8y ago
    Yes, but Kant was not incentivized to write in a certain way by some performance graph in Google Analytics.
    • crispinb 8y ago
      Indeed. Our intellectual history definitely dodged a bullet there.
• rightisleft 8y ago
  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...
  • bunderbunder 8y ago
    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.
• aphextron 8y ago
  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.
  • randomdata 8y ago
    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.
• hfourm 8y ago
  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.
  • VectorLock 8y ago
    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.
    • chris11 8y ago
      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.
• Sohcahtoa82 8y ago
  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.
  • aphextron 8y ago
    >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.
• wolco 8y ago
  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.
• ianbicking 8y ago
  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.
• sytse 8y ago
  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.
• LargeWu 8y ago
  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.
  • no_one_ever 8y ago
    I can hardly remember the last time I personally learned something just from attending a standup, but I guarantee I've taught other developers a thing or two regarding their problems and tasks that they otherwise would have floundered about trying to solve on their own. Just because it doesn't benefit you doesn't mean it doesn't benefit the team and project.
  • tomjakubowski 8y ago
    > 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.
• httpz 8y ago
  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".
• tanu057 8y ago
  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.
• ryanx435 8y ago
  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.
• ceedan 8y ago
  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.
• iEchoic 8y ago
  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.
  • TooBrokeToBeg 8y ago
    > 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.
    • iEchoic 8y ago
      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.
• amai 8y ago
  I read "You don't need startups" and nodded my head in agreement.
• brightball 8y ago
  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.
• lmilcin 8y ago
  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.
• apolymath 8y ago
  Funny how there's a Show HN link for a standup app right above this post...
• tw1010 8y ago
  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?
• ghostbrainalpha 8y ago
  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.
• blubb-fish 8y ago
  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 ...
• joepour 8y ago
  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.
  • wool_gather 8y ago
    > 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!
• Bizarro 8y ago
  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.
• cimi_ 8y ago
  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.
• seancoleman 8y ago
  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.
  • Florin_Andrei 8y ago
    > 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.
• inv 8y ago
  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.
• nineteen999 8y ago
  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.
• mr_tristan 8y ago
  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.
  • QualityReboot 8y ago
    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.
    • chadlavi 8y ago
      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.
    • mr_tristan 8y ago
      It creates silos. We do this on occasion, sometimes people are out, and there's just a few of us around. I _never_ see social interaction when people do that via chat. It's the same thing as just updating your ticket.
• rajacombinator 8y ago
  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.
• peterwwillis 8y ago
  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.
• partycoder 8y ago
  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.
  • alexchamberlain 8y ago
    Or do developer A and developer B make a good team? Looks like you've got a starter and a closer there to me.
    • partycoder 8y ago
      Sometimes that is indeed the case. In other cases you need a full rewrite, and that is not good.
• adrianmonk 8y ago
  > 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.
• agrippanux 8y ago
  The only time anyone cares about a standup is when they are talking.
• stevebmark 8y ago
  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.
• aryehof 8y ago
  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.
• luka-birsa 8y ago
  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.
• rosege 8y ago
  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.
• throwaway11232 8y ago
  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.
• jillesvangurp 8y ago
  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).
• Falkon1313 8y ago
  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.
• ibdf 8y ago
  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.
  • k1ns 8y ago
    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.
• known 8y ago
  Scrum vs Kanban https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-they-the-same-thing/ https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-they-...
• dood 8y ago
  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.
• piccolbo 8y ago
  I am collecting links to SCRUM-related criticism at https://againstscrum.tumblr.com/ https://againstscrum.tumblr.com/ Please contribute!