Slashdot Mirror

← Back to Stories (view on slashdot.org)

Should Developers Abandon Agile? (ronjeffries.com)

Posted by EditorDavid on from the manifesto-destiny dept.

An anonymous reader quotes InfoQ: Ron Jeffries, author, speaker, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto back in 2001, shared a post on his blog in which he advocates that developers should abandon "Agile". The post further elaborated that developers should stay away from the "Faux Agile" or "Dark Agile" forms, and instead get closer to the values and principles of the Manifesto. The terms "Faux Agile" and "Dark Agile" are used by the author to give emphasis to the variety of the so-called "Agile" approaches that have contributed, according to him, to make the life of the developers worse rather than better, which is the antithesis of one of the initial ideas of the Agile Manifesto...
Jeffries writes that "When 'Agile' ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to 'go faster'. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile'...

"it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work..." He argues developers should instead just focus on Agile's good general software development practices -- like regularly producing fully-tested software and consciously avoiding "crufty" complex designs.

But what do Slashdot's readers think? Should developers abandon Agile?

15 of 445 comments (clear)

  1. One problem: no normative definition of "Agile" by david.emery · · Score: 4, Insightful

    This makes it really difficult for an organization to determine if they're truly doing "Agile" or some bastard form. It also calls into question methods and even formal standards built on 'Agile'.

    But when I've pressed Agile Evangelists on this, usually when we've had problems and I've asked, "So are we doing Agile", all I've gotten in return is, "If it's not working, you're not doing it right."

    1. Re:One problem: no normative definition of "Agile" by Hognoxious · · Score: 4, Insightful

      I initially read that as "If it's working, you're not doing it right."

      I'm on the fence as to which is more accurate.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    2. Re:One problem: no normative definition of "Agile" by 93+Escort+Wagon · · Score: 5, Insightful

      Problem is -“agile” is often used as a management code word for “understaffed, overworked, and unsupported”.

      --
      #DeleteChrome
    3. Re:One problem: no normative definition of "Agile" by arth1 · · Score: 5, Insightful

      The "No True Scotsman" fallacy is one of the most annoying things about Agile. "You're not doing it right" has become a mantra for explaining away any shortcomings, of which there are more than a few.

    4. Re:One problem: no normative definition of "Agile" by Anonymous Coward · · Score: 5, Insightful

      If you are implementing features incrementally, showing the customer on regular intervals and then allowing the users to provide feedback and then re-prioritize stories during the project, you are pretty much following the "spirit" of Agile. I see the most important part of Agile as delivering the most valuable features to customers in an iterative fashion so you can constantly make sure you are on the right track. The problem with the old, pure-waterfall approach was the fact teams would take a huge amount of time up-front to come up with requirements (which are often poorly captured and change over time) and then go on to design and build a system for many months/years before actually showing the customer. This results in building something that really doesn't meet the users' needs due to the fact the customer may not have articulated the requirements properly, their actual needs changed over time, and your analysts may not have captured the requirements properly.

    5. Re:One problem: no normative definition of "Agile" by Cytotoxic · · Score: 4, Insightful

      This is the nut of the problem. It always comes down to people, and the most productive teams are going to rub some people the wrong way because often times the most productive way of getting something done is to say "no".

      I've worked with the "just give them what they ask for" crowd. It is just awful.

      It works for a while. They are sooooo happy! You gave them that stupid thing that will never work in a million years! Then after a while, things are a mess and they still blame the dev team.

      The only way that I've found to work with them is to have the backing of their superiors when you look them in the eye and tell them no. Anything less than the full backing from the top levels ends in disaster - methodology be damned.

      This is why outsourcing can be so bad. You need the institutional knowledge that a good group of developers will have. And you need an executive team that has confidence in their developers so that when they push back against some dumb initiative they will have their backs.

      I can't tell you how many times I've had near mutiny when I explained why something was stupid and had the CEO tell me to do it anyway, just to keep someone happy. No competent developer wants to waste his time building something he knows isn't going to work. But at least I was able to tell them that their concerns were heard and why they were dismissed. (and at least they knew I wasn't crazy, and their CEO wasn't crazy... or stupid)

      Absent that connection, I don't know how things can work, long term. With good managers and executives, you could make outsourcing work. But eventually that guy who just doesn't get it is going to come along and insist on his vanity project. And the guys from India are just going to say "Ok, here's the bill". Maybe they fire the local PM when the whole things goes to crap. Or change development companies. But will they even be able to see that the problem was the idea behind the vanity project wasn't any good from the start? Often it is the dev team that is uniquiely positioned to know this, because they've had years of experience with all of the company's business rules and past mistakes.

      So if there is no mechanism for continuity of business knowledge and no respect for that knowledge at the top.... well, I don't see how it could possibly succeed, long term.

  2. Re:Agile is bullshit by fluffernutter · · Score: 4, Insightful

    I disagree. I think it has a lot of good theory behind it. The problem is, the 'do more by doing less' concept *really* has to be embraced by the entire organization; especially those at the top. Too often it isn't. If you work in a place like this, removing Agile probably won't help much.

    --
    Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
  3. Maybe? by apoc.famine · · Score: 5, Insightful

    I've worked in both a small shop (under 20 developers) and a decently large organization (more than 400 employees) although outside the dev shop. I had positive agile experiences in both places.

    What I've found is that agile works given a few conditions:

    1) The organization actually adopts agile, and embraces it.
    2) The owners of the development both understand agile and have the political power to enforce it.
    3) The devs understand agile and can thrive within it.

    When all that happens, and I know that's not often, Agile can shine. I've seen it, and I've really appreciated it. I get how it can go terribly wrong, but it can and does work, if the environment allows it.

    --
    Velociraptor = Distiraptor / Timeraptor
  4. Two cases by sjames · · Score: 5, Insightful

    Part of the problem is the idea that with sufficiently detailed procedures, the village idiot can do theoretical physics as well as Einstein. In fact, no amount of procedure will make that happen. Quite the contrary, all that procedure means that if you ever do hire Einstein, his output will closely resemble that of the village idiot.

    Consider one of the popular union tactics, the "rulebook strike". That's where they destroy productivity and punish the employer by having their members actually follow all the workplace rules and procedures rather than doing the right thing (TM,. pat. pend.). It works.

    1. Re: Two cases by denis.goddard · · Score: 4, Insightful

      Amen. Iâ(TM)ve been managing software development teams for nearly three decades, and IMO the single most important job of software management is to leave developers alone. Shield them from the Drama/Hot Feature/Management question of the Day. Keep their time in meetings to the barest minimum. Make sure their support responsibilities can be planned for, so they are not jumping into one emergency after another. Make sure customers arenâ(TM)t wasting their time with emails and chats. Absolutely resist the âoejust spend an extra few minutes documenting what you did the last 4 hoursâ/clicking pointless checkboxes/justifying every 30-minute interval of their day. Software requires THINKING. Concentration, in long uninterrupted blocks. Thatâ(TM)s the secret to making the secret sauce: let them think and program.

  5. Absolutely! by chromaexcursion · · Score: 4, Insightful

    Because most don't actually do agile.

  6. Supposedly been doing agile for years... by srichard25 · · Score: 4, Insightful

    I've supposedly been doing agile for years, but I've never once worked on a self-organizing team who could build software without working with several external groups. And all of those external groups are set up to work waterfall. You've got the UI designer who wants to design the whole experience up front. You've got the data modeler and DBA who both want to know exactly what data you will be using up front. You've got the architect who wants the full design documented so they can spend 10 minutes looking at it and give you an approval. You've got the project manager who wants to know exactly how long all the development is going to take. So you end up having to do big-design-up-front in order to work with all these external groups.

    A lot of companies say they want developers to do agile, but they need to realize that agile requires changes throughout the organization. It's not something that developers can just do by themselves.

  7. Re:I have a great deal of experience with Agile by Anonymous Coward · · Score: 4, Insightful

    Agile undermines ownership of the project. When, in the process of building a product, a programmer is expected to do their work in 2 week chunks exactly as (usually someone else) has decided with very little room for deviation (gotta maintain that velocity!), it's hard to feel invested in what he or she is building. It's hard to feel like your human judgement means anything at all. You feel like an underappreciated cog (and at many companies, you are!). You certainly don't care if the project succeeds or fails. You just want to get your sprint finished as quickly and easily as possible so you can go home. And, agile in practice reinforces that, because that is how management sees it. It should come as no surprise that taking your expensive developers and turning them into what feels like an H1-B code mill will reduce quality and long-term efficiency. Programmers often do the job of a programmer despite being able to do the job of the manager who cannot do their job because they love building shit. If you take that passion out from under them, you will drastically reduce their output in the long term if you ask me. It might look like great velocity, but that's just a comforting lie management tells themselves (because I've never worked for a manager who had any experience programming... which is sad in and of itself).

  8. Re: Betteridge's law by MadKeithV · · Score: 5, Insightful

    The parent post is a great example of the "You're Not Doing It Right" fallback of Agilists. Agile is something that works in teams that would have succeeded just as well with any other methodology that isn't downright insane, and something that is pretty damn difficult to actually get to work in most real-world situations. There's always a litany of excuses of how you're not doing it right, but no Agile proponent can ever quite exactly say how to make sure you *do* get it right either.

  9. Re:Agile is bullshit by arth1 · · Score: 4, Insightful

    "True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time.

    A problem is that some work is monolithic in nature and cannot be partially released. This is particularly true the closer you get to the hardware side of things.
    Agile fails when it tries to jump a chasm in three small steps.

    Attempting to divide it into even smaller pieces isn't going to solve the inherent denial that some things cannot be split.

    Nor that when something can be split, it doesn't mean it should, even under pressure.
    Getting certifications for N components one at a time, for example, takes longer, costs more, and at the end, should you reach it, you need to get a certification for the whole anyhow.
    Or you should not split security into a separate task that risks not getting done until there's been a release without security. That's bad. And I've seen it happen more than once.