7 ms·

All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to wo

All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand. I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time. The reality is that the company has a bunch of developers who are mediocre at best (and maybe one or two good ones) and managers who do not understand the situation. And of course the budget is already been eaten. They want to ship their product and make some money with that so they can continue to live their life. If I go there and say hey, you need better developers, more rapid prototyping and managers who are technical enough, nothing will change. Nothing will change because there aren't "rock star" developers avaialble, there isn't time to find new managers and definetly no motivation to change everything right now. Sure in some sense I might be correct to say so, but my goal is not to show my superiority, but to improve the situation. But if I teach them a little Scrum, help them setup some CI and so on, they almost always perform better. And then this statement "Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation." No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need. "Agile" helps even the shitties companies to meet the needs of their customers.

briantakita 13y ago
Agile is the new RUP. The main audience is shifting toward the shitties. It's the circle of life for cultural movements. Nothing wrong with Agile. It's just not my thing anymore.
- hpaavola 13y ago
  By definition most companies, most teams and most individuals are average. There are very few really good developers and managers. What suits those few does not really matter. They will do great things not matter what. Agile works for most better than the alternatives.
  - Tyrannosaurs 13y ago
    Unless you have a very oddly skewed set of people, by the definition of average most people are average (or close to it)...
    - vanderZwan 13y ago
      I think you missed the part where he implied that what programming culture considers "good" software is nothing short of a near-perfect to perfect technical implementation. In other words: what the other guy called "shitty" is actually the average. See also the odd thing that most people consider themselves better than average, which by definition cannot be true.
      - Tyrannosaurs 13y ago
        Yes, the idea that almost everyone considers themselves to be a better than average driver. I've always wondered with that whether the problem is with the question. What it's really checking is whether someone will admit to being worse than average, which is a very different thing to thinking you're worse than average.
        ZeroGravitas 13y ago
        In "thinking fast and slow", I'm sure the author gave an example of something people will all admit to being below average at. Googling it, the example given is "starting conversations with strangers" and his theory is that people ignore the question they are asked ("how they compare with average") because it's hard/impossible to actually answer, and instead, without realising it, substitute an easy question ("are you good at x") and answer that instead.
        Tyrannosaurs 13y ago
        That's interesting. I have Thinking Fast and Slow as an audiobook I've not yet got round to listening to. Does he talk about other theories? I wonder if there's also an element of what the person has tied up in that skill and what the consequences of being bad at it are? Certainly it seems unlikely that anyone would want to admit to being bad at their job (kind of tantamount to admitting to be a fraud), or at something which, as with driving, can be actively dangerous if you're bad at it.
- at-fates-hands 13y ago
  I've actually come to the conclusion Agile propagates poor developers and poor managers. I've known some really good developers who go belly up in Agile systems because they can't cope with the tight deadlines, having to ship something in two weeks, or people constantly breathing down their necks. Over the years, I feel like Agile has been used to deliver mediocre products, and in turn, turned good developers into shitty developers simply because the "business" wants to ship something a lot sooner than it should be. It's a downward spiral since all they care about is something getting built, not the inherit quality of said product. Hence, its because of Agile there are shitty developers and shitty products being shipped, not the other way around.
collyw 13y ago
"No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need." Depends what you class as "good software". My colleague left some code which "worked" and "met the needs" (at the time). I made a small change to the database it interacted with and it fell over. I had to go in a debug it, but it was so badly written I had to completely refactor it just to debug it properly. So her software met the needs, my rewrite of it met the needs, and has been far more reliable and maintainable. I would say that is better software.
- hpaavola 13y ago
  Of course technically better implementation is better if the only thing that changes is the technical quality of the implementation. But it does not follow that doing good software is a technical challenge. It does not matter how fast your algorithm is if nobody wants the results that it spits out. Defining good software is really hard task, but in general what I mean by it is that good software increases the well-being of its users. Yes, one aspect of that is the technical quality of the implementation.
  - usea 13y ago
    What happens when the needs of the customers or users change? What happens when your understanding of their needs was imperfect and needs to be updated? Is the software that met the old needs still good? Was it ever good? What happens when the software could only ever meet the old needs, but is impossible to update to meet the new needs? Was it ever good? Needs change. The ability for software to be altered to meet evolving needs is not simply a "technical quality of the implementation." It doesn't just have a faster algorithm. It's better software.
    - hpaavola 13y ago
      I'm not sure what part we disagree here. Yes, technical quality matters. But it matters way less than delivering something that users need. And yes, better technical quality ceteris paribus equals better software.
mattmanser 13y ago
I've read your comments a couple of times and still can't really see what you've added. You're talking about very abnormal situations. Companies that are so technically incompetent they have to hire you. And then saying that we should listen because in your abnormal experience of dealing with teams so dysfunctional they can't even ship bad software that agile at least gets them going a little bit. I suspect almost any change would get them going a little bit as the change itself is the trigger. EDIT: The more I think about it, the more your comment reminds me of the people defending the other fads of years gone past. Workflow diagrams, OOP-design (as a be-all-and-end-all process), UML, Worflow Engines, RAD tools. Your comment reminds me of the defences of them. These things worked because those desperate teams need a light to guide them, not because of the tool itself. And with each of those tools, it turned out the tool itself is mainly counter-productive to functional teams. I think we're realising Agile is another of those false prophets.
- twic 13y ago
  The question is whether this is abnormal or not. I suspect that it is not. That is, i suspect that there are many more mediocre-to-poor developers and managers out there than there are good-to-excellent ones.
  - hpaavola 13y ago
    Exactly. Then the questions is how we can make most of us to perform better. The answer is not to "be excellent developer". The answer must be in the way we do things.
- ctb_mg 13y ago
  I also disagree with the premise that these situations are very abnormal. Ours is a big field which expands outside of sunny California, where you can't walk a few feet without bumping into a rockstar coder. In the rest of the world where the mediocre is the status quo, Agile gets team members organized and motivated. Of course, if you could find rockstars, you'd hire them, solve many problems, and ship your product. Not everyone has the pleasure of that kind of engineer pool.
Tloewald 13y ago
If you get people who aren't customer focused, aren't testing, and are wasting huge amounts of time in pointless meetings focus on their customers, do continuous builds, tests, iterative releases, and have fewer meetings I suspect you can and will reap significant benefits. But that isn't "agile" it's just some good practices with a label du jour. Good software companies were doing nightly builds twenty years ago (when doing such builds was a major technical accomplishment). The agile cargo cult against which the writer is ranting is far larger, more insidious, and counterproductive than that. E.g. Our project is infested with "release train engineers", "coaches", "rally consultants" and other highly paid morons who actively damage the project while claiming credit for any improvements we manage to accomplish behind their backs.
- kasey_junk 13y ago
  I don't disagree about the hypocrisy of the folks who have redefined the Agile movement to be something that is decidedly not Agile. That said, the thing I dislike about this new "Agile has failed" meme is that it discounts how much the movement has changed the status quo. Sure it make sense now that small iterative releases, continuous integration, automated tests, customer collaboration, etc will produce better software. And yes there were teams that did this before Agile became popular, but it certainly wasn't the norm. There used to be no standard way to write/run unit tests. The class of software called continuous integration server did not exist. Gant charts were completely normal planning devises. I've worked in environments that literally believed that a senior developer could use uml to design the entire system down to the method level and then it would be a trivial matter for a junior developer to "fill it in". That sounds insane now, but it happened throughout the software industry. Agile didn't fail, it worked so well it became the norm, and now the term is being co-opted by opportunists. That's sad, but let's not let that detract from the very real success story of the Agile software movement.
  - Tloewald 13y ago
    I agree with much of what you've said, but I have to pick on this remark: "And yes there were teams that did this before Agile became popular, but it certainly wasn't the norm." And there are now lots of teams not doing it but calling what they do "agile" because they're engaging in cargo cult practices. A whole bunch of stupidity is simply painted with agile terminology (e.g. unfocused daily meetings that are referred to as "standups"). I'm sure "healthcare.gov" was "agile".
efsavage 13y ago
Agree. "Agile" methologies are a great way for: 1. Good managers to manage new or mediocre engineers. 2. Good engineers to control new or mediocre managers. No system will completely mitigate bad managers or bad engineers, and if they're both good the right system will manifest itself.
wpietri 13y ago
I think you've mainly missed the point of his article, but let me address the last bit, about non-technical managers. The way to reconcile his view and yours is to have parallel engineering and product management structures. There are non-technical product managers, but there are no non-technical engineering managers. Every team has engineers and a product manager, but neither reports to the other. That way you get people dedicated to understanding needs without putting them in charge of things they aren't qualified to understand.
- exelius 13y ago
  If you have two parallel organizations that interact tightly but have no power over each other, you end up needing a mediator. This usually ends up being project management, or "the process". This is where you get the mixed bag in companies with mediocre talent levels -- usually they don't have anyone who understands the needs of both the engineers and the business. The level of process usually either chokes the engineers' productivity or ends up not giving the business what they need. Again, it's possible to do, but it takes talent that understand both the business needs and how to manage a development organization (note: this is not the same as knowing how to code.) That's rare to find through a corporate HR process.
  - bunderbunder 13y ago
    I work in an team that's organized the way the parent describes, and there's no mediator needed. The engineering managers and product managers have a good working relationship and collaborate closely, so they usually have no problem reaching consensuses that work for everyone. The close collaboration means that each side is aware of (and can usually anticipate) the other side's needs and limitations, but the division of responsibilities ensures that the number of balls getting dropped is minimized. The relationship most certainly does not need a mediator. Sticking a mediator in there would probably end up destroying the arrangement. If the two camps can't work together without one, a better solution is to figure out who it is that doesn't know how to play well with others and get them replaced.
    - 13y ago

briantakita 13y ago

Agile is the new RUP. The main audience is shifting toward the shitties. It's the circle of life for cultural movements. Nothing wrong with Agile. It's just not my thing anymore.

hpaavola 13y ago
By definition most companies, most teams and most individuals are average. There are very few really good developers and managers. What suits those few does not really matter. They will do great things not matter what. Agile works for most better than the alternatives.
- Tyrannosaurs 13y ago
  Unless you have a very oddly skewed set of people, by the definition of average most people are average (or close to it)...
  - vanderZwan 13y ago
    I think you missed the part where he implied that what programming culture considers "good" software is nothing short of a near-perfect to perfect technical implementation. In other words: what the other guy called "shitty" is actually the average. See also the odd thing that most people consider themselves better than average, which by definition cannot be true.
    - Tyrannosaurs 13y ago
      Yes, the idea that almost everyone considers themselves to be a better than average driver. I've always wondered with that whether the problem is with the question. What it's really checking is whether someone will admit to being worse than average, which is a very different thing to thinking you're worse than average.
      - ZeroGravitas 13y ago
        In "thinking fast and slow", I'm sure the author gave an example of something people will all admit to being below average at. Googling it, the example given is "starting conversations with strangers" and his theory is that people ignore the question they are asked ("how they compare with average") because it's hard/impossible to actually answer, and instead, without realising it, substitute an easy question ("are you good at x") and answer that instead.
        Tyrannosaurs 13y ago
        That's interesting. I have Thinking Fast and Slow as an audiobook I've not yet got round to listening to. Does he talk about other theories? I wonder if there's also an element of what the person has tied up in that skill and what the consequences of being bad at it are? Certainly it seems unlikely that anyone would want to admit to being bad at their job (kind of tantamount to admitting to be a fraud), or at something which, as with driving, can be actively dangerous if you're bad at it.
at-fates-hands 13y ago
I've actually come to the conclusion Agile propagates poor developers and poor managers. I've known some really good developers who go belly up in Agile systems because they can't cope with the tight deadlines, having to ship something in two weeks, or people constantly breathing down their necks. Over the years, I feel like Agile has been used to deliver mediocre products, and in turn, turned good developers into shitty developers simply because the "business" wants to ship something a lot sooner than it should be. It's a downward spiral since all they care about is something getting built, not the inherit quality of said product. Hence, its because of Agile there are shitty developers and shitty products being shipped, not the other way around.

collyw 13y ago

"No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need." Depends what you class as "good software". My colleague left some code which "worked" and "met the needs" (at the time). I made a small change to the database it interacted with and it fell over. I had to go in a debug it, but it was so badly written I had to completely refactor it just to debug it properly. So her software met the needs, my rewrite of it met the needs, and has been far more reliable and maintainable. I would say that is better software.

hpaavola 13y ago
Of course technically better implementation is better if the only thing that changes is the technical quality of the implementation. But it does not follow that doing good software is a technical challenge. It does not matter how fast your algorithm is if nobody wants the results that it spits out. Defining good software is really hard task, but in general what I mean by it is that good software increases the well-being of its users. Yes, one aspect of that is the technical quality of the implementation.
- usea 13y ago
  What happens when the needs of the customers or users change? What happens when your understanding of their needs was imperfect and needs to be updated? Is the software that met the old needs still good? Was it ever good? What happens when the software could only ever meet the old needs, but is impossible to update to meet the new needs? Was it ever good? Needs change. The ability for software to be altered to meet evolving needs is not simply a "technical quality of the implementation." It doesn't just have a faster algorithm. It's better software.
  - hpaavola 13y ago
    I'm not sure what part we disagree here. Yes, technical quality matters. But it matters way less than delivering something that users need. And yes, better technical quality ceteris paribus equals better software.

mattmanser 13y ago

I've read your comments a couple of times and still can't really see what you've added. You're talking about very abnormal situations. Companies that are so technically incompetent they have to hire you. And then saying that we should listen because in your abnormal experience of dealing with teams so dysfunctional they can't even ship bad software that agile at least gets them going a little bit. I suspect almost any change would get them going a little bit as the change itself is the trigger. EDIT: The more I think about it, the more your comment reminds me of the people defending the other fads of years gone past. Workflow diagrams, OOP-design (as a be-all-and-end-all process), UML, Worflow Engines, RAD tools. Your comment reminds me of the defences of them. These things worked because those desperate teams need a light to guide them, not because of the tool itself. And with each of those tools, it turned out the tool itself is mainly counter-productive to functional teams. I think we're realising Agile is another of those false prophets.

twic 13y ago
The question is whether this is abnormal or not. I suspect that it is not. That is, i suspect that there are many more mediocre-to-poor developers and managers out there than there are good-to-excellent ones.
- hpaavola 13y ago
  Exactly. Then the questions is how we can make most of us to perform better. The answer is not to "be excellent developer". The answer must be in the way we do things.
ctb_mg 13y ago
I also disagree with the premise that these situations are very abnormal. Ours is a big field which expands outside of sunny California, where you can't walk a few feet without bumping into a rockstar coder. In the rest of the world where the mediocre is the status quo, Agile gets team members organized and motivated. Of course, if you could find rockstars, you'd hire them, solve many problems, and ship your product. Not everyone has the pleasure of that kind of engineer pool.

Tloewald 13y ago

If you get people who aren't customer focused, aren't testing, and are wasting huge amounts of time in pointless meetings focus on their customers, do continuous builds, tests, iterative releases, and have fewer meetings I suspect you can and will reap significant benefits. But that isn't "agile" it's just some good practices with a label du jour. Good software companies were doing nightly builds twenty years ago (when doing such builds was a major technical accomplishment). The agile cargo cult against which the writer is ranting is far larger, more insidious, and counterproductive than that. E.g. Our project is infested with "release train engineers", "coaches", "rally consultants" and other highly paid morons who actively damage the project while claiming credit for any improvements we manage to accomplish behind their backs.

kasey_junk 13y ago
I don't disagree about the hypocrisy of the folks who have redefined the Agile movement to be something that is decidedly not Agile. That said, the thing I dislike about this new "Agile has failed" meme is that it discounts how much the movement has changed the status quo. Sure it make sense now that small iterative releases, continuous integration, automated tests, customer collaboration, etc will produce better software. And yes there were teams that did this before Agile became popular, but it certainly wasn't the norm. There used to be no standard way to write/run unit tests. The class of software called continuous integration server did not exist. Gant charts were completely normal planning devises. I've worked in environments that literally believed that a senior developer could use uml to design the entire system down to the method level and then it would be a trivial matter for a junior developer to "fill it in". That sounds insane now, but it happened throughout the software industry. Agile didn't fail, it worked so well it became the norm, and now the term is being co-opted by opportunists. That's sad, but let's not let that detract from the very real success story of the Agile software movement.
- Tloewald 13y ago
  I agree with much of what you've said, but I have to pick on this remark: "And yes there were teams that did this before Agile became popular, but it certainly wasn't the norm." And there are now lots of teams not doing it but calling what they do "agile" because they're engaging in cargo cult practices. A whole bunch of stupidity is simply painted with agile terminology (e.g. unfocused daily meetings that are referred to as "standups"). I'm sure "healthcare.gov" was "agile".

efsavage 13y ago

Agree. "Agile" methologies are a great way for: 1. Good managers to manage new or mediocre engineers. 2. Good engineers to control new or mediocre managers. No system will completely mitigate bad managers or bad engineers, and if they're both good the right system will manifest itself.

wpietri 13y ago

I think you've mainly missed the point of his article, but let me address the last bit, about non-technical managers. The way to reconcile his view and yours is to have parallel engineering and product management structures. There are non-technical product managers, but there are no non-technical engineering managers. Every team has engineers and a product manager, but neither reports to the other. That way you get people dedicated to understanding needs without putting them in charge of things they aren't qualified to understand.

exelius 13y ago
If you have two parallel organizations that interact tightly but have no power over each other, you end up needing a mediator. This usually ends up being project management, or "the process". This is where you get the mixed bag in companies with mediocre talent levels -- usually they don't have anyone who understands the needs of both the engineers and the business. The level of process usually either chokes the engineers' productivity or ends up not giving the business what they need. Again, it's possible to do, but it takes talent that understand both the business needs and how to manage a development organization (note: this is not the same as knowing how to code.) That's rare to find through a corporate HR process.
- bunderbunder 13y ago
  I work in an team that's organized the way the parent describes, and there's no mediator needed. The engineering managers and product managers have a good working relationship and collaborate closely, so they usually have no problem reaching consensuses that work for everyone. The close collaboration means that each side is aware of (and can usually anticipate) the other side's needs and limitations, but the division of responsibilities ensures that the number of balls getting dropped is minimized. The relationship most certainly does not need a mediator. Sticking a mediator in there would probably end up destroying the arrangement. If the two camps can't work together without one, a better solution is to figure out who it is that doesn't know how to play well with others and get them replaced.
  - 13y ago