Agile: Multi-headed Hydra
-
Years ago I read the book, The Art of Doing Twice the Work In Half the Time[^], by Jeff Sutherland (one of the 17 signatories[^] on the original Agile Manifesto) The original 12 principles [^] were great guidance (not a methodology). Anyways, that book was really good & offered A Methodology (SCRUM) that could be used by Companies to create a (paraphrase) "system for creating software which was flexible.") But of course companies took it and made it so Legalistic that it devolved into garbage. Of course, Agile (which is different from Agile Scrum) & Scrum have both been so altered by so many consultants and books that none of it means anything to anyone any more. If You Read Nothing Else, Read This Quote About Agile (or watch the video) I was watching this 9-year old video of Allen Holub and he makes this statement (click here[
raddevus wrote:
POLL: The Big Question Have you ever been on a project where the user actually sits in the same room (or even building) as the developers?
Many applications in our company (and many (most?) other financial institutions) are built by people sitting on the trading floor with the traders who are using the application. When an application doesn't work, feedback is instant. So in that sense I guess that aspect of agile is being adhered to.
-
Years ago I read the book, The Art of Doing Twice the Work In Half the Time[^], by Jeff Sutherland (one of the 17 signatories[^] on the original Agile Manifesto) The original 12 principles [^] were great guidance (not a methodology). Anyways, that book was really good & offered A Methodology (SCRUM) that could be used by Companies to create a (paraphrase) "system for creating software which was flexible.") But of course companies took it and made it so Legalistic that it devolved into garbage. Of course, Agile (which is different from Agile Scrum) & Scrum have both been so altered by so many consultants and books that none of it means anything to anyone any more. If You Read Nothing Else, Read This Quote About Agile (or watch the video) I was watching this 9-year old video of Allen Holub and he makes this statement (click here[
My experience with stuff like agile and scrum is that people simply don't want it. Developers do, management think they do, but users often don't. One mistake is that people still think of it as a development methodology and so only developers get training. However, it asks a lot from users as well! And those users usually do not get the same training. They just want to tell us what they want, preferably in one no too long sitting, and get exactly what they asked for (or thought they asked for anyway). And it makes sense because to them the software isn't all that complicated or they only use a small portion of the software. They surely don't want to see incomplete software every two weeks. Releasing new functionality every two weeks is a myth, users want the full product or nothing at all. Lots of users can't even see past incomplete software and it only makes them resist change ("see, you can't even do X with the new software!") For all those reasons I prefer a more waterfall approach, it's simply more user friendly. I'm not fleshing out all the details up front and we do have some meetings with users and there are regular meetings with analysts, but it'd be a stretch to call it scrum or even agile. We're agile in the sense that we can always make changes even during development, we can shift priorities, we can do all that, but I'd still call it more waterfall than agile (as a methodology).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
raddevus wrote:
POLL: The Big Question Have you ever been on a project where the user actually sits in the same room (or even building) as the developers?
Many applications in our company (and many (most?) other financial institutions) are built by people sitting on the trading floor with the traders who are using the application. When an application doesn't work, feedback is instant. So in that sense I guess that aspect of agile is being adhered to.
Very interesting. Thanks for sharing. I worked at a large mortgage company with 100s of branches and they attempted to re-write the Loan Origination system and they did not follow that idea. They worked on it for about 5 years and spent $75 million then gave up and used none of the code. It was crazy!
-
My experience with stuff like agile and scrum is that people simply don't want it. Developers do, management think they do, but users often don't. One mistake is that people still think of it as a development methodology and so only developers get training. However, it asks a lot from users as well! And those users usually do not get the same training. They just want to tell us what they want, preferably in one no too long sitting, and get exactly what they asked for (or thought they asked for anyway). And it makes sense because to them the software isn't all that complicated or they only use a small portion of the software. They surely don't want to see incomplete software every two weeks. Releasing new functionality every two weeks is a myth, users want the full product or nothing at all. Lots of users can't even see past incomplete software and it only makes them resist change ("see, you can't even do X with the new software!") For all those reasons I prefer a more waterfall approach, it's simply more user friendly. I'm not fleshing out all the details up front and we do have some meetings with users and there are regular meetings with analysts, but it'd be a stretch to call it scrum or even agile. We're agile in the sense that we can always make changes even during development, we can shift priorities, we can do all that, but I'd still call it more waterfall than agile (as a methodology).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Totally agree with your entire post. 100%!! So many things you said are so true.
Sander Rossel wrote:
One mistake is that people still think of it as a development methodology and so only developers get training.
If you listen to the actual Agile people you discover that it actually affects the entire organization -- and if it doesn't then you are not actually Agile.
Sander Rossel wrote:
They surely don't want to see incomplete software every two weeks.
Exactly! Users are annoyed by having to see partial software that doesn't do the parts they want anyways. They won't even look at it. Many times they won't even run the app once. That has been my experience in every company I've worked in over 33 years. Even as "Agile" has come along, it's really been waterfall with some agile ideas. Thanks for sharing, really appreciate it, and very interesting to hear someone else say those things too.:thumbsup:
-
Very interesting. Thanks for sharing. I worked at a large mortgage company with 100s of branches and they attempted to re-write the Loan Origination system and they did not follow that idea. They worked on it for about 5 years and spent $75 million then gave up and used none of the code. It was crazy!
We have a sort of multi tiered version, in so far as the people building the applications are actually on the trading floor, but they are themselves users of the components they use to build those applications, and the components are built by a different team who are not actually on the trading floor (it's often noisy) but very close by, so the application builders can liaise directly.
-
Years ago I read the book, The Art of Doing Twice the Work In Half the Time[^], by Jeff Sutherland (one of the 17 signatories[^] on the original Agile Manifesto) The original 12 principles [^] were great guidance (not a methodology). Anyways, that book was really good & offered A Methodology (SCRUM) that could be used by Companies to create a (paraphrase) "system for creating software which was flexible.") But of course companies took it and made it so Legalistic that it devolved into garbage. Of course, Agile (which is different from Agile Scrum) & Scrum have both been so altered by so many consultants and books that none of it means anything to anyone any more. If You Read Nothing Else, Read This Quote About Agile (or watch the video) I was watching this 9-year old video of Allen Holub and he makes this statement (click here[
**<ChrisEvansVoice>**Hail Hydra!**</ChrisEvansVoice>**Software Zen:
delete this; -
**<ChrisEvansVoice>**Hail Hydra!**</ChrisEvansVoice>**Software Zen:
delete this; -
Gary Wheeler wrote:
Hail Hydra!
Ah, I see you're an AGILE PROPONENT!! <short pause> GET HIM!!!!!!!:mad::mad::mad: :laugh: :laugh:
raddevus wrote:
you're an AGILE PROPONENT
:elephant: that, them's fightin' words! :-D
Software Zen:
delete this; -
Years ago I read the book, The Art of Doing Twice the Work In Half the Time[^], by Jeff Sutherland (one of the 17 signatories[^] on the original Agile Manifesto) The original 12 principles [^] were great guidance (not a methodology). Anyways, that book was really good & offered A Methodology (SCRUM) that could be used by Companies to create a (paraphrase) "system for creating software which was flexible.") But of course companies took it and made it so Legalistic that it devolved into garbage. Of course, Agile (which is different from Agile Scrum) & Scrum have both been so altered by so many consultants and books that none of it means anything to anyone any more. If You Read Nothing Else, Read This Quote About Agile (or watch the video) I was watching this 9-year old video of Allen Holub and he makes this statement (click here[
, The Art of Doing Twice the Work In Half the Time I usually do half the work in twice the time. Does that count? CQ de W5ALT
Walt Fair, Jr.PhD P. E. Comport Computing Specializing in Technical Engineering Software
-
, The Art of Doing Twice the Work In Half the Time I usually do half the work in twice the time. Does that count? CQ de W5ALT
Walt Fair, Jr.PhD P. E. Comport Computing Specializing in Technical Engineering Software
