[stickfigure]

This is unnecessarily cynical.

I did a couple consulting stints at Pivotal, working on the CF team. They have a very particular methodology that evolved from the earliest days of agile (Rob Mee was a friend of Kent Beck back when XP was being worked out). I walked in there as a very experienced engineer and a healthy amount of skepticism... and it turned out to be a fantastic learning experience. I've since taken the Pivotal process (yeah, even the weird stuff like pair programming) and used it effectively to manage subsequent companies.

I don't love everything about Pivotal (neither Ruby nor Go make my favorite-languages list) but then, not everyone at Pivotal does either. But overall they do agile right, and they have a lot to show for it. You can mock 9:06 but also note that people go home at 6pm and have lives. The schedule has its upsides.

[sheepmullet]

> This is unnecessarily cynical.

I think it's pretty clear that these strict agile processes work well for some and poorly for others - some people do better in a highly structured environment and others do worse - it's a bit like remote work on the other end of the spectrum.

The criticism and pushback comes from the negative experiences devs have had when management pushes a one-size-fits-all approach.

I've been involved in more than 5 failed agile methodology process improvement initiatives. I've seen great engineers reduced to a tiny fraction of their former productivity and seen other "hopeless" engineers get a lot better.

[cbryan]

It's a great process for reigning in "great" engineers that produce a ton of technical debt. It's a fantastic approach for making your engineering team more stable and product delivery more predictable.

[sheepmullet]

> It's a great process for reigning in "great" engineers that produce a ton of technical debt

So any positives can safely be attributed to the new process and any negatives are clearly just the new process shining a light on existing problems.

Gotcha.

And the parent poster was wondering why people were so cynical.

> making your engineering team more stable

Can you expand upon what you mean by more stable?

One of the main selling points to management is it becomes much easier to switch developers between teams.

> product delivery more predictable.

In what sense? And through what mechanism?

It does reduce risk on short term deliverables but that's a very narrow interpretation of predictable.

It's certainly not the case as an external customer - trying to nail down an xp team to a fixed deadline more than a few weeks away is an exercise in frustration.

[subway]

It's a killer process for churning out mediocre cogs.

[XR0CSWV3h3kZWg]

Could you elaborate?

[subway]

Much of the process revolves around trying to ensure everyone on the team can tackle any problem in any part of the codebase. This is accomplished by doing all work paired, rotating pairs daily. Similarly the consultants assigned to your team are regularly rotated in and out to different projects during your engagement.

Specialization is highly discouraged, so the result is a mix of people who can kinda accomplish most things eventually, and a rush to find external resources when you need even moderately specialized knowledge about components in your stack.

[rexpop]

Outside of your oddly combative use of the term cog, this is an accurate portrayal of an integral aspect of their process: distributing knowledge, capability, and reasponsbility across the team.

I am no capitalism apologist. The interoperability of technicians diminishes our marketplace bargaining power, thus diminishing labor's leverage over management/capital. At this point in my life, I have accepted this trade-off in exchange for 1) mutual code-review, 2) nights off on-call, 3) opportunities to learn new tech, 4) a product roadmap that can be prioritized without a freaking gant-chart to slot e.g. language-dependent work into language-adherent technicians' backlogs.

While these and other factors make my role less stressful, and my team more effective, I do concede that knowledge dissemination diminishes tech workers' bargaining power.

[odonnellryan]

Seems to be really successful, though, no?

I'm not defending them, but I know I'd love for my shop -- we do the same things as them -- to grow in this way.

[subway]

As a commercial venture, absolutely. There will always be folks willing to buy the dream they sell.

[odonnellryan]

You don't think they bring value with the work they do itself? Just hype?

[XR0CSWV3h3kZWg]

So specialization is a precondition for non-cogs?

[subway]

Considering the idea I was trying to convey with the word "cog" was "trivially replaced by any of the dozen others we have laying around"... yeah, at least a minimal level of specialization is a "precondition for non-cogs".