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

91–100 of 341 posts

Re: You don’t need standups

#91

Post by kerbalspacepro »

some_account wrote: post #82
chomp wrote: 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…

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.

Re: You don’t need standups

#92

Post by Benjammer »

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…

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.

Re: You don’t need standups

#93

Post by Chyzwar »

some_account wrote: post #82
chomp wrote: 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…

Because you work in the team.

Re: You don’t need standups

#94

Post by s73v3r_ »

smileysteve wrote: post #61
DanielBMarkham wrote: post #31

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…

I famously got outraged at my team the day after our planning meetings + interviews the whole team was on. "Yesterday we had meetings" because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.

But they likely haven't actually started anything. I think that's the worst part about standups is they require everyone to get up and say something. If you've got nothing to say, then you end up saying idiotic stuff like "yesterday was meetings". (I do also think that having everyone take a turn at speaking is one of the good things about them, because otherwise it's really easy for one or two people to take the whole time talking about their thing, and a shyer person might not be able to get in a word that they otherwise really would have wanted/needed to.)

Re: You don’t need standups

#95

Post by DanielBMarkham »

Benjammer wrote: post #85
DanielBMarkham wrote: post #79

Earlier quoted context omitted.

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

Do you have any advice for someone in a senior IC role to actually get people setting the processes to shift their thinking from optimizing general metrics and making everything more homogenous, into a model where everything is contextualized (like your examples) and then we draw out higher-level patterns by analyzing the common traits that organically arise as a result of contextual solutions?

Ping me. I'm happy to provide any free advice I can over the phone as long as it has a chance of helping developers. HN isn't the place for this, however, as whatever I say is just going to open up a religious war. (Disclaimer: I am currently looking for new clients)

You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here.

There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up.

No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.

Re: You don’t need standups

#96

Post by s73v3r_ »

nherment wrote: post #22
jiveturkey wrote: post #15

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

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... :)

Complaining about swearing adds even less to the discussion.

Re: You don’t need standups

#97

Post by crazypyro »

kerbalspacepro wrote: post #91
some_account wrote: post #82

Earlier quoted context omitted.

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…

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.

I would disagree with almost every claim on this list.

Re: You don’t need standups

#98

Post by ben509 »

some_account wrote: post #82
chomp wrote: 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…

I'm not sure how much that micro-managing aspect is peculiar to agile and how much is just inherent to working on a team.

> It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.

That's absolutely the point of a team. Contrary to popular belief, a team is not a meritocracy[1], it's a mediocracy. The beautiful thing about a mediocracy is that it means that you can take vacation or quit and someone else can pick up your work. We have a pretty good gig that we can just chew through tickets, imbibing coffee and excreting code and poo.

Not everyone has that luxury. For many actors, their face needs to be in every episode, so they sign a contract with stiff penalties if they quit.

[1]: Engineering is meritocratic in the larger market; if you are better or worse than your team's medium, you find a better team where the medium is closer to your skill level.

Re: You don’t need standups

#100

Post by maxxxxx »

potatopolis wrote: post #56
maxxxxx wrote: post #11

Earlier quoted context omitted.

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.

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.

There isn't. Raising an issue without ever fixing it is very demotivating and causes a "fuck it" attitude.
Post reply on HN