4 ms·
Agile was always about selling training courses, books, certifications and what not. They managed to sell this by telling the business it would let the dev tea
by mdgrech23 3y ago
Agile was always about selling training courses, books, certifications and what not. They managed to sell this by telling the business it would let the dev team move faster/need less people/save money. After years people are not finally realizing this sales pitch never came to fruition.
- siva7 3y agoDelivering faster was never the promise of Agile. It also can't turn a shit team into an agile team. But it certainly empowers a solid team to deliver what business needs while moving faster.
- BarryMilo 3y agoAgile is better than nothing, which is what most teams would/did have as an alternative.
- __pache__ 3y agoHuh? Why don't lots of successful open source softwares run on agile, then? Pretty sure having motivated people who find the work kinda fun destroys agile/any other methodology. When people wake up excited to pull down tickets or just get shit done, you're doing business right.
- azangru 3y ago> Huh? Why don't lots of successful open source softwares run on agile, then? What open-source projects in particular do you have in mind? And what do they run on, exactly? And what would this model look like if transplanted into a business setting? I can see some aspects of agile project management in open-source projects. One, transparency/visibility. Two, working software over documentation. Three, customer feedback. In fact, some large open-source projects have introduced channels for early interactions with customers (i.e. developers) — for example, the RFCs initiatives of React or Lit, or community engagement in various html or css work groups. I do not know how well developers on open-source projects coordinate/communicate between each other. Or how work gets prioritised. I've certainly seen a fair number of failures in that aspect of open-source projects.
- __pache__ 3y agoAny open source project? Typically people work on what they care about or what is obviously needed. Go with that flow instead of against it. Hire people eager to contribute. Everything else seems incidental
- BarryMilo 3y agoWe could get into a semantic argument about what "lots" means. But open source is very much a corporate thing now, and lots of dev companies do indeed have an agile-inspired workflow at least. Re: that fun thing, yes, but most projects aren't fun on a daily basis. In any case, what I originally meant was that agile is not perfect, but if you've seen startups who don't know any development workflow (ie neither agile nor cascade), software dev grinds to a halt really quickly as they try to reinvent an entire field of management.
- __pache__ 3y agoDisagree, I guess. Agile is worse than nothing. Treat it like a normal job. Often no "management" is needed. Get done what you can, talk to you tomorrow.
- Silhouette 3y agoTeams of good people have always been agile in the truest sense - they will find a way to organise themselves to collectively get the job done. They don't need to be "empowered" by some rigid Agile process to do that. In fact it will most likely get in the way. Agile (capital A) processes have always been trying to sell the idea that a mediocre team can be elevated if they have the right process to guide them. Whether that actually works when the team isn't good enough to self-organise anyway is debatable but that's the sales pitch.
- azangru 3y ago> Teams of good people have always been agile in the truest sense - they will find a way to organise themselves to collectively get the job done. The word "good" here is very vague :-) People can be well-intentioned ("good"), but disorganized, unskilled, or wishful-thinking. People can be strong programmers ("good"), but work by themselves, without coordinating with others. People can be good, yet have managers micromanaging them. People can be good, yet required to work on different projects at once, which breaks focus. People can be good, yet separated from the customers of stakeholders by a layer of managers. People can be good, but required to analyze and estimate the project before even starting working on it, and then be held accountable for their estimate when they run over time. And so on, and so forth.
- seadan83 3y agoThe first agile manifesto people were largely consultants who realized that initial requirements are often bloated and not quite right. Instead it is better to work with a client to gradually develop their ideas and to work with them for that. The cottage industry came out of that pretty quickly and development process often turned into some manager or PM using the first Google result about SDLC. I somewhat agree overall, but the origin story and the context that the original agile manifesto people were consultants I think is an important context