[fxtentacle]

I remember we had a discussion about 10x developers a while ago and how some developers are perceived as moody divas.

My guess would be that the 10x-ers have are independent enough from any given employer that they can reject Scrum even if everyone else has to follow it. And later on, their ability to work on their own terms is what then makes them 10x more productive than the poor scrummers.

[js8]

I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day.

In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up, geared towards working the problem, but no, I have talk and listen about something unrelated. It's like going to a movie and having to suffer the trailers for other movies first.

(There was also this funny psychological research that showed that when you tell someone you will do something, you're less likely (less motivated) to do it. Not sure if true, but if it is then standups alone have caused billions of loses in productivity.)

In any case, I think the discussion about individual productivity is somewhat sidetracking the core issues. What I wrote applies to the whole team as well. In my experience, the best design decisions come from individuals working alone, understanding the problem, and then these design decisions are vetted (and possibly changed) by everyone in an open discussion. This cycle can happen on almost any timescale, depending on the nature of the problem. So one doesn't need to be in an ivory tower for this to work.

Timeboxing as such is not a bad idea. But I think conflating it with "being done" is just wrong.

[toomanybeersies]

Some standups, I feel like I'm back in primary school doing show and tell, as I get regaled with tales of whatever meeting someone had (even better when several people feel the need to bring up the meeting that literally the whole team attended), or their progress on a completely unrelated project/feature which may as well have been what they had for dinner last night, for all relevance it has to me.

They do have their benefits though, especially when well run. A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.

I suppose that most of those things could just be done as a slack message. Sometimes I feel like a meeting helps ideas flow better though. There's been occasions where having an actual verbal conversation with the team has yielded better results than a slack conversation would've.

Either way, I've never had a huge issue with them, as long as standup is the start of my working day and not like 10 AM or something where I'm going to get interrupted.

[eindiran]

> A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.

IME this has been the biggest boon of standups. If they are kept short, and further conversation is done outside the meeting, they are a good way of matching your problems to other people on your team who may have a solution.

> Sometimes I feel like a meeting helps ideas flow better though.

I generally prefer when protracted conversation/problem solving is taken up between the concerned parties after the meeting, as otherwise the meeting drags on for everyone else who doesn't really need to know about your particular issue. But I do definitely agree with your assessment that "actual verbal conversation[s]" are better for me with regard to figuring a problem out.

[irrational]

> and then these design decisions are vetted (and possibly changed) by everyone in an open discussion

But don’t you dare try to have an open discussion at a stand up meeting. The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Honestly, that just kills the flow of communication. I have never scheduled a separate meeting to continue the discussion. We just end standup, go back to our desks, and don’t talk to anyone.

[mindcrime]

The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it.

Have you considered that if this didn't happen, it would be one of your co-workers on this thread, instead of you, and they'd be complaining that:

"Our scrum standups are supposed to be 15 minutes long, but they always take an hour or more, because people start going down some rabbit hole that doesn't concern half the team, and the scrum master won't politely interrupt and ask them to schedule a separate meeting. So much time has been wasted by this that it's unbelievable."

I have never scheduled a separate meeting to continue the discussion.

Why not?

[username90]

If a useful discussion happens during a standup the people discussing can just leave and let the others continue the standup without them. There is no point in being strict with these things.

[mindcrime]

Agreed. I was just curious about why, specifically, the parent poster never schedules follow-ups. If the discussion in question was actually valuable, it seems like they would want to pick it up later (or use your approach of just forking off immediately. I look at those two things are being approximately equivalent).

[cutemonster]

> can just leave and let the others continue

That can be hard -- many / some people would be worried it'd be impolite to leave and in a way say "the things you're talking about aren't interesting to me".

And they'll stay and feel frustrated, in silence.

[seer]

That sounds overly harsh. What we do in our team is "postpone" those discussions. When people have went through their updates, anyone who wants to stay is free to do so and can continue that discussion, usually in the same channel. This way you're not forcing people who _don't_ want to listen to that discussion to sit through it twiddling their thumbs - best of both worlds :).

[geochronology]

This. When I structured the standups for our own team, I budgeted 15 minutes for updates and 15 minutes for open conversation.

The result has worked almost exactly as intended: there's breathing room to discuss issues or ideas that come up in the course of conversation, but discipline around keeping those conversations brief enough to stay on the rails.

IMO at previous companies getting told "this isn't the time for that discussion" really frustrated me. As the OP stated, these conversations never happened, and it's healthier to allow some time and space for people to talk off-script when they're all meeting together.

[KSteffensen]

Would moving the standup to sometime where you are naturally interrupted, e.g. just before or after lunch, work better for you or is it the nature of the standup itself that's the problem?

[jariel]

1) Communicating is part of the job 2) Don't think about it in terms of 'failure'. You're just doing work. Sometimes the route is direct, sometimes it's not. 3) 'Time boxing' really has to be done, because products are not made in a vacuum. Time is money and it's a huge constraint. So everything really does have to be boxed up and parameterized by 'time' in the most reasonable means possible that doesn't screw everything up.

[brailsafe]

1) They were disputing scrums, not necessarily communication. 2) It's hard to not think of something as failure, if it's treated as failure, which is often the case. This is like telling someone who's being mistreated in a relationship to not think of it as abuse, just think of it as your way of life. 3) Time boxing may be important if a number of different types of schedule conflicts may arise, but I think it can place an undue importance on the measurability of how something gets done, often at the cost of it actually getting done well.

[jariel]

1) Scrums are literally communicating. 2) Just because someone feels there is a failure does not mean other people perceive it that way. If you describe it as a step towards the finish, then it is. 3) Time-boxing is inevitable. If there is a side-step due to some other issue, then you describe why the time boxes must be moved.

[WalterBright]

You just gotta trust that your top guys know what they're doing and let them do it.

It's how Lockheed let Kelly Johnson run the Skunkworks however he wanted to. Johnson delivered the impossible again and again, and Lockheed was smart enough to not interfere.

[ckastner]

I'm not entirely convinced that Johnson's example generalizes well. He might just represent an instance of survivorship bias.

Some people can be brilliant at something while at the same time being toxic, with the toxicity ultimately winning. Kalanick at Uber might be an example.

[WalterBright]

Lots of companies have tried to establish a skunkworks, but with "improvements". None have done particularly well. (The "improvements" were taking away the autonomy of the skunkworks.)

https://en.wikipedia.org/wiki/Skunkworks_project

[meheleventyone]

I've also seen it fail the other way where the Skunkworks becomes the preserve of "high achievers" not producing a lot that's useful. Almost every 'Office of the CTO' I've seen has suffered that failure mode. Lot's of things get built but none are more than fluffy experiments and there's no path to actually putting any of those things into production. Once in a while they'll be forced through and the production team has to spend a lot of effort fixing and making the project actually work.

[ricardobeat]

Isn't that just a lack of clear goals? Skunkworks had extremely ambitious deliverables and was not a science lab, even though they helped develop a lot of new technology.

[meheleventyone]

I think that's a part of it but there's also the question of how they interface with everyone else. IME a lot of these teams end up working in isolation from everyone else. And the patronage of the team usually makes them somewhat untouchable or unquestionable.

[ckastner]

I'm not arguing against the autonomy part, on the contrary: I join you in arguing in favor of it, and also that such an autonomy requires a brilliant personality at the head of it.

However, while the combination of autonomy and brilliant personality might be a prerequisite of outstanding success, I'm not yet convinced that it's an overwhelming indicator of it. I believe that a brilliant but toxic personality with autonomy can lead to an ultimately fatal instability.

[C1sc0cat]

Which is not orthogonal from SCRUM done well

[toomanybeersies]

I definitely fit into the "moody diva 10x developer"

I've given up trying to estimate how long a task will take and more or less just pick an arbitrary (usually comfortably large) number of points.

The thing is, it isn't even about estimating the scope of work, which is often unknown until it's complete, especially if I'm battling technical debt. A given task might take me an afternoon on a good day, or half a week on a bad week. Case in point, I got more work done on Monday than all of last week. That's the joy of having ADHD I suppose.

At least my manager is very understanding, and recognises that on a macro scale I get a lot of high quality work done. I think that's the key to being a good manager, understanding that your subordinates have different working styles and managing them with that in mind. I'm sure there are "10x developers" out there who work in a more consistent manner, or benefit from more hands-on management than I do.