Probably not coincidentally, this was the only place I've worked where KPIs were truly a useful way of framing our place within the organization.
Product managers are often hired to be a cat's paw for an unsustainable and/or ineffective way of getting technical work done. This is what many businesses want when they hire into product, because this is a more convenient explanation for why things aren't better than any alternative (such as you're doing too much stuff, you're building the wrong things, etc.).
This selects for people with the skill and temperament to thrive in this role. Being a bullshit artist is a great fit. Being a pushover and repeating everything your stakeholders say is easy. Asking difficult questions and being a skeptic is hard and doesn't make you popular.
Now people get certifications in scrum dogma and claim we have to follow the one true way. Now it's entirely about managing people instead of about satisfying customers. That's why a bunch of folks left years ago to work on development as craft.
We can't say with a straight face that we expected IBM or Accenture like conpanies to move to an "agile" process.
And smal and/or smart conpanies were already doing "agile" without making manifesto and boasting it at every occasion. What's left is the middle ground wh
'll blindly follow any trend and get certifications to proudly have the buzzwords on their company site, and "agile" weren't for them either.
> managing people instead of about satisfying customers.
I wrote another article that somewhat alludes to this, it's linked at the start of this one. If I'm not helping people, either customers, or developers by making their jobs easier, then what exactly am I doing as a professional?
Author here, this was one of the motivations for writing this and the other article linked at the start. I've seen agile actively harming maintenance and quality more times than I've seen it ever help maintenance or quality.
You know things are fucked up when you need to put technical debt, refactors, library updates, etc down as "stories" (erm hello, where is the customer story in "fix that giant performance TODO") instead of just doing them. Sure, we can just carry them out to avoid the wrath of the scrum master and co, but then you have to balance time between doing the stories, and fixing bugs.
Has it changed? The Manifesto[1] is still there, unmodified, to provide thoughts on what you need to consider if you are going to run a software project without managers.
> Fuck user stories, fuck sprints, fuck Jira, and fuck product management
That does not sound like Aglie, especially given that you specifically call out managers, which are incongruent with Agile. The top-down organization where process flows down from management at the top to the developers at the bottom that you speak of is what is colloquially known as 'Waterfall'. This 'Waterfall' organization structure is what many believe the Manifesto was written to counteract, so it is interesting that you’re now calling it Agile.
Ah, but you could say, "That's not Agile's fault that people don't live up to it," but in a sense, it is, because Agile did not bother to anticipate that people would fall off of the path. Agile has no orthodoxy. Agile does not suggest punishment for bringing up deadlines. This has allowed people to pick-and-choose.
"Not living up to Agile" is one of its principals: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." That's not what we're talking about, though.
> Agile did not bother to anticipate that people would fall off of the path.
This isn't a case of falling off the path, it's a case of not even being on the same planet. Agile is written about the things you need to think about if developers don't have managers overseeing a project. The OP was talking about what managers are doing. They are at completely different ends of the spectrum.
If you want to use a religious analogy, this is like there being a religious leader preaching about God and a group of people who believe God doesn't exist. Logically, you wouldn't lump them together. They would be seen as distinct groups with opposing thoughts. Exactly how we treat this situation in a religious context: For example, Christianity and atheism.
So, in the corporate world, pretty much Agile==Scrumfall (and SAFe). Executive management wouldn't have seen any benefit to Agile otherwise. The only reason why companies adopt Agile is because of the fine-grained measurement and control promised by Agile consultants.
Now get back to work on the stories planned for this sprint. You have sprint commitments to meet, and others in the release train are depending on those deliverables.
- The Agile Prayer
Agile is more like a checklist of things to remember if you're going to operate without managers. Like, stay in touch with the business people, keep your work available for other developers to see, work with people who can be motivated without a manager hovering over them, etc. All obvious when you think about what role managers fill and what you need to do if they're gone, but still a decent reminder if you're serious about going down that road.
It's not something you do, rather something you can think about if you've decided managers aren't the right fit for your project.
But...Agile doesn't involve that. Even when the same words are used, they don't have the same meaning, often, and the substantive processes even within vaguely Scrum-ish methodologies vary widely.
There are exceptions, but in far too many companies AGILE has become a religion that slows the workforce down with high priests who insist that their ritualistic practices be followed and their tithes be paid =[
We should be fighting against the standardization of the industry because it allows more competition for wages.
On the other hand, damn near every company seems to only want to hire 'senior' developers who can deliver working software in spite of process, which I assume is somehow related to all the nonobvious process skills being commoditized.
I've started to form a belief[0] that large software projects in general are A Bad Idea. Whatever it is, if it requires more than a handful of people to build, it's probably for the greater good of everyone--the workers involved, the users, humanity in general, anyone-not-identifying-as-shareholders--that it not be done.
Software is the only thing I can think of where the input effort of creating it is completely divorced from the output work it can churn through. The right program at the right time, written in 10 minutes by just the right person, can save hundreds of years of otherwise manual labor.
There's a sort of sense that arithmetic got us out of the stone age, calculus fed the world, computer programming gave us the stars. That sort of power is far too important to imbue into corporations.
When you get a large group of people together, they start to think of themselves as Important. And when people think of themselves as Important, they start to think the work they do is Hard. And when they think the work they do is Hard, they start to think the software to help them do their work should be Complex. And none of it comes out of anything other than "we have a large group of people together."
Like, microkernel operating systems have a reputation for being slow based on early experiments with them from the 1980s. There are modern microkernel systems that are perfectly fast and efficient and yet people still think "monolith go brrrrrr" and not "all my software lives here" is the reason Linux is any good.
Like, I've seen people pitching blockchain-based solutions for municipal information and issue-reporting services, like anything beyond the most basic, not-completely-incompetent, traditional RDBMS is really necessary for such a project.
Like, there's a serious cohort of economists that think that the best way to handle social safety benefits is to just give them to everyone who asks, no questions asked, because otherwise the management of welfare benefits gets to be so expensive that it eclipses any potential savings against "fraud". And I'm inclined to believe them.
I see people talk about "there's no such thing as a 10x programmer". I think these people have been stuck in ossified institutions so long that they have no idea what it looks like to see a person fly. Cut away 90% of the currently employed software developers. Dissolve the Googles and Facebooks of the world. Don't replace them with anything. Leave us with the 10% of crafstpeople who can actually work through a problem on their own. And make them report directly to the C-suite. No more middle managers. No more grunt work of CRUD forms. If it can be done on paper than it's a waste of time to write software to do it.
[0] AKA this is a feeling, not something I've created a double-blind randomized trial to study, dear pedantic HN reader.
Setting aside the Linux kernel, this is how Unix itself works, and one of the reasons it was successful.
I don’t agree that we should shut down all the “1x” developers though. I think everyone deserves to love their work and people will excel when given the chance. But throwing them against a massive monolith that takes years to understand is dead certain to make them feel stupid and go slow.
Technical excellence doesn't pay the bills.
Curious - what products do you pay for due to their technical excellence of their backend instead of the value they provide you directly?
If the people who started the computing revolution last century knew that their descendants would be attending daily standups and debating "story points", they'd never have done it--in fact, they'd have blocked it from happening in the first place.