I worked in a couple shops that did XP ("extreme programming") in the early 2000s. At the time this was a kind of progressive movement, associated with empowering developers, came out of the Smalltalk world and other "odd" places, was associated with a rather more grassroots engineering culture. Prototype and iterate. Very different from "classic" engineering orthodoxy. At the time very new, and came along with a bunch of other stuff that promised more rapid development; heavy object oriented dev, dynamic languages, test first design, etc. etc.
I had mixed experiences with it but absorbed a lot of good lessons. While I can't speak to "scrum" that much (I've seen degraded forms of it a few times but not the actual "real" thing) I think many of those fundamentals have been lost in the intervening years... err.. decades (cry).
Two things key for me, that it seems that people don't care about anymore:
i. Developers doing their own estimates. Absolutely essential to managing scope. This one always goes out the window or gets ignored first. I have worked in so many "agile" teams that would choke on their own vomit before taking the power away from managers or "experts" on the team to decide how long something will take. If this is the case, there is no point in scoping in an "agile" process anymore. You'll just have to crunch to meet their deadline, and that's that. That's not "agile" that's "sweatshop." (Or, if you routinely blow out / pad the estimates too large to compensate... inefficient)
ii. Ship the minimal viable product, and then iterate on it. You ain't gonna need it, etc. Release frequently and often and in small chunks. Absolutely foreign concept to most of the recent UX and PMs I've worked with, especially at BigCo, who treat the design doc / mock / spec as the finished product, with the actual development just being a kind of "last mile." Want to know what changed between their last giant spec document and now? Read the whole 50 pager again.
My wife was taking UX design courses and even there, while paying lip service to agile there was all this type of "produce a planning document" with big upfront information hierarchies and total project design. And yes, even working in embedded and other things not front facing, I found this to some degree. A fear of iteration, still. The act of forcing the customer or PM or whatever into a discipline of an incremental thought process honestly helps with frequent delivery, and keeps the process responsible to the user, the real final customer.
What is so often missed is that agile in the classic XP sense was an exchange, some compromises: I (the engineer) agree to work rapidly and ship frequently and to give you great visibility, but you (the customer) agree to be provide me with constant feedback and prioritization, to accept my estimates/scoping, and to think incrementally and practically about what you want now rather than what you think you might need 6 months from now.
Daily standups and iteration meetings and story cards? Handy. But these are just part of the mechanics and can easily devolve into theatre or pantomime of "agile" if the other pieces aren't there.
I had mixed experiences with it but absorbed a lot of good lessons. While I can't speak to "scrum" that much (I've seen degraded forms of it a few times but not the actual "real" thing) I think many of those fundamentals have been lost in the intervening years... err.. decades (cry).
Two things key for me, that it seems that people don't care about anymore:
i. Developers doing their own estimates. Absolutely essential to managing scope. This one always goes out the window or gets ignored first. I have worked in so many "agile" teams that would choke on their own vomit before taking the power away from managers or "experts" on the team to decide how long something will take. If this is the case, there is no point in scoping in an "agile" process anymore. You'll just have to crunch to meet their deadline, and that's that. That's not "agile" that's "sweatshop." (Or, if you routinely blow out / pad the estimates too large to compensate... inefficient)
ii. Ship the minimal viable product, and then iterate on it. You ain't gonna need it, etc. Release frequently and often and in small chunks. Absolutely foreign concept to most of the recent UX and PMs I've worked with, especially at BigCo, who treat the design doc / mock / spec as the finished product, with the actual development just being a kind of "last mile." Want to know what changed between their last giant spec document and now? Read the whole 50 pager again. My wife was taking UX design courses and even there, while paying lip service to agile there was all this type of "produce a planning document" with big upfront information hierarchies and total project design. And yes, even working in embedded and other things not front facing, I found this to some degree. A fear of iteration, still. The act of forcing the customer or PM or whatever into a discipline of an incremental thought process honestly helps with frequent delivery, and keeps the process responsible to the user, the real final customer.
What is so often missed is that agile in the classic XP sense was an exchange, some compromises: I (the engineer) agree to work rapidly and ship frequently and to give you great visibility, but you (the customer) agree to be provide me with constant feedback and prioritization, to accept my estimates/scoping, and to think incrementally and practically about what you want now rather than what you think you might need 6 months from now.
Daily standups and iteration meetings and story cards? Handy. But these are just part of the mechanics and can easily devolve into theatre or pantomime of "agile" if the other pieces aren't there.