/u/lr4444lr and /u/ajmurmann nailed it. "Agile" is just what the Agile Manifesto says. Strictly speaking, "Agile" in and of itself isn't even a methodology - it's just a set of principles, to which a number of concrete methodologies claim some association. They differ in the degree to which they faithfully represent the spirit of the manifesto.

So really, you're never "doing Agile". You're "doing $X" where $X can be Scrum, XP, Crystal, AgileUP, SAFe, or whatever. At most companies what you get, in my experience, is a bastardized version of Scrum cobbled together by somebody who has never actually developed software, took a couple of Scrum classes (maybe), paid too much money for some "help" from some "Agile coaches", and is hoping some of the resulting shit will stick to the wall.

FWIW, I've actually had the pleasure of working at company that did Scrum and really did it well, and it was honestly a great experience. Actual Scrum, as documented in the Scrum Guide, isn't bad. The problem is when people take base Scrum and start tacking on additional shit (see: "agile coaches" and "agile consultants") and wind up with a bureaucratic / kafka-esque tarpit of interminable meetings, ceremonies, and artifacts. In other words, pretty much exactly what the Agile Manifesto stood against in the first place.

It's a methodology that makes software more resilient to the changing needs of the business. Anything that violates the 12 canonical principles[0] should be thrown out - and this has to be determined by each org. individually.

[0] https://agilemanifesto.org/principles.html

You asked about Agile, but I will talk about Scrum instead, because I am more familiar with it.

https://scrumguides.org/scrum-guide.html

Ctrl+F "JIRA" - 0 results

Ctrl+F "velocity" - 0 results

Ctrl+F "on-call" - 0 results

Ctrl+F "manager" - 0 results

Selected quotes:

> Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

> During the Sprint: No changes are made that would endanger the Sprint Goal;

> The Daily Scrum is a 15-minute event

A short version is that you have a small team of intelligent people who are given sufficient autonomy. They split time into intervals called "sprints", each sprint is 2-4 weeks long. (If you have no experience with Scrum, start with 2 weeks. When you get used to it, the team can decide the correct length.)

At the beginning of the sprint, the developers and the representative of the customer agree what gets done. During the sprint, the developers do it. Every day there is a short meeting in the morning, when developers say "I completed this; I am going to work on this; I am blocked by this", nothing more.

At the end of the sprint, developers show the implemented changes to the representative of the customer. Then the developers talk among themselves about what was good during this sprint, what was bad, and what they want to do differently the next time.

The important thing (ignored at almost all companies pretending to do Scrum) is that in this ideal world, managers do not exist. Developers manage themselves. In the daily meetings, developers report their progress to each other. What needs to be done, is decided by the representative of the customer (literally a person from a different company, or from a different department if this is an internal project). How it gets done, that is decided by the developers. When developers talk about what was good and bad, and what needs to be done differently, they actually have the power to do it differently the next time. Developers assign the work between themselves, and make estimates how long something would take.

Shortly: the developers are treated as adults, and their responsibility to the customer is defined on a biweekly or monthly basis.

You speak with a client. They say what they want. You build it they test it, and state objections and or request more features. You discuss and then build the agreed thing. And then you do this loop untill you ship

The whole idea is that there is no strictly formal version of the process. It can't be answered with a package. The process itself is agile, ammendable, fluid, mutable, improvable. You do what works for you.

Just stick to the principles of focusing on the product customer value over the processes themselves, with recurring reflection over how your process is working, as per the agile manifesto.

If your company hasn't done this before, Scrum is a good starting point, but it is by no means a goal nor the final destination. This is where most companies fail.

agilemanifesto.org

Constant reflection and drive towards faster feedback. XP or if I squint Scrum can be a starting point, but you gotta adapt to the individuals on the team and the characteristics of the type of problem you are solving.

Agile is to Lenin as Agile processes are to Stalin.

Read the Agile Manifesto. That’s what Agile is. All else is either: - (good) trying to implement the Agile Manifesto, or - (bad) trying to make current process appear like Agile.