BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon London

Adopt the right emerging trends to solve your complex engineering challenges. Attend in-person or online.
QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person or online.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or online.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Controversial Voke Report Warns Agile Adopters

QCon San Francisco (Oct 2-6, 2023): Find real-world practical inspiration from senior software engineers.

Controversial Voke Report Warns Agile Adopters

Leia em Português

This item in japanese

Bookmarks

Jul 20, 2012 1 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more

Earlier this week Voke, a US based analyst firm that focuses on application lifecycle and its global transformation, published what can only be called a controversial report on Agile methodologies and their implementation across different technology companies. You can find the report on Voke’s website, but you’ll need a premium subscription to view its contents. You can also find a detailed summary of the report by David Ramel on the Application Development trends website.

The report, entitled “The Agile Dilemma”, is backed by data from a survey completed by over 200 participants - representatives of technology and non-technology companies that use or had used Agile development. Its aim was to provide context for organizations that are evaluating the Agile approach for their teams. Based on the participants’ comments the report defines Agile as a “developer-centric” approach that allows the exclusion of QA and SysOps from the process. It also states that Agile principles allow developers to “push back on processes, tools, documentation, and following plans”. This, combined with a high number of participants (40%) reporting no success with Agile, leaves the authors of the report less than enthusiastic about the methodology: “Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training”, they say.

Outside of the report some interesting conclusions may be drawn from the survey answers - 64% of the participants found the transition to Agile “confusing, hard or slow”. Only 28% report success with the new approach. The main benefits reported were faster releases and more feedback. There are plenty of Agile success stories and articles avaliable on the Internet that contradict Voke’s report. There are also members of the tech community that agree with the report completly. What is your take on Agile? Do you think it is a massive scam or do you agree with one of the commenters on the slashdot website when they ask “...did the analysts just talk to the wrong 200 people?"

Rate this Article

Adoption
Style

This content is in the Agile topic

Related Topics:

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • good

    by Ali Motaz,

  • yes, lets have critical look at Agile

    by Konstantin Ignatyev,

  • Agile is at fault?

    by Alan Dayley,

  • The plural of anecdotes isn't data

    by hans ma,

  • Wow... Horrible definition of Agile

    by David Bock,

  • Scapegoating is easy, root cause analysis is hard

    by Dave Nicolette,

  • A report on the What, not on the Why, and some myths

    by William Martinez,

  • It's like saying "democracy doesn't work because people are stupid".

    by Richard Clayton,

  • My thoughts

    by Jordan Bortz,

  • Agile or Tragile?

    by Shane Hastie,

  • Questionable Conclusions

    by Graham Perry,

  • Agile sells services

    by Dan Mezick,

  • Pot meet kettle

    by Marc Stock,

  • ' transition to Agile “confusing, hard or slow”'

    by Michał Żelechowski,

  • Agile - a methodology weighed above its real mass

    by amila navarathna,

  • Possibly missing the point

    by Dave Nicolette,

  • This is a great debate :-)

    by Ethar Alali,

  • Voke report: Agile delivers higher customer satisfaction and quality

    by Jez Humble,

    • Re: Voke report: Agile delivers higher customer satisfaction and quality

      by Jordan Bortz,

      • Re: Voke report: Agile delivers higher customer satisfaction and quality

        by Jez Humble,

        • good

          by Ali Motaz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          i think its good that someone (hopefully reputable) is attacking the methodology community
          i do believe in agile, and i do believe its developer centric,
          but ... this is not a bad thing
          what is really bad are those who are trying to sell the buzz, and those promoting specific methodologies proclaimed to be agile
          agile development is and should stop at the manifesto, i love the agile values and principles mentioned in the agile manifesto, and i seriously doubt they can be proven wrong
          the problem most of the time is in IT departments in large organizations and when they try to build custom software, building custom software is a flawed act, we shouldnt do it

          software that is built according to user requirements is a bad idea, the failure is not caused by the method followed, the failure is caused by the inherit flaws in the task itself
          if an organization cannot find an application that already does what it wants, exactly, they shouldnt try to custom build it, they should change their operation to accommodate for the software they can buy ... its so arrogant for a company to think its so unique

          and in the case they have to build a new application to operate, then they must admit it to themselves that their business is IT centric and that they should transform themselves to be an IT company, like google or amazon, amazon is not a retailer, they are an IT Business

          if they cant transform themselve, then dont they should not make new software, something out there must work for you ...

          the most successful IT projects in any company are those when the software is bought and the project is managed by business, when the IT department is sidestepped ... the business will have no one to blame and will compromise or pay

          Back to top
        • yes, lets have critical look at Agile

          by Konstantin Ignatyev,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Simply put Agile is good old 'time and materials' contract.
          Contractors love it because they paid for everything they do, redo, learn, redo again, etc. That is why all the consultants scream 'Agile' and happy to push for it.

          However 'time and materials' contracts also allow great people create great things, but unfortunately great talented people are in minority. So, initial plentiful Agile success stories can be explained by early adopters phenomena: most talented people used the 'time and materials' contract to unleash their creativity, but by now statistics kicks in: average, and below average folks simply take advantage of the 'time and materials' contract.

          What is needed is some sort of 'independent' certification and evaluation of providers akin to the bar association for lawyers. Contracts with lawyers are 'time and materials', but bar provides little bit of assurance that lawyer can provide adequate service. This part is missing in software development, there should be some organization that interviews and tests developers and consulting organization and score them for proficiency.

          Back to top
        • Agile is at fault?

          by Alan Dayley,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I like critical reviews of any methodology or process, including those I espouse. This report is, to me, a headline looking to make a bigger contraversy than what exists.

          From the report:

          "In our survey results we saw that the organizations that struggled the most with traditional projects, also struggled with Agile ... By contrast, organizations with the highest traditional success rates also had the most successful Agile projects"


          So, the reason Agile fails is probably the same reason ANY process fails at a given company. Bad company culture + Agile = Bad Company Culture + Traditional. Culture eats strategy for lunch, every time! Companies that do poorly with traditional also to poorly with Agile, but, somehow, this is the fault of Agile. Really?

          The report does point out some things that are needed for any major process shift, like better training, better consultants (coaches) and so on. The Agile proponents would do well to improve in these areas. And to not ignore culture.

          Back to top
        • The plural of anecdotes isn't data

          by hans ma,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          There are plenty of Agile success stories and articles avaliable on the Internet that contradict Voke’s report.

          There are plenty of success stories proving that faith healing works, and even many articles that contradict the moon landings. Isn't the Internet great?

          Even if interviewing 200 people may not be the greatest sample nor the most stringent methodology (among many open questions, it's not clear from the summaries how they were selected, how many non-responders there were, etc.), it's a huge step up from Agile consultants presenting Agile success stories as "proof" that Agile works so they can sell their Agile services, books, and seminars.

          We need more of this, preferably by people who are not in the business themselves, who trained in doing research and who won't charge for reading the final result.

          Agile has at its core a lot of ideas that sound reasonable. But not everything that sounds reasonable is right. And yes, there's a scam-like gold rush around agile that has attracted a huge lot of snake-oil salesmen, preachers and people who may be totally earnest and sincere but really have no clue what they're doing. Still, a great many people throw all skepticism over board and believe whatever they say, never mind conflicts of interest or total lack of data to support their wild claims.

          Back to top
        • Re: Agile is at fault?

          by hans ma,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Companies that do poorly with traditional also to poorly with Agile, but, somehow, this is the fault of Agile. Really?


          I'm not sure that this is claimed in the report. Put another way, it simply confirms that Agile won't fix your organisation or culture.

          However, why can't Agile be at fault for once? So far, the fundamental laws of the Agile (Lean, Extreme, Craftsmanship, whatever) scene have always been:

          • If your traditional (watch for the "waterfall" bogeyman!) project fails, it's because the methodology sucks.

          • If your Agile (Lean, etc.) project fails, it's because you suck.


          The "you suck" comes in different flavours, such as: failing to hire the right developers, failing to adhere to the True Form of Agile, failing to change your organisation to support Agile, failing to adapt the True Form of Agile to your situation, and failing to hire me (the best Agile consultant you'll ever find).

          Back to top
        • Wow... Horrible definition of Agile

          by David Bock,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I think they talked to the wrong people because they had the wrong definition of 'afile'. I hate that term, because it doesn't encompass any one set of ideas and has been polluted with marketing (which, by the way, also happened to CMMI... Just look at the marketing floor at a SEPG conference going back 8+ years).

          A better definition of 'agile' for a survey like this would be a process where the scope of work is maintained in a backlog, further specified shortly before work began, had a constraining function in its well defined processes (eg iterations in scrum, work in progress for Kanban), rapid delivery of features to stakeholders for evaluation, and QA integrated as to not be a separate activity.

          As they defined it, I'm not surprised most teams without QA and 'pushing back on processes' fail. Most software projects DO fail according to the stats, regardless of the methodology.

          Back to top
        • Re: yes, lets have critical look at Agile

          by C Curl,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Simply put Agile is good old 'time and materials' contract.


          Interesting, I've noticed something similar. For a project which is delivered by an outside supplier, this means the customer bears the full risk of the project not being delivered, overrunning or not being delivered right, while the supplier can happily carry on with T&M. Maybe that's why most developers will love it, since they don't take as much risk, while pushing it out to other areas (in particular the product owner).

          I've started to blend in more traditional methods - take time to understand what's asked for, the problem domain, and sketch and evaluate design that aligns with the project vision (just be prepared to throw some away). Present it as a vision, but keep options open and delay commitment. Document it or create something that others may evaluate (if it's big enough - then make sure it's not just the guys which happen to be at the whiteboard today). Having a large team of developers chasing what's top of the priority queue this week, without understanding or having a vision for what the total solution could look like is very expensive if they're off on the wrong track, or suboptimizing to their field of vision. If you're a supplier, it will burn through a huge chunk of cash - which of course is all good if you're delivering on T&M (just not for your customer).

          Experience has taught me to become a methodology atheist - don't buy anyone's hype about any methodology, but listen to their points, balance your views, consider when there's a good fit, experiment, but above all - get the job done.

          Back to top
        • Scapegoating is easy, root cause analysis is hard

          by Dave Nicolette,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Those who go through their careers blaming others for their outcomes - a methodology, a bad manager, bad colleagues, bad customers, consultants, or even just a buzzword - will continue to achieve the same outcomes. Those who are interested in improvement will look beyond the buzzwords. Personally, I'm more interested in the latter.

          What is a survey if not the plural of "anecdote"?

          Back to top
        • No people are at fault

          by Paul Beckford,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          This article and the discussion is a sign that Agile like everything before it is now going through the decline phase of the fad cycle. Take a look at this article on fads:

          hear-see-do.com/AM/projects/hartwick%20miller%2...

          Why? because people (consultants) have over promised and under delivered. I'm an Agile consultant myself and I have been dismayed to see the direction the "Agile Industry" has taken over the last 10 years. It started off as a grass roots movement of practitioners (developers, testers, etc) and has morphed into product branding and snake oil peddling of the variety it was meant to replace.

          There are a lot of great ideas that The Agile movement has brought to the fore, most of which pre-date the Agile moniker, but unfortunately many of these ideas are now tainted by the unscrupulous way they've been sold.

          The old adage still applies: Caveat Emptor!

          Agile at it's core is a set of values and principles manifest in a set of practices. As mentioned previously,, if these values and principles run counter to the culture of your organisation then Agile will fail. Agile is not a silver bullet and its not for everyone.

          Paul. Aka @Fadfree

          Back to top
        • A report on the What, not on the Why, and some myths

          by William Martinez,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          This is a report that is simply exposing that Agile may not be that successful as it is publicized. Now, It just exposes fact, percentages and, at least from the resume I read, it is not going down to analyze why. It does ask for the concept of Agile understood in the sample, and that may give us a clue.

          From what I read, some of the ideas (like getting away from planning and documentation) look very similar to the list of myths I explained in an article a month ago.

          So, instead of concluding Agile is bad, or agile is good if done well, we need to ask for more info. At the end, the methodology in use is not magic and can be improved, and following a methodology is not the same as following the principles, and following the principles is not the same as always selecting the same path, as somethings going up hill is the answer to success.

          Back to top
        • Re: yes, lets have critical look at Agile

          by First name Last name,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Yes, I agree with you. As a consultant, I love agile because it is flexible on timeline. You get paid to make mistake and redo work.

          Back to top
        • It's like saying "democracy doesn't work because people are stupid".

          by Richard Clayton,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          (The subject line) may be true in certain, if not many cases, but like the other commenters mentioned, it's not grounds for halting the movement towards an Agile process. Every process fails if the people using it are not thoroughly indoctrinated into it or committed to following it. Based on many of the findings the survey reported, it's clear that many of the participants were not effectively indoctrinated into or committed to following the process. I bet if the same study tracked 200 projects moving from Agile to Waterfall the same results would be realized.

          Back to top
        • My thoughts

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I have an entire blog devoted to agile dreams versus realities.

          Start here: jordanbortz.wordpress.com/2012/02/19/my-most-re...

          Jordan

          Back to top
        • Agile or Tragile?

          by Shane Hastie,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          The small sample size and what sounds like a very negative biased group (I haven't seen the full report so can't comment in depth about the sample selection) makes me wonder if they have deliberately looked for a controversial point of view with this survey.

          Irrespective of what you call the process used, building good software is hard work and needs a multi-disciplinary team who work together to understand the customers' needs, design, build, test and prove the product. In my experience disciplined agile teams tend to produce products that do in fact work for their customers and deliver value for their organisations.

          The key to building good products is constant customer interaction, disciplined technical practices and team collaboration. To me that is the core of a effective Agile implementation.

          Back to top
        • Questionable Conclusions

          by Graham Perry,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          A couple of points:

          The Survey: How were the participants drawn up? Did they respond to a "Tell us about your good or bad experiences with agile" survey? In which case this would mask out agile teams who deliver all the time without problems.

          2nd point: Yes developers can be lazy but that is not a fault of the agile methodology but with team management, structure and culture.

          For agile to work you have to believe in agile. Agile may be a problem for some people because it threatens their view of how projects should be delivered. There are too many successful agile projects for the methodology to be written off as a 'scam'

          Graham Perry
          Altica

          Back to top
        • Agile sells services

          by Dan Mezick,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          There is little doubt that some 'agile enablement' firms are using Agile to sell high-margin services in volume, always valuing [endless service billing] over [client learning]. The Voke organization may be in fact actively seeking stories like this; the point is that they can find them so easily! At issue is whether we as a community are alarmed, and ready to pay attention....or willing to simply look the other way.

          The Agile community does not self-police its ranks and any Voke-type analysis firm can find numerous examples of problems in the Agile coaching/services/consulting market. Problem #1: service firms gaming the client engagement to maximize revenue flows, essentially setting up an 'extended stay' program for themselves. This is suboptimal: Reliance on a coach simply swaps one kind of organizational dysfunction for another, at a high bill rate.

          This problem (service firms creating dependency in vulnerable clients) is especially painful to observe in the Agile market, since Agile ideas are clearly about people, while optimizing on the selling services (often at the expense of client learning) is all about money. I for one am glad Voke is calling this out, since the Agile community seems unwilling or unable to muster the backbone necessary to call out obvious patterns of borderline conduct in the Agile coaching marketplace.

          Good for Voke, to state the obvious about what is going on-- and about time. Let them sell some reports, and get the word out!

          Question: when is your Agile coach leaving?

          I'm sure many readers here can reiterate stories of coaches from 'agile enablement' firms who end up staying in an account for 8 months, 12 months...even 1,2 years or more. Often occupying the Scrum Master and even PO roles for a LONG TIME. What gives here? Clients are maneuvered into ongoing dependencies that are NOT healthy. The "change" manifested is a series of transactions at high bills rates...loads of money changes hands, no org-learning is takes place. Is that OK with you? Service firms operating this way in the Agile space are giving Agile a very bad name. Look no further than the this report.

          Back to top
        • Pot meet kettle

          by Marc Stock,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I call Volke's report a scam to make money selling reports. The fact that I need a subscription just to view a report of survey results from companies who are probably not really agile at all proves my point.

          I'm no agile fanboy but really? Agile allows for the exclusion of QA? Just because a company says they are "doing Agile" doesn't mean anything. Tons of companies say they are doing Agile these days but in my experience as a contractor I've found that to be patently false. They cherry pick a few things from agile so that they can say they are following the latest development trends but that's it. Find me stats from companies doing real Agile projects and then we can talk, until then you're just trying to generate traffic for your overpriced reports.

          Back to top
        • ' transition to Agile “confusing, hard or slow”'

          by Michał Żelechowski,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I am not pro or against Agile, I think every methodology in use works better in some cases and worse in the other. But honestly - has anyone of you seen smooth transition from some state to the other in big or old-stiff company? Or have you ever seen smooth transition from Agile to classic?

          Back to top
        • Re: Questionable Conclusions

          by Cameron Purdy,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Graham -

          For agile to work you have to believe in agile.


          Speaking of belief, Agile often takes on the attributes of a cult -- particularly when anyone decides to point out failures or problems related to "Agile".

          There are too many successful agile projects for the methodology to be written off as a 'scam'


          Interestingly, the same could be said for Waterfall -- or any other methodology.

          The real-world problems that I've witnessed with Agile are primarily that Agile doesn't have strong in-built safeguards for when the team is not strong enough (or well enough managed) to deliver. I've seen this destroy entire software companies here in the Boston area, and the one thing that never seems to get tarnished by these amazing failures is the "Agile methodology" itself that created the environment in which the destruction could so readily occur.

          My own conclusion is that Agile methodologies can work very well in a team of strong players that also has strong leadership and team cohesion. Outside of that type of environment, the risks quickly outweigh the benefits.

          Peace,

          Cameron Purdy
          (Working for Oracle but expressing my own opinions.)

          Back to top
        • Evidence of Agile Success

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Where are these "way too many" successful agile projects?

          I am not aware of a large number of successful agile projects. Can you enumerate them please?

          I am aware that after Yahoo adopted Scrum in 2007, that their user base and stock price have fallen considerably. Their stock is off 60% from 2006 prices.

          MySpace adopted Scrum and then collapsed.....with a 90% loss in market value and most of their user base.

          Reports from a blogger at Nokia, creator of the "Nokia Test" for Scrum Teams, are that the Scrum boards are coming down and they are giving up on Scrum.

          Jordan

          Back to top
        • Re: Questionable Conclusions

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Also which software companies were destroyed (how) by Agile? I tend to believe this more but still would like details...

          Jordan

          Back to top
        • Re: Agile is at fault?

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          +1

          Back to top
        • Re: Agile is at fault?

          by First name Last name,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          You suck argument can be applied for waterfall methodology as well. You need to good project leader and lead developer to guide the project.

          Back to top
        • Re: Evidence of Agile Success

          by Thomas Wilczak,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Giving up on Scrum doesn't necessarily mean giving up on agile.

          Also, a link to said blog post would be helpful in forming an argument.

          Back to top
        • Re: Evidence of Agile Success

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Certainly: www.jillesvangurp.com/2011/12/03/scrum-agile-ma...

          Is the link where Nokia tears down the Scrum boards.

          I did ask him what they went to after that, but he hasn't yet responded to it.

          Please feel free to ask him yourself it is an interesting question. www.jillesvangurp.com/2011/12/03/scrum-agile-ma...

          The relevant quote: "I would say by this point, scrum is definitely on the way out. We still have floors where the walls are still plastered in post its. But we also have other floors where the walls are now empty but are still bearing the traces of what used to be scrum boards and where engineers work on delivering great software without too much interference from random management...

          ...The story of Nokia (where I work), which is often cited as an early adopter of scrum, has been well publicized and clearly, we’ve had a huge software problem over the past years. After a few bad years, Nokia is now delivering good, solid products again."



          Jordan

          Back to top
        • Re: Evidence of Agile Success

          by Dave Nicolette,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I read Jilles' blog post about Scrum at Nokia and found it to be very well thought-out and balanced. One line in the post stands out for me: "You can't substitute experience with process."

          Back to top
        • Re: Questionable Conclusions

          by Mark N,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I have to agree with Cameron. Although I don't have that much experience with Agile, I have plenty of experience with people and technology (software, hardware, etc). I worked in a self-directed team in the mid 90s. We where the only team in the company like that that i knew of. But we meet Cameron's "requirement" (strong enough and well managed). We delivered a good/timely product. I don't think there was another team who did - at least not was well as ours. And based on my experience, if they were self directed too, they would not have been successful. I am sure by cherry picking the other teams, one or more self-directed (aka agile) teams could have been created.

          So is waterfall better? No. But policies, procedures, "gates", BUFD and etc are the norm because "high quality" and mutli-skilled people are NOT the norm (They might think they are :) ). Can you succeed with Waterfall? Well, the old "monkeys and typewriter" adage applies as does sheer determination. You might get lucky but you more than likely will "get what you pay for".

          I think the "correct" way is defined in the link Jordan provides below:
          "A good software organization will have key people that keep things together technically and organizationally and a larger group of people with various skills and qualities that do stuff that they’ve been told to do but are not necessarily capable of doing this unsupervised. With a good mix of those people working together, you can achieve great things fast. "
          The keys are "a good mix", which is tough to define, and "key people that keep things together technically and organizationally ", which is not the typical Project Manager, Manager, BA people running the show.

          Back to top
        • Re: Scapegoating is easy, root cause analysis is hard

          by Luis Espinal,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Those who go through their careers blaming others for their outcomes - a methodology, a bad manager, bad colleagues, bad customers, consultants, or even just a buzzword - will continue to achieve the same outcomes. Those who are interested in improvement will look beyond the buzzwords. Personally, I'm more interested in the latter.

          What is a survey if not the plural of "anecdote"?


          Not all anecdotes are created equal. Like opinions, anecdotes can be object or subjective, sources of valuable information or FUD. That nature is transitive to the surveys that collect them (and the methodologies with which the surveys are conducted.)

          Back to top
        • Orgs need to deal with stupid people (or rather lazy/incompetent ones.)

          by Luis Espinal,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          (The subject line) may be true in certain, if not many cases, but like the other commenters mentioned, it's not grounds for halting the movement towards an Agile process. Every process fails if the people using it are not thoroughly indoctrinated into it or committed to following it. Based on many of the findings the survey reported, it's clear that many of the participants were not effectively indoctrinated into or committed to following the process. I bet if the same study tracked 200 projects moving from Agile to Waterfall the same results would be realized.


          I don't think the survey's goal is to halt the adoption of agile, but to state a clear 'caveat emptor' that is badly needed in the industry. I do believe in agile principles myself, but I've seen my fair share of snake-oil salesmen and lazy programmers who use the term agile to shove the risk to other areas and to rid of supposedly-unnecessary processes.

          Not everyone who claims to be an agilista knows what he/she's talking about (or worse, they are purposely selling a lie to bill/milk customers while delivering delayed, over-scheduled crap to them.) What is worse is that many in the agilista hive-mind (not the actual practitioners mind you) who when confronted with these issues simply defaul to "you suck at agile" strawman.

          Surveys like these are important. This is software engineering (no craftmanship, but engineering), and as such, it needs to rigorously check and double check its practices and practitioners. We have too many freeloaders who can't code themselves out of a wet paper back hiding behind "you-suck-at-X" (where X is any methodology or practice.)

          Back to top
        • Re: Agile or Tragile?

          by Luis Espinal,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          The small sample size and what sounds like a very negative biased group (I haven't seen the full report so can't comment in depth about the sample selection) makes me wonder if they have deliberately looked for a controversial point of view with this survey.


          That could be resolved by looking at the full report, couldn't? ;)


          It is all within the realm of possibilities that the authors of this report decided on a controversial point a priori and looked for a negative biased group. But, let's think about it for a second:

          How many of us in the software industry have not seen the X-methodology snake-oil salesman or incompetent practitioner who uses a distorted version of X-methodology to milk customers to death while being incompetent? By "X-methodology" we can replace it with anything that when applied correctly and under the right conditions, it can deliver: XP, Agile, RUP, even Waterfall.

          Even if the survey authors are biased and with premedidation created a FUD-like report (something that needs to be demonstrated mind you), reports like these should be embraced. Embraced as in "analyze with skepticism, extract lessons learned, and let the chips fall where they may."

          In software, we need to do this more often, a lot more than what is currently being done. There are significant flaws in how software is being build, and how metodologies (or their names) get used (or misused), be it by ignorance or unscrupulous, unethical malice.

          Irrespective of what you call the process used, building good software is hard work and needs a multi-disciplinary team who work together to understand the customers' needs, design, build, test and prove the product. In my experience disciplined agile teams tend to produce products that do in fact work for their customers and deliver value for their organisations.

          The key to building good products is constant customer interaction, disciplined technical practices and team collaboration. To me that is the core of a effective Agile implementation.


          ^^^^ I agree absolutely with this.

          Back to top
        • Re: Evidence of Agile Success

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Indeed. I think the two most factors are judgement and experience, something I've been wanting to blog about, and something rarely mentioned as crucial to "success".

          Sure Agile pays lip service to "people over process" but rarely do they look for superstars; they tend to try to polish average people

          Jordan

          Back to top
        • Agile - a methodology weighed above its real mass

          by amila navarathna,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Writing software isn't easy. Its inevitable that some software projects fail. And when things go wrong, it's obvious to look around for some help, and "agile" was sold by many as the survivor of the day, but is it?

          With bunch of smart, hard thinking (they leave office by 5pm) team members (not only developers), who have worked in the same organization for some time, who understand the domain in to some extent, and who understand the organizational politics in to greater extent, can be successful with Agile methodology. But quite interestingly, agile methodologies are used in completely opposite organizational contexts. Why?

          Why projects get failed, again and again? No clear requirements, implied requirements, wrong prioritization, misunderstanding (or not knowing) technology capabilities, and so on. Are those the root causes? No. The real root cause is that someone does not want to think hard upfront (doesn't matter one or two out of dozen think hard, its a team effort). Many believe work hard against think hard. So writing, re-writing and re-writing code again and again is valued more than thinking for few hours / days. Also writing 10 classes, and re-writing them few times is an easy winner compared to writing one class, thinking about what to write half day, when it comes to "hard working developers".

          Blame game is another booster for Agile processes, when things go wrong (yes, things will go wrong regardless), its easier to keep the things open-ended, so that everyone can save their back. Sometimes its funny to see the full functional agile teams without a business owner (that is a role, not a designation).

          Agile is a good methodology, but not a silver bullet. I have seen many success stories, following proper agile methodologies. But more and more it is dragged in to the wrong side, now many refer they are agile when there is no process at all, or to cover individuals mistakes. More and more incapable people push for agile, because they think it is the trend (and it's a fashion to talk about agile these days).
          Please use agile properly, or don't call it agile.

          Back to top
        • Re: Scapegoating is easy, root cause analysis is hard

          by Dave Nicolette,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I have to wonder about the idea of an objective opinion. ;-)

          Back to top
        • Possibly missing the point

          by Dave Nicolette,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          There are some thoughtful comments here, as well as some in which people try hard to sound objective while seeming to grind their teeth to avoid sounding either pro- or anti-"agile".

          What's absent from the discussion is any recognition of systems thinking. Poor outcomes are due to (a) lazy, stupid, incompetent people, or (b) a process or methodology or buzzword. Really? Is the world that simple?

          IME there's no binary "success" or "failure." All outcomes are mixed. The same outcome might have a positive effect on one stakeholder and a negative effect on another. The same initiative might appear positive when viewed through one lens and negative when viewed through another. Binary thinking, combined with a tendency to look for someone or something to blame, won't lead to any useful conclusions, IMO.

          I haven't met anyone in the IT field who wants to do bad work. OTOH, every individual is constrained in the choices/actions he/she can take by the system in which he/she operates. To understand how/why an outcome did not meet expectations, we have to take a holistic look at the environment and not be satisfied with finding a "lazy" person or a "failed" methodology to blame.

          Back to top
        • Re: Possibly missing the point

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          By that measure, "ad hoc" code 'n' fix as a methodology could never be blamed for being the shoddy methodology that it is.

          When cornered, agilists will always attempt to make crtitique of agile offlimits.

          I think blaming "lazy" developers is stupid; but blaming untalented developers makes sense.

          Blaming a half baked methodology makes sense as well.
          Jordan

          Back to top
        • Re: Possibly missing the point

          by Dave Nicolette,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Who is selling "ad hoc code 'n' fix" as a "methodology?"

          Back to top
        • Re: Possibly missing the point

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Why ask such a question? My point is clear.

          Jordan

          Back to top
        • Re: Possibly missing the point

          by Dave Nicolette,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          It is clear, but not a point. No one promotes 'ad hoc' as a 'methodology'. The comparison is a non sequitur.

          You are only validating my observation that many people are fixated on the buzzwords or are more interested in finding a scapegoat for real or perceived problems than they are in understanding each situation on the merits.

          Back to top
        • Re: ' transition to Agile “confusing, hard or slow”'

          by Dave Nicolette,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Your observation reminds me of the Satir change model. Any change will be disruptive and the disruption will cause poorer performance in the short term before any potential improvements are realized.

          I suspect some organizations implement a change with the expectation that improvement will happen immediately, as if they had replaced an old, slow machine with a new, fast one. All they have to do is flip the switch to "on" and they should see improvement. Doesn't work that way.

          Back to top
        • Re: ' transition to Agile “confusing, hard or slow”'

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          You seem to be intentionally obfuscating what is a clear point of mine.

          My point is, certainly, it is possible to create a "harmful" methodology, and then, even in that case people such as yourself will blame the people implementing the process and not the process itself.

          I'm sorry -- apologism only goes so far.

          In this case you are even indicating that it's never possible to indict any methodology ever as harmful.

          Papering over failed methodologies as merely "disruptive" is nonsense.

          I'm sure hand grenades are disruptive; I'm not sure they would work well in meetings and I don't think that failed outcomes could be blamed on the users of said "grenade" methodology.

          Better luck next time,
          Jordan

          Back to top
        • Re: ' transition to Agile “confusing, hard or slow”'

          by Dave Nicolette,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I don't see what that comment has to do with the difficulty of transitions or the Satir change model.

          Back to top
        • Re: ' transition to Agile “confusing, hard or slow”'

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Just because something is difficult doesn't mean that it is effective or worthwhile.

          Jordan

          Back to top
        • This is a great debate :-)

          by Ethar Alali,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Well done guys, I like this discussion.

          1) Leanness/Agility in itself removes processes which are redundant in other methods. The use of a spec in, say, waterfall or RUP and having tests to validate the code is a useful redundancy 'safety net' that can save them. Using Agile methods requires MORE discipline from developers rather than less. However, because teams jump in to little or no redundancy, too quickly, and often don't work the practises, they find themselves in trouble. As has been quoted already from Booch, "A fool with a tool is still a fool". It takes time to remove that safety, in all aspects (see Kanban equations for more info on what safety actually means and then think about how lean processes can then work in software).

          Note, the vast majority of dev teams I have come across don't measure anything, making it impossible to truly improve (indeed, sometimes they lose things they're good at in the process), implement agile practises and they share agile values half-heartedly. They much prefer to concentrate on the programming as the fun activity (I agree with the comment that a lot of devs use agile as a backlash against tasks they find boring or don't want to do).

          2) Laziness isn't necessarily a bad thing. I am incredibly lazy. If I think for an hour (which uses very few calories. Make of that what you will :), then code for an hour, instead of code for an hour and refactor for two, I save energy. Being lazy can be a driver to working smarter, not harder.

          3) Agile practitioners often can't back up their claims with metrics. It is considered a YAGNI process, even though they will have retros to 'continuously improve' based on no information whatsoever. Also, no team I have been involved in understands why true Kanban works and where the 'sweet spot' is in terms of columns. Unfortunately, the people who understand that best are those who have an understanding of JIT manufacturing and believe me, most developers don't in the slightest. If I reiterate that JIT manufacturing and Kanban are management concepts, what would agilist say?

          4) Companies won't A/B test agile practises to see which worked best for comparatively similarly capable teams. Changing the variables of the teams can be analysed to some degree with Taguchi matrices (experimental design) and the best ways of working for that type of can be ascertained from that.

          5) Agile methods and the manifesto came along at the right time for developers to appeal to developers and it spread virally as a result. The first edition of XP explained was a joke of a book IMHO, as it didn't look at development as a professional vocation. The second edition, written some 5 years later, is a much better book from the perspective of professional development. Beck obviously grew up in that time, as he became a consultant and less of a software developer (see his closing statements in the second edition). OK, so XP took the feedback of his experiences and applied it to XP itself and improved itself. But as he says in the book, there is no excuse if you should know better. As has been said already, an admitted in XP explained, they aim to work with developers of "...ordinary talent" which unfortunately IME, correlates heavily with 'developers who don't work processes'.

          I won't be reading the report. I have both agile and non-agile practises in my toolkit and work to find the best model for an organisation before I start. Even papers on the agile alliance site note there are many situations where agile methods won't work (and vice versa for more heavyweight methods). So it is useful to me to work in both spaces.

          Back to top
        • Re: Possibly missing the point

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          You are projecting.
          Jordan

          Back to top
        • Re: ' transition to Agile “confusing, hard or slow”'

          by Mark N,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Just because something is difficult doesn't mean that it is effective or worthwhile.

          Jordan


          Did this discussion topic switch to Scala? ;)

          Back to top
        • Voke report: Agile delivers higher customer satisfaction and quality

          by Jez Humble,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I actually got to read the whole report in order to provide comment for an SD Times article.

          I think it's fair to say the numbers in the report don't support the conclusion they draw, and that in fact they've simply done a hatchet job - I've written up more detail here: continuousdelivery.com/2012/07/voke-report-agil...

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Your response on SD Time looks like a hatchet job...

          You interviewed Toughtworks to refute this? Oh my.... foxes guarding the chickens... an agile consultancy shop wants to disagree with it.

          Thoughtworks presentation of "facts" -- such as that Agile invented TDD, refactoring, etc, is nonsense.

          All it means isthe report is accurate and the agile consultancies are getting whaambulance out.

          Jordan

          Back to top
        • Re: ' transition to Agile “confusing, hard or slow”'

          by Michał Żelechowski,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I haven't heard about Satir model before, however I find it intuitive to understand and I think it matches the case here. My point was also, that there's no straight connection from the fact that slopy organizations have problem with changing their environment to the statement that Agile didn't work for them. It could be equally probable, that transition to anything else could cause the problem. Therefore, the report could be biased, because it does not take into account, if companies in question are capable of making changes of any kind (even such cases such as improving parking space).

          Back to top
        • Re: ' transition to Agile “confusing, hard or slow”'

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I don't think Voke was necessarily making a value judgement there.

          They just said they found x% found it hard, confusing or slow.

          The same could be said about buying a house, finding an apartment, whatever.

          They are just setting the expectation in this area -- don't expect it to be a milk run.

          In terms of can people, orgs, change, it's a valid question, but once again, the conclusions are valid.

          There could be some great diet X, and if people are unable to switch to or maintain it, it doesn't matter how good it is, if 99.99% of the population can't or won't do it.

          So what voke is talking about is real world scenarios (in vivo) not idealistic test tube environments (in vitro).

          Just because some drug works in vitro doesn't mean it works in vivo.

          That is why medical test results and the resulting licensing for application thereof are done in vivo.

          That is what Voke has done here.

          Guess what, the in vivo results are not on par with the in vitro ones.

          Blame the patient, not the "medicine" that doesn't work on real live patients :)
          Jordan

          Back to top
        • Re: ' transition to Agile “confusing, hard or slow”'

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I guess I'd like to add the obvious corollary, that even if the patient did change, possibly the diet itself is ineffective.

          What voke has going is a system test meaning:

          Coeff of How Well the Methodology works * Coeff of How Well they adapt to change in general * Coeff of How easy the methodology is to adapt in general * Coeff of How Good the Team Members are


          Of course in an ideal world, it would be great to test all those out individually as well as in concert.

          However, in the real world, one can assume, that, at least two of the variables are essentially random (skillset and how well they adapt to change in general) and should be non zero.

          Thus, if the methodology was easy to adapt to, and or produced excellent results, then the non zero portion of the other two coeffs should lead to something a lot better than that only 2% can describe tangible success.

          Thus, the conclusions that voke draws seem reasonable to me

          Jordan

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jez Humble,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Actually I said "agile practitioners ... pioneered engineering practices such as test-driven development, continuous integration and refactoring."

          The point I make is that if you actually read the report the data they present doesn't support their conclusions.

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          So what's your support for your statement that "agile practioners ... pioneered engineering practices such as tdd, CI, and refactoring"?

          You don't think those existed prior to 2001? Please elucidate us all on which "agile practioner(s)" pioneered exactly what and when.

          I was certainly doing Unit Testing, CI, refactoring, long before 2001 (in 1992 in fact and even earlier) and I would never deign to deem myself the "pioneer" of said mechanisms...nor would I call myself an "agile practitioner".

          So, kindly support your assertions in that area.

          Jordan

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I think the crux of our disagreement, is that you the word "pioneered" when "monetized" would probably be the more accurate word choice.

          Jordan

          Back to top
        • Some Humor to Lighten up the Discussion

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Something I think everyone will enjoy reading and pondering regardless of the side of the fence they are on:
          jordanbortz.wordpress.com/2011/11/30/howto-crea...

          Jordan

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jez Humble,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Do you think agile didn't exist before 2001 either?

          Perhaps "popularized" would be a better word. If you've ever written a book, you would know that "monetized" is definitely not appropriate.

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jez Humble,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          You can find a nice guide to the origins of these practices on the Agile Alliance website, here: guide.agilealliance.org/ While in some cases a proto-version of these practices preceded their adoption by agile practitioners, I think it's fair to say that it was people within what became the agile community who are responsible for bringing them into their modern form and popularizing them.

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Actually, yes, I think "agile" didn't exist before the agile manifesto.

          The practices did, or practices that were appropriated by agile did, but the movement did not.

          Are you going to say everyone who used a post it in 1985 was actually doing agile?

          I think Monetized is an appropriate word, that is the point voke is bringing up.

          Perhaps "commercialized" is a better word than either monetized or popularized here.

          Certainly the Agile movement commercialized and amalgamated a few practices that were commmonly done prior to the "agile movement".

          Jordan

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          If you look at the evolution of the practices, including myself, you would find that the origin of many or most of them is within the SMALLTALK community.

          It was smalltalkers who had the first fully OO RAD environment, who were pioneering many of these issues.

          Beck, Cunningham, Sutherland, Jeffries, Schwaber, at a minimum were all part of the Smalltalk community.

          And just like the smalltalk and OO community had a lot of divisive, almost zealot type boosters, who were on a "mission" to transform everyone who didn't use smalltalk, the agilists took this same fervor to agile.

          By 2001, Smalltalk was totally dead, but the fervor that led to it's demise and the rise of other languages like Java and C#, the reinvented themselves as Agilists and took the fervor to the agile/management space.

          In other words, the flock just changed feathers and direction a little bit, and boom the agile movement was born.
          .
          I would know, having been part of the smalltalk community since 1987.

          Jordan

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jez Humble,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          Of course the movement existed before the manifesto, in the form of Scrum, XP, DSDM and the rest of the lightweight methodologies. As you clearly know.

          Semantics aside, just because there are zealots in the agile movement and it sometimes doesn't live up to the ideals it sets out doesn't mean the whole thing is just a big marketing exercise - although clearly Scrum in particular has strayed over that line on occasion.

          If you actually read the report, Voke's data shows that projects that use agile methodologies show improved quality and customer satisfaction. Of course they are careful to cover this up so that if you didn't read that table tucked away towards the end of the report you'd never know. And that's what I find objectionable - the fact that their conclusion clearly precedes the data.

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          No, I don't know that "the movement" existed before the manifesto.

          Practices existed before the manifesto.

          From what I can tell, some book authors and consultants decided they wanted to create a movement -- starting with a manifesto -- to cash in on these "truths" that they had either discovered or appropriated.

          If you read the Voke report, you would find, that the teams that did the best with "Agile" were the teams who were doing the best "without Agile".

          Therefore, one could reasonably conclude, that it's the people -- not the process that mattered.

          There is no evidence, still, that Scrum, XP, or anything else, is more effective than placebo, but there is plenty of Evidence, that these have been marketed far more than any evidence of their effectiveness would warrant.

          Therefore the Voke report is saying hey, there is a lot of hype here but is there any substance? And they didn't find much substance.

          Sorry -- bubble has been burst -- move on.

          Clearly if Agile was a resounding success, it would be reflected not only in reports but also in the marketplace. Since neither has happened more than placebo would suggest, it's really, really time to move on here.

          Jordan

          Back to top
        • Re: Voke report: Agile delivers higher customer satisfaction and quality

          by Jordan Bortz,

          Your message is awaiting moderation. Thank you for participating in the discussion.

          I just wanted to add and concur that originally these were called "lightweight" methodologies and I think the term is accurate -- whether they are for lightweight projects or lightweight developers.

          Maybe some fraction of SW development does indeed fall into these categories -- or yet another "startup/Minimalism" category.

          One of the major points to happen from the "Snowbird" conference was the jettisoning of the term lightweight for "agile".

          It was thought that "lighweight" would indicate non serious or disposable. So -- after much discussion "agile" was settled on, as a more marketable glittering generality.

          However, if said methodologies, had been indeed marketed, under the more realistic and accurate name of "lightweight" we wouldn't be seeing the problem we see today.

          The fact that there was a deliberate effort to make this a universal solution, driven, possibly, and only possibly, of course, by the notion of a future profit potential, have we seen this phenomenon.

          Let's call a spade for what it is -- if this is a lightweight methodology for lightweight programmers or lightweight product owners or lightweight projects in general, fine call it that.

          I can certainly see if someone has a $15k budget for a project, and "BUFD" would cost $10k, sure, jettison that, let's code 'n' fix til we TDD towards a solution.

          But that is what it is...a solution for some small projects or some serious unknowns...not a universal panacea.


          Jordan

          Back to top

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT