Yes I can reply to my own post with alacrity I hope.
I am trying to understand how future-proofing would work in today's fast build (scrum) and fast build (Scrum again) work environment. You have your stories that the program management folks pick from for each scrum and they very rarely give you an opportunity to read stories that are not in the current scrum. Even As a lead I was seldom given a look at the whole project, at most a month ahead an I don't believe Future-Proofing for 30 days would add enough value to make it worth while. Even as far down the road as 30 days may seem, we all know how fast code can change and how ideas can change even 30 Days out. You would need to capture current and future requirements and some how freeze them to make it worth while or you would be pulling future code as fast as you were writing now code.
I am afraid that Agile Program Management my well make even the Idea of Future-Proofing obsolete just as it has waterfall and a whole whole host of others.
Have a good day and I hope my attempt with out the sarcasm is of some merit to the conversation.
Perhaps that is relative to the workplace, we are fairly self governing at Dyson. The team has an awareness of what's coming, we pick our tickets in sessions it's fairly open. I don't have any other experience to compare it to but I suppose agile works differently everywhere.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.