We have a whole load of practices in programming that only really work well if you’re already good at whatever the process is supposed to help with.
Scrum is a process improvement framework, but only if you already know how to do process improvement. If you don’t, then Scrum is just the baseline mini-waterfall process with a chance to air your dirty laundry every fortnight.
Agile is good at helping you embrace change, but only if you’re already good enough at managing change to understand which changes should be embraced.
#NoEstimates helps you avoid the overhead of estimates, but only if you’re already good enough at estimates to know that you always write user stories that take 0.5-2 days to implement.
TDD helps you design your APIs, but only if you’re already good enough at API design to understand things like dependency injection and loose coupling.
Microservices help you isolate modules, but only if you’re already good enough at modularity not to get swamped in HTTP calls.
This is all very well for selling consultancy (“if your [agile] isn’t working, then you aren’t [agiling] hard enough, let me [agile] you some more”) but where’s the on-ramp?
I discovered the on-ramp on the C2 wiki, and on YouTube.
The C2 wiki ( https://wiki.c2.com/ ) is a treasure trove of the eXtreme Programming community.
YouTube hosts talks by them, that I find easier to follow (especially when they do coding on stage).
There are people that refer to other people in their explanations. These other people show you better ideas.
Follow the links until you are spinning around in circles (people referring to each other instead of others), then study everything produced by the circle you reached.
Pingback: On programmer behaviours that make Scrum so bad | Structure and Interpretation of Computer Programmers