A colleague argued that Mastodon would not support conversations as it lacks quote-tweet equivalent. I (Ward) 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. post
@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.
@marick @tfb @jaymcgrath I’m not saying “shared ownership of business value” is a magical fix to organizational dysfunction, (It may be a common outcome in an effective organisation). More fundamental is trust between the business side and technical parts of the business so they can effectively work together. I suspect some early teams had (or achieved) this - at least in their part of the business.
@MatthewPCooke @tfb @jaymcgrath Yes, but I am pretty resolute that trust can only be built through repeated action.
@marick @tfb @jaymcgrath agreed. It’s quite easy for me to sit here and say that it was clear early on that the wider Agile rollout was going to be a total car crash but as confident as I am in that fact, I’m totally lacking confidence that there was a way to generically rollout something so broadly in a way that would address or avoid the typical org dysfunctions that would ultimately make so many people curse it - that’s why I hated the idea of doing Agile consulting or working for an org doing an Agile transformation.
@marick @tfb @jaymcgrath but i assume if I had gone into an Agile conversion business to try and help I’d have to assume it would be a very long term gig (if I wanted a good chance at going agile well) with incredibly slow introduction of Agile, and huge amounts of working on context/people specific stuff and trust building. Looking at agile as more a toolkit of ideas once all key people were agreed on the main challenges and actually in a position to genuinely jointly try to improve their situation.
@marick @tfb @jaymcgrath and doing all that is a million miles from something that can be easily scaled up for a global rollout and taught in a two day Agile coach training programme (or whatever) It’s not hugely scaleable or sellable!
@marick @tfb @jaymcgrath perhaps a list of the types of behaviours and dysfunctions that if very heavily present in an org would likely cause an Agile adoption to fail. Then perhaps lots of orgs might have said “oh man this Agile shit basically says it requires a mythical kind of company that doesn’t actually exist anywhere so it’s probably bollocks” that might have helped save the reputation of Agile and a lot of hurt - although someone might still have sold them a different version not branded as Agile.
@marick @tfb @jaymcgrath Although there was no original “danger signs” list, a different version of Agile was rolled out to everyone than what was intended, as was pointed out repeatedly by Martin Fowler (and surely many others) in his posts about the Agile Industrial Complex and its habit of imposing process etc, So I’m not actually sure if earlier warnings would have helped
@MatthewPCooke @tfb @jaymcgrath One of the things I liked about the original XP book is that, in the preface or introduction, it said “XP is for teams that ”. I don’t know if that had an effect.
@marick @tfb @jaymcgrath I love the original XP book I’ll pull out a copy and look. Maybe my suitability checklist/warnings idea *already* worked and that’s why no one adopted XP after reading it!
@marick @tfb @jaymcgrath it says it’s for small teams faced with vague and changing requirements on the back. Maybe that had some impact since small teams have less money to pay for agile conversions than large orgs!
@MatthewPCooke @tfb @jaymcgrath Interesting… I think there was a lot of small-team action in the early Agile space, though I note that the highly influential C3 and Fidelity projects were funded enough that a reasonably expensive consultant/coach was brought in to help.
It does seem to me that, after that phase of history, successful projects were driven and “funded” bottom-up.
@MatthewPCooke @tfb @jaymcgrath I think you’re right. Early Agile people were, for the most part, afraid of antagonizing management, so they – we – didn’t suggest that they had work to do, too.
Early Scrum people were fond of this anecdote:
A chicken said to a pig, let’s start a restaurant. We’ll call it “Bacon and Eggs”. The pig declined, saying “You’d just be involved, but I’d be *committed*.” …
@MatthewPCooke @tfb @jaymcgrath … I used that effectively to reduce (well-intentioned, in the main) management tampering with team activities like estimates. So I was a bit bemused when people started calling it divisive. It’s long gone from Scrum, I believe.
@marick "trying to help the actual person"
@tfb @jaymcgrath
@tfb @marick @jaymcgrath yes, totally. I joined the Agile movement prior to the term Agile being defined, and I think it was pretty obvious that the wide Agile rollout would not work due to common organizational dysfunctions that were broader than Agile was trying to address. Just talking to people trying to adopt Agile and what their work environments were like and I immediately decided I never wanted to coach or help with agile adoption because most companies that wanted to buy in help were too dysfunctional way beyond the software dev process.
@MatthewPCooke @tfb @jaymcgrath It’s funny. Once I was brought in as a spare coach in a “roll Scrum out across the organization” effort. I had an epiphany when a programmer said that what the rollout had accomplished was that “at least my job doesn’t suck as much as it used to”.
That was when I started to edge away from coaching. Ironically, it seems that may have been an unusually *good* result.
@marick Meet the new boss, same as the old boss.
@marick
I think we need to read Animal Farm again...
@marick In the early days, what size were the largest companies that “did agile right”? My impression from third-hand sources was always that agile was mostly adopted by small high-functioning teams in tech-focused companies, and that most people dealing with terrible “agile” these days are working for large bureaucratic institutions that are intentionally structured in a way that limits the decision-making impact of individual teams. Is that at all accurate?
@jnkrtech My impression is different, perhaps biased because I was most aware of the Agile people who’d done the Smalltalk–>Patterns–>Agile transition. Because of that, my impression was that Agile sprang from specific teams in *non*-tech-focused companies. Chrysler and “a large Boston-based mutual fund company” got a lot of attention. In the UK, Agile was associated with financial firms (what else does London do?) which weren’t tech-focused like, say, Google, I think.
@jnkrtech A significant early Agile project applied XP to the aftermath of the 9/11 Twin Towers terrorist attack. If I remember right, it involved using DNA evidence to identify remains. Fast iterations. Changing requirements. Close collaboration.
My impression from the early days was that the software-centric companies were most hostile to Agile. I gave a talk to Google, pre-IPO. They were not impressed.
@jnkrtech I’m not able to comment on the state of things today.
@marick This is really great information and is definitely news to me, thanks!
The reason I ask is that if the complaints about agile are the same as the complaints about waterfall, then I wonder less “how did agile lose its way” and more “what structural similarities are there between organizations pre-agile and post-agile?” I want to wave my hands and say something vague about the employer/employee relationship, but if I’m being honest I haven’t connected the dots well enough to make an actual argument.
@jnkrtech I think you are correct to think that power dynamics had (much) more of an affect than did the content of Agile.
@marick It's threads like this that convinces me the word "agile" is irreversibly corrupted. It will not communicate what we intend it to communicate.
In this environment, I don't think there's any effective way to talk methodology without going immediately into the specifics.
.