8 ms·

Agile Is Dead (2015) [pdf]

65 points by ivanche 9y ago

maxxxxx 9y ago
Agile is a good case study for how good ideas get perverted quickly by consultants and companies. Object orientation also got changed from message passing to elaborate inheritance schemes. People always get confused when I tell that you can do OOP without inheritance besides a few cases.
- noarchy 9y ago
  >Agile is a good case study for how good ideas get perverted quickly by consultants and companies. The points made in the Agile Manifesto having me nodding my head in agreement more often than not. But the implementations, like Scrum, are another matter entirely. It has become a management methodology, further and further removed from the developers. And that comes complete with all of the trappings you'd expect: process for the sake of process, empty metrics (like "velocity") that can be passed up the management chain, and so on.
  - hashkb 9y ago
    Can you say more about how velocity is an empty metric? I'm an IC, sometimes tech lead, (e.g. not management) and j have always found it indispensable.
    - another-dave 9y ago
      Velocity is too often used as a stick to beat people with — "Team B is doing 15 more points that you"; "Last month, we were doing an extra 5 points every sprint, but now we've stagnated — what happened?" The only worthwhile external measure of value is features that the team deliver (i.e. broadly counting improvements to non-functional requirements as features too). Velocity is meant to be constant (in an ideal world) to allow the Product Owner (i.e. someone _inside_ the team) a broad brush to provide estimates on when things may be ready — even used in this way, they depend on a stable team with a velocity that's not too volatile. They shouldn't be shared externally to try and show how productive the team are. For example, I've previously had management ask if our team can try a bit harder & deliver another 30 points per sprint. As points are meaningless outside of the team though, that's a false economy: I think they got the picture when I said our team could deliver another 1,000 points per sprint if they wanted us to.
      - srtjstjsj 9y ago
        Bad management can fail using any methodology. No process will make bad people do good things -- at best it can stop them bad things. The goal for a productivity process is to help good people to great things.
        another-dave 9y ago
        Sure, but the parent was asking for an example of how it could become an empty metric — from my experience, this can happen when it goes outside the control of the team and "Goodhart's law" comes into play — When a measure becomes a target, it ceases to be a good measure. I'm not against meausring velocity, but I think it is a tool best used from within the team rather than from a management level > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    - maxxxxx 9y ago
      Once some managers get hold of velocity numbers they use them as the main metric. "How can increase the number of story points per sprint?" or "Why does dev A finish more story points than dev B?". Then you get all kinds of perverse incentives to game the system. Or: They start comparing story points between teams which in reality is a totally meaningless thing.
  - tootie 9y ago
    Scrum is perfectly fine. In fact, it's a great way to achieve agility. But it only works if everyone understands both the process and the goals. For all the "scrum sucks" posts I've seen, I've yet to see anyone offer anything better.
    - UK-Al05 9y ago
      Simple kanban and communication. Religiously following the 'process' is the opposite of agile. Being able to use your judgement to decide to do something is agile. In scrum you always do the same thing regardless if it's needed. Well in the implementations I've been in.
    - sanderjd 9y ago
      What is better is coming up with a process that is right for your team, based on evaluating what has worked and what hasn't worked. For the teams I've been on, daily stand-ups have been a drag, and it has been a major improvement to eliminate them. Similarly, 100% pair programming has been unpleasant for the majority of the team, and it has been an improvement to stop feeling guilty about doing a lot of solitary programming. The criticism that scrum tries to get you to run a marathon as a series of sprints also resonates with me. It never seemed to allow time for more complex and vaguely defined projects to flourish, but rather we would look back and see an accumulation of short-term thoughts, but little cohesive whole. What has worked for me: code reviews code reviews code reviews, copious automated testing, a prioritized backlog, estimating size of work in some sort of abstract unit, burn downs, demos and retrospectives, short meetings with defined agendas, ignoring anything that makes up terminology, especially if any use of that made-up terminology includes a (TM) superscript.
  - ryandrake 9y ago
    Is there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers? I read this all the time: The agile folks were right about software development, but Scrum/consultants/managers/process sucks! Everyone likes the Agile philosophy but then they all say it's never been implemented right. Reminds me of the "communism is the way--it's just that every time it's implemented it's done wrong!" argument. My criticisms of Agile are: 1. It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress; and 2. it addresses developer needs but does not sufficiently address the requirements of the rest of the organization, including management. Developers gotta develop, but the rest of the business needs things like measurements, reports, status, ETA, sometimes proposals, change requests, etc. A methodology that does not address these artifacts is going to have a hard time fitting in.
    - zdragnar 9y ago
      The agile manifesto was never intended to be a value proposition for the business per se, it was intended to be a promise of professional discipline. You don't ask the business if a refactor is okay, because the business doesn't know how to value or risk it. You refactor because that's what a disciplined professional does, in the course of their work. Think of another profession, if that helps. Teachers don't ask students or administrators if a test would be valuable after a given lesson. Builders don't ask if a hammer would be appropriate for a nail, or if they should use an air gun. There's a certain expectation that they should know and do these things. Scrum works if the scrum master functions as a mediator for the team to collaboratively prioritize work- ideally, this would be a role, not a job title. Scrum fails if the scrum master is just a project manager tasked with making sure the whole backlog entered by the product owner is done on time.
      - sanderjd 9y ago
        I think I agree with you, but I find your analogies quite lacking, which makes me question our shared premise. Teachers absolutely do have the cadence of tests after lessons dictated to them by administrators. Builders absolutely do negotiate with their customers over whether their "implementation" is sufficient or whether it should be "refactored" (ie. partially or completely torn out and re-done to improve the quality). I'm not sure where this leaves things, but it seems to me that the differing incentives and negotiation between stakeholders is perhaps inevitable.
  - OnlyRepliesToBS 9y ago
    It's a religion and all negative implements are always at the fault of the implementer. That is called unfalsifiability.
- ythn 9y ago
  How do you write polymorphic code without inheritance?
  - kcmastrpc 9y ago
    with interfaces? example: see golang
  - falcolas 9y ago
    You use a language that lets you use methods and members of objects without requiring a specific class. Java does this via interfaces, Ruby and Python by not typing the parameters.
    - ythn 9y ago
      Sometimes "use another language" is not a viable option. We are mainly an embedded c++ shop and switching to Java is not an option.
      - tome 9y ago
        Then you inherit from a virtual class, which is not actually inheritance in anything but name.
        bmm6o 9y ago
        This is often expressed as "interface inheritance" vs "implementation inheritance".
  - frou_dh 9y ago
    Interfaces give polymorphism. Implementation inheritance gives method reuse. If you think about the term polymorph ("many shapes"), that describes the world of differing objects that have the opportunity to satisfy an interface.
    - ahartmetz 9y ago
- borplk 9y ago
  It's perverted by the companies first and secondarily by the consultants as the enablers. Most companies have never cared and do not care for anything agile or anything manifesto. For them Agile™ is nothing but a brand name and a weapon that legitimises the way they want to exert power over their employees. They cherry pick elements from the methodology. Change it to their liking and slap the professionally accepted label on it. That's how the pointy-haired manager turns daily standup to daily micro management meeting and daily beatings with a stick. Basically no development methodology survives the conflicts of interest at play in the long run.
  - greenrd 9y ago
    I don't think that's necessarily a case of conflict of interest, but merely misunderstanding what agile methodologies are really about. They're really quite radical.
    - borplk 9y ago
      The reason the methodologies get butchered is partially and substantially because different forces try to pull it to their own side for their own benefit. The behaviour is too sophisticated for it to be merely an innocent misunderstanding. On some level it is being knowingly manipulated and weaponised. It's inevitable because essentially every methodology is a very fuzzy description of a set of ideas and practices so people and groups will interpret it in a way that benefits them.
      - greenrd 9y ago
        Yes, too little attention is paid to the motivations for doing it, and the political obstacles that can be placed in the way - the founders of agile were quite naive about office politics and sociology, in my estimation.
bane 9y ago
Whenever we hire a new Agile practitioner, as part of the interview I ask them to discuss the Agile Manifesto [1]. And then we run through some basic program design and I ask them what tools they bring to help support various program needs. They usually bring out various ceremonies and processes and what not. I then ask them to justify what they've offered against the Manifesto. If they're thoughtful about it (the Manifesto isn't always correct, and if you read it carefully leaves open the need for some of this stuff). If they simply insist it's correct they're cargo culting and we can move on. What I've found is that the ceremonies are appropriately named in that many of the practitioners seem to not know what they're for or why they're done. The teams that seem to really excel are the ones that seem to have thoughtful managers that shape the practices of their dev group to the specifics of their work. The ones that seem to always be bogged down and require huge numbers of staff to get even small amounts of work done seem to be the ones that follow a checklist of getting as many of the agile practice "things" jammed into their work processes as possible. I don't think Agile is dead, but I think it requires smarter team leads who look at what's come out of it as a set of tools to be employed against specific development challenges rather than a religion that needs worshiping. 1 - http://agilemanifesto.org/ http://agilemanifesto.org/
- borplk 9y ago
  I've noticed the same thing. I think it comes from a lack of experience which further creates fear and lack of self-confidence to challenge the practices of the cult. It's also similar to the "nobody got fired for buying IBM" issue. It's "nobody got fired for sticking to the established cult ceremonies". They are people who are afraid and don't care about the team or the company. They are only concerned about their own job security and paycheck. So they never risk trying something that is not in the book. The only way to get them to do something else is to make that thing the "new best practice". Give it a tacky name. Send them to some conferences and get them a "Senior Lingo Bingo Dingo master practitioner" certificate for the new cult ceremony and they will do it with their eyes closed. Or maybe ... just fire them.
- auxbuss 9y ago
  The issue I’ve always had with Agile – with a capital A – is that the manifesto itself is not agile; it’s been cast in stone – or, at least, embedded in a static web page. (That’s why I’ve never “signed” the manifesto.) I’ve been in this game for enough decades to know that you have to reinvent yourself every five years or so. Some things remain the same over time, of course, but a great deal changes. These changes must at some point affect the assertions laid down in the Agile Manifesto. Where is the mechanism for change? I must at this point point out that I consider myself agile. I absolutely have skin in the game. Now, to the language of managers. I work at CTO/Head of Tech level. That involves a bunch of strategic, operational, and financial stuff that doesn’t pertain to tech matters (tangentially sometimes), but my role at the tech level I regard as supportive not <air quotes> managerial. I usually describe my role as “looking after” not managing – I actively remove the terms manager and management from that part of my role. I expect – nay demand – that the teams responsible for delivery drive development/maintenance. My role is to provide them with what they need – to support, to look after, and so on – individuals and interactions. For me, that’s agile. That’s a dynamic process that’s enabled by tooling and that tooling changes rapidly. No set of pronouncements or practices can remain relevant in such a dynamic environment; unquestioningly following a static text is dangerously close to religious practice – I don’t regard this as a good thing, ymmv. So, while I believe that the Agile Manifesto is an excellent baseline, it is flawed and somewhat contradictory in operation. But, like democracy, it’s the best we’ve got.
curtis 9y ago
In the software development field (and I'm sure other fields as well), we have this notion of "ownership" that means something more specific than lay people would expect. If someone "owns" a subsystem, they are not just responsible for it, they also have the authority to modify it, and they understand it well enough that they can modify it. Most often (at least in startups) the owner of a subsystem either implemented it or implemented substantial portions of it. OK, this is on topic, I swear. This notion of ownership can apply not just just to individual contributors but scales up to teams and even larger organizations. A team can own an entire major system for example. Software organizations of any size at all need a process in order to ship usable software. Well-run software organizations don't just have a process, they own that process as in the sense above. The organization has the responsibility for the process, they have the authority to change it, and they understand it well enough that they can. Obviously such an organization can respond to deficiencies in the process and adjust it to work better. They can even revamp it completely if they need to. Your Agile software development process isn't going to work well if you organization doesn't fully own it.
- greenrd 9y ago
  Sometimes code ownership means something slightly stronger, i.e. that no-one else has the authority to change the code. It's fine for a team to own code in this sense, but it's really bad news if an individual owns code. This is one of the things that Scrum tries to prevent, by not pre-assigning tickets/cards.
  - curtis 9y ago
    There is an alternative problem where there is no strong ownership in place, but code that should be changed doesn't get fixed or updated because nobody owns it. To get back to the point that I was trying to emphasize, a big problem with software development organizations is that often they do not own their software development process, making it essentially out of anybody's control. I guess in a scenario like that upper-level management (e.g. the CEO) could try to take ownership of the process, but that's unlikely to ever work out well.
  - closeparen 9y ago

65 points by ivanche 9y ago

Agile is a good case study for how good ideas get perverted quickly by consultants and companies. Object orientation also got changed from message passing to elaborate inheritance schemes. People always get confused when I tell that you can do OOP without inheritance besides a few cases.

noarchy 9y ago
>Agile is a good case study for how good ideas get perverted quickly by consultants and companies. The points made in the Agile Manifesto having me nodding my head in agreement more often than not. But the implementations, like Scrum, are another matter entirely. It has become a management methodology, further and further removed from the developers. And that comes complete with all of the trappings you'd expect: process for the sake of process, empty metrics (like "velocity") that can be passed up the management chain, and so on.
- hashkb 9y ago
  Can you say more about how velocity is an empty metric? I'm an IC, sometimes tech lead, (e.g. not management) and j have always found it indispensable.
  - another-dave 9y ago
    Velocity is too often used as a stick to beat people with — "Team B is doing 15 more points that you"; "Last month, we were doing an extra 5 points every sprint, but now we've stagnated — what happened?" The only worthwhile external measure of value is features that the team deliver (i.e. broadly counting improvements to non-functional requirements as features too). Velocity is meant to be constant (in an ideal world) to allow the Product Owner (i.e. someone _inside_ the team) a broad brush to provide estimates on when things may be ready — even used in this way, they depend on a stable team with a velocity that's not too volatile. They shouldn't be shared externally to try and show how productive the team are. For example, I've previously had management ask if our team can try a bit harder & deliver another 30 points per sprint. As points are meaningless outside of the team though, that's a false economy: I think they got the picture when I said our team could deliver another 1,000 points per sprint if they wanted us to.
    - srtjstjsj 9y ago
      Bad management can fail using any methodology. No process will make bad people do good things -- at best it can stop them bad things. The goal for a productivity process is to help good people to great things.
      - another-dave 9y ago
        Sure, but the parent was asking for an example of how it could become an empty metric — from my experience, this can happen when it goes outside the control of the team and "Goodhart's law" comes into play — When a measure becomes a target, it ceases to be a good measure. I'm not against meausring velocity, but I think it is a tool best used from within the team rather than from a management level > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  - maxxxxx 9y ago
    Once some managers get hold of velocity numbers they use them as the main metric. "How can increase the number of story points per sprint?" or "Why does dev A finish more story points than dev B?". Then you get all kinds of perverse incentives to game the system. Or: They start comparing story points between teams which in reality is a totally meaningless thing.
- tootie 9y ago
  Scrum is perfectly fine. In fact, it's a great way to achieve agility. But it only works if everyone understands both the process and the goals. For all the "scrum sucks" posts I've seen, I've yet to see anyone offer anything better.
  - UK-Al05 9y ago
    Simple kanban and communication. Religiously following the 'process' is the opposite of agile. Being able to use your judgement to decide to do something is agile. In scrum you always do the same thing regardless if it's needed. Well in the implementations I've been in.
  - sanderjd 9y ago
    What is better is coming up with a process that is right for your team, based on evaluating what has worked and what hasn't worked. For the teams I've been on, daily stand-ups have been a drag, and it has been a major improvement to eliminate them. Similarly, 100% pair programming has been unpleasant for the majority of the team, and it has been an improvement to stop feeling guilty about doing a lot of solitary programming. The criticism that scrum tries to get you to run a marathon as a series of sprints also resonates with me. It never seemed to allow time for more complex and vaguely defined projects to flourish, but rather we would look back and see an accumulation of short-term thoughts, but little cohesive whole. What has worked for me: code reviews code reviews code reviews, copious automated testing, a prioritized backlog, estimating size of work in some sort of abstract unit, burn downs, demos and retrospectives, short meetings with defined agendas, ignoring anything that makes up terminology, especially if any use of that made-up terminology includes a (TM) superscript.
- ryandrake 9y ago
  Is there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers? I read this all the time: The agile folks were right about software development, but Scrum/consultants/managers/process sucks! Everyone likes the Agile philosophy but then they all say it's never been implemented right. Reminds me of the "communism is the way--it's just that every time it's implemented it's done wrong!" argument. My criticisms of Agile are: 1. It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress; and 2. it addresses developer needs but does not sufficiently address the requirements of the rest of the organization, including management. Developers gotta develop, but the rest of the business needs things like measurements, reports, status, ETA, sometimes proposals, change requests, etc. A methodology that does not address these artifacts is going to have a hard time fitting in.
  - zdragnar 9y ago
    The agile manifesto was never intended to be a value proposition for the business per se, it was intended to be a promise of professional discipline. You don't ask the business if a refactor is okay, because the business doesn't know how to value or risk it. You refactor because that's what a disciplined professional does, in the course of their work. Think of another profession, if that helps. Teachers don't ask students or administrators if a test would be valuable after a given lesson. Builders don't ask if a hammer would be appropriate for a nail, or if they should use an air gun. There's a certain expectation that they should know and do these things. Scrum works if the scrum master functions as a mediator for the team to collaboratively prioritize work- ideally, this would be a role, not a job title. Scrum fails if the scrum master is just a project manager tasked with making sure the whole backlog entered by the product owner is done on time.
    - sanderjd 9y ago
      I think I agree with you, but I find your analogies quite lacking, which makes me question our shared premise. Teachers absolutely do have the cadence of tests after lessons dictated to them by administrators. Builders absolutely do negotiate with their customers over whether their "implementation" is sufficient or whether it should be "refactored" (ie. partially or completely torn out and re-done to improve the quality). I'm not sure where this leaves things, but it seems to me that the differing incentives and negotiation between stakeholders is perhaps inevitable.
- OnlyRepliesToBS 9y ago
  It's a religion and all negative implements are always at the fault of the implementer. That is called unfalsifiability.
ythn 9y ago
How do you write polymorphic code without inheritance?
- kcmastrpc 9y ago
  with interfaces? example: see golang
- falcolas 9y ago
  You use a language that lets you use methods and members of objects without requiring a specific class. Java does this via interfaces, Ruby and Python by not typing the parameters.
  - ythn 9y ago
    Sometimes "use another language" is not a viable option. We are mainly an embedded c++ shop and switching to Java is not an option.
    - tome 9y ago
      Then you inherit from a virtual class, which is not actually inheritance in anything but name.
      - bmm6o 9y ago
        This is often expressed as "interface inheritance" vs "implementation inheritance".
- frou_dh 9y ago
  Interfaces give polymorphism. Implementation inheritance gives method reuse. If you think about the term polymorph ("many shapes"), that describes the world of differing objects that have the opportunity to satisfy an interface.
  - ahartmetz 9y ago
borplk 9y ago
It's perverted by the companies first and secondarily by the consultants as the enablers. Most companies have never cared and do not care for anything agile or anything manifesto. For them Agile™ is nothing but a brand name and a weapon that legitimises the way they want to exert power over their employees. They cherry pick elements from the methodology. Change it to their liking and slap the professionally accepted label on it. That's how the pointy-haired manager turns daily standup to daily micro management meeting and daily beatings with a stick. Basically no development methodology survives the conflicts of interest at play in the long run.
- greenrd 9y ago
  I don't think that's necessarily a case of conflict of interest, but merely misunderstanding what agile methodologies are really about. They're really quite radical.
  - borplk 9y ago
    The reason the methodologies get butchered is partially and substantially because different forces try to pull it to their own side for their own benefit. The behaviour is too sophisticated for it to be merely an innocent misunderstanding. On some level it is being knowingly manipulated and weaponised. It's inevitable because essentially every methodology is a very fuzzy description of a set of ideas and practices so people and groups will interpret it in a way that benefits them.
    - greenrd 9y ago
      Yes, too little attention is paid to the motivations for doing it, and the political obstacles that can be placed in the way - the founders of agile were quite naive about office politics and sociology, in my estimation.

bane 9y ago

Whenever we hire a new Agile practitioner, as part of the interview I ask them to discuss the Agile Manifesto [1]. And then we run through some basic program design and I ask them what tools they bring to help support various program needs. They usually bring out various ceremonies and processes and what not. I then ask them to justify what they've offered against the Manifesto. If they're thoughtful about it (the Manifesto isn't always correct, and if you read it carefully leaves open the need for some of this stuff). If they simply insist it's correct they're cargo culting and we can move on. What I've found is that the ceremonies are appropriately named in that many of the practitioners seem to not know what they're for or why they're done. The teams that seem to really excel are the ones that seem to have thoughtful managers that shape the practices of their dev group to the specifics of their work. The ones that seem to always be bogged down and require huge numbers of staff to get even small amounts of work done seem to be the ones that follow a checklist of getting as many of the agile practice "things" jammed into their work processes as possible. I don't think Agile is dead, but I think it requires smarter team leads who look at what's come out of it as a set of tools to be employed against specific development challenges rather than a religion that needs worshiping. 1 - http://agilemanifesto.org/ http://agilemanifesto.org/

borplk 9y ago
I've noticed the same thing. I think it comes from a lack of experience which further creates fear and lack of self-confidence to challenge the practices of the cult. It's also similar to the "nobody got fired for buying IBM" issue. It's "nobody got fired for sticking to the established cult ceremonies". They are people who are afraid and don't care about the team or the company. They are only concerned about their own job security and paycheck. So they never risk trying something that is not in the book. The only way to get them to do something else is to make that thing the "new best practice". Give it a tacky name. Send them to some conferences and get them a "Senior Lingo Bingo Dingo master practitioner" certificate for the new cult ceremony and they will do it with their eyes closed. Or maybe ... just fire them.
auxbuss 9y ago
The issue I’ve always had with Agile – with a capital A – is that the manifesto itself is not agile; it’s been cast in stone – or, at least, embedded in a static web page. (That’s why I’ve never “signed” the manifesto.) I’ve been in this game for enough decades to know that you have to reinvent yourself every five years or so. Some things remain the same over time, of course, but a great deal changes. These changes must at some point affect the assertions laid down in the Agile Manifesto. Where is the mechanism for change? I must at this point point out that I consider myself agile. I absolutely have skin in the game. Now, to the language of managers. I work at CTO/Head of Tech level. That involves a bunch of strategic, operational, and financial stuff that doesn’t pertain to tech matters (tangentially sometimes), but my role at the tech level I regard as supportive not <air quotes> managerial. I usually describe my role as “looking after” not managing – I actively remove the terms manager and management from that part of my role. I expect – nay demand – that the teams responsible for delivery drive development/maintenance. My role is to provide them with what they need – to support, to look after, and so on – individuals and interactions. For me, that’s agile. That’s a dynamic process that’s enabled by tooling and that tooling changes rapidly. No set of pronouncements or practices can remain relevant in such a dynamic environment; unquestioningly following a static text is dangerously close to religious practice – I don’t regard this as a good thing, ymmv. So, while I believe that the Agile Manifesto is an excellent baseline, it is flawed and somewhat contradictory in operation. But, like democracy, it’s the best we’ve got.

curtis 9y ago

In the software development field (and I'm sure other fields as well), we have this notion of "ownership" that means something more specific than lay people would expect. If someone "owns" a subsystem, they are not just responsible for it, they also have the authority to modify it, and they understand it well enough that they can modify it. Most often (at least in startups) the owner of a subsystem either implemented it or implemented substantial portions of it. OK, this is on topic, I swear. This notion of ownership can apply not just just to individual contributors but scales up to teams and even larger organizations. A team can own an entire major system for example. Software organizations of any size at all need a process in order to ship usable software. Well-run software organizations don't just have a process, they own that process as in the sense above. The organization has the responsibility for the process, they have the authority to change it, and they understand it well enough that they can. Obviously such an organization can respond to deficiencies in the process and adjust it to work better. They can even revamp it completely if they need to. Your Agile software development process isn't going to work well if you organization doesn't fully own it.

greenrd 9y ago
Sometimes code ownership means something slightly stronger, i.e. that no-one else has the authority to change the code. It's fine for a team to own code in this sense, but it's really bad news if an individual owns code. This is one of the things that Scrum tries to prevent, by not pre-assigning tickets/cards.
- curtis 9y ago
  There is an alternative problem where there is no strong ownership in place, but code that should be changed doesn't get fixed or updated because nobody owns it. To get back to the point that I was trying to emphasize, a big problem with software development organizations is that often they do not own their software development process, making it essentially out of anybody's control. I guess in a scenario like that upper-level management (e.g. the CEO) could try to take ownership of the process, but that's unlikely to ever work out well.
- closeparen 9y ago