I see, I see! That is very interesting. I suppose when I think about it, actually running the CI wouldn't have been much different, but I'm very surprised that it only took a day or two to write the code to scrape the output files - presumably it was easy enough to scrape them, but how that translated into checking their correctness so easily is a bit of a mystery to me at the moment. I don't doubt it, I just don't understand it.
If I recall correctly, Robert Propst - the person who created the Herman Miller design that ended up being misused by companies and turned into the cubicle farm that preceded open offices - came to despise his creation. Ironic indeed. In fact, I would argue Agile is actually one of the biggest things to blame for the enigma you mention: that we pay huge salaries to many devs but still put them in open plan offices.
Realistically, if it was purely a decision about office space costs, companies would no longer be using open plan for developers - dev salaries are so much higher that it wouldn't be a serious impact. Instead, Agile has made companies believe that "everyone being in constant face to face contact" is some kind of bonus - that face to face collaboration at all times is a good thing, and therefore that open plan offices are actually good for developers and teams to get work done. We may know that's not true, but corporate management does not (or feigns ignorance for the short-term financial benefits of not moving to a closed office plan). On top of that, it's much harder to prove financially that moving to closed offices benefitted the company (impossible to isolate that from other financial factors), but easy to prove that using open plan saved money by requiring less office space.
Your article that you linked me to is excellent. It hits the nail on the head when it comes to multiple dev teams in companies - things like common CI/CD tool maintenance, staff morale, company tools, all tend to be shifted around permanently as "someone else's problem" if teams are left to themselves, since there's no measurement or performance incentive for teams to take it up as their own problem.
There is definitely a lack of that "servant leadership" style you describe that ought to return; I suppose I would describe it as leaders who 'enable' their teams (I can't say I love how that word is used nowadays, but it's useful here). Unfortunately 'enable' often gets interpreted to mean 'leader who just delegates everything', when in reality it means as much of the leader giving advice and instruction to his team as the other way around. I've been rewatching Merlin in the last few days, and it reminds me somewhat of the traditional view of a king: The king may be the leader, but it is also his duty to serve his people, and his power is nothing without them. A distinctly two-way relationship.
As for the compiler stuff, that makes sense. It seems to come down to how abstract the tasks are and how easy they therefore are to reorder and prioritise, and that in turn would have required good planning at the start to make the project flexible enough to accommodate that.
By the way, I have been reading more extensively into Agile 2, to try and see for myself what I think of its viability as a new "default" for project management. From my analysis it looks very good indeed - I am certainly glad to see that the principles are far from short, and that the primary values do not favour one side of their sentences over another. I do have a question, though.
Principle 2-2 states that "The only proof of value is a business outcome". I am curious to know what conversations took place when this principle was discussed? When I read it, I immediately find myself concerned that it appears to strike a similar chord to the original Agile's "working software over comprehensive documentation" line. Since it does specifically say in this principle that working software is not proof of value, I should explain further what I mean by this.
Suppose we were to implement software for a gaming company; let's say it is a simple web game, that they intend to expand and develop over time. If we measure this software by business metrics or an OKR, we are directly incentivising ourselves not to prioritise making sure that the software is easily scalable and maintainable; this will not show up in the OKR at all, it will not be something the customer can see, and as such nobody will be any the wiser until it is too late.
I *assume* that in the course of discussing this principle, this sort of problem was discussed - and I can certainly agree that given the length of the document, and the fact that other principles make a point of addressing very similar problems such as 'not being a slave to backlog' and 'not committing full capacity', that it is quite a minor point (and that it would be difficult if not impossible to make it fully non-misinterpretable). Still, I am curious to know what the basis of this principle's final text is.
All of that said, Agile 2 looks very good to me - while I do still think that having no framework may be better than replacing Agile, if we are to replace it with a new framework, this would probably be it. When I next have time I will get around to changing the article to formally recommend it as an alternative solution, as I think it does an exceptionally job of balancing the issues in such a way as to prioritise good development as well as being practical in commercial terms.
