8 ms·

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 custome

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
      > I'm just not sure I'd agree that that means "agile has failed". I think that's because you're disagreeing with what Agile has failed at. You're interpreting it as "Agile has failed to be an effective process", while GP and the article are interpreting it as "Agile has failed to achieve widespread adoption". Agile can certainly be an effective process, but that doesn't matter if 90% of the companies that claim they use Agile are actually using something very un-Agile that they happen to call Agile. This actually raises the barrier to Agile being adopted by more companies, because now everyone hears "Agile" and automatically thinks of it as this... thing that's adopted by MBAs instead of what it actually is, so they reject it.
      - derefr 11y ago
        I think there's a third interpretation: "Agile has failed to spread the spirit of its message to its followers without being corrupted in the process." 'Agile' has achieved widespread adoption. Agile techniques have not. Thus, if 'Agile' were a person—the founder and namesake of a religion, say—they would be ashamed at what their followers were doing in their name.
- andyidsinga 11y ago
  I've almost always used agile == scrum ...I'm not completely clueless, but geeze, I don't talk to my general manager about scrum or xp ...I just talk about agile. EDIT: and I put the agile manifesto outside my cube-wall highlighting Individuals and interactions over processes and tools
  - mindcrime 11y ago
    I don't talk to my general manager about scrum or xp ...I just talk about agile. Interesting. I'm not sure I'd agree with that approach, as I think the distinction between "agile" as a general description of a family of processes, and the specifics of a given implementation within that family, does matter. But maybe I just nit-pick too much. Then again, I also hate the term "sprint" and try not to use it. I think it's misleading and such an inappropriate metaphor as to be actively harmful. I prefer to use "iteration", even in a Scrum environment.
    - andyidsinga 11y ago
      re sprint: I also hate "sprints" ...you can't sprint forever. I've not tried to get rid of it though.. maybe I should try. So, because we can't sprint forever, I built "admin week" into our process - we sprint for 2 weeks, heads down nobody bugs devs (but me). then the 3rd week we "rest", do demo day - show progress and prep for next "sprint".
      - mindcrime 11y ago
        I also hate "sprints" ...you can't sprint forever. Exactly! It's a totally broken metaphor, as nobody can sprint, sprint, sprint, sprint, ... forever with no pauses, rest, or slow periods in between. So, because we can't sprint forever, I built "admin week" into our process - we sprint for 2 weeks, heads down nobody bugs devs (but me). then the 3rd week we "rest", do demo day - show progress and prep for next "sprint". Yeah, I usually try to do something similar to that. It makes a lot more sense to me, than trying to pretend that you can "sprint" continuously for an indefinite period of time.
  - 11y ago
- AnimalMuppet 11y ago
  Part of real agile is that you are free to hack your process. It's a variable you can adjust, not a constant. This means that anybody giving you a fixed process and saying it's "Agile" has completely missed the point.
  - vpeters25 11y ago
    Correct, although I usually suggest inexperienced agile teams to start by sticking to the "rules" for a few iterations before "hacking" the process. There are way too many teams out there rolling their own "flavor" of scrum and unfortunately, doing it wrong, because they didn't evolve it from the basics.
    - AnimalMuppet 11y ago
      Agreed.
- Florin_Andrei 11y ago
  > "Agile" is not a methodology that you can adopt. It simply does not exist. Tell that to 99% of the people I've seen who are convinced they "do Agile". What they do is micromanagement, and call it something fancy.
  - derefr 11y ago
    I don't know why, but that line made something click for me, about what the intent of "Agile" is/was. Agile, from what I can tell, is supposed to be a way to get out from under micromanagement—by effectively creating a contractual interface and protocol for the interactions between the development team and the "stakeholders" (i.e. anyone who could change the business's direction—clients, yes, but also PMs, managers, whomever). The core of Agile is that developers get to not talk to any stakeholders for a whole two weeks at a time (a "sprint"), and just code. Not heads-down-black-hole coding, but rather collaborative just-us-developers-in-a-room-together coding. The entire rest of Agile, other than that core, is a process for making sure that the project doesn't swerve out in some stupid direction due to the developers being incommunicado with the stakeholders. User-stories and TDD, client representatives, Scrum, etc. are all just to let a bunch of programmers—without any managers—achieve a peerwise consensus of what they should be working on. Said that way, it's very likely that it's literally impossible for most corporations to "do Agile" given policies about how management is to be done.
- sageabilly 11y ago
  Really I think the CEO read some article in "Big CEO Magazine" while on his yacht last year about how Agile is the best thing for software companies since sliced bread and he got it in his head about how obviously everyone in the company now needs to "do Agile" and then told his little minions to make the company "do the Agile thing now" and so you ended up with a lot of non-technical managers trying to implement Agile processes and methodologies which is the exact thing the original article is railing against. In my experience as a business analyst, the Agile Manifesto is fantastic until the cookie-cutter MBA's get a hold of it and try to turn it into a rigid set of rules and guidelines that Must Be Followed For Improved Performance!
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.

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
    > I'm just not sure I'd agree that that means "agile has failed". I think that's because you're disagreeing with what Agile has failed at. You're interpreting it as "Agile has failed to be an effective process", while GP and the article are interpreting it as "Agile has failed to achieve widespread adoption". Agile can certainly be an effective process, but that doesn't matter if 90% of the companies that claim they use Agile are actually using something very un-Agile that they happen to call Agile. This actually raises the barrier to Agile being adopted by more companies, because now everyone hears "Agile" and automatically thinks of it as this... thing that's adopted by MBAs instead of what it actually is, so they reject it.
    - derefr 11y ago
      I think there's a third interpretation: "Agile has failed to spread the spirit of its message to its followers without being corrupted in the process." 'Agile' has achieved widespread adoption. Agile techniques have not. Thus, if 'Agile' were a person—the founder and namesake of a religion, say—they would be ashamed at what their followers were doing in their name.
andyidsinga 11y ago
I've almost always used agile == scrum ...I'm not completely clueless, but geeze, I don't talk to my general manager about scrum or xp ...I just talk about agile. EDIT: and I put the agile manifesto outside my cube-wall highlighting Individuals and interactions over processes and tools
- mindcrime 11y ago
  I don't talk to my general manager about scrum or xp ...I just talk about agile. Interesting. I'm not sure I'd agree with that approach, as I think the distinction between "agile" as a general description of a family of processes, and the specifics of a given implementation within that family, does matter. But maybe I just nit-pick too much. Then again, I also hate the term "sprint" and try not to use it. I think it's misleading and such an inappropriate metaphor as to be actively harmful. I prefer to use "iteration", even in a Scrum environment.
  - andyidsinga 11y ago
    re sprint: I also hate "sprints" ...you can't sprint forever. I've not tried to get rid of it though.. maybe I should try. So, because we can't sprint forever, I built "admin week" into our process - we sprint for 2 weeks, heads down nobody bugs devs (but me). then the 3rd week we "rest", do demo day - show progress and prep for next "sprint".
    - mindcrime 11y ago
      I also hate "sprints" ...you can't sprint forever. Exactly! It's a totally broken metaphor, as nobody can sprint, sprint, sprint, sprint, ... forever with no pauses, rest, or slow periods in between. So, because we can't sprint forever, I built "admin week" into our process - we sprint for 2 weeks, heads down nobody bugs devs (but me). then the 3rd week we "rest", do demo day - show progress and prep for next "sprint". Yeah, I usually try to do something similar to that. It makes a lot more sense to me, than trying to pretend that you can "sprint" continuously for an indefinite period of time.
- 11y ago
AnimalMuppet 11y ago
Part of real agile is that you are free to hack your process. It's a variable you can adjust, not a constant. This means that anybody giving you a fixed process and saying it's "Agile" has completely missed the point.
- vpeters25 11y ago
  Correct, although I usually suggest inexperienced agile teams to start by sticking to the "rules" for a few iterations before "hacking" the process. There are way too many teams out there rolling their own "flavor" of scrum and unfortunately, doing it wrong, because they didn't evolve it from the basics.
  - AnimalMuppet 11y ago
    Agreed.
Florin_Andrei 11y ago
> "Agile" is not a methodology that you can adopt. It simply does not exist. Tell that to 99% of the people I've seen who are convinced they "do Agile". What they do is micromanagement, and call it something fancy.
- derefr 11y ago
  I don't know why, but that line made something click for me, about what the intent of "Agile" is/was. Agile, from what I can tell, is supposed to be a way to get out from under micromanagement—by effectively creating a contractual interface and protocol for the interactions between the development team and the "stakeholders" (i.e. anyone who could change the business's direction—clients, yes, but also PMs, managers, whomever). The core of Agile is that developers get to not talk to any stakeholders for a whole two weeks at a time (a "sprint"), and just code. Not heads-down-black-hole coding, but rather collaborative just-us-developers-in-a-room-together coding. The entire rest of Agile, other than that core, is a process for making sure that the project doesn't swerve out in some stupid direction due to the developers being incommunicado with the stakeholders. User-stories and TDD, client representatives, Scrum, etc. are all just to let a bunch of programmers—without any managers—achieve a peerwise consensus of what they should be working on. Said that way, it's very likely that it's literally impossible for most corporations to "do Agile" given policies about how management is to be done.
sageabilly 11y ago
Really I think the CEO read some article in "Big CEO Magazine" while on his yacht last year about how Agile is the best thing for software companies since sliced bread and he got it in his head about how obviously everyone in the company now needs to "do Agile" and then told his little minions to make the company "do the Agile thing now" and so you ended up with a lot of non-technical managers trying to implement Agile processes and methodologies which is the exact thing the original article is railing against. In my experience as a business analyst, the Agile Manifesto is fantastic until the cookie-cutter MBA's get a hold of it and try to turn it into a rigid set of rules and guidelines that Must Be Followed For Improved Performance!

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.