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.
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.
Which is different to saying anyone trained to be an engineer will be able to get stuff done. But getting stuff done was always a recnognised requirement of an engineer; i.e. by definition they should be getting stuff done.
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.
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.
I did leave and the company did crumble shortly afterwards. The main reason wasn’t related to processes, though. It was already too late when the faux-agile was introduced.
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.
Spot on. You and parent have hit the two points that matter:
1. Agile is about removing impediments to productivity
2. velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc are all, in some way, impediments to productivity (even if they do have some value).
I think the real reason you cannot have real agile is because businesses don't run in a way that is compatible with agile, so over time all processes within a business will evolve to match how the business itself functions.
Except it's not even really about productivity, it's about outcomes. The productivity is only important insofar as it achieves the outcomes. The ideal agile process would have the team on the golf course or in the spa but still changing the world (any suggestions on achieving this, gratefully accepted, as always).
Sadly, I think you are correct. It's very hard, at best, to make "the business" operate in a way that's truly compatible with the agile approach on the tech side. :-(
I won't say it's impossible, but it's definitely not easy.
For me the value in Agile is what we end up NOT doing - we never get to that shit because in the end it's not that important. So we never waste time doing it.
Sorry, but anybody who thinks Agile is about velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc. has been sold a bill of goods. Now that's not to say that those things don't have (some) value. But they aren't "the thing" about Agile. Not even close.