• 2 Posts
  • 10 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle
  • Recently did this and yes it’s a pain. I don’t know if it’s going to help until next time we change phones, but what I did this time was name the device after the person, rather than the phone model.

    The idea being that I can delete the old device in the future and replace it with the new device, named the same. That way I don’t have to change the device name in each automation every time. Hopefully that made sense. But I still haven’t tested it in reality.



  • Agile isn’t meant to replace anything. You need to use the right method for your context. No one said the purpose of agile is to replace all other methods.

    Agile doesn’t have to be implemented perfectly to work. You seem to be holding agile to some higher standard than anything else.

    You have to get over the communism comparisons. They aren’t relevant.

    Just because you haven’t worked in an agile environment you enjoyed, that doesn’t mean it can’t work. It can and does work. Just like any other method. And it can and does fail. Just like any other method.

    OP didn’t work in agile. They were told that they were working in agile but it was just an excuse for the business to not have requirements and continually change their mind. Every one of the issues they raised could have happened in any other methodology. It’s poor management.



  • I disagree. I’m currently working in agile and it’s the best team I’ve worked in/with. It can easily go wrong, but it can also work really effectively. Implementing agile in an “ok” way, is still better than waterfall in most instances. Of course it depends on the business context.

    Take all of OPs complaints for example. Sure, they can be an issue if agile is implemented poorly (or not at all in OPs case), but all of them are inherent issues with waterfall. Developing something only to find out days before launch the business has something else in mind. There would be much less chance of that happening in an agile environment over something like waterfall.

    There’s a big problem with people saying they work in agile, when they’re really not. Like in OPs instance. And that leads to the negative sentiment about agile never working. I get it, I’ve been there and had to work in agile teams that weren’t really agile. That doesn’t mean it can never work.






  • That’s the biggest problem with waterfall to be honest. You can sit there and point at requirements, but requirements can be interpreted differently. And that’s a bigger issue with waterfall because you’re handed a list of requirements with little context on what the purpose is of what you’re doing because you weren’t in any of the conversations earlier on in the process.

    Agile doesn’t mean you don’t have requirements. What happened really sucks. But you aren’t working in agile. You’re just being screwed.



  • The problem is that it’s a lot easier to implement agile poorly, than it is to implement it in a way that works.

    You’ve essentially described what agile shouldn’t be. The fact it’s called agile, means people assume it just means you can change things whenever you want because that’s being “agile”. That isn’t what agile methodology is meant to be. If that’s what you’re experiencing, then it’s being done wrong. And it’s frustrating because this is extremely common.

    Waterfall can be just as bad. I’ve worked on plenty of waterfall projects only to spend months of my time on things that never see the light of day. Things change, and waterfall can rarely deal with change mid-project without starting over. It’s completely dependent on the context of the work.