Live data from Hacker News

You don’t need standups

medium.com

271–280 of 341 posts

Re: You don’t need standups

#271

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…

I upvoted because I partly agree - if you're good you don't need these various methodologies. However, I'm curious - do you think these processes can actually convert a bad team into an ok one?

The processes help coordination and accountability; if they may be improved, the team will improve. Will it become an ok one? It may.

Re: You don’t need standups

#272
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.

Re: You don’t need standups

#273

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…

You are right, of course, in an abstract sense. But in the real world, this reminds me of the "we never had communism!" argument (because somehow, all those who implemented it, got it "wrong" and failed the principles). I mean, the principles behind communism might be noble and great, but if they ignore the human nature and the realities of the world, then, what good are they? If communism always seems to lead to murderous regimes, maybe it's better to avoid it than to attempt to "implement it right, this time"?

Of course, the parallels between "communism" and "agile" are imperfect. But the same way that various forms of "real communism" might work in small communities but fail spectacularly in large organizations, maybe "agile" is in fact actively harmful in corporations? Just a thought.... because I've never seen it implemented right. OTOH, I can't say I've seem good software practices in any large corporations (small pockets of excellence, yes, but they often work "against the system", not because of it).

Re: You don’t need standups

#274

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…

You are right, of course, in an abstract sense. But in the real world, this reminds me of the "we never had communism!" argument (because somehow, all those who implemented it, got it "wrong" and failed the principles). I mean, the principles behind communism might be noble and great, but if they ignore the human nature and the realities of the world, then, what good are they? If communism always seems to lead to mur…

This seems like some application of "no true scottsman" combined with complex human interactions in a theoretically "simple" system. I guess the perfectly rational consumer fits in somehow too.

Re: You don’t need standups

#275
post #198
post #81

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…

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 suc…

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.

Re: You don’t need standups

#276
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).

Re: You don’t need standups

#277
post #249

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 t…

As a n00b just getting into software development this might be a dumb question but does saying "Yup, still workin' on those bugs" really create a sense of blockage or such? I gotta think that's kinda a common thing to be said and other devs would understand that that happens...

If working on the same ones, then after a few days, yes. By then you should have explored some debugging techniques, options for solution, etc., and either can't figure out how to replicate or debug it or have found a tricky bug and 1-3 ideas for a solution, but all the potential solutions seem bad. That's when you can say you're blocked, ask the team for ideas on how else to replicate/debug, or try to get consensus for the least-worst hacky fix that you've come up with, or any other ideas based on what you've found. We all spin our wheels or get stuck sometimes, so of course we understand, and that's exactly what it's for. But you have to give that context and say where you're stuck.

Re: You don’t need standups

#278
post #63

Earlier quoted context omitted.

"working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with. "I tried this and this and measured this latency from the application and suspect it's a race condition, I checked this code and feel like I'm on the right track, and if someone wants to take a second set of eyes on my bug I would appreciate it" is a much much better update. Sta…

What if I don't want a team mate to look at something I'm working on? What if I just want to focus on building, not explaining and sharing? The current trend of "agile" is just another form of micro management. It's not good for the programmers at all, it's only good for product owners and team leads who are coordinating resources. Because it's micro management. We just call it something else now. It forces developer…

> it makes them easily replaceable

I don't think a developer is ever "easily replacable" (discounting obviously incompetent people which shouldn't have been hired in the first place). As soon as we join a team we start accumulating all kinds of knowledge about the codebase, the domain, the history, company politics, etc. Replacing with a new hire is back to square one. It's expensive, disturbing, and generally undesirable from a company perspective.

Yet you can't blame companies for trying to make each developer "as replacable as possible". There is always an employee churn -- people leaving for all kinds of reasons, some after a short while, some after decades -- and new people being hired. It's in the company's best interest to minimize the cost of this entirely predictable churn.

Actually, I think it's in the best interest of the developer as well. The more replacable we can make ourselves, the easier it is to leave to work on new, exciting projects. The more irreplacable, the more likely we are to be the dude who spent the past ten years maintaining the module written in $OBSOLETE_LANGUAGE_OR_FRAMEWORK because everyone else left and nothing was really documented.

I don't think daily stand-ups is really the tool for making yourself replacable since the information transmitted tends to be very short lived. Good code structure, well maintained tests, rock solid build env, good documentation of purpose, requirements, design considerations ... we never quite arrive at that nirvana but it would be the goal to aim for.

Re: You don’t need standups

#279
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.

Re: You don’t need standups

#280

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…

Or do developer A and developer B make a good team? Looks like you've got a starter and a closer there to me.
Post reply on HN