Highly talented developers don't need this structure and process, but if given the freedom, they are also more likely to create software that only they understand, using flavor-of-the-month languages or frameworks that they have personally selected. When their work is done and they move on, nobody else can figure out what they have done or why.

I think what you're describing is average to slightly above average developers who are working on boring, already solved problems. So they have to find something to make it more interesting.

Always some cool new framework (or even better, one developed just for this situation because its fun). All of them, no exception, loved exploring another framework du jour (and java has/had tons of those) for each project. None of them were 'finishers' - ideal for them would be prototype something quickly, and then move on, daily project grind was universally hated.

Few had to be treated like babies by managers - finding new topics hey can play with to maximize contribution to the project (which often paid off, ie once we got 10x throughput increase compared to default ActiveMQ installation, the guy did some proper debugging/perf testing only possible due to open source nature of the product... brilliant guy, but hardly a team player, complicated personality).

I've met plenty of senior devs that stick to target and idolize maintainability.

No point in insisting that your anecdotal evidence is universal (by asserting "you're incorrect").

Obviously claiming extremes is always wrong. But I'd still wager that most people who are indeed senior devs -- myself included -- are long past the "let's try this new thing because reasons!" thing.

I think you might be using a slightly incomplete definition of “highly talented.” My highly talented colleagues take maintainability and minimizing tech debt into account when making technical contributions.

I'm also an excellent "team player." I worked for a Japanese corporation for almost 27 years, and you don't last long at Japanese companies, if you don't "team" well.

But I also don't shy from using advanced techniques; usually in language idioms, as opposed to ungrokkable algorithms. Most of my algorithms are fairly basic. I tend to go after difficult problems, though, and it's ... difficult ... to solve difficult problems, simply. Sometimes, I have beautiful, low-code solutions, sometimes, I have solutions that would send Rube Goldberg into fits.

They all work, though; and they ship.

I expect the folks that maintain my code (usually Yours Troolie) to be at a level similar to mine, and I won't "dumb down" my code, so someone fresh out of a JS bootcamp can understand it. I have an insane level of documentation, and supporting artifacts. If someone is able to understand the code, they will get a lot of help.

I'm militant about Quality. My code needs to work well, be performant, be flexible, and to have clear, unambiguous boundaries. A great deal of my work consists of reusable, standalone packages (I use them heavily, in my projects; Most of my dependencies are ones that I wrote). This affords an intense level of Quality. It's abstraction with teeth.

I'm used to owning the entire project lifecycle, from napkin sketch, to shrinkwrap. This gives me a great deal of insight into what is necessary for "the long game," without getting caught up in "bikeshedding."

My experience is that most companies that I've encountered, don't want people like me, working for them, so you get what you get.

IMHE, not so much. You can't tell which code they wrote, except it's easy to read, and there's a lot of it. The loudmouths, they write inscrutable, flavour-of-the-month code. The talented coders aren't as bothered by this as much as everyone else is.

Micromanagement processes and resume driven development are both problems but they are very different problems. IME good developers aren't going to be the ones pushing for all the shiny new toys all the time and writing inscrutable code. Good developers value stability and simplicity and they choose tools that help to get the job done. Good developers also write code that is relatively easy to understand.

The kind of developer you're talking about above isn't highly talented. In fact they're exactly the kind of dangerous mediocre developer that many of these overly controlled development processes evolved to contain. But the best ways to deal with them still aren't micromanagement. You can either teach them to be better (if they have a positive attitude but don't yet understand why what they're doing is often a bad idea) or fire/not hire them (if they're the mercenary type who only wants to exploit your salary payments until they can boost their resume at your expense and jump to exploiting someone else for bigger salary payments).

Instead, most companies incentivize this very behavior. I wouldn't call them "mediocre developers" when they are playing the hiring meta game correctly, even if it leaves a wake of destruction behind.

In true Scrum spirit, the team that has problems with lack of documentation, should figure that out from (1) retrospective, and start (2) including that work in Sprint explicitly, and (3) to explain to business owner that without these tasks, features are gonna get delivered 3x slower.

Benefits: documentation/testing will be explicitly required as a requirement, time will be allocated and accounted for, business and stakeholders will be aligned on that.

This doesn't happen because scrum leaders never care enough about the product, but at places where they do care it is well documented and structured

I'll often write the documentation before the functionality. When I'm done, I run Jazzy, and I have an indexed, navigable, relevant, up-to-date document set. I point GH Pages at it, and voila! You have a well-documented codebase.

It also encourages brevity and keeps the focus local.

[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/

Indeed. But in most real world cases, this is because they’ve internalized good process and shaken off the categorical constraints that more junior or less disciplined developers still need to rely on.

While the archetype of the idiosyncratic graybeard poring out inscrutable, magical code has exemplars, it’s not the norm that many of us see when we look around.

During periods where software engineering becomes more collaborative and corporatized (as we’re in now), it’s hard for these types to find a home. Yet there are hundreds of organizations stocked with many highly talented developers doing “good” work well.

The type of person you're describing I have run into a few times but usually they are not considered highly talented at FAANG, more like the type of person to quickly hit career wall because they overly focus on coding instead of business objectives.

I couldn’t disagree more strongly. My experience is that scrum teaches junior devs bad Han it’s around blame shifting, focuses them on process, prevents them from learning about the business, and bogs them down in meetings that don’t help them learn.

> or teams at companies with poor culture

I would argue that scrum ossifies bad culture. It has a habit of giving bad leaders metrics around things they shouldn’t be measuring.

There’s a lot of software engineering research about processes and the case in the literature for scrum is very weak.

I’d argue that spending time on activities like scrum poker or sprint planning are actively harmful for most kinds of teams. The points games are inherently adversarial, only add value for scrum masters, and waste time that could be spent understanding requirements/business problems better. The incentives are inherently perverse and the whole exercise encourages and rewards dishonesty.

As far as no true Scotsman, I didn’t mean it like that—I don’t care if people don’t want to use scrum, but I do take light exception when people shit on it an go on to describe a process that is alien to me. Though I guess what my teen was doing was a bit more of a mix of scrum and XP.

That seems to be the exception rather than the rule in my head experience. Even still, what concrete value comes from assigning fairly arbitrary effort estimates in this fashion?

> but I do take light exception when people shit on it an go on to describe a process that is alien to me

Respectfully, I’ve seen a bunch of scrum implementations and attempts in that direction and they have a lot of overlapping pathologies. I’ve also gone to the source material. IMHO scrum simply wastes time on meetings that give a false sense of visibility and create a lot of negative incentives. For those costs, I’ve never seen a return that was worth the trade off.

It sounds very much like you were doing some flavor of XP with a few scrum meetings sprinkled in. This isn’t the process scrum evangelists and consultants are pushing. But I’d still argue that most story pointing meetings are wasteful.

When devs overestimate they then tend to take the extra time to overengineer the solution, and when they underestimate they tend to take on technical debt to make the very arbitrary deadline.

This sounds counter-intuitive, but I’ve found in many teams the value of story pointing is to instigate healthy conversations about requirements and surface assumptions in a team that might be reticent to engage in those kinds of conversations naturally. The actual point values are probably the least important outcome - any inaccuracies tend to average out over time anyway.

I’ve gone in to many teams in my career where “planning” amounts to 1-liner tickets describing a month’s worth of work, and the team has a few dozen of these in the backlog. Conversations about what is actually involved in delivery don’t happen, and execution is chaotic because everyone has a different understanding about what we’re building.

This sounds like a dysfunctional team because it is. A surprising number of teams are dysfunctional, and many of these frameworks and tools come out of attempts to solve for dysfunction.

In these teams trust and morale tends to be low. The abstraction of story points (and associating them with complexity, not time) opens the door to having conversations about what the work actually is rather than how long everyone will take to do it.

It’s a lot easier to hear “why do you think this is a 5-pointer instead of a 3-pointer” instead of “why do you think this will take 5 weeks, I think it should only take 3.”

Scrum isn’t a universally-applicable tool, and introducing story points without also leveraging their ability to stimulate conversations about the work is a waste of time, but applied well they can help break through to teams that aren’t ready (or don’t have the muscle memory,) to have these conversations without some kind of trigger.

I actually don’t disagree that story-pointing feels like a waste of time, but I do find it useful to talk about what’s involved in a task and figure out how long is might take. I don’t think it’s unreasonable for management to want a rough idea of when something will be delivered, mostly so that they are able to plan themselves. Of course, it all depends on endless variables as to how much process a company needs. In larger companies with multiple teams, I strongly believe in self-organizing teams with a well-defined point of contact and freedom to implement as much or as little process as they want.

Edited to fix horrendous typo as a result of typing on my phone. I likely didn’t catch them all.

My team asked for this. I dont know why they need it but apparently it helps them understand how much work theyre agreeing (and committing to shipping) in a sprint.

I think if you have a good grasp on what each issue will entail, you dont really need it but if youre less experienced maybe it helps?

Similar to misses, we don't really get much from shipping on that cadence either, other than progress and building confidence in upper management to base their timelines on us delivering what we expect.

(that convo can be had on slack, btw, just like standups.)

the problem is "scrum masters" waiting to refine/reject stories during refinement (or not refining at all), or engineers not updating their cards frequently enough, or nobody guarding the backlog and allowing anyone to dump stuff into it. when these things happen, you get three-hour-plus-long sprint planning that wastes everyone's time

the other thing I absolutely hate are capital-r-Retros. retros are supposed to be the meeting that everyone looks forward to, but they often get skipped because it's an hour of people sharing platitudes because the room isn't safe enough to REALLY say what you feel. if i ran retros, they would be at a nearby pub or chill restaurant, over beverages and food, with no real structure other than "at some point we should talk about how this week went."

Otherwise (and I’m forgetting which thread I’m in here so maybe repeating myself), I have experienced incredibly valuable retros. They were structured but still fun.

And very much agree with the first paragraph. I also agree it could just be done on Slack, but I personally like having a daily meeting where I get to see my team all together… so long as that meeting is short (max 5 mins on a good day).

That doesn’t mean that you don’t have a process at all. You might have once or twice a week sync meetings, and a biweekly planing meeting.

But scrum as it is traditionally thought (Daily stand ups, scrum master, agile coach) and all that hoopla is thought to be out of date.

If a company is spending 500k for an engineer the last thing they want is pointless meetings wasting their time, or have a non technical lower level agile coach try to dictate things (which I have seen it happen).

At that level the expectation is that the engineer is mature and will know how to unblock themselves and doesn’t need infantile hand holding.

These companies won’t succeed if they try to act like they’re working with mature engineers, because they’re usually not.

Skills like knowing how to unblock yourself, how to identify systemic problems in a team and correct them don’t come naturally to a lot of people.

If you’re not encountering teams like this I’m happy for you, but lower-performing teams often benefit by adopting a rigid methodology to kick-start the process of self-improvement.

In an ideal world, they further transform their working style into something that works for them by reflecting on their experience on a regular basis.

That said, every agile process needs to be treated for what it is; maybe a decent starting place, and probably a collection of good ideas for the context it grew out of, but not directly transferable; the whole point of a retro (the one meeting that the agile manifesto actually stipulates) is to modify the process for the team.

Imo in bigger stand-ups, there's more pressure to sort of "show off", which means talking more, and combined with having more people there already it takes forever and is really painful.

But if it's just a handful of people who work together saying a couple sentences each on average, unless they're blocked or something interesting happened, it's fine.

And I actively dislike / don't understand the value of that sort of ritual...

I think this is just like the remote vs. in-person thing; it's mostly a personality trait. I don't have the "daily team ritual" gene, but others do, and that's ok.

But I'd urge you to reread your post and consider that it comes across as presumptuous, myopic, and holier-than-thou.

Those are just low-immunity weakened places that Scrum is able to infect.

https://github.com/rayfrankenstein/AITOW/blob/master/README....

“a Michelin-starred restaurant doesn’t have laminated recipes on the kitchen wall. A McDonalds does. Both of these are a good thing, depending on who you’re working with and what you’re trying to achieve”

Here's the problem though: how to you hire for a "McDonalds". It seems good to be self aware about whether you're running a McDonalds or a Michelin star restaurant, but can you be honest about that with candidates and still hire people?

He always argued with the regional manager about it during store inspections. But since this McDonald's made a lot of money, and everyone was actually preparing the food correctly, the store manager generally got his way.

Scrum masters — backlog / kanban board groomers — are for junior devs, who haven’t yet developed any sense for what an approachable task size is; what their comparative advantage is vs others on their team; etc. Senior devs do have that experience — and it’s surprisingly portable between teams/orgs.