3 ms·
I think the big divide here is between tech companies and non tech companies. Tech companies can look at the agile manifesto and use it as a heuristic guide, b
by habitue 5y ago
I think the big divide here is between tech companies and non tech companies.
Tech companies can look at the agile manifesto and use it as a heuristic guide, because engineers are already kind of on the same page about it. You don't need heavyweight process etc.
Non tech-companies need the window dressing of tech companies to retain their best engineers, but ultimately agile is kinda telling them to turn everything upside down and also threatening to make them superfluous. Nobody is really up for that.
So agile in non-tech companies is Kabuki theater and engenders cynicism, and agile in tech companies is basically superfluous "water is wet" advice no one even bothers to comment about.
You'll notice a lot of these blogs about how agile has failed are coming from consultants, who are basically brought into traditional companies that are struggling with some part of this process, not tech companies.
- pjmlp 5y agoYes, pretty much this.
- gonzo41 5y agoI totally agree, and I think another big reason Agile fails to cut through in companies is because anyone who wants to be Agile in a non tech company is fighting a crushing bureaucracy. So rather than innovating and climbing higher on innovation they leave due to the massive inertia that is encountered trying to change company culture.
- misil 5y agoThis very much resonates with my experience. I've seen this very process take place when working at a small tech startup that ended up being bought by a non-tech giant keen on undergoing a "digitalization" initiative. Our prior processes were lightweight, goal-oriented and effective. No one bothered calling them "agile", they were just the natural way to deal with an ever changing landscape of customer and system requirements. After the buy-out we were told to undergo a thorough transformation into this brand new unified top-down software development process the company had some consultants design for them. Complete with a baffling array of buzzword driven "agile" development practices and project/squad/team/chapter manager/lead/head roles to be filled. The more you kept inquiring what exactly those roles should entail, the more conflicting and vaguer the answers got until you realized that no one had the faintest idea how any of this was supposed to actually mesh together in practice. The license packages for the expensive project planning software we were to use where long paid however.