Hi -

Some insightful observations again (IMO)! You definitely have some depth in these issues.

In Carl's projects, keeping the tests up to date was not much different than today. If something changed and a test broke, we discovered it the next day when looking at the results of the night's test run. It was nightly cadence CI.

Writing the code for that was not hard to justify: back then, programmers did not have to justify what they did: they just did it. Their progress on "stories" was not tracked every morning.

So I decided that instead of us looking over results manually, I would write a program to scrape the output files, determine pass or fail, and add that to a VAX relational database. It took me a day or two to write the code. Carl thought it was a great idea - it would save us a lot of time - so no issue there.

Carl had the latitude to manage the project/team as he saw fit. And he was very much a systems thinker.

The observation you made this time that I think is very astute was "most leaders today don't really engage with devs..." I am pretty sure that we talk about that in our Agile 2 book. It is true. Agile has given us a (deficient) model of what team "leads" (Scrum Masters) should do, but it has not told us what leads of sets of teams should do, so most development managers who have many teams tend to operate hands-off, and so there is a leadership gap. I have written about that: https://www.linkedin.com/pulse/agile-scale-requires-special-kind-leadership-cliff-berg/

Yes, these open plan offices are terrible. What amazes me is that the pattern really stuck. Ironically, we pay IT people a lot, but then skimp on their desk space.

Re. your question about a compiler language feature backlog, having a backlog of features is one of the "practices" that are considered to be in the Agile "toolbox". Of course that does not "make one agile". But it does give one more flexibility than having those features decomposed into tasks with all those tasks on a master schedule. We could easily change our mind about which features to tackle next, and so rather than discussions being about task dependencies, they tended to be about feature dependencies, which was more meaningful.