Everyone claims they are following “agile methods” but few do (2018)
1–10 of 118 posts
Re: Everyone claims they are following “agile methods” but few do (2018)
#2A common point of contention is that agile is a list of philosophical guidelines, not a hard-and-fast framework for how to do things. A "true agile" shop should be periodically reviewing and updating their processes in the light of what makes the most sense. If, however, "being agile" is an organizational checkbox then some form of generally accepted agile methodology will be implemented whether it is the best fit for the company, whether the teams truly understand it, and without a built-in plan to reflect and decide if they are even doing agile right or if it's actually benefiting the organization.
Re: Everyone claims they are following “agile methods” but few do (2018)
#3> Middle managers can also miss the importance of co-locating teams by bringing together designers, engineers, product managers and content specialists in the same physical space. The most highly functioning agile teams aren’t just at the same location or on the same floor: they share the same table.
I can't refute this strongly enough. Managers should do their jobs and manage. Doesn't matter where team members are located.
Anyway, this agile nonsense gets too much air time. We got it: highly iterative feedback loop development.
Re: Everyone claims they are following “agile methods” but few do (2018)
#4This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy.
Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier.
Standups can take different shapes, the 'V' in MVP differs wildly by industries, and the cycle time that a product needs to have can be determined by external market forces (e.g. the school year).
Agile is meant to adapt to the characteristics of the business it is used in, rather than to be specifically some universal way of everyone trying to everything in the same way.
Re: Everyone claims they are following “agile methods” but few do (2018)
#5> Middle managers can also miss the importance of co-locating teams by bringing together designers, engineers, product managers and content specialists in the same physical space. The most highly functioning agile teams aren’t just at the same location or on the same floor: they share the same table. I can't refute this strongly enough. Managers should do their jobs and manage. Doesn't matter where team members are l…
Actually no it doesn't referring to "agile nonsense" is a real red flag.
Real Agile RAD /DSDM really does work best with collocated teams and experienced developers not lowest bid outsourced talent.
I have worked on both RAD and OSI 9000 (BS5750) waterfall projects so I have experience in both types of development.
Oh my Second RAD project was featured at the IEEE and when I was younger I worked with the BSI in the early days of BS5750
Re: Everyone claims they are following “agile methods” but few do (2018)
#6This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy. Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier. Standups c…
> This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy.
Maybe so, but you are also describing Agile as if it can be anything a company wants it to be, which effectively makes Agile meaningless.
I've worked with clients that have a waterfall-like development process, "standups" that are both status-reporting to management and on the spot planning, adaption to change is very slow and cumbersome, velocity charts serving management more than the team itself, tickets that represent multiple stories at once, management adding tickets(i.e. more story points) without removing less important ones, gigantic release cycles, etc.
Is that still "Agile"?
Re: Everyone claims they are following “agile methods” but few do (2018)
#7This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy. Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier. Standups c…
> This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy. Maybe so, but you are also describing Agile as if it can be anything a company wants it to be, which effectively makes Agile meaningless. I've worked with clients that have a waterfall-like development process, "standups" that are both status-reporting to management and on the spot plan…
Are they following the Agile Manifesto?
https://agilemanifesto.org/
If so, then it is. If not, then it isn't.
Re: Everyone claims they are following “agile methods” but few do (2018)
#8The article presents too many Agile/Scrum "artifacts" for my taste, eg
Agile favors so-called T-shaped skills Agile is a true democracyThe Agile philosophy certainly has something to say, but it's not hard to see the possible negative implications of "self-managing/self-policing teams" when they're owned by capitalist organizations.
These kinds of ninja teams can be extremely effective, but they should own a share in what they create, otherwise the whole thing becomes a BS attempt to make people work harder via "transparency"
Re: Everyone claims they are following “agile methods” but few do (2018)
#9I'm ready for what comes next after Agile.
I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone.
What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over.
I don't really want full waterfall again but I would really love to see some sort of lite versions of Functional specifications & design specifications come back.
Agile works best IMO in the Pre-1.0 phase of a product and gets progressively worse the further you get towards maintenance of a product. I also think Agile works better and better the closer you are to the UI, and worse and worse the further you get from the UI. Solid back end design and infrastructure rarely fits well into "Sprints" and solid back end infrastructure is not sexy at all in a demo, so Agile can demote back end design to the point everything gets done in a way that is too MVP. Then later on when scalability, performance, bugginess, and maintainability come into play you're into that "established product" phase where Agile doesn't do as well. So you've got problems in an area of the product Agile has trouble with happening in a phase of development Agile has trouble with.
Agile also seems to really require absolutely top notch product management folks, and they are seriously rare.
The thing is of the 5 shops:
* 3 Were acquired
* 1 Went IPO
* I work at the 5th currently
So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.
Re: Everyone claims they are following “agile methods” but few do (2018)
#10Earlier quoted context omitted.
> This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy. Maybe so, but you are also describing Agile as if it can be anything a company wants it to be, which effectively makes Agile meaningless. I've worked with clients that have a waterfall-like development process, "standups" that are both status-reporting to management and on the spot plan…
Are they following the Agile Manifesto? https://agilemanifesto.org/ If so, then it is. If not, then it isn't.
Of course not, and that's really the point. Plenty of organizations will tell you they are Agile when they aren't truly following the Agile manifesto, but that's not going to stop the evangelicals from eating the horse manure("our team has standups 'n stuff") that reassures them that their belief system works.
Everyone's bullshitting each other, and I wish it would stop, but I know it won't. Not everyone can be a "true scotsman".
I'm not even defending Agile or other related methodologies like Scrum. They have some good ideas, but I haven't seen quantifiable evidence that they are good for businesses. Many of the ideas are good for software engineers, but that doesn't mean they are actually good for teams or companies. Even then, I've management use "responding to change over following a plan" as a license to make more arbitrary changes to what engineers will work on in a given day because they can take it. Planning days and point systems be damned.