Earlier quoted context omitted.
That sounds familiar... Oh ! That's where agile ideas come from! http://www.extremeprogramming.org/
That existed before agile.
But bad on agile for letting charlatans co-opt the term.
61–70 of 108 posts
Earlier quoted context omitted.
That sounds familiar... Oh ! That's where agile ideas come from! http://www.extremeprogramming.org/
That existed before agile.
But bad on agile for letting charlatans co-opt the term.
Earlier quoted context omitted.
The point is to use what ever works best for your team, not blindly follow some process that may or may not necessarily work for you. Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.
Sounds like you need a process that can be flexible, able to respond to change, some might say… agile ;-) I kid, but I think the early proponents of Scrum and similar were trying to achieve a loose framework to do exactly what you’re talking about. The modern incarnations of these can be horrific, but the original intent was always to empower teams to make their own process. Ahh well. Like so many good ideas (democra…
The team is self-organizing but person X is the decision maker in the process.
There is an engineering manager, but they will get overruled by person X more often than not.
The framework is simple, but person X will add new rules.
Agile/Scrum says people must understand the domain, but person X is the only one talking to stakeholders since engineers are "not people persons".
I wish more people understood this. Nobody should be arguing for Agile anymore. Don't say "no, but-" or "that is not what the Manifesto says-" because you're only strengthening the case for Agile as propagated by the fraudmasters simply by virtue of it sharing the same name as the thing you're arguing for. Leave the term behind, find something else.
The problem is that it's a neverending treadmill of naming if you do that. Every good idea will be taken over by fraudsters. A lot of good ideas are already tainted by this, and while you have to pick your battles, there's something to be said for standing your ground on naming.
Agile/Scrum is one of those things that are impossible to criticize. You can come up with a well-reasoned critique of Agile and there's always some Agile evangelist that pops up to tell you that you're not doing "real agile" and, therefore, your experience is invalid. At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the…
Earlier quoted context omitted.
I’ve seen agile done well once. Yes it does happen. The process was not described, spoken of or even considered. It just existed between a few like minded decent engineers. Their manager got an “agile PM” forced on them and it broke. The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.
Quality engineering has to be *repeatable*. If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX. I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.
http://programming-motherfucker.com/
I wish that was a joke, but it's Zed so... No, you can't replace customer collaboration with more programming. When you're in a programming hole of misunderstood solutions, you can't fix that by doing more programming. When things keep changing without good reasons, you can't fix that by doing more programming, etc.
- tell the client to get their shit together
- fire the client
- walk away
Earlier quoted context omitted.
Is it really vaguely defined? I find it perfectly precise in what it tells you what you need to optimize for. It just doesn't tell you how because it couldn't possibly know. But finding out is hard work. What the fraudsters are telling you is that you don't need to do any of the things in the manifesto because they know everything already. A general lack of industriousness on the part of software companies is really…
>Is it really vaguely defined? https://agilemanifesto.org/ does this look like a clear and precise proscription for a good way to engineer software? Or does it look more like a bunch of "inspiring quotes" from a discount southern baptist church website from the 1990s? I learned this the hard way when I was younger when I tried to write some tests for some bugs and my boss told me that we needed to deal with it with m…
I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process and not just a bunch of magic incantations to do that, like the enterprise world seems to think.
Earlier quoted context omitted.
"Agile" was defined so vaguely in the beginning that it became a kind of template for everyone to project their (often contradictory) ideas and dreams on to. Scrum fixed that by being as bad as it was precisely defined. I can get what the originators of agile were getting at but they explained themselves super badly.
Scrum is supposed to be training wheels for agile, not the end point. I think a lot of ppl forget that.
One of the nice things about scrum is that it has an official source who defines it and you can look at it to see what it is and what it is not intended to be.
http://programming-motherfucker.com/
I wish that was a joke, but it's Zed so... No, you can't replace customer collaboration with more programming. When you're in a programming hole of misunderstood solutions, you can't fix that by doing more programming. When things keep changing without good reasons, you can't fix that by doing more programming, etc.
Agile/Scrum is one of those things that are impossible to criticize. You can come up with a well-reasoned critique of Agile and there's always some Agile evangelist that pops up to tell you that you're not doing "real agile" and, therefore, your experience is invalid. At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the…
Just the typical "No True Scotsman" fallacy [1], happens all the time when there is no good defense of the position.