EDIT: and by changed, I don't mean improved. I was a huge advocate of agile and eXtreme Programming early in my career, and I even worked in shops where it seemed to be really having good results. Now I see everyone using SCRUM and... it's garbage and I want to gouge my eyes out in the meetings.
I see a lot of talking but not a lot of code getting written. And where the code gets written, it's always a pile of ego-boosting needless complexity.
Anything that becomes mainstream is likely to get twisted and turned into whatever the "powers that be" want it to be.
So, while using XP or Scrum or Kanban for that matter properly in a sane environment is going to be great, if you work in an un-sane (sic) one, then the powers that be have turned whatever system you're using into theirs. This is how things like SAFe are born, that try to make "agile safe for the corporation" and of course they're nothing more than corporate BS under an agile name and that gives agile a bad name.
Just like Jira is getting a bad name because it's so configurable that corporations are able to use it to do what they do. You can also use it as nothing than an electronic place to house your "post-it notes on a wall". All up to you, your cow-orkers and company. Nobody can blame Atlassian / Jira for taking the money of these corporations. I know I would if I had had the idea of releasing a ticketing system that doesn't even know that you should use surrogate keys for all your entities instead of making an issue key that can change if you move issues between projects your "primary key" that is referenced everywhere and shit breaks :shrug:
I miss buganizer at Google. It didn't try to hoist a process. It was... "here's a ticket. go do it. or not. whatever" low clutter. right to signal to noise ratio. The bug tracker in Google's ill faited github competitor was similar. Really decent.
The problem with JIRA is it becomes a little fantasy code writing exercise for people who've stopped coding (managers). You get to pretend you're dispatching program for your robots^H^H^H^Hteam to execute. And write out a little maze for your rats to run through.
Also was just talking to a friend about this. The original agile folks, the XP people... were explicitly against using software to track tasks. It was yellow sticky notes on a whiteboard. ON PURPOSE.
You may have hit on a carrot.
SAFe was truly one of the worst things I encountered with consulting clients. Planning days were an unbelievable exercise in futility. Waterfall masquerading as agile, the absolute worst of both worlds.
we've been using SAFe for a few years, I despise every minute of the planning process. Feel like a mix between using a crystal ball and forcing square pegs in round holes... Of course the additional disfunctionality at my company between sales, PO/PM/BO and engineering doesn't help, though it seems that I've avoided the worst SAFe train of the company.
1. Get the change to work
2. Refine the change to make it cleaner, less complex.
One other anecdote, me and a buddy were responsible for cleaning up a fairly sophisticated DSS scheduling system. The original dev left and a poseur came in and wrecked the codebase for over a year. Hospitals were cancelling contracts left and right and our cash flow was ... uh, short a lot. Our rule was if we ran across some bad code while working on our tickets: a bug, janky code, disorganized code, shit variable names, whatever, we fix it on the spot. We were able to do this because we had 3 month cycles and nobody breathing down our necks asking, "what did you do yesterday?" "why aren't all your tickets done this sprint?" Well it worked and we ended up with a clean scheduling system that was really nice after a few years and the company exited with a decent sale. I couldn't imagine a culture like this today.
0. Compose a new abstraction to describe the change.
And then at #2, the abstraction starts to get in the way.
I recommend the first half of the Out Of The Tarpit paper.