The Agile Methodology is Horse Manure!
ฝัง
- เผยแพร่เมื่อ 27 ก.ย. 2024
- In this session we take a quick dive into the the "Agile" methodology that is part of the software development life cycle. We compare the current modern incarnation and it's original roots and find that to be frank it's utter horse manure!
Is modern agile a lost case, can it be saved? watch this video to find out.
If you work at a company, chances are they're not doing agile or anything close to agile. It's also not a methodology, it's a mindset. As long as you adhere to the principles, you're doing agile. So, even you get a fail.
Disagree with most things on the video. We need more focus on documentation rather than getting working software fast. Focusing on the later just leaves you with rushed unmaintainable crap that can only be understood by the underpaid, inexperienced junior that was too eager to prove he's an asset to the company by getting shit done fast.
I do agree that non-technical managers can be an issue, but in my experience having nobody correctly translate a client's wishes to requirements to proper documentation is just a recipe for disaster later on. Clients change their minds, then nobody is certain this change wasn't what they originally stated (or worse), the manager decides they know what the client wants and what the client wants is not written anywhere other than a nebulous 5 words sentences per requirement.
And I also agree on agile snakeoil salesmen being cancerous bullshit. I had to attend a course like that and it was worthless. Full of "exercises" that just wasted hours that could have been invested in other things. All because the company wants a scrum certification.
Thank you for you in depth comment!
While I do agree documentation is important, the issue is the first build will always be guaranteed to be wrong, this is because the problem space is *not* initially understood and things evolve as we explore the problem space. Therefore focusing on documentation first is not the correct approach as that assumes one fully understands the entire problem upfront (which we do not). But for sure documentation *after* one has an actual working platform is indeed important.
Regarding juniors running wild, that is a different topic about project leadership and developer management and a good lead would nip that in the bud, but that is one for another topic.
Also "correctly translating a client's wishes" that right there is actually the issue, part of the original Agile manifesto explicitly states about "customer collaboration" meaning the distance between developers and customers/users should be zero, it is precisely *because* we have all these intermediaries that all the miscommunication happens in the first place, and no amount of "proper documentation" will ever solve that. You will learn so much more when you sit right next to your customer and observe how they interact with your platform then all the documentation in the world!
@@watthedoodlesure the first build won't necessarily be right but I have always put documentation first and I have been able to actually document how the interface is going to work and put it in front of users and get feedback so that we build a better tool before we ever start coding. If you do good documentation and make sure that it's done in a way that it gets in front of users early so you get feedback to refine and perfect the documentation then you will spend less time coding and you'll get closer to the target on the first build. I have been building software this way for over 25 years and it works really well and I get things done really fast and you need to do good documentation first that way the build goes really fast and everyone understands it and it's clean code and it's closer to the mark the first time we all need to get away from this stupid dichotomy where it's only waterfall or only rapid code and it's nothing in between because it's the place in between where sanity lies.
@@aaronbono4688 sure I agree, however from your description that sounds more like system design than documentation. But we may be arguing semantics at this point!
I absolutely agree regarding system design which is very important in any build so we're are on the same page here.
What I'm against is the the endless documentation with the expectation for everything to be detailed down to the last dot before anything is ever built, I don't agree with that approach!
I high level design, schema design, major building blocks those are all you need initially to get going in my view.
For the record in total I've been building software for around 22 years (so just a few years fewer than yourself) 😄👍
@@watthedoodle so again it comes around to getting away from these discussions of the extreme waterfall versus the extreme dive head first into coding and start discussing the sane and effective middle ground. No matter what the topic these days we keep getting mired in discussing the extremes and we have lost sight of the fact that we live in a world of spectrum where there is plenty of middle ground.
@@aaronbono4688 Yes I agree there is a middle ground, and I think that is captured well in the original Agile manifesto, so it doesn't say "no" documentation and planning, because those are the values "on the right", it just advocates to try and focus more on the left (hence the spectrum). If others think "oh the left means no X" then that is also a false understanding of the original agile manifesto.
Tlrw; Agile is bad because companies aren't doing Agile. Not very insightful.
Thank you for you comment. With respect sir, that is absolutely *not* the conclusion of this video. In fact it's the complete opposite. This is clearly understood if one watches the full video.