Agile is Dead

The agile revolution has won. There is no doubt about it. No longer are its evangelists the pioneers who blaze new trails and chart the unknown, like they used to a couple of years ago. Agile principles, methodology, tool sets, even agile lingo, have become mainstream. Frankly, everybody and their dog is “doing agile” these days. Of course, there are pockets of resistance in the more backward (or “conservative” to be more polite) companies, but they are destined to eventually see the error of their ways and switch over. Even the most pointy haired of pointy haired bosses know that if they don’t learn, accept and embrace agile methodologies, they are doomed to very soon become everybody’s laughing stock, not to mention their careers are going to go down the drain.

And that my friends, is agile movement’s doom. The revolution is over. The establishment has struck back, as it usually does, using the strategy it always chooses – assimilation, dilution, extermination.

These days, you can call everything “agile”, even the most ridiculously non-agile concepts and get away with it (“agile RUP”, anybody?). See, the problem is that the PHBs that decided that they absolutely have to “go agile”, at the same time decided that they don’t really want or need to change their habits – instead they will just re-dress and rename their usual processes and culture. Which obviously means two things:

  • buying yourself an expensive, yet “agile” tool set, so as to justify inflated budgets
  • getting a bunch of costly certification or two, so that nobody higher up in the food chain can claim they are not “agile”

I have noticed quite a few comments on this site, typically posted by the “foot soldier” developers, that “this whole ‘agile’ thing is same old, same old. All it does is bring us more meetings, more reporting, more micro management”. How typical. Agile processes are being introduced in companies without paying attention to the absolute fundamental need for a culture shift – it really is “same old, same old”, it is just dressed funny. The end result is that teams mindlessly follow “agile” process steps, because the expensive, certified consultant told them to, or a costly tool, mandated by the upper management, forces them to. And they fill out more and more paperwork — even more than they used to before they went agile. Unit test reports (usually hand-filled in Excel). Ridiculously detailed time tracking. Insanely elaborate acceptance criteria for user stories. Torture of daily standups (an hour of it every day, with mandatory report-out to management). It is all in there. There is not a trace of principles of communication, respect, trust, self-organization left in such teams (it has never been there in the first place), they do not evolve to becoming creative and effective, but they are still “agile” and they can prove it! They are certified!

And quite honestly, we have brought this upon us ourselves. Instead of concentrating on spreading the word about the principles – which is hard, because traditionally-bred teams and managers have trouble understanding, not to mention converting – the agile community has concentrated on proliferating certifications. Certified Scrum Master? Scrum Practitioner? Scrum Trainer? Grand Klan Master? Chief Lizard Wrangler? Cappo di Tutti Cappi? Sure, why not, just shell our a bunch of monies and sit there for two days, pretending to listen to some bloke that already is certified by us. Admit it – it is a Ponzi scheme. There is no proof whatsoever that becoming “certified” makes you a better developer or project manager – but it does mean that the thing is easier to sell to top level management. ISO certifications and CMMI server the same purpose – improving the chances of selling consulting services to managers. And of selling software to customers (“gee, they must be good, they have ISO 9001 and CMMI 5, let’s buy from them”).

It does not stop there. Soon, agile is going to have a “maturity model” of its own – backed by IBM, no less. Who cares if it is worthless — it is from IBM, so it is “professional”, right? I wouldn’t be surprised if the next move is for some big player to simply go out and acquire trademarks to all relevant agile processes – “Scrum(TM) and you can only use it under license form Microsoft”? “XP(TM) brought to you by IBM (and we better not catch you using it without paying us)”. Why not? What’s to stop them?

The revolution is over. It is time for a new one.

Or is it? I invite you to a discussion. Convince me that I am wrong.

41 thoughts on “Agile is Dead”

  1. ‘agile has become mainstream’
    is that so? Numbers, anyone?
    The agile community speaking about it like mad is no proof.
    I don’t want to argue against agile, I just want to know if my thinking time is well invested.

    As some other commenters have already pointed out agile isn’t about doing what the books say. This, and a more universal notion of how to be successful with software development is best summarized by a C.C. Shelley quote:

    ‘Excellence is the driver of software development, not uniformity.’



  3. I put together a high level trend analysis of agile & scrum here:

    Granted this is using free, available tools from Google and Indeed. You’d need to deep dive into it to remove dupes, etc but it serves the purpose of the article well enough.

    As for the American Snake Oil comment, Google Trends shows the United States as #6 in search volume behind India, Sweden, Finland, Norway and New Zealand.

  4. When the big guys (Accenture, et al.) starting providing “agile” services that were merely a few of the agile practices wrapped around their big process, it must have surely been obvious that agile was heading down the toilet. I laugh when I hear developers with two (or more) machines at their desk claim that they’re using XP as they do solo programming. Sadder still is the misuse of the term “refactoring” when what is really occurring is a complete rewrite because the current version was a hacked up mess with no foresight. Likewise, the whole scrum concept has been perverted into just another form of micromanagement via meetings. It’s really tragic because a lot of the ideas and practices are really just common sense in many ways (which is why it’s hard to get them into practice).

    As you mention, just buying tools and certifications does not make an organization agile. Indeed, it takes a fundamental shift in the culture which sadly just does not happen at big corporations where the main practices are politics and empire building. That being said, big corporations are inherently non-agile because they simply can’t turn on a dime (it’s also the reason that big corporations buy innovation rather than create it). So indeed, I would concur that Agile is dead or dying with regards to its original meaning and intent. Sort of like the term Software Engineer is handed out to anyone who claims to be able to write code whether or not they engage in any sort of actual engineering practices.

  5. I work at IBM and we’re recently becoming “agile” but there are 2 issues I see right now: 1) it’s going to take more than the development team to become agile and 2) the development team is going to have to become truly agile instead of just adopting the new lingo.

    1) Our higher level management, the ones that make the decisions as to what is funded, are not agile. So how can we become a truly agile company if our leaders are not? It cannot work that way. I have to admit I’m not involved in the funding side, and to tell you the truth, I don’t think I want to because it’s probably a circus, but it doesn’t really work well that they commit us to a particular set of features and in agile you never commit to anything. How can development choose to throw (even the low priority) features away if we are funded for that? Even if we could throw the low priority features away, we would probably end up with a resource action because now we can’t justify having 20 developers work on a project that was originally funded for 30 developers. The issue here is that the people funding our work have no freaking clue how long and how much effort it takes to actually get it done. So their original 30 people funding project would probably need to be done by 50 people and when/if we cut function out…we then get stuck with 20 people STILL working excessive amount of overtime.

    2) Most of development has not seen an advantage in our transformation to becoming agile. We ARE stuck with more process, more tools, more terms, etc. The latest thing that came out of our reflections meeting was that we needed to start tracking “ideal hours” in our tasks and I asked “why? are we going to use that somehow?” and the answer was “maybe, we’re not sure but we might so we want to start tracking that” and to me that is the definition of waste which agile frowns upon. This turned out to be a back and forth between myself and the leader, of course I came out as being unwilling to help in the process and argumentative.

    However, there are people at IBM that are trying really hard to incorporate truly agile methodologies and guide us through the process. I think a big part of the success/failure to any new process is left up to the individuals of a team. We’ve reduced our 3 hour weekly meetings to daily 15min SCRUM meetings…and they NEVER go over 15 minutes. We have increased our communication with our test team EARLY in the cycle. We have started test driven development. We have started a pair programming pilot. We have started to tell management early when something is just not going to make it. We have started to do the must do things first and leave the other stuff for later. We have started to put less focus on design documents and more into actual chalk talks and code. We are more focus on one thing at a time for the most part, leaders have a really hard time with this because they want us to do 10 things at once but we’re getting there. We started demoing after each Sprint to get immediate feedback, and it has worked wonders so far.

    So do I think it’s a complete waste of time? No. I have actually enjoyed my work more now than ever before. I make decisions, or so I feel like I am. I have input as to how long something is really going to take. I take pride in what I do and I’m given an opportunity to show it off everyday during the SCRUM and at the end of a Sprint through demos.

    Aside from all that, the biggest difference for me is that we’re putting some structure to a failed process. It allows us to realistically see what we’re going to really accomplish in a release at the start of the release cycle, instead of at the end. We are probably going to release the same number of features, perhaps less, we would have if weren’t agile. The difference is that we know that upfront and instead of feeling like we didn’t reach our goal at the end, we actually feel like we did what we set out to do and that is rewarding.

    I don’t know if what we’re doing is agile, but it sure is better than whatever the hell we were doing before.

  6. Hey guys,
    I’m relatively new to the industry, and as I’m only 22 and just graduated with my degree in Software Engineering, I’m having trouble defining what agile is exactly now (not any specifics like scrum or xp).
    I was under the impression that all the core processes in waterfall are still essential; planning, RQ, design, and that the only difference was rather then a chunk of implementation followed by V&V / testing work, you can perform them in small sprints or cycles to allow for V&V / testing processes during implementation. This in turn allowed for defects to be discovered much earlier, and corrected earlier, hence reducing the overall time, cost, and effort, and also allowing for clients who don’t know what they want (everything bar government/defense work where they know their requirements) to make changes that can be adopted much more efficiently.

    So now what I don’t understand is this how you “follow agile” as such. If you follow a modified version of agile, is that agile? My belief was that as long as you have iterations in your implementation, you are agile, as this seemed to be the only difference between that and waterfall (essentially)? Any other changes to how you do your planning, documentation, design work, how much effort you put in these phases, are just your companies own modification to it, as no one follows a lifecycle the way it is defined. As far as I know, no one follows the waterfall lifecycle or a strict agile lifecycle that hasn’t been catered in some way for their organisation.
    Have I got it all wrong? or am I missing a bigger picture?

  7. Start Ups and Agile – I think with 15 years of s/w dev background (Waterfall to Extreme) I can share a success story as a ScrumMaster Dog. I’ve followed RAD, JAD, Lotus, IBM and Oracle’s dev methodology.

    #1 Rule – get management buy-in!! Enough said…anyway here’s my ramble –

    Having recently worked at a StartUp (and startup types tend to have the agile culture) that was essentially using “agile” concepts before we learned of the true methodology – I can only say that the upgrade in processes to Agile was well worth the effort. Our iterations started at 4 weeks but we trimmed them to 3. Our kept our standups to under 20 minutes and our Product Owners were very involved as were QA, Training, Doc and Management. At first we had several small team standups but we found consolidating the teams into one standup proved effective with our cross functional teams (QA etc). We had remote developers so we had to keep the tempo up and to the point etc.

    The competitive nature of our teams was a healthy and refreshing side effect of the formal implementation of Agile. We did the 2 day consulting gig and it was well worth the money to get the entire company speaking and understanding the lingo, principles etc. Marketing and our Services teams also incorporated many of the Agile principals with success. Honestly, the process works hands down. Now, given we were a small shop of developers (20-25) it was probably much easier to gain buy in from the brass as well developers than say at a Gorilla like IBM, Oracle etc. But that’s why I like startups. Further, being nimble in the world of COS is key and Agile deffinately helped everything from UI to Ease of Use to better Whole Software Product. You will need to invest some time in Tools as collecting and tracking User Stories/Points gets really ugly in Excel 😉

    Each of you will determine the effectiveness of your teams as they incorporate the principals. I found a key determination is truly defining what “Done” means in your stories. This can be challenging but worth the effort IMHO.

    Anyway, good luck to those in getting support and with your implementations – I found it very worthwhile and a productive part of our overall team chemistry.

  8. First of all, I agree with the author that agile work processes are becoming mainstream and subsequently, they get watered down. I think this is inevitable, because most corporations ‘do’ agile only to attract customers and/or developers. They want to fake it, because really changing is painful for status quo (its people and its beliefs).

    This is no big deal.

    Developers and (mostly smaller) companies that know when and how agile principles are the most important, know how to get the benefits from it. They don’t need market-wide recognition. Of course, the word agile will come to stand for something different, so maybe there will be a new one. But anyone really working (not necessarily only developing) along agile principles will recognize others with the same mindset. They don’t need labels and/or certifications for that.

  9. Janusz, you really kicked up a hornet’s nest with this one! I don’t believe it’s about traditional methods or agile. You need traditional methods at a macro level to keep auditors happy. What you do at the task level should be flexible in terms of methodology and some teams can use agile for certain deliverables. I would not mandate agile or force traditional teams to change. In my last company, we had pockets of agile for new products and traditional teams for enhancement or maintenance projects. Continuous agile is not sustainable or fun.

  10. The sentiment, “Agile is Dead” is correct in some ways. Our company is pushing Scrum and I told one of the other Tech Leads, that I have yet to hear one principle of Agile mentioned; especially “People over Process.” But I’ve seen that to varying degrees over my entire 25 year career. Here’s my conclusion. Agile conflicts with alot of people’s chosen worldview. In other word’s more fundamental principles underlie agile, Humility, meekness, honesty, consideration; strength of character. We have a politically correct viewpoint gripping companies, where the foundation for pride, self esteem, confidence, etc tends to be more selfish and inward thinking.
    We never get back to challenging each other on the things that should bind us together. Maybe in politiacl terms, We haven’t conserved the things we should and have progressed the things we shouldn’t. We identify and pit our little group against the world because we are better. Even the Agile “Camp” has done this. We all are selfish and tend to look to the wrong items for our self worth. Is the term Agile dead? maybe, but the principles never die, because the people who came up with the word Agile, only discovered eternal principles as applied to software development. The thing for all of us it to improve ourselves based on those principles. Is your battle is against waterfall or against selfishness? was it waterfall that caused the issues or someone’s pride that dogmatically held to a design and schedule they deemed perfect. What people put their pride in must change, that is harder to affect.

  11. Agile is dead, long live agile!
    You are right is useless in most of the case. Especially when teams of the same projeect are spread all over the world and they have to work remote.
    Here in Romania, Agile is the big fashion. most of the software companies started using agile even if is requested or not, useful or not, they just have to use it, to keep the stack as higher as possible.
    Hey Agile, please let us do our Waterfall, V-model ways of testing or any other methodologies but not you.

  12. Yes, Agile has gone mainstream and there are organizations that should bring in outside assistance to help formulate their plan rather than grow it organically since that will lead to the problems you raised above. However, I have participated in an agile project in an organization that uses agile for all their projects and found it to be effective and refreshing. When done right, I don’t believe I’ve seen a more effective approach to software dev.

    This approach to software development is radical versus waterfall leaving many lost trying to reconcile the paradigms, but it would be a real loss to the industry if it were to stay a grassroots and radical effort. I agree with your assessment regarding certifications and have blogged on this topic regarding EA certification. Certification should only distinguish that an individual has completed a level of training, but it’s up to the organizations hiring that talent to decide if the person can or cannot accomplish the task at hand; no different than any other criteria and should not be used as a filter. Most often the best don’t apply for the certification because it’s viewed as a waste of time. Moreover, in my experience, those who do go after certifications approach it like collecting baseball cards rather than achieving a level of mastery; only apprenticeship can provide this.

    So, in summary, agile goes mainstream = good. Certifications without verification=bad. Businesses should reach outside the organization for assistance going agile to avoid political and bureaucratic processes.

  13. I can speak with some modest authority on this general topic given I run the U.S. division of the largest, Agile consultancies operating in seven countries today. Rather than agree or critique Jausz’s blog article (or the remarks of those who have posted comments). let me add our own experience and perspective on the subject.

    First, without question, Agile semantics and concepts (in the generic form) are accepted, if not embraced everywhere I go (we work almost exclusively with fortune 2000 firms). I routinely meet with CIO’s, COO’s, SVP’s of App Devp and occasionally the CMO, CFO and CEO. All these stakeholders are universally enthusiastic about “Agile”. Most however (imho) are clueless what Agile really means beyond the platitudes and vocabulary.

    Second, without question, the critically important culture, transparency, engineering practices, skills, disciplines and automation infrastructure that make it possible to conceive, design, code, test and deploy vertical slices of a new products or systems in sprints of short duration (1-2 weeks) are rarely present in the very same companies espousing “Agile”.

    So, if our experience is a reasonable proxy for the marketplace as a whole, do the circumstances suggest that “Agile” is dead or possibly “meaningless” due to the diluted understanding? IMHO, no. Why? simple. Most medium and large companies are in a desperate struggle to reinvent themselves to maintain relevancy in the big secular trends now underway. Today’s global recession has only revealed the cracks in the foundation.. The foundation of these companies was already failing before the recession and will continue to do so until these comapnies respond with authentic, people centered change or they will collapse under their own weight.

    So, I’m am quite optimistic and excited by the Authentic Agile principles, values and aligned software development practices that are accelerating in those companies with courageous leaders… for the others practicing faux Agile, we all know they will eventually fail.. but this is not a failure of Agile, nor do these failures contaminate “real Agile”.. if there is a negative outcome for “Agile” it will likely be the vocabulary we are forced to adopt to avoid being tarred and feathered by our less enlightened colleagues.

  14. You are right that “mature” companies and “professionals” will carry on working the old style just changing the label – this is what defines “mature”, “professional”, “experienced” etc for many people, and that is what is valued by many.
    You are right that ability to apply word Scrum or Agile to your work becomes meaningless, as it was with ISO9000+ – for many it was a leap ahead, for other just another buzzword you need to have in your portfolio to improve your competitive advantage

    I question the importance of this finding, though.

    Who cares that some corporation twists the idea of Scrum, Agile or XP? Maybe except the direct victims – but hey, who cares what a headcount feels?
    Nobody in his right mind will believe that an inefficient waterfall company suddenly became agile. They used to be unable to produce anything valuable with reasonable budget, and they still are – nothing really changed.

    It’s all about people – you talk to them, you see what they did in the past, maybe see how they work now and then you decide – doing business together or not. Certificates don’t really matter, and the same applies to your buzzword collection.

    Unless you are NASA, the Government or a corporate manager, but that’s a different story.

  15. Agile was never alive. To convince you that you are wrong, we’d need to go back to your premises, which are wrong. Resistance to Agile is perfectly healthy and not “backward” or a “failing to see errors in ways”.

    You are wrong here and I’ll show you why if you like, but first you must be prepared to accept the possibility that “Agile” is a bogus pseudoscience that infects this industry and its demise as an anti-concept is a progressive advance, assuming nothing equally destructive replaces it.

    Are you willing to discuss this?

  16. I warned Brian Marick about this the first time he explained to me that Agile didn’t mean “agile” nor the general principles of the manifesto, but rather a specific set of practices that a specific group of people liked to use. We had a huge argument about it. It ended our friendship.

    He didn’t like that I kept going meta (“going meta” is another way of saying “thinking through what we are trying to do and why and how”) and that I believed testing is a useful skill set worth specializing in.

    Any time we reify and simplify a movement down to a formula, stupid and fearful people take over. It’s what they do. It’s all they know. Agile methodology has a beautiful and simple set of premises, combined with a daunting set of skills worth mastering. But “Agile(TM)” can be easily faked by people who don’t have the motivation or patience for craftsmanship.

    I’ve been trying to stop the certification stormtroopers from destroying the testing craft, but not enough people are speaking out and standing up. I hope you have better luck in the agile development side.

    1. Hear, hear!

      In particular: “going meta” & “thinking through what we are trying to do and why and how” vs “stupid and fearful people take over. It’s what they do. It’s all they know ….. people who don’t have the motivation or patience for craftsmanship.”

      Well said!

  17. @sginter – “It’s all about people” – spot on. What differentiates good teams from bad teams are people in them, not processes they use

  18. @Tony – I hope you have arguments to back up your assertion that agile is a menace and a snake oil. I would be happy to hear them and discuss, because I beg to differ.

  19. Good thinking! I totally agree. Now everybody’s doing agile, it will turn into mainstream, with mainstream audiences involved, who indeed will desire a maturity model, and rules and guidelines to follow (“you can not do modeling in an agile project.”, “It’s not allowed to have more than three categories on a task board”). Moreover, everybody who knows how to tear off a post-it note from a block is made into a Certified Scrum Master (something like a Certified Pokemon Trainer isn’t it?).

    We will have to be very careful for this type of anti-patterns! So that’s where we’ll go next. I’ve been doing talk on agile anti-patterns for some time now, but still glazing looks in the audiences 🙂

    Please also read my blog post “Trjoan rigidity” on agile scrictness at

  20. There are some excellent points here.

    For me, I’m not too concerned whether Agile is old, new, mainstream or still embryonic. What matters to me is that it works. I’ve been involved with huge Waterfall projects and seen the pain and misery suffered by the project teams – coming to work was a real chore and very little was delivered to time, cost and business benefit. With Agile teams (many of who started as Waterfall BAs, Devs & PMs), I’ve seen them look forward to the working day, knowing they will actually achieve something. And I’ve seen the Corporate Management Team move from scepticism to wanting to introduce the Agile ethos in other (non-software development) business areas.

    For me, Agile delivers – its’s as simple as that!

  21. Buit I do agree that becoming “mainstream” often results in dilution and morphing into something less effective (but often more palatable) than the original idea.

    For those who really don’t want a revolution, tailoring something to more comfortably fit the status quo can mean they don’t look/feel left out.

  22. Perhaps it is the fate of agility to fade away, leaving only the grin.

    Applying an adjective to a noun does not change the true character of the noun… it is easy to misunderstand, or even to deliberately lie. Just claiming ‘agility’ never did make one agile. As Jeff Sutherland has observed, most implementations of agile and/or Scrum are really implementations of ‘agilebut’ or ‘Scrumbut’. That is, the implementors would be agile BUT there are all these jolly good reasons why “we’re different, and that won’t work for us”!

    Every time I hear an ‘agilista’ use the term ‘waterfall’, the warning bells go off, and I know I’m listening to someone who hasn’t taken the trouble to understand the real issues. Hence I’m suspicious they don’t really understand the principles. Let alone understand where they came from or the inter-dependencies between them. So I don’t expect agility from such folk. Most folk work in the 75-80% of organisations that hover around the median measure of effectiveness (pick your scale: productivity, velocity, customer loyalty, product quality, … however you choose to measure effective achievement of the business goals). The trouble is, that median scores less than one (1) on a five-point scale. So most folk have never experienced a highly effective organisation… they cannot recognise the characteristics of high performance ‘cos they have never seen them. So they settle for doing what everyone else is doing. This is called ‘fashion’.

    In the end, what matters is being effective. Whatever methods you use. Measuring your activities, counting your certificates, displaying your merit badges, ticking all your agile principle boxes… it’s all dysfunctional (or possibly, diagnostic). The only measure that really matters is progress toward your goals. If you have any beyond ‘being agile’. In an ideal world, you won’t be judged by what you are, but by what you achieve. Some hope, eh?

    Best regards,
    Grant (PG) Rule
    MD, Software Measurement Services Ltd.

  23. @Anonymous Coward

    You are welcome. I always welcome interesting and intellectually stimulating comments.


  24. Although some of your points are interesting, I think there is a common misunderstanding about what agile should really be. Agile should not mean one hour standups, more paperwork, and more meetings. In fact, standups should not last more than 15 minutes, if they do then you should really assess your agile environment.

    As far as Agile becoming mainstream, it really makes no difference. True agile is unique to every team. I don’t believe that you can apply the same agile methodologies to every development team. If that were true, then it would not be called agile. Teams should be not be concerned with whether or not agile is mainstream, there is no time for that. Instead they should be concerned with how they can use agile principles to guide them in improving their overall collaboration and efficiency.

    A large number of companies are implementing Agile methodologies without really understanding how or why. I think part of the problem is that change can be difficult especially in larger development teams. It takes discipline and practice. I’m not saying Agile is the gospel, it is simply an option that may or may not be useful to you.

    Agile tools can help, but if you’re not researching these tools and assessing their usefulness for your situation, then I really have no sympathy for misuse or lost investment.

  25. Moving an organisation that has very traditional PRINCE2 waterfall program structure to all the methodologies of agile is not something that happens overnight. The key is to learn lessons of agile, lean, etc and improve communication and practices across the whole project team. This works well only where you have people that are open to change and that can adapt.

  26. I’m a DITA (Darwin Information Typing Architecture) practitioner. DITA is an IBM creation released to the public domain and now governed by an open consortium (OASIS). Based on my experience with DITA – vibrant community, healthy development, broad vendor support (although there are snake oil salesmen), and a maturity model – I don’t think that an Agile Maturity Model supported by IBM is necessarily a bad thing.

  27. Well, that’s sort of the whole point of my post – we in the agile community have apparently not stressed the need for understanding the principles first and foremost, instead concentrating on defining a multitude of “not optional” processes and practices and moreover, signifying their importance with certifications.

    So it is in large part _our_ fault that companies trying to introduce agile concepts find themselves misguided and concentrate on wrong things – introducing new processes instead of changing the culture.

  28. A knowledgeable agilist can weed out the “scrumbuts and notagile” companies usually with a cursory glance at their agile job postings. If you want to grill them in person, I suggest starting with these to determine their agility:

    But I’m not here to rant about the agile buzzwords being thrown around with the frequency of Web 2.0 and SaaS…. I think the much more exciting and interesting point to make here is that agile is evolving into an overall lean framework.

    Agile & Scrum only make up pieces of the puzzle for a company’s success. Who wants to run flawless agile & scrum frameworks that produce software no one uses? There is a lean startup movement taking shape that bakes in Minimum Viable Product and Customer Feedback loops to help the product succeed.

    These feedback loops and iterative business models go together with agile like peanut butter & chocolate.. and I believe they’ll continue to evolve and change the way we build successful software companies.

    Low cost barrier to entry, distributed teams, iterative development using the web as an operating system… these are exciting times!

    So let go of agile as it was…. let the PMI incorporate agile if they want… I see amazing potential here regardless.

  29. I like using the Inigo Montoya quote (from the Princess Bride) because I feel it encapsulates this issue of practices versus principles. Like many of you, I have found that there is a big gap between people who say they are practicing agile and those who are familiar with the values and principles.

    Agile gives you the freedom to create a process that exactly fits your team, work, and context. However, it also gives you the responsibility for creating that process. For some, this is exciting. For others, this is scary.

    For those who do not like risk or have been socialized in their work environment that failure is bad, they will likely want the comfort and security of a defined process. Unfortunately, it is highly unlikely that they will look to adopt and improve it to fit their needs. The process will become a scapegoat if things don’t work out as expected.

    For those of us who keep striving to improve our lot, agile is a welcome change.

    I wrote about getting back to the principles here:

  30. I’ve gotten to the point where, if I see “agile” development in the job ad, I think “oh noooo…”

    It’s like when you hear “we treat people like family here” in an interview (“oh noooo…”)

    Agile development is an excuse to seat people in a pit and have a select primadonnas treat everyone like unworthly kindergarteners. And those primadonnas could be people who don’t know anything about development. And the standing meetings, what a gimmick.

    Talent looks for places where they are not treated like kindergarteners.

  31. Been through a lot of revolutions, Structured Methods, 6 Sigma, SEI CMM, Spiral, OOAD, RUP, Iterative, Lean and now I am signed up for Agile. (PHB). Attending the class and the instructor wants to know why I keep laughing. OK to the point. Any process can/will work if you have a good team and talent. Even a half ass process is better that chaos and good teams will take a process and adapt it and get the job done. The more processes “techniques” you know the more you can pick the good items from them and get the job done. What I would like to know is can any one point me to independent benchmarks with validated metrics on how Agile performs ( please no SW vendor sponsored white papers ( sound of gagging in the background)? Show me the numbers>>> Quality? Cycle Time? Productivity, Customer Satisfaction. Lots of warm fuzzy stories not much empirical backup. Yep Mr President we are kicking their butts and the new plan is working great… please send more troops… sort of deal ( remember my name is Old as Dirt so reference the 60’s.. although…). Damn getting sarcastic again.. I asked my instructor about this ( she is a professor at our local State University) and the whole scene became very awkward.( He’s a witch .. burn him, burn him…) The answer given was basically the numbers are out there but no one wants to share them. Hmmm secret to know the handshake. my spider sense began to tingle. Oh well that’s it. Hope there is still interest out there.. and I would really like to look at some hard data.

  32. What you experienced is not untypical for overused language. The term ‘Agile’ has been tossed around long enough to accumulate meaning it doesn’t actually have. Also don’t expect vendors to differentiate between their products or service offerings and underlying concepts (sad I know).
    I have a feeling the fans of agile practices will strike back by rebranding their efforts sooner or later…
    Pariuri SportiveRezultate LiveClasamente Fotbal

  33. Agile is not actually dead. It is very useful for certain companies because those companies see the need for it. They just dont blindly follow it because some HOT SHOT scrum master KUNG POW said so.

    If everyone who are involved in the process, especially the person facing the client, does understand the advantages of agile and works accordingly, then agile could be very very successful, otherwise it would act like a wife just before divorce; you can’t get rid of it neither can you accept it.

  34. Intekhab, IMHO the problem is that month after month Agile becomes more of just a word and looses its meaning. Well, it happens with any good thing becoming popular. The more clients ask for “agile” development, the more there’s motivation to just call anything “agile” without changing anything.

    There’s nothing bad in agile itself, translations and interpretations of it is what changes.

Leave a Reply

Your email address will not be published. Required fields are marked *