A colleague argued that Mastodon would not support conversations as it lacks quote-tweet equivalent. I suspect that there are some visibility constraints that disrupt conversations from some vantage points. I will capture the text of one interesting conversation and use it as a test case by sharing this with my colleagues. post 
The conversation went on too long for a screenshot. I used the debugger to find the div that held the text, $0, then copied out the paragraphs within.
copy( [...$0.querySelectorAll('p')] .map(p => p.innerText) .join("\n\n<p>") )
text
@jaymcgrath Yes, but the question is what could people like me have done to prevent that.
@marick @jaymcgrath I'm pretty sure the Achilles heel of agile was the implicit assumption of good intent and competence on the part of management. Without those, the same tools that were supposed to reduce pointless meetings and passive agression actually increase them considerably. My experience with not terrible but not good management under pseudo-agile was significantly worse than with gant charts.
Probably there needs to be a renaissance of the same insights behind agile, but informed by the big failings of the last 20 years: management with ill intent, and the outsized arrogance of everyone around programming
@marick @jaymcgrath I think both of those two were enough in evidence by the late 90's, that one could have tried to anticipate them. But I'm certainly not blaming yous for not having done so: I remember the development culture of the time, and the amount of things being taken on was significant enough as it was
@tfb @jaymcgrath Well, it’s interesting. I’d say that ~2000 Agile had, at best, an ambivalent relationship to management. My opinion toward management was that you must deliver valuable software at frequent intervals *so that they leave you alone*. I think that was pretty common.
The whole “alignment on business value” thing came later. The original focus (I believe) was trying to help the actual person representing the business.
@marick @tfb @jaymcgrath I do agree this is probably the weakest aspect that goes way back. As a result agile was often implemented as a “fix” or solution for a technical delivery silo either directly brought in by management or approved by management whereas it needed to be a trust building joint venture with shared objectives. Regular delivery may help in part, but it won’t magically enable everyone to understand that the business side and technical side working together, building trust and forming a joint set of objectives and understanding of the challenges is a (if not *the*) fundamental part of working more effectively.
@MatthewPCooke @tfb @jaymcgrath I’m afraid I disagree. My story of Agile is that it was an attempt to buy the permission to create software the way the team thought they should (by promising to disappoint the business less – and delivering on that promise).
The original focus on the business was a focus on a *person* – the product owner / customer– who was a *person* attached to the team and whom people in the team wanted to please. …
@MatthewPCooke @tfb @jaymcgrath … I just don’t believe that the early lightweight teams felt they needed to be “aligned with the business” (rather than with a person) in anything more than an abstract, aspirational way. My personal opinion is that the idea that teams should specifically attend to “business value” had potential in theory but failed in practice enough that we can declare it a Bad Idea.
@marick @MatthewPCooke @tfb @jaymcgrath
My objective (before and after agile) has long been to help make *this group of business people I happen to be working for* more successful at *whatever they want to do.*
Is it "good for their overall corporation or business," as "business value"?
I don't really care.
They can be out to sabotage the rest of their company, for all I care. I'm there and being paid to help *these people* achieve what they want. I'm a mercenary.
...
@marick @MatthewPCooke @tfb @jaymcgrath
If *these people who I'm being paid to enable* are *not aligned with the rest of /their/ business*, well, ... That's Not My Problem. Their superiors should worry about that, if it causes them issues.
@JeffGrigg @marick @tfb @jaymcgrath I imagine from a practical perspective in larger companies there is a limit to how widely you can resolve or improve organizational dysfunctionals. So perhaps holding together one part of an org long enough to win a battle with another part of the same org is the best achievable outcome
@JeffGrigg @MatthewPCooke @tfb @jaymcgrath You’d expect the management types to be focused on individuals and the programmers to be focused on abstractions, but it ended up the programmers who cared about “Nick, that person over there” and the management-types got wrapped up in the abstract and ineffable “business value”.
@marick @JeffGrigg @tfb @jaymcgrath yes you might think that should be owned by “management”. But I think it’s much less likely management would be focused on it than you might think and that’s because most of the problems stem from silos and fundamental attribution error (FAE). As a result people promoted into senior positions in most silos then ideally need to collaborate across silos. It is very easy conflict avoid with cross silo peers and/or decide your peers in other silos are all arseholes due to FAE which often means management is actually the least trusting and most dysfunctional part of the org (at least in terms of people dynamics). That they suffer the issues themselves even more than dev doesn’t leave them in a strong position to diagnose or resolve the issues as part of an Agile rollout.
@marick @tfb @jaymcgrath I wasn’t very clear in my original message, I agree completely with what you describe as early Agile and how it’s turned out. I’m just saying that the need to “buy the permission to create software well” and concept of pleasing a “product owner” are tools that can be used to try and address an exceptionally common organizational dysfunction. I’m just commenting that that dysfunction was not really talked about much in official early Agile methods but it still exists today and it is what I suspect of preventing many teams from effectively self organising, delivery value and generally reaping the benefits of other Agile ideas.
.