What agile means to me (and why it never really works)

Japanesse companies, Toyota in particular, took hold of American management thought and applied it to their manufacturing processes better than we did. The wisest method was the concept of "continuous improvement", which is to say they constantly are going back and refactoring portions of their manufacturing process to reduce waste, increase throughput, and so forth.<p>It's very similar to how you might optimize a program. You find a hotspot you think might need improvement and you spend a portion of time improving it. Measure results before and after. Rinse and repeat.<p>I'm sure there are a lot of small things they learned along the way but the simple idea of continuously improving their processes has kept them on top.<p>Truly enlightened Agile development is not doing Scrum, XP, etc., it is being wise enough to look at your process and see how it can be improved. Pick and choose different ideas that will fix the parts that need to be fixed, but never be fully satisfied with what you are doing.<p>The real failure in any project management philosophy is believing that it is the "One True Way" that all things must be done for all teams everywhere all the time.

Very good points. At the MagicRuby conference this year, @pragdave said "Agile is not a noun." He went on to say something like "Agile is not what you do, it's how you do it." (I probably mis-quoted that.)<p>It made a big impact on me and made me realize why I had been so disturbed by how the company (that I worked for then) was handling project management. Everything was locked down. Everything had deadlines. Every process was locked in stone and decided on by the manager. Heck, they even said "This is your deadline. Tell me how many people you need to make it happen." ... And when I told them, they failed to get those people on time and still demanded on the deadline. (I left the company about halfway to the deadline as I had found a better position elsewhere, so I have no idea how they are doing on that deadline, but I can't imagine they are going to make it.)

<i>If you have to have everything on your requirements list, you can't be agile<p>If you need to plan beyond the next sprint with any degree of accuracy, you're not agile<p>If you think you can "fix" an iteration by adding more people, you're not agile<p>If you are prepared to change the end date of an iteration to "fit something in", you're not agile<p>If you have to give a fixed date for delivery - it's very, very difficult to be agile. </i><p>90% of companies that are committing to Agile need to read this list, be honest with themselves, and choose a different process because there is something on this list they are not ready to give up.

My impression is this:<p>1. developers find a new way to do things efficiently<p>2. its good<p>3. word spreads in the community. Method gets a nice name<p>4. consulting companies smell money. Develop training for big $. Win managements<p>5. management wants to be modern, but doesn't want to change key aspects, like number of developers, communication, carrier paths, hierarchies etc.<p>6. management requires: everybody has to be able to use this method. Name of the method is filled with different contents: easy to understand, fits well into every companies profile, works for every dumbass<p>7. method stops to work<p>8. consultants still sell it. Everybody has to do the sh....

This is so true. When I first read about Agile it was like an extraordinary breath of fresh air compared to the stifling spec-driven CYA corporate environment I was working in at the time. Now 95% of what is termed "Agile" seems to be as much pointless drivel as I ever saw in that environment.

It never ceases to amaze me how we take good ideas and screw them up. It also amazes me how many people are pissed about agile. I blogged about this a year or two ago, and got something like 50K visits (shameless plug for those who haven't read the article: <a href="http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php" rel="nofollow">http://www.whattofix.com/blog/archives/2010/09/agile-ruined-...</a>? )<p>Just to be a bit of a contrarian, there's a difference between what something means on paper, how it's practiced, and what people think it means. We get into trouble when we confuse this.

A good article but I don't believe that the points presented in the article support the conclusion "why it never really works". "An alarming number of people... believe that Agile is a project management methodology, and that Agile really means SCRUM, XP, Kanban..." Why is it alarming for anyone to believe this? "I was once told by an Agile Trainer (LOL) that the correct way to phrase the requirement..." OK - so that doesn't make much sense to me. "Needless to say his company lost a $m project on the back of such BS" Companies can fail for lots of different reasons - and perhaps this particular Agile Trainer contributed and then again maybe not. That particular Agile Trainer may have been incompetent or misrepresented. The company may have failed for any number of different reasons. So I don't think that this example supports that conclusion. "Agile (big 'A' again) has become a bit of an albatross - it doesn't really work, it doesn't deliver the benefits it promised" I found that the article moved too quickly to this conclusion.<p>You could argue that that wasn't the main point of the article - but if that is the case then I would suggest that the title is a little too provoctive and the first few paragraphs are irrelevant. I enjoyed the article but I think that it would have been better if it simply didn't try to suggest that Agile never really works and just put forward what agile means to you. If the article was called "What agile means to me" and started from the line "agility [...] is a wonderful thing" it would have been great.

The HN headline is not consistent with the article, which is odd, as it seems the article was submitted by the author?

In my own experience, SCRUM is only as efficient as the scrum master and product owner. For the scrum master, it takes leadership to motivate the rest of the team and provide help when there are blockers. For the product owner, it takes a high level of organization to clearly define the sprints' tasks and meaning behind the tasks.

Agile vs. not Agile doesn't matter much.<p>Project management is project management; ultimately you need to do all the same things to succeed, it's just a matter of how you organize them.<p>In the big picture, Agile projects fail for the same reasons other project fail, and they succeed for the same reason other projects fail.

<i>"Measure as much as you can - no feedback == no direction"</i><p>Can't agree more. We have built some internal applications where everything was implemented, the acceptance criterias were met and everyone was satisfied until they actually started using the system and said, ".. wait a minute, this doesnt help us as much as we had liked". But, we had already moved on to the next big thing.<p>"If I’d asked people what they wanted, they would have asked for a faster horse" - Henry Ford, <a href="http://bit.ly/kmLhvZ" rel="nofollow">http://bit.ly/kmLhvZ</a>

Had a tdd openspace at codestock this weekend that morphed in to an agile discussion. Someone asked "what's the one key thing I need as a foundation to become Agile?" (paraphrasing that).<p>4 people all said "communication" at the same time.<p>Communication has always been the backbone of successful projects, in my view. In 16+ years of software dev, I've only had 2 situations where there were technical knowledge issues that were a huge barrier - issues like "how do I connect to a database?" being something someone on a team had massive trouble with.<p>Outside of those outliers, pretty much all other issues have come down to a communication issue of some type - not identifying things clearly enough, not raising the alarm when a roadblock was hit, not alerting a client in time, not getting adequate feedback from a client, not getting things in writing, etc. To the extent that "Agile" practices help encourage regular communication to avoid those issues, it's great. When "Agile" gets formalized in to such a state that it becomes a roadblock itself, that's where the problems start. Since "Agile" has been productized and sold over the last decade, I suspect it's becoming a stumbling block in many orgs, and we'll hopefully see a new iteration/generation of Agile practices which free up people again. Perhaps a stronger embrace of mobile tech in Agile practices would help?

Not to take all the good points away from this article, but I found these two statements contradictory:<p>1. If you do have a fixed time, then scope is variable<p>2. If you have to give a fixed date for delivery - it's very, very difficult to be agile.<p>I've found that #2 is possible as long as you allow for #1. When you have a deadline, you actually become more agile - decisions on what should and shouldn't be done are quicker and the cut off line between "must have"s and "nice to have"s is more obvious - simply because decisions <i>have</i> to be made. Think of moving out of an apartment: are you surprised how productive you get in those last few days?<p>I have also see misuse of #2: teams take #2 as carte blanche to hold the business at ransom to the "it'll be done when its done" mantra.<p>It almost seems like there's three kinds of agile nowadays:<p>1. Big A - the agile that the manifesto became for whatever reasons<p>2. Small a - the agile that the purists conjure up in reaction to Big A<p>3. Reality - where when it happens, you can look at each other and say "We were really agile right there - and shipped something right!"

"If you have to have everything on your requirements list, you can't be agile"<p>Anything on the requirements list which isn't necessary to the product shouldn't be listed as a requirement in the first place.<p>"If you need to plan beyond the next sprint with any degree of accuracy, you're not agile"<p>Sounds to me like engineering and agile process are incompatible.

In my opinion, we developers are trying too hard to come up with rules on project management, and it just doesn't work.<p>The reason agile works is because capable developers are given freedom to make good decisions based on the situation; and it fails when decisions are made by someone else -- be it incapable developers, sales person, management or even another capable developer who is not quite involved in the project.<p>Making up rules just gives a false sense of confidence to those "someone else".

Strikes me that many sorts of methodologies and approaches need a reminder about this. The point of agility or any other engineering methodology is to get better at what you're doing, not a slavish adherence to a set of Ten Commandments without thinking about what they really mean for you and the folks with whom you work.<p>I'll leave the obvious religious corollaries as an exercise for the reader.

The key tenant to agile is built in 'tolerance' for change in resource and scope with emphasis on pipeline management instead of scheduling.<p>The reason why classic forms of development fail is because these issues (changes) were the exception instead of the rule in methodologies leading up to the 'agile' generation

&#62; The best way to achieve your goal is to start with the right people<p>That is pie in the sky. Everyone says it and it's bogus for most people/companies/projects. 90% of the time you have the people you're gonna have. You need to know and make the best of them.

no doubt, agile is not the "answer" to traditional workflow models, but my (admittedly somewhat limited) experience with it has been pretty good. it's really dependent on the people you work with (something the author states).<p>coding with people you know, and understand (and perhaps hence predict) really makes production fast. however, the "tight-nit"-ness of a team like that, means that it doesn't scale so well in ways that businesses like, i.e, throw more money/resources at it, and it gets better/faster.<p>mind you, i think the real lesson to be taken away, is that, when there is a problem with something like this, there is no "correct" solution, which works in all cases, for everyone.

I've got to quote 37signals on this one: "Planning is guessing."<p>In my experience, agile development fails when management turns guesses into promises.

I've had a lot of trouble with agile projects, though I do think that when it works, it's by far the best way to create working software.<p>My biggest trouble with agile happened when I was dealing with a client who clearly intended to hold my feet to the fire where it came to promised functionality and deadlines, but was absolutely unwilling to consider an alternative approach to a feature or removing functionality to meet an iteration.<p>"Customer collaboration over contract negotiation" is the best way to write good software, but if your client is going to go to your boss and complain that say "hey you promised functionality X by date Y!", you better be careful negotiating that contract!<p>"Responding to change over following a plan" is the best way to write software, but if your client is going to rake you over the coals if you don't meet the deadline that was <i>in. the. plan.</i>, well then you're probably better off just following the plan.<p>Really, agile is a highly effective way of working that requires a tremendous amount of skill and mutual respect (and trust) between all members of a team.<p>Another problem with agile is that just so much has been built up around it. I'm not saying that these things are bad, but they have diluted the original message.<p>I remember once a consultant ambushed me in a meeting and asked "what are your developer velocities?" I didn't know what that meant, and he said (I think he was setting this up) "well, if you don't know your velocities, you aren't agile."<p>For the record, a developer velocity is (as this dude explained it) a way of measuring whether a developer is struggling based on how much of a user "story" is being developed over a particular period of time. It's not a bad way to measure things, but this is a process, a tool, a procedure. As the agile manifesto says, we value these things, but it seems like "agile" has less and less to do with the simple and profound (I mean that without any irony) statements and is starting to become a big mess of consultant and techno babble.<p>We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:<p>Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan<p>That is, while there is value in the items on the right, we value the items on the left more.<p><a href="http://agilemanifesto.org/" rel="nofollow">http://agilemanifesto.org/</a><p>To me, this is the best way to write software, but it isn't something you can just decide to do. It requires a really major mind shift from everyone. And if it turns out your client values the things on the things on the right more than the things on the left after all,you can find yourself in a very precarious situation as a dev.