11 ms·

Coconut Headphones: Why Agile Has Failed (2014)

71 points by numo16 11y ago

ThrustVectoring 11y ago
This is exactly why John Boyd never wrote any books explaining his thought process - his entire point is to drop fixed and inflexible doctrine in favor of striking at the heart of what makes military operations work, and explicitly serializing your mental models is a quick way to convince people to interpret them as a fixed doctrine.
- hga 11y ago
  Example of "cult doctrine" he would be very aware of: in Vietnam, the Air Force was using WWII fighter formations, which granted them 1/4th the power the Navy's modern, jet adapted ones had. In part, this wasn't seen as a problem by the flight leaders, who would tended to be senior officers, since they got all the action while the other 3 had to mostly concentrate on staying in formation....
sageabilly 11y ago
The best example of this I have seen lately: Big Software Company officially changed over to Agile this year. Now has two-week development sprints. Any customer who calls in with huge, flaming, earth-shattering issues with the software is now told that the earliest their issue can be brought up is whenever the current sprint is over. There's absolutely no leeway whatsoever to do any ad-hoc development for customers (frequently Fortune 500 or 100 who are paying millions for their software support.)
- mindcrime 11y ago
  Big Software Company officially changed over to Agile this year. If they phrased it that way, they probably didn't. There is no such thing as "Agile". That is, "Agile" is not a methodology that you can adopt. It simply does not exist. There are a number of processes out there (Scrum, XP, Crystal, etc.) that can be described as "agile" because they conform to the tenets of the Agile Manifesto to varying degrees. But anytime you hear a company say "we adopted Agile" you already know that they don't know WTF they are talking about, and can stop listening right there. Sadly, misunderstandings of "agile" are so pervasive that the term basically has no meaning anymore. Most - if not all - of what the author of TFA is ranting against, is very explicitly not "agile" in any sense. I wouldn't say "agile" (that is, "a set of principles and ideas as articulated in the Agile Manifesto) has failed at all. I'd say a lot of people who don't understand what "agile" means have overloaded the term with another meaning, which is being the word to describe their fucked-up hybrid of waterfall and cowboy coding.
  - dragonwriter 11y ago
    > If they phrased it that way, they probably didn't. A central point of TFA -- which the grandparent post offers an example of -- is that "Agile" has "failed" because rather than adopting the values of the Agile Manifesto, organizations adopted cargo-cult "Agile" rituals without understanding the principles and purposes of Agile (TFA goes on to claim the "core" point is that non-technical managers of technical projects will always fail, but while I think the cargo cult observation is valid, I think this conclusion is a leap that is unjustified from that observation -- the principles of the Agile Manifesto are non-technical principles and agility and adaptability aren't things that take particular domain-specific skills to understand. Strong top-down directive management that isn't respecting and leveraging subordinates expertise within their respective domains in terms of choices of how to achieve goals -- including technical experts on projects which have a technical component, which may or may not be purely or even principally technical projects -- is going to fail, but that doesn't mean that managers need to be technical if the project is technical, or even that a binary technical/non-technical distinction is appropriate for projects.)
    - mindcrime 11y ago
      A central point of TFA -- which the grandparent post offers an example of -- is that "Agile" has "failed" because rather than adopting the values of the Agile Manifesto, organizations adopted cargo-cult "Agile" rituals without understanding the principles and purposes of Agile Right, and I agree 110% with that. I'm just not sure I'd agree that that means "agile has failed". There are companies out there using agile oriented processes and having quite a lot of success with them. When done well, Scrum really is a very effective process. I remember when I worked for Lulu.com, we had a great scrum-master, a company culture where everybody, including the business people, "bought in" to the approach, and a group of really talented developers, and it all worked great for us. So had "agile failed" there? I'd say not. What I will definitely agree with, and what I've said myself, is that the term "agile" has been overloaded to the point of being essentially meaningless now, except in a very constrained context.
      - amyjess 11y ago
- andyidsinga 11y ago
  yep.. this is interesting becase a sprint can always be cancelled -- its just that cancelling it is on management not on the development team. Its totally legitimate to do occasionally if all of a sudden product management realizes that the team is going in the totally wrong direction vis a vis customer needs. What management isn't allowed to do, per agile, is change the scope of whats in the sprint vis a vis new stories, and tasks. because management can cancel a sprint at any time - and its on them, I guess the theory is they'll do it sparingly. If sprints get cancelled over and over it starts to become apparent that there is a misunderstanding of the user and not the engineering effort. EDIT: see comments (with @mindcrime) re "agile" vis a vis the agile manifesto vs implementations such as scrum, XP etc. I'm using agile == scrum which is not technically correct (sorry)
  - dragonwriter 11y ago
    You seem to be confusing "Agile" with "Scrum" and "Management" (which is an amorphous group) with "the Product Owner" (who is expressly a specific individual.) With those replacements, the described divisions of responsibility are accurate descriptions of the rules laid out in The Scrum Guide™. But an Agile organization may or may find the practices in the The Scrum Guide™ suitable; confusion of Agile (which favors free adaptability to the conditions and what works for the actual team involved, with selection and modification of processes and tools around that) with Scrum (which is a very specifically-defined canned methodology with defined organizational roles, even if it has specific designed-in limited areas of adaptability) is itself a symptom of at least incipient cargo-cult Agile of the type to which the article attributes the failure of "Agile".
    - andyidsinga 11y ago
      Yep - I'm combining some things for sure. But I didn't cargo cult it -- I came to my current agile through experience over several projects (4 or 5). Somwhere in the middle of those learned about agile via the manifesto and then read a single book about scrum (this one : http://www.amazon.com/Scrum-Breathtakingly-Brief-Agile-Introduction-ebook/dp/B007P5N8D4/ref=sr_1_1?s=books&ie=UTF8&qid=1442600395&sr=1-1&keywords=agile http://www.amazon.com/Scrum-Breathtakingly-Brief-Agile-Intro... ). We've modified it a little from there.
nine_k 11y ago
In short: «The core problem is that non-technical managers of software projects will always fail, or at best be counter productive, whatever the methodology. Developing software is a deeply technical endeavour.» Technical excellence or at least competence is key and can't be replaced with any process. Estimates are not very useful; technical debt is dangerous toxic waste, and any process that does not treat it well is bound to fail. A discussion 2 years ago: https://news.ycombinator.com/item?id=7389940 https://news.ycombinator.com/item?id=7389940
- capkutay 11y ago
  If that's the core message, why is the article titled 'Why Agile has failed'. Non-technical managers would ruin any engineering project whether it's agile or waterfall.
  - hga 11y ago
    Because "Agile" (or at least some forms of it) claim to have solved this problem? Something I'm not aware of any other methodology (family) doing.
zorked 11y ago
Good,a while ago it was the contrarian, underground cult, then it was all the rage, then you were not a professional if you didn't worship it, then the cracks started to show, now it's failed and passé. When should we expect the revival?
- maxxxxx 11y ago
  Like all other trends it has a lot of good aspects to it and will come back in some form. Right now functional programming is the rage. Just wait until some functional programming projects fail. Then people will say "functional programming has failed". Happened with object oriented programming. There is no methodology that can be subverted by people who don't understand it.
Tekker 11y ago
I think the overarching aspect of agile has failed, in part because it requires more implementation than most companies are willing to put up with. I see, in general (and I am a certified scrummaster, FWIW), that companies tend to embrace sprints - usually going for two weeks - and daily standups (which they might do poorly, but at least they try). Everything else - estimation sessions, lessons learned, burndown charts - are up for grabs. Maybe that's a failure of the company. Maybe that's a failure or Agile, for failing to take into account the normal inertia of companies - I don't konw. It is better than waterfall, but it's not fully embraced.
noobiemcfoob 11y ago
"Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver." ^ This. This. This. I can't say this enough. I understand business is business, but that side of a company needs to be more flexible for development. Hard deadlines only lead to cutting corners and poor, quick design decisions that make everything there after much worse.
- mindcrime 11y ago
  Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver. I used to think this way. But the longer I've been doing this, the more I realize that some (but definitely not all) hard deadlines exist for good reasons. There are external realities that a business has to deal with, like tax laws and accounting guidelines, that change, and go into effect on set dates. And there are times when you have a very specific reason for wanting at least a demo of $NEW_FEATURE before, say, a major marketing event like a trade-show or conference. These things aren't arbitrary and made up just to piss off the developers, even when it seems that way. However... and here's the part that nearly everybody seems to miss: If you're using a good agile based process (say, Scrum, done well) "hard deadlines" are a little bit less of an issue, exactly because you're always working on "the most important thing you could possibly be working on" at any given time, and at the end of a given iteration (when you do ship functioning code), you at least have "the most complete possible version" available, even if it's not 100% complete. This is why prioritizing requirements is so crucial, but sadly, a lot of the business users who nominally should be doing the prioritizing, don't understand how this concept works.
  - TheCoelacanth 11y ago
    Yes, bad things aren't always possible to avoid. That's just the nature of human existence. But you shouldn't go out of your way to create problems for yourself. Some deadlines are unavoidable, but you shouldn't create artificial deadlines and you definitely shouldn't create an artificial deadline for every single micro-task that someone is working on.
andyidsinga 11y ago
Although I agree that putting non-technical managers in charge of a technical team can be a problem in some cases - I think the article focuses a little too much on that aspect vs what I think may be more problematic -- that, in my experience, focus falls on process dogma (even agile's) when there isn't enough interaction with the user. From the start of the article: > They identified that the programmer is the central actor in the creation of software, and that the best software grows and evolves organically in contact with its users. I find myself echoing this a lot lately - that contact with users is the key to success in software development. Note that this has to be told to both management AND engineers. I've met lots of engineers in my time that don't want contact with users ...that is a problem.
- mindcrime 11y ago
  Note that this has to be told to both management AND engineers. I've met lots of engineers in my time that don't want contact with users ...that is a problem. That's a fair point, and it also comes out when you see hackers denigrate the role of "product manager". I mean, yeah, I get it... there are bad product managers who are completely non-technical, and clueless. You don't have to tell me. BUT... a real product manager is technical enough to have an intelligent conversation with the developers AND enjoys talking to customers and can "dumb things down" enough to talk to non-technical people and serves as that "bridge" between the users and the developers (go ahead, insert "Office Space" reference here). The problem is, people who actually have the required combinations of talents to be good product managers are very rare, meaning that most product managers suck. But when done right, it is a valuable role.
  - andyidsinga 11y ago
    totally agree that a real project manager will be technical to some degree -- even if just an aficionado / technologist type. I do like to balance the scales a little and defend less technical leaders -- I've had a few really good non-technical leaders/bosses in the past 20 years. They were so good because they a) respected and trusted their technical teams immensely and b) made a really hard effort to learn from them such they could do the bridging you describe.
Florin_Andrei 11y ago
> The original agile manifesto was very much about self organizing teams, it would be great if we could get back to that. Sorry, not going to catch on. Corporations make money. Where there's money, there are power struggles. Where there are power struggles, nobody is going to relinquish power and let people "self-organize". Sure, there might be exceptions, but the vast masses out there will never follow.
- hga 11y ago
  The trick here would be convincing the right people that letting "us" have more power and self-organize would provide them with more money and power. In my experience, a lot of it comes down to the issue of control (which I'll admit I'm predisposed to see). I've seen more than a few people who'd rather have their projects fail, lose their jobs, or even kill their company than lose their perception of control over "us".
PythonicAlpha 11y ago
My experience with agile development in companies: It is largely used to delegate the responsibility for a project and the results away from the management to the developers. They just throw the objectives (made by the management) over the wall to the developers, those have to give an estimation and the managements is free of any further responsibility. So the developers will in practice exploit themselves. This already was profitable in the automotive industry, where instead of the management, the fellow workers pressured the coworkers. The peer-pressure can be even more pressing than any management mechanics. This finally of course is the opposite of agile development as it meant to be -- but that is nothing, that anybody in management would care about. The label "agile" is good enough and even most employees don't see how they where betrayed. They think (at least for some time), they where "empowered", but the real empowerment is, that they are now free to enslave themselves for the boss.
hipsterrific 11y ago
This article hurts. I'm currently contracting with a large company and they said they were agile. The only agile thing about them is their cultic insistence on two week sprints and retros, other than that, the project rots from within. Case in point: team I work in takes care of all the web front end. One team needed some web work but then management came thundering down to us demanding that we finish another module because someone opened their mouth and over delivered, now it's time to save someone's hide. Imagine having one team yell at you while management yells at you. Oh, and did I mention that management wanted 100% feature complete on a module that was 30% done? Genius. After reading this, my liver was like "oh sh that hurts."
- dctoedt 11y ago
  > demanding that we finish another module because someone opened their mouth and over delivered, now it's time to save someone's hide. Question: Did you mean over-promised (vice over-delivered)? If the latter, could you please explain what you meant? Sorry if I'm missing the obvious; I'm not a dev.
arenaninja 11y ago
This is the area of software development I actively dislike. I've had interview questions about whether at work we practiced agile, or SCRUM or some other crap. I'd much rather work than relegate time to learning about the trendiest way to ship. When I was in charge of development, it was simple. Ship as soon as it's ready as long as it's not a Friday, bugfixes go all the way to the top of the pile. I don't even know what scrum means. If it's dead, I'm glad I've heard the last of it.
- Cymen 11y ago
  What size teams have you worked on? What has the experience level been across the team (was it all experienced, a variety of senior/mid/junior)? My experience is it starts to get more important when the team gets bigger than say 6-7.
ssewell 11y ago
Agile methodologies can work, but it often requires a feature-centric deployment model, not deadline-centric. Having a fixed N-week deployment cycle can't simply be applied to all products and expect it to work. I've found that an "Agile" approach can work quite well as long as you apply a healthy does of common sense to it. I think to often people forget that product management frameworks are there to create a common language and set exceptions, not blindly dictate exactly how one should operate.
JustSomeNobody 11y ago
The problem is that management has to do "something". When the developers are off designing and coding, what are the managers supposed to do? They have no clue, so they adopt "agile" so that they can appear to be busy collecting data on how well the team is doing.
grandalf 11y ago
I've found that organizations who strongly embrace agile or other management fads/tenets are often recovering from one or more projects that took too long or went over budget... someone got blamed, someone hired a consultant or read an agile book, and the next thing you know the rules of agile are used as weapons in whatever internal political battles predated the change. Or, non-technical management is being criticized for too-slow development and an exasperated engineering/product team resorts to agile as a method of radical transparency (you were on board with the sprint plan, we delivered, so stfu, etc.) I'd say any of these are pretty big warning signs about an organization's culture... in particular they likely reveal that the culture doesn't appreciate good engineering practice or good product practice.

71 points by numo16 11y ago

This is exactly why John Boyd never wrote any books explaining his thought process - his entire point is to drop fixed and inflexible doctrine in favor of striking at the heart of what makes military operations work, and explicitly serializing your mental models is a quick way to convince people to interpret them as a fixed doctrine.

hga 11y ago
Example of "cult doctrine" he would be very aware of: in Vietnam, the Air Force was using WWII fighter formations, which granted them 1/4th the power the Navy's modern, jet adapted ones had. In part, this wasn't seen as a problem by the flight leaders, who would tended to be senior officers, since they got all the action while the other 3 had to mostly concentrate on staying in formation....

sageabilly 11y ago

The best example of this I have seen lately: Big Software Company officially changed over to Agile this year. Now has two-week development sprints. Any customer who calls in with huge, flaming, earth-shattering issues with the software is now told that the earliest their issue can be brought up is whenever the current sprint is over. There's absolutely no leeway whatsoever to do any ad-hoc development for customers (frequently Fortune 500 or 100 who are paying millions for their software support.)

mindcrime 11y ago
Big Software Company officially changed over to Agile this year. If they phrased it that way, they probably didn't. There is no such thing as "Agile". That is, "Agile" is not a methodology that you can adopt. It simply does not exist. There are a number of processes out there (Scrum, XP, Crystal, etc.) that can be described as "agile" because they conform to the tenets of the Agile Manifesto to varying degrees. But anytime you hear a company say "we adopted Agile" you already know that they don't know WTF they are talking about, and can stop listening right there. Sadly, misunderstandings of "agile" are so pervasive that the term basically has no meaning anymore. Most - if not all - of what the author of TFA is ranting against, is very explicitly not "agile" in any sense. I wouldn't say "agile" (that is, "a set of principles and ideas as articulated in the Agile Manifesto) has failed at all. I'd say a lot of people who don't understand what "agile" means have overloaded the term with another meaning, which is being the word to describe their fucked-up hybrid of waterfall and cowboy coding.
- dragonwriter 11y ago
  > If they phrased it that way, they probably didn't. A central point of TFA -- which the grandparent post offers an example of -- is that "Agile" has "failed" because rather than adopting the values of the Agile Manifesto, organizations adopted cargo-cult "Agile" rituals without understanding the principles and purposes of Agile (TFA goes on to claim the "core" point is that non-technical managers of technical projects will always fail, but while I think the cargo cult observation is valid, I think this conclusion is a leap that is unjustified from that observation -- the principles of the Agile Manifesto are non-technical principles and agility and adaptability aren't things that take particular domain-specific skills to understand. Strong top-down directive management that isn't respecting and leveraging subordinates expertise within their respective domains in terms of choices of how to achieve goals -- including technical experts on projects which have a technical component, which may or may not be purely or even principally technical projects -- is going to fail, but that doesn't mean that managers need to be technical if the project is technical, or even that a binary technical/non-technical distinction is appropriate for projects.)
  - mindcrime 11y ago
    A central point of TFA -- which the grandparent post offers an example of -- is that "Agile" has "failed" because rather than adopting the values of the Agile Manifesto, organizations adopted cargo-cult "Agile" rituals without understanding the principles and purposes of Agile Right, and I agree 110% with that. I'm just not sure I'd agree that that means "agile has failed". There are companies out there using agile oriented processes and having quite a lot of success with them. When done well, Scrum really is a very effective process. I remember when I worked for Lulu.com, we had a great scrum-master, a company culture where everybody, including the business people, "bought in" to the approach, and a group of really talented developers, and it all worked great for us. So had "agile failed" there? I'd say not. What I will definitely agree with, and what I've said myself, is that the term "agile" has been overloaded to the point of being essentially meaningless now, except in a very constrained context.
    - amyjess 11y ago
andyidsinga 11y ago
yep.. this is interesting becase a sprint can always be cancelled -- its just that cancelling it is on management not on the development team. Its totally legitimate to do occasionally if all of a sudden product management realizes that the team is going in the totally wrong direction vis a vis customer needs. What management isn't allowed to do, per agile, is change the scope of whats in the sprint vis a vis new stories, and tasks. because management can cancel a sprint at any time - and its on them, I guess the theory is they'll do it sparingly. If sprints get cancelled over and over it starts to become apparent that there is a misunderstanding of the user and not the engineering effort. EDIT: see comments (with @mindcrime) re "agile" vis a vis the agile manifesto vs implementations such as scrum, XP etc. I'm using agile == scrum which is not technically correct (sorry)
- dragonwriter 11y ago
  You seem to be confusing "Agile" with "Scrum" and "Management" (which is an amorphous group) with "the Product Owner" (who is expressly a specific individual.) With those replacements, the described divisions of responsibility are accurate descriptions of the rules laid out in The Scrum Guide™. But an Agile organization may or may find the practices in the The Scrum Guide™ suitable; confusion of Agile (which favors free adaptability to the conditions and what works for the actual team involved, with selection and modification of processes and tools around that) with Scrum (which is a very specifically-defined canned methodology with defined organizational roles, even if it has specific designed-in limited areas of adaptability) is itself a symptom of at least incipient cargo-cult Agile of the type to which the article attributes the failure of "Agile".
  - andyidsinga 11y ago
    Yep - I'm combining some things for sure. But I didn't cargo cult it -- I came to my current agile through experience over several projects (4 or 5). Somwhere in the middle of those learned about agile via the manifesto and then read a single book about scrum (this one : http://www.amazon.com/Scrum-Breathtakingly-Brief-Agile-Introduction-ebook/dp/B007P5N8D4/ref=sr_1_1?s=books&ie=UTF8&qid=1442600395&sr=1-1&keywords=agile http://www.amazon.com/Scrum-Breathtakingly-Brief-Agile-Intro... ). We've modified it a little from there.

nine_k 11y ago

In short: «The core problem is that non-technical managers of software projects will always fail, or at best be counter productive, whatever the methodology. Developing software is a deeply technical endeavour.» Technical excellence or at least competence is key and can't be replaced with any process. Estimates are not very useful; technical debt is dangerous toxic waste, and any process that does not treat it well is bound to fail. A discussion 2 years ago: https://news.ycombinator.com/item?id=7389940 https://news.ycombinator.com/item?id=7389940

capkutay 11y ago
If that's the core message, why is the article titled 'Why Agile has failed'. Non-technical managers would ruin any engineering project whether it's agile or waterfall.
- hga 11y ago
  Because "Agile" (or at least some forms of it) claim to have solved this problem? Something I'm not aware of any other methodology (family) doing.

zorked 11y ago

Good,a while ago it was the contrarian, underground cult, then it was all the rage, then you were not a professional if you didn't worship it, then the cracks started to show, now it's failed and passé. When should we expect the revival?

maxxxxx 11y ago
Like all other trends it has a lot of good aspects to it and will come back in some form. Right now functional programming is the rage. Just wait until some functional programming projects fail. Then people will say "functional programming has failed". Happened with object oriented programming. There is no methodology that can be subverted by people who don't understand it.

Tekker 11y ago

I think the overarching aspect of agile has failed, in part because it requires more implementation than most companies are willing to put up with. I see, in general (and I am a certified scrummaster, FWIW), that companies tend to embrace sprints - usually going for two weeks - and daily standups (which they might do poorly, but at least they try). Everything else - estimation sessions, lessons learned, burndown charts - are up for grabs. Maybe that's a failure of the company. Maybe that's a failure or Agile, for failing to take into account the normal inertia of companies - I don't konw. It is better than waterfall, but it's not fully embraced.

noobiemcfoob 11y ago

"Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver." ^ This. This. This. I can't say this enough. I understand business is business, but that side of a company needs to be more flexible for development. Hard deadlines only lead to cutting corners and poor, quick design decisions that make everything there after much worse.

mindcrime 11y ago
Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver. I used to think this way. But the longer I've been doing this, the more I realize that some (but definitely not all) hard deadlines exist for good reasons. There are external realities that a business has to deal with, like tax laws and accounting guidelines, that change, and go into effect on set dates. And there are times when you have a very specific reason for wanting at least a demo of $NEW_FEATURE before, say, a major marketing event like a trade-show or conference. These things aren't arbitrary and made up just to piss off the developers, even when it seems that way. However... and here's the part that nearly everybody seems to miss: If you're using a good agile based process (say, Scrum, done well) "hard deadlines" are a little bit less of an issue, exactly because you're always working on "the most important thing you could possibly be working on" at any given time, and at the end of a given iteration (when you do ship functioning code), you at least have "the most complete possible version" available, even if it's not 100% complete. This is why prioritizing requirements is so crucial, but sadly, a lot of the business users who nominally should be doing the prioritizing, don't understand how this concept works.
- TheCoelacanth 11y ago
  Yes, bad things aren't always possible to avoid. That's just the nature of human existence. But you shouldn't go out of your way to create problems for yourself. Some deadlines are unavoidable, but you shouldn't create artificial deadlines and you definitely shouldn't create an artificial deadline for every single micro-task that someone is working on.

andyidsinga 11y ago

Although I agree that putting non-technical managers in charge of a technical team can be a problem in some cases - I think the article focuses a little too much on that aspect vs what I think may be more problematic -- that, in my experience, focus falls on process dogma (even agile's) when there isn't enough interaction with the user. From the start of the article: > They identified that the programmer is the central actor in the creation of software, and that the best software grows and evolves organically in contact with its users. I find myself echoing this a lot lately - that contact with users is the key to success in software development. Note that this has to be told to both management AND engineers. I've met lots of engineers in my time that don't want contact with users ...that is a problem.

mindcrime 11y ago
Note that this has to be told to both management AND engineers. I've met lots of engineers in my time that don't want contact with users ...that is a problem. That's a fair point, and it also comes out when you see hackers denigrate the role of "product manager". I mean, yeah, I get it... there are bad product managers who are completely non-technical, and clueless. You don't have to tell me. BUT... a real product manager is technical enough to have an intelligent conversation with the developers AND enjoys talking to customers and can "dumb things down" enough to talk to non-technical people and serves as that "bridge" between the users and the developers (go ahead, insert "Office Space" reference here). The problem is, people who actually have the required combinations of talents to be good product managers are very rare, meaning that most product managers suck. But when done right, it is a valuable role.
- andyidsinga 11y ago
  totally agree that a real project manager will be technical to some degree -- even if just an aficionado / technologist type. I do like to balance the scales a little and defend less technical leaders -- I've had a few really good non-technical leaders/bosses in the past 20 years. They were so good because they a) respected and trusted their technical teams immensely and b) made a really hard effort to learn from them such they could do the bridging you describe.

Florin_Andrei 11y ago

> The original agile manifesto was very much about self organizing teams, it would be great if we could get back to that. Sorry, not going to catch on. Corporations make money. Where there's money, there are power struggles. Where there are power struggles, nobody is going to relinquish power and let people "self-organize". Sure, there might be exceptions, but the vast masses out there will never follow.

hga 11y ago
The trick here would be convincing the right people that letting "us" have more power and self-organize would provide them with more money and power. In my experience, a lot of it comes down to the issue of control (which I'll admit I'm predisposed to see). I've seen more than a few people who'd rather have their projects fail, lose their jobs, or even kill their company than lose their perception of control over "us".

PythonicAlpha 11y ago

My experience with agile development in companies: It is largely used to delegate the responsibility for a project and the results away from the management to the developers. They just throw the objectives (made by the management) over the wall to the developers, those have to give an estimation and the managements is free of any further responsibility. So the developers will in practice exploit themselves. This already was profitable in the automotive industry, where instead of the management, the fellow workers pressured the coworkers. The peer-pressure can be even more pressing than any management mechanics. This finally of course is the opposite of agile development as it meant to be -- but that is nothing, that anybody in management would care about. The label "agile" is good enough and even most employees don't see how they where betrayed. They think (at least for some time), they where "empowered", but the real empowerment is, that they are now free to enslave themselves for the boss.

hipsterrific 11y ago

This article hurts. I'm currently contracting with a large company and they said they were agile. The only agile thing about them is their cultic insistence on two week sprints and retros, other than that, the project rots from within. Case in point: team I work in takes care of all the web front end. One team needed some web work but then management came thundering down to us demanding that we finish another module because someone opened their mouth and over delivered, now it's time to save someone's hide. Imagine having one team yell at you while management yells at you. Oh, and did I mention that management wanted 100% feature complete on a module that was 30% done? Genius. After reading this, my liver was like "oh sh that hurts."

dctoedt 11y ago
> demanding that we finish another module because someone opened their mouth and over delivered, now it's time to save someone's hide. Question: Did you mean over-promised (vice over-delivered)? If the latter, could you please explain what you meant? Sorry if I'm missing the obvious; I'm not a dev.

arenaninja 11y ago

This is the area of software development I actively dislike. I've had interview questions about whether at work we practiced agile, or SCRUM or some other crap. I'd much rather work than relegate time to learning about the trendiest way to ship. When I was in charge of development, it was simple. Ship as soon as it's ready as long as it's not a Friday, bugfixes go all the way to the top of the pile. I don't even know what scrum means. If it's dead, I'm glad I've heard the last of it.

Cymen 11y ago
What size teams have you worked on? What has the experience level been across the team (was it all experienced, a variety of senior/mid/junior)? My experience is it starts to get more important when the team gets bigger than say 6-7.

ssewell 11y ago

Agile methodologies can work, but it often requires a feature-centric deployment model, not deadline-centric. Having a fixed N-week deployment cycle can't simply be applied to all products and expect it to work. I've found that an "Agile" approach can work quite well as long as you apply a healthy does of common sense to it. I think to often people forget that product management frameworks are there to create a common language and set exceptions, not blindly dictate exactly how one should operate.

JustSomeNobody 11y ago

The problem is that management has to do "something". When the developers are off designing and coding, what are the managers supposed to do? They have no clue, so they adopt "agile" so that they can appear to be busy collecting data on how well the team is doing.

grandalf 11y ago

I've found that organizations who strongly embrace agile or other management fads/tenets are often recovering from one or more projects that took too long or went over budget... someone got blamed, someone hired a consultant or read an agile book, and the next thing you know the rules of agile are used as weapons in whatever internal political battles predated the change. Or, non-technical management is being criticized for too-slow development and an exasperated engineering/product team resorts to agile as a method of radical transparency (you were on board with the sprint plan, we delivered, so stfu, etc.) I'd say any of these are pretty big warning signs about an organization's culture... in particular they likely reveal that the culture doesn't appreciate good engineering practice or good product practice.