12 ms·

The root problem in my estimation is that people want a boilerplate bureaucratic process which they can follow and achieve good enough™ results. A lot of the a

The root problem in my estimation is that people want a boilerplate bureaucratic process which they can follow and achieve good enough™ results. A lot of the activities done in agile or scrum or whatever processes are potentially useful tools in specific situations. But people don't want to understand the history and reasoning behind the tools nor do they want to apply them judiciously as appropriate. They want a one size fits all process that produces results, if not optimally, at least consistently. And whatever Agile flavor of the month is popular is just that, it's good enough. And the benefit is that you get this fun mind trick to deflect blame ("I don't know what happened we followed the process. People don't fail processes do.") or ("I'll tell you what went wrong we didn't follow the xzy process. If we had just agiled a little harder this project would have shipped on time").

lowbloodsugar 4y ago
And the boiler plate process thinking is the literal opposite of agile.
matchagaucho 4y ago
Most companies will go through 1-2 agile boilerplates before defining, building and owning their own process. If a team moves onto a 3rd boilerplate, they've missed the premise of agile retrospectives.
dilyevsky 4y ago
+1 the problem is the management’s desire for modern day taylorism. Once that line of thinking sets in it really doesn’t matter which process you pick it’s still going to suck
- tharkun__ 4y ago
  And it works so well with metrics! S.M.A.R.T, right? Wrong! Goodhardt's law. Once you put any sort of pressure on the metric, it collapses. Deliver X story points per sprint? WTF? That is not the spirit of agile. That is Big Corp subverting what agile was trying to subvert from big Corp Man Days in the first place.
nradov 4y ago
Organizations that adopt one of the better bureaucratic processes like Scaled Agile Framework (SAFe) do actually ship on time. What they ship might have quality problems or fail to meet customer requirements, but at least they ship something. For some organizations that alone is a huge step forward and can put them on a path to additional improvements.
alexashka 4y ago
The problem is making people who can't do the actual work into managers. It's really a class problem. Rich people don't want to associate with those filthy poors unless they get to be above them, so they created MBA programs and a managerial class.
- jshen 4y ago
  This is completely wrong.
  - nier 4y ago
    Both of you are right.
keyraycheck 4y ago
+1 I went all the way from Agile maximalist to common sense-ist. For me agile these days is simply: - talk to your team to sync often but short - seek feedback (from stakeholders, ideally users) - allocate time to work on your backlog so it nice and tidy and technical stuff: - release early, release often (i.e. CI/CD/devops stuff) - automated testing, regular code reviews - refactoring, working with small commits/PRs More a common sense, than a "process" or "ideology".
- jshen 4y ago
  I agree with this, but it misses the thing many teams need and that is a process to reliably hit dates they commit to.
  - lmm 4y ago
    95% of the time the reason teams "need" that is bullshit internal politics and everyone is better off if you can structure the organisation to not do that.
    - jshen 4y ago
      This is not true for most. Imagine going to a contractor to get a house built and they tell you that they can’t tell you what it will cost or when it will be done.
      - foepys 4y ago
        I don't know about the US but in Germany this is already the case. You get a rough estimate but nothing is set in stone. Overshooting deadlines and increasing costs due to materials not being available or them suddenly costing twice as much is normal. Also coordination between all the various contractors is always getting messed up because the person putting up the scaffolding didn't show up, so the plumber cannot work and cannot come back for 3 weeks, which messes up the plan for the drywall, which gets pushed back, and so on.
tootie 4y ago
Having lived through a lot of different orgs, following all the rigor of textbook scrum is like training wheels for effective agile. Running with true agility and without the ceremonies requires a disciplined team. I've seen some undisciplined, immature and just flat out mediocre teams that will just flounder without the training wheels. I've seen plenty of highly disciplined teams that have really internalized the meaning of agile delivery and don't need to be told all the steps and will actually self-organize. You just have to calibrate your level of rigidity for who your team is.
- dalyons 4y ago
  i think this is a very insightful take which i totally agree with. Although I have also seen many high functioning teams who could have reached self-organizing/self-whatever, but they arent allowed to raise to that next level because the scrum orthodoxy is mandated/unquestionable. Its frustrating.
  - tootie 4y ago
    Yeah I think the common storyline is that a manager who was trained in an immature organization and has seen the training wheels approach be successful decides that they can repeat their success by following the same steps every single time. To be a good manager to have to manage to your team, not to a set of rules. That's not easy for a lot of people.
rukuu001 4y ago
Oh yes. The people crying about 'bad agile' haven't accepted most people just don't care about captital-A Agile at all. They just want to clear their Jira tickets and go home. Modern agile processes are designed for those people.
oxfordmale 4y ago
>> If we had just agiled a little harder This shows the uncanny parallel between Agile and religious sects. If you agiled and failed, you should have agiled harder. Or, even better, part with your hard-earned cash on Agile coaches to show you the one True Path™. There is only one canonical work, be it a relatively short one, the Agile Manifesto. However, there are multiple interpretations, with each faction claiming they are the one True Path™ to reach enlightenment. Each of these factions has culturally appropriated existing concepts, such as daily stand-ups and backlogs, and claims these are unique to their implementation of Agile. That leaves you to wonder how developers managed in the dark ages, before the Agile revolution. Did developers chuck out unassigned tickets with their poo buckets on the streets? Could they only deliver Babylonian towers as they lacked a way to communicate with each other daily?
penguinvondoom 4y ago
IMO the main problem is in the very way organisations are structured - it is about power, and people (really meaning management) want to achieve good enough results, given that their control is maintained. Agile as aesthetics is cool, but actual implementations move power away from management and we can't have that. So we will rebrand project managers to POs and whatever managers to scrum masters, and will follow the rituals as long as they don't get in the way of normal run of things. Agile was grounded on solid principles, but is very ideologically naive, which allowed its easy cooption by consultants and management.
- MrBuddyCasino 4y ago
  This is a very good summary. The universal formulation of this is Pournelle's Iron Law of Bureaucracy [0]. Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people: First, there will be those who are devoted to the goals of the organization. Examples are dedicated classroom teachers in an educational bureaucracy, many of the engineers and launch technicians and scientists at NASA, even some agricultural scientists and advisors in the former Soviet Union collective farming administration. Secondly, there will be those dedicated to the organization itself. Examples are many of the administrators in the education system, many professors of education, many teachers union officials, much of the NASA headquarters staff, etc. The Iron Law states that in every case the second group will gain and keep control of the organization. It will write the rules, and control promotions within the organization. [0] https://www.jerrypournelle.com/reports/jerryp/iron.html https://www.jerrypournelle.com/reports/jerryp/iron.html
  - nopassrecover 4y ago
    This whole trail through to the top comment is spot on. It's also helped me work out a corollary in my mind that has puzzled me for a bit. My sense, in the Marxist tradition, is that modern organisations are dependent on the extraction of value from highly capable technical resources and, especially outside the tech bubble, they largely resent this dependency. Let's say developers are an example of a highly capable technical resource, though I am by no means limiting the scope. This results in a series of mechanics that lead to developers being alienated: - From the product of their development (ownership of IP and the resultant value of their code, distance from seeing the positive impacts of their work or talking to those it helps) - From the act of developing itself (by its reduction to commercial use and control over how it is done, approval gates, arbitrary coding standards, ticket systems, scrum processes, project managers and product owners, Jira, timesheets etc.) - From their fellow workers (stack ranking, power dynamics, labour competition, structural organisational tension) - From their human nature and natural talent (by the reduction of their humanity and passion and capability to a mere "developer" or "engineer", use of stereotypes, reduction of humanity to output/LOC/story points delivered, corporate gaslighting at questioning this state of affairs etc.) And most non-developer people that have worked in an average organisation and spent much time with developers have seen all of this at play, and heard how much developers hate it. Yet many still refuse, even in the face of self-interest (e.g. faster delivery of outcomes for a non-technical manager), to empathise and accept the reality of the experience enough to support better workplaces for developers. A tangible recent example is the insistence with all sorts of reasons on getting developers back into the office where they can be watched despite demonstrably lower productivity and engagement. My sense of this is that what developers can bring to the modern world is the closest humanity has got to magic. And this dependency is resented. And this resentment leads to workplaces in which this resentment is externalised in the form of debasement (e.g. caricatures and other forms of ego compensation - "they're just the boffins, they don't have people skills!"), control ("the boffins can't really be trusted - better add some process and oversight, and given they don't have the people skills better make sure they aren't anywhere near management/clients!"), and dependency inversion ("sure the boffins can do their coding stuff, but they'd be nothing without us to help babysit and organise things, they don't get the way the world works, clearly it's they who actually need us!"). And this environment in turn leads developers to internalise this systemic resentment as a resentment of themselves, their capability, and their work, aka burnout. But one question has been bubbling away for me for a while. How do so many organisations arrive at a system in which it's almost a badge of honour to not be one of the doers? That those who can't do, should, as a moral claim, oversee, and manage, and lead? And we should keep adding more of those people until the doers can't possible do. Even when that produces lower tangible results. Maybe at one point I internalised the Office Space / IT Crowd idea - the non-doers are "people people" who didn't spend decades at their PCs honing their craft but instead went to wild parties and focused on normal people stuff (the implication of course being that developers are lesser than normal people). Maybe the developers really can't be trusted. Maybe they do need to be managed and watched and distanced. Maybe the code monkey caricature (before being reclaimed by those it was used to demean) is right. But now I wonder. What if those people are empowered by the systems into positions of power over developers because in the first instance they affirm the original resentment: what if putting non-doers in charge safely perpetuates the idea that the developers belong at the bottom of the pyramid and affirms the extraction of their labour in support of the salaries and profits of those above relying on it? Or to put it another way, what if the code monkey caricature is effectively a justification of Marxist exploitation? And what if the second order effect here is that some, let's call them the senior management class - leaders of the Second order of Pournelle's Iron Law of Bureaucracy in the example above - are more conscious of these dynamics and consciously perpetuating them. What if they are knowingly hiring more non-doers to help keep this balance and control. What if it's not accidental, or people skills, that means non-doers are in charge? What if the very reason they're there in the first place is to be in charge even in positions outside of formal leadership (or at least indirectly support the power of someone else who brought them in for that reason) - after all they're not there to do. So to close out a long post, a corollary to Pournelle's Iron Law of Bureaucracy: in any bureaucratic organisation the ability to be able to contribute to the goals of the organisation will be an insurmountable barrier to having influence or control within it.
saiya-jin 4y ago
People want to minimize complexity in their lives, the less you understand the topic the more you want some magic 1-click/effort solution. It can be software dev, politics or anything else. That's why populism is so damn effective on masses who often wouldn't be even able to articulate properly current internal and global political/economical/whatever situation, yet have very strong opinions how these things should be.
dustedcodes 4y ago
> They want a one size fits all process that produces results, if not optimally, at least consistently I disagree with this statement. Waterfall produced good enough results. What they really want is the most meeting and process heavy approach irrespective of results, because those who advocate for Agile are the people who have no real job and this gives them enough bullshit to bs themselves through every day of their work week.
- wkat4242 4y ago
  Waterfall was good in a time where requirements were more static. It's not great when you don't know the requirements fully or they may change during the project. I'm not a fan of agile either though. I'm not a team player and agile is way too heavy on the framework side for me. Too many procedures and too much fuss around the work. Just give me a task and let me get on with it. But some parts of it are ok like close collaboration with the (internal) client. Luckily I work for a company that thinks logging our hours in Jira means we're agile so I don't really have a lot to do with it.
sigg3 4y ago
> They want a one size fits all process that produces results, if not optimally, at least consistently. There's an additional perhaps even more important aspect contributing here: the sociality of language and shared values in technology as social communities. IMO If it hadn't been agile it would have been something else; we build common understandings with the terminology we have available, in order for our activities to make sense. It doesn't matter if the terminology is applied correctly, viz. adhering to the theory (although many escape this accusation by a tacking "hybrid" onto everything). What matters is practical applicability: when we use these terms we're more often understanding rather than misunderstanding each other. So the terms are used in more abstract ways than intended. (E.g. agile as methodology in health bureaucracy is kinda weird.)
Tycho 4y ago
I said to our CTO that I found the Agile practices we had recently adopted a bit annoying, and his reply was “look, Agile is bullshit, but what it gives us is standardisation across teams.”
rahoulb 4y ago
Not least - the Agile Manifesto states "favour people over processes" - by definition, there isn't a fixed process that you should be following as it will change whenever people are added to or leave the team. This is the exact opposite of what companies want - consistency with (most) people being interchangeable.

lowbloodsugar 4y ago

And the boiler plate process thinking is the literal opposite of agile.

matchagaucho 4y ago

Most companies will go through 1-2 agile boilerplates before defining, building and owning their own process. If a team moves onto a 3rd boilerplate, they've missed the premise of agile retrospectives.

dilyevsky 4y ago

+1 the problem is the management’s desire for modern day taylorism. Once that line of thinking sets in it really doesn’t matter which process you pick it’s still going to suck

tharkun__ 4y ago
And it works so well with metrics! S.M.A.R.T, right? Wrong! Goodhardt's law. Once you put any sort of pressure on the metric, it collapses. Deliver X story points per sprint? WTF? That is not the spirit of agile. That is Big Corp subverting what agile was trying to subvert from big Corp Man Days in the first place.

nradov 4y ago

Organizations that adopt one of the better bureaucratic processes like Scaled Agile Framework (SAFe) do actually ship on time. What they ship might have quality problems or fail to meet customer requirements, but at least they ship something. For some organizations that alone is a huge step forward and can put them on a path to additional improvements.

alexashka 4y ago

The problem is making people who can't do the actual work into managers. It's really a class problem. Rich people don't want to associate with those filthy poors unless they get to be above them, so they created MBA programs and a managerial class.

jshen 4y ago
This is completely wrong.
- nier 4y ago
  Both of you are right.

keyraycheck 4y ago

+1 I went all the way from Agile maximalist to common sense-ist. For me agile these days is simply: - talk to your team to sync often but short - seek feedback (from stakeholders, ideally users) - allocate time to work on your backlog so it nice and tidy and technical stuff: - release early, release often (i.e. CI/CD/devops stuff) - automated testing, regular code reviews - refactoring, working with small commits/PRs More a common sense, than a "process" or "ideology".

jshen 4y ago
I agree with this, but it misses the thing many teams need and that is a process to reliably hit dates they commit to.
- lmm 4y ago
  95% of the time the reason teams "need" that is bullshit internal politics and everyone is better off if you can structure the organisation to not do that.
  - jshen 4y ago
    This is not true for most. Imagine going to a contractor to get a house built and they tell you that they can’t tell you what it will cost or when it will be done.
    - foepys 4y ago
      I don't know about the US but in Germany this is already the case. You get a rough estimate but nothing is set in stone. Overshooting deadlines and increasing costs due to materials not being available or them suddenly costing twice as much is normal. Also coordination between all the various contractors is always getting messed up because the person putting up the scaffolding didn't show up, so the plumber cannot work and cannot come back for 3 weeks, which messes up the plan for the drywall, which gets pushed back, and so on.

tootie 4y ago

Having lived through a lot of different orgs, following all the rigor of textbook scrum is like training wheels for effective agile. Running with true agility and without the ceremonies requires a disciplined team. I've seen some undisciplined, immature and just flat out mediocre teams that will just flounder without the training wheels. I've seen plenty of highly disciplined teams that have really internalized the meaning of agile delivery and don't need to be told all the steps and will actually self-organize. You just have to calibrate your level of rigidity for who your team is.

dalyons 4y ago
i think this is a very insightful take which i totally agree with. Although I have also seen many high functioning teams who could have reached self-organizing/self-whatever, but they arent allowed to raise to that next level because the scrum orthodoxy is mandated/unquestionable. Its frustrating.
- tootie 4y ago
  Yeah I think the common storyline is that a manager who was trained in an immature organization and has seen the training wheels approach be successful decides that they can repeat their success by following the same steps every single time. To be a good manager to have to manage to your team, not to a set of rules. That's not easy for a lot of people.

rukuu001 4y ago

Oh yes. The people crying about 'bad agile' haven't accepted most people just don't care about captital-A Agile at all. They just want to clear their Jira tickets and go home. Modern agile processes are designed for those people.

oxfordmale 4y ago

>> If we had just agiled a little harder This shows the uncanny parallel between Agile and religious sects. If you agiled and failed, you should have agiled harder. Or, even better, part with your hard-earned cash on Agile coaches to show you the one True Path™. There is only one canonical work, be it a relatively short one, the Agile Manifesto. However, there are multiple interpretations, with each faction claiming they are the one True Path™ to reach enlightenment. Each of these factions has culturally appropriated existing concepts, such as daily stand-ups and backlogs, and claims these are unique to their implementation of Agile. That leaves you to wonder how developers managed in the dark ages, before the Agile revolution. Did developers chuck out unassigned tickets with their poo buckets on the streets? Could they only deliver Babylonian towers as they lacked a way to communicate with each other daily?

penguinvondoom 4y ago

IMO the main problem is in the very way organisations are structured - it is about power, and people (really meaning management) want to achieve good enough results, given that their control is maintained. Agile as aesthetics is cool, but actual implementations move power away from management and we can't have that. So we will rebrand project managers to POs and whatever managers to scrum masters, and will follow the rituals as long as they don't get in the way of normal run of things. Agile was grounded on solid principles, but is very ideologically naive, which allowed its easy cooption by consultants and management.

MrBuddyCasino 4y ago
This is a very good summary. The universal formulation of this is Pournelle's Iron Law of Bureaucracy [0]. Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people: First, there will be those who are devoted to the goals of the organization. Examples are dedicated classroom teachers in an educational bureaucracy, many of the engineers and launch technicians and scientists at NASA, even some agricultural scientists and advisors in the former Soviet Union collective farming administration. Secondly, there will be those dedicated to the organization itself. Examples are many of the administrators in the education system, many professors of education, many teachers union officials, much of the NASA headquarters staff, etc. The Iron Law states that in every case the second group will gain and keep control of the organization. It will write the rules, and control promotions within the organization. [0] https://www.jerrypournelle.com/reports/jerryp/iron.html https://www.jerrypournelle.com/reports/jerryp/iron.html
- nopassrecover 4y ago
  This whole trail through to the top comment is spot on. It's also helped me work out a corollary in my mind that has puzzled me for a bit. My sense, in the Marxist tradition, is that modern organisations are dependent on the extraction of value from highly capable technical resources and, especially outside the tech bubble, they largely resent this dependency. Let's say developers are an example of a highly capable technical resource, though I am by no means limiting the scope. This results in a series of mechanics that lead to developers being alienated: - From the product of their development (ownership of IP and the resultant value of their code, distance from seeing the positive impacts of their work or talking to those it helps) - From the act of developing itself (by its reduction to commercial use and control over how it is done, approval gates, arbitrary coding standards, ticket systems, scrum processes, project managers and product owners, Jira, timesheets etc.) - From their fellow workers (stack ranking, power dynamics, labour competition, structural organisational tension) - From their human nature and natural talent (by the reduction of their humanity and passion and capability to a mere "developer" or "engineer", use of stereotypes, reduction of humanity to output/LOC/story points delivered, corporate gaslighting at questioning this state of affairs etc.) And most non-developer people that have worked in an average organisation and spent much time with developers have seen all of this at play, and heard how much developers hate it. Yet many still refuse, even in the face of self-interest (e.g. faster delivery of outcomes for a non-technical manager), to empathise and accept the reality of the experience enough to support better workplaces for developers. A tangible recent example is the insistence with all sorts of reasons on getting developers back into the office where they can be watched despite demonstrably lower productivity and engagement. My sense of this is that what developers can bring to the modern world is the closest humanity has got to magic. And this dependency is resented. And this resentment leads to workplaces in which this resentment is externalised in the form of debasement (e.g. caricatures and other forms of ego compensation - "they're just the boffins, they don't have people skills!"), control ("the boffins can't really be trusted - better add some process and oversight, and given they don't have the people skills better make sure they aren't anywhere near management/clients!"), and dependency inversion ("sure the boffins can do their coding stuff, but they'd be nothing without us to help babysit and organise things, they don't get the way the world works, clearly it's they who actually need us!"). And this environment in turn leads developers to internalise this systemic resentment as a resentment of themselves, their capability, and their work, aka burnout. But one question has been bubbling away for me for a while. How do so many organisations arrive at a system in which it's almost a badge of honour to not be one of the doers? That those who can't do, should, as a moral claim, oversee, and manage, and lead? And we should keep adding more of those people until the doers can't possible do. Even when that produces lower tangible results. Maybe at one point I internalised the Office Space / IT Crowd idea - the non-doers are "people people" who didn't spend decades at their PCs honing their craft but instead went to wild parties and focused on normal people stuff (the implication of course being that developers are lesser than normal people). Maybe the developers really can't be trusted. Maybe they do need to be managed and watched and distanced. Maybe the code monkey caricature (before being reclaimed by those it was used to demean) is right. But now I wonder. What if those people are empowered by the systems into positions of power over developers because in the first instance they affirm the original resentment: what if putting non-doers in charge safely perpetuates the idea that the developers belong at the bottom of the pyramid and affirms the extraction of their labour in support of the salaries and profits of those above relying on it? Or to put it another way, what if the code monkey caricature is effectively a justification of Marxist exploitation? And what if the second order effect here is that some, let's call them the senior management class - leaders of the Second order of Pournelle's Iron Law of Bureaucracy in the example above - are more conscious of these dynamics and consciously perpetuating them. What if they are knowingly hiring more non-doers to help keep this balance and control. What if it's not accidental, or people skills, that means non-doers are in charge? What if the very reason they're there in the first place is to be in charge even in positions outside of formal leadership (or at least indirectly support the power of someone else who brought them in for that reason) - after all they're not there to do. So to close out a long post, a corollary to Pournelle's Iron Law of Bureaucracy: in any bureaucratic organisation the ability to be able to contribute to the goals of the organisation will be an insurmountable barrier to having influence or control within it.

saiya-jin 4y ago

People want to minimize complexity in their lives, the less you understand the topic the more you want some magic 1-click/effort solution. It can be software dev, politics or anything else. That's why populism is so damn effective on masses who often wouldn't be even able to articulate properly current internal and global political/economical/whatever situation, yet have very strong opinions how these things should be.

dustedcodes 4y ago

> They want a one size fits all process that produces results, if not optimally, at least consistently I disagree with this statement. Waterfall produced good enough results. What they really want is the most meeting and process heavy approach irrespective of results, because those who advocate for Agile are the people who have no real job and this gives them enough bullshit to bs themselves through every day of their work week.

wkat4242 4y ago
Waterfall was good in a time where requirements were more static. It's not great when you don't know the requirements fully or they may change during the project. I'm not a fan of agile either though. I'm not a team player and agile is way too heavy on the framework side for me. Too many procedures and too much fuss around the work. Just give me a task and let me get on with it. But some parts of it are ok like close collaboration with the (internal) client. Luckily I work for a company that thinks logging our hours in Jira means we're agile so I don't really have a lot to do with it.

sigg3 4y ago

> They want a one size fits all process that produces results, if not optimally, at least consistently. There's an additional perhaps even more important aspect contributing here: the sociality of language and shared values in technology as social communities. IMO If it hadn't been agile it would have been something else; we build common understandings with the terminology we have available, in order for our activities to make sense. It doesn't matter if the terminology is applied correctly, viz. adhering to the theory (although many escape this accusation by a tacking "hybrid" onto everything). What matters is practical applicability: when we use these terms we're more often understanding rather than misunderstanding each other. So the terms are used in more abstract ways than intended. (E.g. agile as methodology in health bureaucracy is kinda weird.)

Tycho 4y ago

I said to our CTO that I found the Agile practices we had recently adopted a bit annoying, and his reply was “look, Agile is bullshit, but what it gives us is standardisation across teams.”

rahoulb 4y ago

Not least - the Agile Manifesto states "favour people over processes" - by definition, there isn't a fixed process that you should be following as it will change whenever people are added to or leave the team. This is the exact opposite of what companies want - consistency with (most) people being interchangeable.