Listen, Test, Code, Design OVER Sprints, Scrums, and ScrumMasters

"Back to basics" is Scrum?

I've been noticing people talk about getting "back to the basics" and then proceed to talk about Scrum roles and rituals.

This annoys me for 2 main reasons:

1.  Scrum was never "basics" for me and I've typically been doing this longer than the person who suggests this
2. The more important reason is that if we think about this carefully, Scrum cannot be the "basics"

"Back to basics" should be about the essence of what we are doing

"Back to basics", "focusing on the fundamentals", etc. is about getting back to the essence of an activity.  I touched upon this when I was exploring the concept of doctrine but let's think about this using the frame of "basics" or "fundamentals".

If we look at the context of developing software for a purpose, as opposed to as a hobby, what is the essence of what needs to happen?

1. You need a shared understanding of what problem the software is intended to solve.  We have learned that the best way to do this is to engage directly with the relevant situation and people.
2. You need a shared understanding of what the solution needs to do to solve the problem.  We have learned that the best way to do this is through conversations leading to agreed examples and then iterating.
3. You need to build the solution.  We have learned that the best way to do this is in a thoughtful, collaborative, disciplined way.
4. You need to manage the growing complexity of the system to ensure that it continues to be easy to change.  We have learned that the best way to do this is as an ongoing exercise reflecting the best knowledge we have at each point.

A more compact version of this might be: Listen, Test, Code, Design.

If you don't get good at these basics, all your Sprints, Scrums, and ScrumMasters won't matter much.