Comment by culi
1 day ago
> Toward the end of our time at CAS we experimented with sociocracy as a way to organize without hierarchy and coercion, but despite my enthusiasm for the form, we didn’t start with universal buy-in or understanding from the whole team, we didn’t fully adopt its structures, and, like many democracies before us, we ultimately voted to abolish our own democracy when we formed the “leadership circle” and created a hierarchy.
I'm convinced that "what works" when it comes to self-organization is almost always a function of how involved/educated the participants are about the principles. Every time someone on HN complains about agile the typical response is that "they weren't doing agile correctly". And honestly I believe it. I just extend this to most forms of self-organization.
To be clear, I definitely do believe that certain structures are more effective than others for a given goal but I also believe that often the biggest factor in success is the buy-in and investment the members have. I even extend this (admittedly, somewhat reductive) analysis to debates between OOP vs functional codebase structures. If everyone is well versed in "proper" OOP or "proper" functional software design both strategies can be effective. If everyone is sociocracy fanatic then that can certainly work effectively. Because it's not as much about the superstructure as it is about proficiency.
People will often write about something that worked for them, and from that pull out abstractions they believe are generalised and universal. They rarely are.
Organisational patterns that work for startups rapidly iterating to find product market fit won’t work well for a consultancy building a better defined product for a single client, or a corpo IT department trying to shoehorn a new distribution channel through a 30 year old logistics system.
A team of experienced engineers who know the problem domain and have worked together for years needs different organisational structures than a team of new hires and grads. A team of introverted hermits and a team of extroverts will function differently regardless of organisational structure.
You need to have some idea of where ideas work and don’t work before you can design the ones needed for your specific situation.
> Every time someone on HN complains about agile the typical response is that "they weren't doing agile correctly".
The problem is that "agile" is not really a thing. Originally it is just a few sentences saying "have common sense". And it became a big bullshit business with certifications and coaches.
> Every time someone on HN complains about agile the typical response is that "they weren't doing agile correctly".
No true Scotsman would ever ...
The agile methodologies are built around adaptive and corrective iterations of work. If an org is not adapting process, if they are not correcting process issues, they are by definition ‘not doing it right’ because they are fundamentally doing something else.
Agile can/should/must (d)evolve into waterfall in all but name if that’s the local optimum. The agile methodologies response to problems is to solve those issues through frequent iterative localized change. Failing to apply a methodology isn’t a methodological failure, per se.
Business process mislabelling and misdirected frustration about lacking management are not examples of the No True Scotsman fallacy.
Frenchmen are not Scotsmen. Not False Scotsmen nor True Scotsmen. They have a different name for a reason. No matter how many tourists confuse the flags or culture, by definition they are separate and distinct. France and Scotland are literally on different pages in the books.
It is no coincidence there is a ‘typical response’ around this that has not changed for decades. Typical responses are the MBA version of RTFM.
agile has become "no true scotsman", it's impossible to criticize because someone always will get out of woodwork and start yelling you're doing it wrong.
I begin to think the "successful" dev teams using agile don't need agile principles in the first place and would work just fine under any other system, up and including "just a shared text file with all the current ideas and system issues", purely because they are competent at their job.
I always thought the relgious Agile was kind of kooky when it met the real world, but I really think kanban / theory of constraints is very good and real for the business world.
as long as managers don't start slapping KPIs on it
Which is why agile falls apart... ToC/KanBan is
- prioritize - work on top item - goto 1