|
Yeah, that makes sense to me for "specialized" application (probably expensive to pay for your time too, I'm guessing).
But I've never seen an instance of external software made for masses where they can sequester a user.
I could be wrong, but I've never seen it myself.
And I also know users -- they are so bored with IT / App Dev that they can barely speak two sentences about what they actually want.
I had internal users (tech support) who
1. drew a winform exactly as they wanted it
2. said the winform must appear in the app when the user holds the left button down. (As soon as the button is let up, the winform must disappear.)
3. This winform would display extra data that was displayed nowhere else (bec they didn't like to see a lot of data at once.
I made the winform look exactly as they wanted it. Even down to the colors they asked for.
THey said this functionality was extremely important.
I created a video of the functionality and asked them to watch it.
I never got any response that they viewed the video.
I finished the functionality and got a call from
tech support mgr 6 months later: "Where the hell is the data? Why didn't you put that feature in?"
Li'l ole Me: Uh, did you left click and hold it when you're on a row of data?
tech support mgr: Oh...
They don't even look at or use the functionality they beg for and design themselves.
There's no way they gonna sit in a room for months. No freakin' way!
|
|
|
|
|
I agree, there are users like that. For me, it was mostly when the "user" coming up with the requirements was a middle manager not the one really using the app.
raddevus wrote: Yeah, that makes sense to me for "specialized" application (probably expensive to pay for your time too, I'm guessing).
True, our software was rather specialized so people were motivated to have it working. And you guessed correctly, I was decently paid 
Mircea
|
|
|
|
|
raddevus wrote: 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.
It's amazing how many people don't know this. Agile (in the sense I know of it) can be implemented by Scrum, Kanban, or Extreme Programming (XP). And, I can promise you that most "consultants" don't know a damn thing about Scrum, etc. 
raddevus wrote: Well, then, glad we had this little talk. No one is doing Agile, then.
I didn't watch the full video, but IIRC to do XP properly called for something like that. It was the OG in Agile implementation. Thankfully, it died out like the fad it was.
But... few things to note...
1) Just because someone is able to give a speech doesn't make them the arbiter of truth. I mean maybe, but maybe not. People need to believe in something authoritative in a system humans agree on that seems authoritative... like giving a speech.
2) The end user isn't always John or Jane Doe sitting at home. In the enterprise an end user could mean the business. They are your customers since they are asking to you to make a product on behalf of the customers sitting at home. So, to that degree, the "end user" should be in a tight feedback loop.
3) This dude just might be one of those uptight dudes who can't evolve. I dunno. Maybe he's not. Maybe he's awesome. I didn't watch the video. But, Agile implementations have come a long way since the early days of implementations like XP.
raddevus wrote: Agile is 100% fake.
This is where most people get it wrong. Agile is a set of guidelines and philosophies, but it's not an implementation of said philosophies. To use OOP parlance, it's an interface. But, it ain't gonna do crap unless there's an implementation.
And guess what... all those implementations are not the same: Scrum, Kanban, XP, etc. Thus Scrum is not Agile and Agile is not Scrum, but Scum is an implementation of Agile principles. Which is to say, any hard rule would come from Scrum, etc. and not Agile. I dunno if that dude conveyed that in his speech, but if he didn't... I wouldn't trust him regardless if he has a microphone in hand.
So, Agile isn't fake, it's just guidelines and most people don't really know the difference. This is straight from the Agile Manifesto (which is way more authoritative than that dude):
- Satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development.
- Deliver working versions frequently.
- Bring business people and developers together.
- Build projects around motivated individuals.
- Engage in face-to-face conversation.
- Measure progress with working versions of the final product.
- Promote sustainable development.
- Pay continuous attention to technical excellence and good design.
- Keep it simple.
- Use self-organizing teams.
- Regularly reflect and review.
Number 4 is of particular importance, but that does not mean have some end user sitting over your back when you code. That's some XP nonsense that died off thankfully.
Jeremy Falcon
modified 9-Sep-24 17:47pm.
|
|
|
|
|
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 
|
|
|
|
|
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
|
|
|
|
|
Btw, if I had to distill Agile into a one liner it would be this:
Iterative development and tight feedback loops.
That tight feedback loop will remove the need for anyone standing over your shoulder.
Jeremy Falcon
modified 9-Sep-24 17:57pm.
|
|
|
|
|
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. 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
modified 9-Sep-24 18:32pm.
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
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).
|
|
|
|
|
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.
|
|
|
|
|
<ChrisEvansVoice>Hail Hydra!</ChrisEvansVoice>
Software Zen: delete this;
|
|
|
|
|
|
raddevus wrote: you're an AGILE PROPONENT
![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) that, them's fightin' words! 
Software Zen: delete this;
|
|
|
|
|
, 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
|
|
|
|
|
Dr.Walt Fair, PE wrote: I usually do half the work in twice the time. Does that count?
Yes, definitely.
From what I've found from working > 33 years in IT.
That is actually the way work is done. 
|
|
|
|
|
No updates in "The Insider News" for over a week.
|
|
|
|
|
Agreed, I'm missing my daily dose of snappy remarks. Hope all is well??
|
|
|
|
|
I had almost decided to come make a post inquiring about how one immigrates and acquires the same vacation plan.
|
|
|
|
|
And all is right with the world! The daily news is back baby!!
|
|
|
|
|
Where? I don't see a Daily Insider? I see a Daily Build from yesterday though.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
