Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You don’t need standups

medium.com

Post reply on HN
Print view View original

281–290 of 341 posts

Re: You don’t need standups

#281

Post by paulmooreparks »

j4kp07 wrote: post #221
kerbalspacepro wrote: post #91

Earlier quoted context omitted.

1. Agile is not personally great for programmers. 2. Agile is good for managers. 3. Managers run the business and make sure it exists. 4. Programmers need the business in order to have a job. 5. Agile is therefore good for the business, 6. And therefore Agile is good for Programmers, though not personally.

Unfortunately, you have been taught and are executing Agile in the completely wrong fashion. My first guess would be, you are actually working in Waterfall, but your managers have labeled it Agile and cherry-picked the parts they liked.

Agile has a remarkable resemblance to both communism and faith healing: Every time I say it doesn't work, a true believer replies and says I wasn't doing it right or I didn't believe in it enough.

Re: You don’t need standups

#282

Post by mvindahl »

BigJono wrote: post #220
gav wrote: post #68

Earlier quoted context omitted.

> 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. The idea of standups and breaking down work into chunks that fit in a short sprint is to avoid this sort of situation where somebody is off on their own and not getting feedback. I find that people are overly optimistic about their chances…

A task should be something that can be done independently by one person. Sometimes you have a big chunk of work that's tightly coupled and can take months to implement, how do you best track that? In my experience what happens is one of three things: (a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of…

My 5 cents on this:

- Usually, for large chunks of work, you want to bring in more people. Both because they tend to involve several modules or several layers of the stack, and very few people are equally skilled in every part of the codebase. But also because there will most probably be design decisions and tradeoffs along the way to discuss. Coordinate who is working on which parts of the codebase at any given time.

- I'd avoid excessive preplanning. But I'd make tasks to make explicit the general plan and the interdependencies. E.g. create new server API, then refactor client, then remove old server API.

- Don't be too concerned with showing progress in stand-ups. Feeling like you need to do this to justify yourself is a team process smell. Abandon them if they bring no value, e.g. if you have a de facto three people subteam who is coordinating all the time anyway.

Re: You don’t need standups

#283

Post by watwut »

DanielBMarkham wrote: post #75
aunty_helen wrote: post #64

Earlier quoted context omitted.

>Because they show common misunderstandings about Agile I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working. People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told. I went thr…

I'm Old Expert Programmer Dude now, so I get to tell stories. 1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?" Another coach said nope, we're professionals! What do we need standups for? The rest of us met every morning for breakfast. No standing up, no meeting. But we knew…

> The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap. We did well. He did not.

Basically, since the other guy did not wanted standup you intentionally left him out of loop and communicated only among yourself during breakfast. If there was ever ugly politics, it is this one.

> He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.

Frankly, I really don't want to work in environment you and your friends are creating. Regardless of whether I enjoy the process you are pushing for, I don't want to work with people who intentionally sabotage people they disagree with - and then brag about it. If there is something called inability to work with different people, this right here is it.

The pattern I see here is that your colleges are intentionally toxic to those who don't share their preferences and then blame victims. You refused to communicate like adults resorting to passive aggression, not your opposition.

Re: You don’t need standups

#284

Post by zmmmmm »

cellularmitosis wrote: post #275
zmmmmm wrote: post #198

Earlier quoted context omitted.

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

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

Re: You don’t need standups

#285

Post by BigJono »

mvindahl wrote: post #282
BigJono wrote: post #220

Earlier quoted context omitted.

A task should be something that can be done independently by one person. Sometimes you have a big chunk of work that's tightly coupled and can take months to implement, how do you best track that? In my experience what happens is one of three things: (a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of…

My 5 cents on this: - Usually, for large chunks of work, you want to bring in more people. Both because they tend to involve several modules or several layers of the stack, and very few people are equally skilled in every part of the codebase. But also because there will most probably be design decisions and tradeoffs along the way to discuss. Coordinate who is working on which parts of the codebase at any given time…

Oh for sure, I'm not saying not to involve other people, just that the actual implementation for some things is most efficient if it falls to one person.

Re: You don’t need standups

#286

Post by BigJono »

gav wrote: post #253
BigJono wrote: post #220

Earlier quoted context omitted.

A task should be something that can be done independently by one person. Sometimes you have a big chunk of work that's tightly coupled and can take months to implement, how do you best track that? In my experience what happens is one of three things: (a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of…

I struggle to think of an example where I'd ever let somebody go off and work on something for months. I can't think of how they would be successful, let alone take on the risk that they quit or get hit by a bus and nobody can continue the work.

It really depends on what kind of software you're building. A large new CRUD feature (which is what most of us are building 95% of the time) can easily be split among many people. But a complex data visualisation, or a novel algorithm, can easily take a month or two and isn't easily split amongst the team, even if you have multiple members with the expertise to implement it.

EDIT: Also, just because someone is working on a siloed task doesn't mean that nobody else can pick up where they left off. For that to be true you have to assume they document nothing and code like an idiot (which is unfortunately probably pretty common).

Re: You don’t need standups

#287

Post by isbvhodnvemrwvn »

Shaanie wrote: post #137
leggomylibro wrote: post #59

Earlier quoted context omitted.

It works very poorly in practice, in my experience. You interrupt people 2-4 hours into their work, which is highly disruptive for those who get the most done in the morning. Often discussions run on past many peoples' lunch time, which can make people cranky and occasionally leads to tense exchanges which might have been more amicable if people weren't hangry. You wind up with people melding the work they did during…

If you're not keeping the daily scrum shorter than 15 minutes then that's in and of itself a problem that will make people annoyed and disrupted.

The problem probably isn't the time the meeting takes, it's the subsequent discussions about various things brought up during the meeting.

Re: You don’t need standups

#288

Post by isbvhodnvemrwvn »

BigJono wrote: post #286
gav wrote: post #253

Earlier quoted context omitted.

I struggle to think of an example where I'd ever let somebody go off and work on something for months. I can't think of how they would be successful, let alone take on the risk that they quit or get hit by a bus and nobody can continue the work.

It really depends on what kind of software you're building. A large new CRUD feature (which is what most of us are building 95% of the time) can easily be split among many people. But a complex data visualisation, or a novel algorithm, can easily take a month or two and isn't easily split amongst the team, even if you have multiple members with the expertise to implement it. EDIT: Also, just because someone is workin…

This type of work is highly atypical. All the scrum ceremonies were designed around fast feedback, if you can't fit it into the work you do then using anything agile-related is not going to work.

Re: You don’t need standups

#289

Post by JDiculous »

vfc1 wrote: 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…

Best description of standup I've ever seen. One of the many reasons I left corporate tech.

Re: You don’t need standups

#290

Post by JJMcJ »

ravenstine wrote: post #28

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…

Some standups the boss gives off an unpleasant vibe than nothing should ever take more than a day.

Get stuck on something for a few days, and it feels like it's time for a new job.

Post reply on HN