4 ms·

Same here. Well everything except retrospectives, which I think are generally wasteful or better done in small pieces. Was afraid I wouldn't see something abo

by axaxs 6y ago

Same here. Well everything except retrospectives, which I think are generally wasteful or better done in small pieces. Was afraid I wouldn't see something about overdoing microservices, but I think the monolith line covers it enough.

eyelidlessness 6y ago
Retros should be like recall elections: always available, never scheduled, with a high but achievable barrier to entry and specific veto principles both ways. The point of a retrospective is "something big happened and we should learn and adapt". They shouldn't be routine, because most weeks/sprints, nothing that big happened (or something that big happened too frequently/urgently to wait for a calendar). They shouldn't be too hard to trigger, or you're never going to get one (or results from one). The best process for this is "shit goes down and you should make appropriate dedicated space for it". Edit to add: I want to emphatically contradict my metaphor in one way, which is that retros should be exactly the opposite of a recall election in terms of identifying/naming/assigning fault. They should be about identifying good/bad outcomes and good/bad patterns, but not about pointing fingers at or casting aspersions on people.
- pseudalopex 6y ago
  It shouldn't take something big to reflect on what went well and what didn't. Or suggest a change.
  - axaxs 6y ago
    Most teams are silo'd like it or not. A backend guy or two, a frontend guy or two, layers of management, product, qa, ops people. If I'm a backend person, I'll talk to the backend guy person if we messed up. If the frontend guys are lamenting among themselves, I find myself not really caring and time being wasted. There's zero reason that teamwide changes can't be proposed for discussion via email or slack.
    - arbalist 6y ago
      It doesn't take domain knowledge to take responsibility for improvement. If your retros are taken up by lamentation maybe you should try to bring more focus.
    - pseudalopex 6y ago
      Lots of companies have teams for back end, front end, ops, etc. Slack is a good way for things to get lost in the noise or decided by whoever is in the channel at the time. Email doesn't have those problems but discussions can stretch out over days. And people speak more freely when there isn't a written record.
  - eyelidlessness 6y ago
    You’re right it shouldn’t. Those don’t need a recall election. Just a normal one. Elections should be like sprints too.
- kenhwang 6y ago
  We have an retro automatically if we have a production outage. This doesn't mean its an everyone must attend in-person meeting. Most of the time its just a writeup. Otherwise, a lead or multiple senior engineers just exercises their judgement on when something serious enough happened that the team needs to be aware of or act on.
ncann 6y ago
Agree about retrospectives. It's such a waste of time. Most of the time it's just there so that the scrum master can show off their new game and try to justify their usefulness.

by axaxs 6y ago

eyelidlessness 6y ago

Retros should be like recall elections: always available, never scheduled, with a high but achievable barrier to entry and specific veto principles both ways. The point of a retrospective is "something big happened and we should learn and adapt". They shouldn't be routine, because most weeks/sprints, nothing that big happened (or something that big happened too frequently/urgently to wait for a calendar). They shouldn't be too hard to trigger, or you're never going to get one (or results from one). The best process for this is "shit goes down and you should make appropriate dedicated space for it". Edit to add: I want to emphatically contradict my metaphor in one way, which is that retros should be exactly the opposite of a recall election in terms of identifying/naming/assigning fault. They should be about identifying good/bad outcomes and good/bad patterns, but not about pointing fingers at or casting aspersions on people.

pseudalopex 6y ago
It shouldn't take something big to reflect on what went well and what didn't. Or suggest a change.
- axaxs 6y ago
  Most teams are silo'd like it or not. A backend guy or two, a frontend guy or two, layers of management, product, qa, ops people. If I'm a backend person, I'll talk to the backend guy person if we messed up. If the frontend guys are lamenting among themselves, I find myself not really caring and time being wasted. There's zero reason that teamwide changes can't be proposed for discussion via email or slack.
  - arbalist 6y ago
    It doesn't take domain knowledge to take responsibility for improvement. If your retros are taken up by lamentation maybe you should try to bring more focus.
  - pseudalopex 6y ago
    Lots of companies have teams for back end, front end, ops, etc. Slack is a good way for things to get lost in the noise or decided by whoever is in the channel at the time. Email doesn't have those problems but discussions can stretch out over days. And people speak more freely when there isn't a written record.
- eyelidlessness 6y ago
  You’re right it shouldn’t. Those don’t need a recall election. Just a normal one. Elections should be like sprints too.
kenhwang 6y ago
We have an retro automatically if we have a production outage. This doesn't mean its an everyone must attend in-person meeting. Most of the time its just a writeup. Otherwise, a lead or multiple senior engineers just exercises their judgement on when something serious enough happened that the team needs to be aware of or act on.

ncann 6y ago

Agree about retrospectives. It's such a waste of time. Most of the time it's just there so that the scrum master can show off their new game and try to justify their usefulness.