4 ms·

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 d

• 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.
  • fiachamp 8y ago
    In orgs I've been in the daily standup was clearly intended to help people get a heads up on who can help them with blockers or may be working on a similar part of the codebase that day. It also helps PMs know what kind of support they'll need to give their dev team that day since they often get pulled into meetings by other parts of the company. As far as timeboxing, the PM is timeboxed by having stuff in good enough state of definition that their devs feel they can work on them. So if you don't have your specs there by the time sprint planning happens, your projects don't get done and you risk your job. Of course, we have an issue if the PM is writing shitty specs and not around to help answer edge case questions.
• dane-pgp 8y ago
  You might be right, but I think you shouldn't be focusing your resentment at standups themselves, you should be focusing on the managerial or corporate culture. I've worked in places that did standups and places that didn't, and found that the lack of trust / constant surveillance / psychological pressure can be there regardless of whether standups are used. What does change, though, is that with standups, a manager has the reassurance that they are checking up on their developers every day, and the developers in return get the reassurance that their boss is only going to interrupt them once per day at a fixed time (or at least there's a better chance this is how it works out). I see "agile" as being a set of compromises and helpful cultural patterns which were designed by taking into account all the weird cognitive biases that brains get forced into by the group dynamics of working in a team on a project.
• aeternus 8y ago
  Standups are one possible solution to a variety of common problems when managing engineers: - Many engineers prefer to solve issues themselves rather than ask others for help. Often newer engineers don't know when to ask others for help. Standups help to foster this communication. - Reading code is generally harder than writing code, especially when written using a framework that the engineer is unfamiliar with. This leads to a tendency to declare existing code tech debt and want to re-write it, especially by less experienced engineers. Sometimes this is warranted but often it is not. Standups help guard against this by allowing more senior engineers or managers to catch this early-on. - There can be valid business reasons to get an unscalable feature out in ~2 weeks rather than scalable feature in ~2 months. Standups provide a quick way to explain the underlying business reasons to the team. - Business and contracts do require dates & deadlines. Even though it is not perfect, there needs to be some attempt at predicting when a certain feature can be delivered. Jira, and ticket tracking is important for this.
• mmcnl 8y ago
  Standups are about developers updating eachother. Basically no one outside the development team should be in the standup. I don't get what's negative about this.
• zmmmmm 8y ago
  Not really a fan of standups either, but I want to express a counter point: developers consistently over-estimate their understanding of the problem domain they are working in and the wider context it sits in. That is yes, managers don't "trust" developers - but not in quite as negative a sense as you think. There is a positive aspect of supporting the person, ensuring they are connected to the right resources to succeed and stopping them getting stuck on things that don't matter. I have a small team of devs and I consistently find that given task X they will get stuck and end up spending a lot of time on small subpart Y. And they really want to solve Y, because they are engineers and doing the "hard" stuff is what often drives them. So without some kind of input, what they will do is spend a week on Y and then report back that X was much harder than expected. When told at that point "Oh, we really actually don't need the Y part, we could just to Z instead" they will be quite disappointed, and wonder why they weren't informed that Y wasn't that important to begin with. So more regular communication of some kind is really important to avoid this. As I mentioned, I don't really like daily standups as the optimal way to achieve it ... but I don't quite accept the "leave your developers alone for weeks at a time" strategy either.
  • tchaffee 8y ago
    I wish more devs understood what you said instead of taking it as being micro managed. In short, what good managers distrust is the ability to communicate. We are all pretty bad at it. These meetings just give us an opportunity to continually refine what it is we are actually working towards. Agile to me doesn't mean daily standups. It does mean sharing with each other what we've learned about the problem which almost always means reprioritizing. If that communication isn't happening at least a few times a week, there's something off or unusual.
  • cellularmitosis 8y ago
    I understand that avoiding spending a week on Y is important for business value, but constantly prioritizing shipping features in the cheapest manner possible also means not investing in the long-term growth of your developers. You don't learn much of value by gluing together a handful of framework functions. You become a better engineer by really struggling with and digging into Y for an entire week. If engineers are never given the freedom to do that, they stagnate as framework glue monkeys. "Deep work" is a rare thing in scrum shops.
• rajacombinator 8y ago
  Yep this is the exactly right and obvious interpretation.
• JDiculous 8y ago
  Best description of standup I've ever seen. One of the many reasons I left corporate tech.