Take a look at the works of Nicholas Felton http://feltron.com/ especially his reports of his years of personal data like http://feltron.com/FAR09.html
These might give you ideas.
22 karma · joined February 9, 2014
So we should be free in what we build but how should be influenced 1) by the what and 2) your team's experience. The why is key to know what to build. Without knowing why, pondering about what is pointless.
The constant potential for modification in an efficient manner is indeed a key of software development and very difficult to achieve in my experience. Besides concentrating on small things you need to watch and maintain your architecture of the system. Alas there is a point where you need to change the architecture. I think Martin Fowler was it what found out that at a certain point an architecture which was a right fit at the beginning cannot be maintained in a reasonable way and has to be stepped up. I would be interested what are the combination of practices that work for you is (even if they do not apply to my team). With pragmatism I refer to the artifact, the what, it needs to be a good fit to the problem and the users. And it is important to thing with what solution can "you get away with". Not in the way it is build but what does it achieve, the capability it provides. I have seen too many developers failing to fulfill requirements in time and budget because they stuck to the wording of the requirement. The requirement was a box for them, a prison. The problem behind the requirement is the one the developer needs to solve, not the requirement as is which is often wrong or unclear anyway. I have seen so much leverage here that I am putting most of my effort here: teaching to find and eliminate assumptions, getting to the problem, goals and needs of the user and the business, ...
The practices, the how. In my 15 years of professional development I tried many different practices and some are good for some situations, others feel like a waste of time and effort. I am yet on the search for a consistent set that fits me and my team. How do you consistently apply the practices? Only in projects? Or do you use katas or something like that?
Again thank you for discussing. I believe such honest and clear discussions are needed more than the many arguments about what is better or worse.
I think it is important to ponder about what is the best (efficient, best matching, ...) solution to the problems the user has. In your definition agility sounds like the absence of pragmatism.
I don't think reduction only leads to perfection. If it would be, then our starting point must always be the right one. But in practice you start somewhere, reduce, move forward, add stuff, move sideways, try out and test. Sometimes you need to add stuff to make it clearer to your users.
Then why do software developers get no training in talking to users? In understanding them and make sense of what they tell us and what they really?
This to me is the biggest short coming of today's software 'engineering'