Stories
Slash Boxes
Comments

SoylentNews is people

posted by CoolHand on Friday May 08 2015, @11:26PM   Printer-friendly
from the coding-for-dollars dept.

Andy Hunt - one of the originators of the Agile Manifesto, and NOT your humble submitter - has concluded that Agile has lost its way:

in the 14 years since then, we‘ve lost our way. The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large swaths of people doing “flacid agile,” a half-hearted attempt at following a few select software development practices, poorly. We have scads of vocal agile zealots—as per the definition that a zealot is one who redoubles their effort after they've forgotten their aim.

And worst of all, agile methods themselves have not been agile. Now there‘s an irony for you.

How did we get into this mess?

The basis of an agile approach is to embrace change; to be aware of changes to the product under development, the needs and wishes of the users, the environment, the competition, the market, the technology; all of these can be volatile fountains of change. To embrace the flood of changes, agile methods advise us to “inspect and adapt.” That is, to figure out what‘s changed and adapt to it by changing our methods, refactoring our code, collaborating with our customers, and so on. But most agile adopters simply can‘t do that, for a very good reason. When you are first learning a new skill—a new programming language, or a new technique, or a new development method—you do not yet have the experience, mental models, or ability to handle an abstract concept such as “inspect and adapt.” Those abilities are only present in practitioners with much more experience, at higher skill levels

Andy also has some thoughts on how to correct this - starting with the idea that Agile methodologies must be applied to Agile methodologies, to allow them to adapt to changing needs.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by MichaelDavidCrawford on Saturday May 09 2015, @12:02AM

    by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Saturday May 09 2015, @12:02AM (#180562) Homepage Journal

    - programming, actually I practiced pair programming in the early nineties, long before that was part of any methodology I have ever heard of, but when I see a job board post for a company that says it practices Agile or Scrum, I don't even apply.

    --
    Yes I Have No Bananas. [gofundme.com]
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 5, Insightful) by TheGratefulNet on Saturday May 09 2015, @01:26AM

    by TheGratefulNet (659) on Saturday May 09 2015, @01:26AM (#180592)

    buzzword salad. eat it up, YUM! (oh wait, that applies only to fishheads).

    I laugh at all the ways we try to make a 'science' out of programming. its not really science, its art. its a skill and takes talent and experience and some people work well in this field and some do not.

    what agile tried to do is to make programming 'work' for even the clueless and talent-lacking. the employment market is filled with extremely young players (and managers!) and they simply cannot function well. so they clasp onto fad techniques and hoping a 'daily standup' will ensure a good product.

    too fucking funny!

    the right answer is: building things requires insight and talent and it does not really matter what method you use. sometimes planning out a whole system makes sense (waterfall) and sometimes being very dynamic makes sense (agile). often its a hybrid that defines catagorization.

    but all I see now - in the bay area - is jobs that -require- agile development models. it does not matter if they work (mostly they do not) but its trendy and managers are the most conservative of employees; they want SAFETY and if something fails they want to put the blame on something else, just not them.

    agile gives them 'structure' when they can't be creative on their own. its a cop-out. its not any more or less effective than 'extreme programming' or 'pair programming' or any other hipster name you want to give.

    good people build things and get stuff done. not everyone who passes comp-sci with a sheepskin is able to truly build things. agile is not any magic bullet.

    but sadly, I am not seeing any new jobs that don't have agile as part of their descr. sad how lemming-like our profession has become.

    --
    "It is now safe to switch off your computer."
    • (Score: 3, Insightful) by Geotti on Saturday May 09 2015, @03:05AM

      by Geotti (1146) on Saturday May 09 2015, @03:05AM (#180611) Journal

      its not really science, its art.

      It can be (and often is) an art, but most of the time it's a craft. Everything else still stands, though. Just nitpicking.

    • (Score: 2) by kaszz on Saturday May 09 2015, @08:13AM

      by kaszz (4211) on Saturday May 09 2015, @08:13AM (#180677) Journal

      It's not the age that is the problem. It's the thinking that is the problem. You can learn clues, learning thinking is harder..

    • (Score: 2) by hash14 on Saturday May 09 2015, @05:25PM

      by hash14 (1102) on Saturday May 09 2015, @05:25PM (#180809)

      what agile tried to do is to make programming 'work' for even the clueless and talent-lacking.

      ...

      the right answer is: building things requires insight and talent and it does not really matter what method you use. sometimes planning out a whole system makes sense (waterfall) and sometimes being very dynamic makes sense (agile). often its a hybrid that defines catagorization.

      This is spot on. If I had to summarize Agile, it would basically be:

      Hack the shit out of anything you're working on. Don't think about anything you're working on, just make sure you can "deliver" it at the end of your iteration and stuff the remaining problems in the backlog. Next iteration, take a few more issues out of the backlog and continue hacking the shit out of them in the same way until everything's a disorganized mess that nobody can understand. As long as you never stop to think about doing things right and instead just focus make sure that it seems to do what you want, you're making progress; Congratulations! as long as you're following the guidelines, you're doing it right!

      I'm not advocating for a straight waterfall approach, but the crucial thing that waterfall has that Agile doesn't is _A DESIGN PHASE_. Without this, you just get a disorganized mess of complete crap. Good software design requires knowing what the final product is going to look like before you start; but Agile has absolutely no focus on this which is why it has a strong tendency to just fall apart when the whole thing becomes impossible to maintain. As they say, there's many ways to do it, but only a few of them are right (or something like that).

      Generally speaking, you want to do a more waterfall-style approach on early projects and then transition to more agile-style approaches as they become more mature. There are always exceptions of course, but design (even in an Agile iteration) can never be overlooked.

      not everyone who passes comp-sci with a sheepskin is able to truly build things.

      This is true as well. Computer Science/Software Engineering programs frequently don't focus on being good designers. They focus on esoteric concepts like complexity classes and programming paradigms (which are very interesting for sure, but only really useful to theorists or very high-skilled engineers) or teach data structures when many students don't have any context for it. They don't teach things like scalable object-oriented design (or design patterns) or modularity of existing code. In fact, when I think about it, I haven't taken many programming courses, but the ones that I have focus on implementing a few methods, but not designing a whole system. Lacking that, you can't be a very good or useful software engineer.

  • (Score: 2) by Nerdfest on Saturday May 09 2015, @01:44AM

    by Nerdfest (80) on Saturday May 09 2015, @01:44AM (#180597)

    Pair programming is great, but draining. I find that I can't do it all the time. I've found that Agile works very well, but often it's used as an exclude for poor specs. Even then it would work except that everyone seems to keep wanting to pull back into waterfall all of the time which demonstrably does not work when you don't have a clear predefined set of requirements.