Agile: Multi-headed Hydra
-
Wow! Great analysis. That guy, Allen Holub is still around and runs his own consulting company and still espouses the belief that "there will be a user in your dev room or else you aren't doing Agile". He has written books and is a big deal in the "Agile" world. The few seconds before he makes the outrageous claim about must have user, he says, "if you are working on any time schedule then you are not doing Agile." Interesting because all companies work on some kind of schedule. I agree with the 12 Principles and like them for guidance in my own work. I think it is all just guidance but I don't believe in the Agile thing written in books or spewed by consultants. That's all fake. Again, great conversation. Thanks :thumbsup:
Unfortunately, charisma sells. And I get it, people like likeable people. But that's no guarantee they're correct. It just means they're charismatic. And it's not like the average person will do research. It takes a special person of high intellect IMO to do that. And you're totally welcome.
Jeremy Falcon
-
I agree wholeheartedly. I think Real Agile (12 principles) is how "real work is done", because as I look at how I create software / manage projects myself those things all come into play when I'm actually driving toward a finished product. But, alas, many companies (even tho they may not know it) are not driving toward a finished product. They are just typing code.
Oh, I will say, there is one thing that XP popularized which is good and that is pair programming. Now, XP says you need to do that all the time, but XP is garbage. Pair programming can be invaluable when stuck on a problem, training, etc. However, if 2 coders don't have any stuck issues it slows people down and code reviews make this pointless anyway. Assuming those code reviews / PRs aren't too large and far apart. This comes from real life experience and being on and running teams. Not from a book. So, pair programming is a tool. A great tool actually as it can save so much time. Just don't over do it. Edit: Don't confuse pair programming with [mob programming](https://www.agilealliance.org/glossary/mob-programming/). I think mob programming is pretty awesome. I wouldn't do it 24/7, but I love the guy behind it (Woody Zuill). Met him a couple times... great guy and makes a lot of good points. But, even the dude behind mob programming will tell you, you don't have to do it 24/7. Do as much as you're comfortable with. You can; that's cool. But there's nobody with a hammer over your shoulder. It's meant to be fun and collaborative.
Jeremy Falcon
-
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[
That's the problem I've always had with agile. Like you, in the 36 years I was active I never had 100% access to a customer. I could call occasionally to ask questions and clarify requirements but they were generally busy doing their daily work. They had limited time for me. Once in a great while they'd come to the office but usually for training after development or for requirements/kickoff meetings beforehand. But sitting in on Dev meetings or generally being there during development - never, not once. Not even during my last 3 or 4 years when my company was actually trying to switch over to agile scrum. They had their own jobs to do and those jobs ranged much further than just running our software. Heck, we couldn't even get them to install beta versions to tell us what they liked or hated no matter how much we begged.
-
That's the problem I've always had with agile. Like you, in the 36 years I was active I never had 100% access to a customer. I could call occasionally to ask questions and clarify requirements but they were generally busy doing their daily work. They had limited time for me. Once in a great while they'd come to the office but usually for training after development or for requirements/kickoff meetings beforehand. But sitting in on Dev meetings or generally being there during development - never, not once. Not even during my last 3 or 4 years when my company was actually trying to switch over to agile scrum. They had their own jobs to do and those jobs ranged much further than just running our software. Heck, we couldn't even get them to install beta versions to tell us what they liked or hated no matter how much we begged.
Yep! That's exactly what my experience too. This part of Agile (always having a user present) seems totally fake to me for "normal" applications. I'm sure there are special cases like Nuclear Reactor software or something, but other software it just doesn't happen.
FreedMalloc wrote:
Heck, we couldn't even get them to install beta versions to tell us what they liked or hated no matter how much we begged.
Yep, all of this is really just an intrusion to them. They don't want to play with your software which isn't the actual software they need to use to do their job.
-
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
