12 ms·

The End of Agile: Death by Over-Simplification

71 points by ern 12y ago

rnernento 12y ago
One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. Developers become responsible for their own individual tasks but don't take responsibility for the project as a whole or how that task might fit into it. For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results.
- wavefunction 12y ago
  You need better developers and managers then. What you're describing is a personality trait, not a side-effect of adopting AGILE practices. The developers have to care about the project as a whole and the managers need to communicate upwards, downwards, and horizontally: that's how a team maintains a high-level view while implementing in the weeds.
- dragonwriter 12y ago
  > One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. There are no doubt methodologies that do that, and some of them are probably sold as being "agile", but there is nothing particularly agile about doing that and most writing son Agile (and its close relative, Lean) actually recommend doing the exact opposite and eliminating most role distinctions within development teams and finding ways to establish broader collective ownership of the product as a whole (different authors differ in the specific approaches they recommend trying in order to achieve this.) > For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results. That sounds like you didn't adopt Agile -- the orientation toward software development encompassed in the Agile Manifesto -- but some externally-defined canned process that some consultant slapped an "agile" sticker on to sell to people who don't know what Agile is. If your existing pattern of interactions is working effectively, "adopting Agile" shouldn't mean much change besides something like periodic discussions of how it is working, and what any pain points are in it, and how to tweak it to resolve those pain points. In fact, even if your current processes aren't working, that's what adopting Agile should look like at first -- any bigger changes should come out of what the team discovers in those discussions (which may then lead to adopting, on a trial basis, particular practices that have been defined externally that appear to be designed to address the issues that the team is having to evaluate if they work for the team, but adopting a set of canned externally-defined processes without reference to the specific needs of the team isn't adopting Agile -- its something opposed to Agile that puts process over people and interactions.)
UK-AL 12y ago
"In my personal opinion, we will have to go back to the basics: To all the wonderful design fundamentals that were being discussed in the 90’s: the SOLID principles of OOD, design patterns, software reuse," - Err, Agile is based on those principles to. Agile takes quality above all else, a task is not finished until its finished well. Agile has always been combined with software craftsmanship, especially XP style engineering principles.
adamors 12y ago
> In my personal opinion, we will have to go back to the basics: To all the wonderful design fundamentals that were being discussed in the 90’s: the SOLID principles of OOD, design patterns, software reuse, component-based software development. Many of us are doing just this while practicing Agile. It's not an either or situation. Are people really this out of touch with contemporary software development practices?
- BSousa 12y ago
  From experience, not many, a few. Worked with a good bunch of developers that didn't even know SOLID existed (but what do you expect when developers now a days have a 30 day bootcamp or read a Rails book and are able to get developer jobs?)
k__ 12y ago
My Software engineering Prof. Once wrote, those agile methods were first used by highly skilled teams that knew what they wanted. There has never been any evidence for them to be a silver bullet. Big planning slows down experienced engineers, but can help the unskilled quite well...
- tbrownaw 12y ago
  My Software engineering Prof. Once wrote, those agile methods were first used by highly skilled teams that knew what they wanted. There has never been any evidence for them to be a silver bullet. This is the case for pretty much anything new and cool. Big planning slows down experienced engineers, but can help the unskilled quite well... Plans serve (at least) two purposes. One is so that you know what you're doing. This doesn't have to be formal and can live partly inside your head. Experienced people probably do more of this, they just do it faster and don't bother writing as much of it out (because recalculating on-the-fly is faster and less error-prone than looking up last week's overly-detailed predictions). The other is so that other people know what you're doing and when you'll be done with it. For this the proper amount is whatever provides the most useful information (for all combinations of "most" and "useful"), without taking so much time as to cost more than it's worth.
- richliss 12y ago
  This times a thousand. The reason Agile worked is because skilled professionals who wanted to do software better did it properly. Sadly there was lots of money to be made by certifying unskilled professionals who suddenly flooded the market and couldn't do software better but made it hard to find the good guys. I knew there were serious issues when at an Agile meetup recently I had attendees having a go at me for daring to suggest that some process might be needed for dealing with staff who are either inexperienced, or unprofessional.
lostcolony 12y ago
Agile requires a bit of fudging around the edges, but it already admits that that is required (people > processes). Yeah, YAGNI and its ilk may apply, but sometimes you -do know you're going to need it-. That story is in the pipeline, your users are demanding it; to design and code only to the current story, dismissing the design considerations that that future story would impose upon the current one, is shortsighted and self-defeating. You shouldn't be delivering -features- from that story yet, but by all means recognize that "Oh, we'll need a hook for that, and it would make sense for me to implement this with an event manager so we can add subscribers, and keep these decoupled, rather than just make a direct method invocation", etc, so you can easily tackle that future story when it comes up. Oh, hey, the build and deploy process sucks, and that has no direct user value, and thus no story. Well, deal with it anyway; you -know- that is costing you time, and being able to rapidly iterate = faster development time = less cost = desirable to the user. Etc. Really, agile always seemed to me to be two different things. One was a series of processes. The other was a series of values (among which was people > processes). And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around. EDIT: I've also seen teams that take the values as excuses to ignore the processes, which also fails hard. "People over processes? Okay, no process then, everyone just code! Get shit done!" The point is to take on the processes, modify them in accordance with the values as experience leads you. Something doesn't work for your team? Change it. As someone mentioned elsewhere on this thread, that's what retrospectives are for.
- tbrownaw 12y ago
  And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around. The problem is, that's how it's being sold. The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.
  - lostcolony 12y ago
    I'd not go so broad as that, though I tend to agree. Bringing in outside consultation can help when the team is fractured, or when there's a disconnect between the team's needs and what management is willing to allow (that is, an outsider saying to management "Look, you've already agreed to be agile; that means you have to give the team autonomy to try this" can be more effective than the team saying "We want to try this"). But yes, there's a lot of snake oil salesmen, "Agile is good for what ails ya!"
scottlilly 12y ago
I think that one problem has been with some people promoting TDD by saying to write "the simplest thing possible to get the unit test to pass". I've seen "Uncle Bob" do his bowling game demo, without using the expected classes for Game, Frame, etc. It's an interesting exercise, but would be a horrible way to write any large-scale business application. However, some people walk away from that with the idea that they should write quick "hacky" code, instead of doing any thinking about design. When I write a program, I use my [constantly-evolving] set of "best practices", based on what I've experienced when writing other applications. Writing a factory method for object instantiation is not "the simplest thing possible", but I've seen it come in very handy at times, so that's what I'm doing in my projects now. After all, aren't retrospectives, and modifying your process based on what you've learned during your project, one of the huge points of Agile - even though I've rarely seen them done, let alone done well.
- cageface 12y ago
  This is a classic and hilarious series of posts on the foolhardiness of the TDD approach to software design: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ Personally I prefer Rich Hickey's "Hammock Driven Development": https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc
planetjones 12y ago
Fair points, for the most part I think. To write good software, you need good people who know what they're doing. Whatever process you follow without that you're always in trouble (requirements, design, coding, testing, etc. all those need good people). What I really hate about the Agile consultants, etc. is that many say switch to Agile and the world becomes a better place. Not with bad people it doesn't. However, I think a lot of the Agile stuff can really help get the best out of the good people. For the bad people I have seen it work the opposite way - they lose the safety net of structured requirements analysis, design, etc. and end up creating a mess. Best part for me was the link to the anti agile manifesto: http://antiagilemanifesto.com/ http://antiagilemanifesto.com/
darkxanthos 12y ago
With any story like this there's always one bit that's understated. There's agile as it is practiced and agile as it is described by the founders. They're quite different. Agile as described by the founders is so squishy it can almost never be wrong. How so? There is no process. There is no explicit denial of waterfall process. There's only values and stated preferences. If an agile project fails one can always say "Why didn't you choose a better process for the people?" Ultimately the whole point was to deliver working software and optimize for change. That hasn't died as far as I can tell... We just achieve it in many different ways. What could be more agile than that?
sramsay 12y ago
I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people, and in which a certain set of predictable inputs will reliably produce an assured set of outputs. Of course, whether "other areas of engineering" are like this is another question (I suspect that when there's a five billion dollar cost overrun on a bridge, we have our answer about predictable processes). But in the larger sense, I think this is the dream of every geek -- a process, a system that works independently of the people involved. We're going to keep chasing that one down for as long as our business is around. I think Agile changed the way we all work, but it didn't fundamentally change the nature of the endeavor, which is full of guessing, hunches, miscommunication, dropped balls, and overreach, as well as insight, heroism, eleventh-hour refactors, and (above all else) lessons learned through bitter experience.
- IanCal 12y ago
  > I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people I don't know where you got that idea from, given this vital line in the original manifesto: > Individuals and interactions over processes and tools http://agilemanifesto.org/ http://agilemanifesto.org/ The entire point was to get past the "one size fits none" solutions and just build some stuff.
  - dodyg 12y ago
    Would you like some Certifications with that?
  - sramsay 12y ago
    A manifesto written after the first burst of agile enthusiasm (and the first major public "failure)." Do you really read, say, the original Extreme Programming book as being in line with that manifesto?
- pinaceae 12y ago
  that's because there is no engineering yet in software development. it is at the stage of middle ages production, a manufacture in its original sense. client says 'i need a shoe' and developers start from scratch, everytime. it's as if you're tasked with buidling a house and first you design bricks, nails, ... (libraries, frameworks, languages). the fact that shit like i18n to this day is not natively handled by the frameworks itself and does break software in 2014 is amazing. oh you entered a date with saudi locale and their business days do not match ours? oh shucks. outside of large scale public infrastructure projects construction is entirely predictable and safe now. it all starts with education and there is no software engineering one - engineering is all about known entities, process and safety margins. best practices, gathered for hundreds of years. it also explains these massive successes with software right now - it is a very young industry, public utilities do neot exist yet. you can reap massive rewards by offering sewage removal in a better way (facebook).
atlantic 12y ago
>Now the question is: what will guide Agile through the “slope of enlightenment”? Ditch the Agile consultants. Let each team build its own understanding of Agile principles, and implement Agile in its own way. Once Agile stops being an over-hyped cash cow, it may again bring some benefits to software development. In other words, and as the author says, back to basics.
vannevar 12y ago
This is a poor argument. The first three "myths" in the article are all straw-men. First, Agile isn't a design process, it's an implementation process. How you arrive at those user stories is up to you, and nothing in Agile proscribes using OOD, SOLID, patterns, or any other software design process your heart desires. And please show me the Agile article that says that you should constantly refactor working code, or that technical debt should be accumulated freely because it can always be repaid. Myth #4 might make the basis of a good article (and has), but it hardly means the end of agile to suggest that just blindly following agile rituals doesn't guarantee agility.
- darkxanthos 12y ago
  Show me where in the agile manifesto ANY process is recommended: http://agilemanifesto.org/ http://agilemanifesto.org/ This is the entirety of the issue. Once one refers to it as a process their entire argument is flawed.
  - fennecfoxen 12y ago
    You click the 'twelve principles' link and go to http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html For instance: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Oh hey! It's a process! Heck, it's like a meta-process, even. THE meta-process.
    - walterbell 12y ago
      Heinz von Foerster has spoken about the interaction between properties of the observer and the observed. In the quote below, one could replace "obscene" with "agile" -- each is impervious to objective measurement. http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cybernetics_cybernetics_hvf.pdf http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cyb... "There is at aperiodic intervals a ritual performed by the supreme judges of this land in which they attempt to establish once and for all a list of all the properties that define an obscene object or act. Since obscenity is not a property residing within things (for if we show Mr. X a painting and he calls it obscene, we know a lot about Mr. X but very little about the painting), when our lawmakers will finally come up with their imaginary list we shall know a lot about them but their laws will be dangerous nonsense."
programminggeek 12y ago
The thing I see every time someone decries the death of agile is that they fail to mention or probably aren't doing retrospectives after every sprint. Good retrospectives aren't complicated and don't take that much time, but they are arguably the most important part of a successful agile team. Most of the best ideas in agile come from lean manufacturing concepts and arguably the most important part of lean manufacturing is continuous improvement. Continuous improvement in software process comes from retrospectives. When teams fail to do retrospectives, they fail to learn from their mistakes and discuss ways to improve. I don't care what your process is, if you do retrospectives consistently and commit to take action after each retrospective, you can make any process more awesome. Teams that don't improve their process end up with a crappy process that nobody likes. This is not an agile specific problem.
bayesianhorse 12y ago
The article to me feels like the author has a high appreciation of his own understanding of software development - and maybe even very rightly so - but doesn't want to put this in a certain language other people developed (in this case "agile" methods). I don't believe technical debt can be avoided. And it seems counter to the "debt metaphor" that you take time away from working on current demands to save time later. There seems to be no real evidence that time spent now is necessarily worth more time later (beyond reasonable planning or avoiding really stupid decisions). The debt metaphor would actually mean that time now is worth more than time later (time value of time, if you will). Probably it depends on where the time for "avoiding technical debt" is actually taken away from...
MarkMc 12y ago
Agile may be dead, but not for any of the reasons the author describes. The first first two 'myths' are not something that Agile claims, and the last two 'myths' are in fact true. > Myth 1: Good design will emerge from the implementation of user stories ... However, in practice the code does not have this tendency to self-organize. Code may not self-organize, but a small team of programmers can. It is not the implementation of simple user stories that produces good code but rather the ability and willingness of the team to constantly refactor the code. The main point of Agile development is that you get better quality code written faster if you take a somewhat messy codebase and refactor it, instead of try to come up with a great design before writing any code. > Myth 2: It will always be possible to pay the technical debt in the future ... However, in practice it is not so easy to pay the technical debt. Agile doesn't claim it's always possible to pay technical debt in future, otherwise there would be no need to refactor code. What it does say is that programmers have a tendency to overestimate the chance that the chunk of code they are working on will need to be clean and flexible in future (ie. "You Ain't Gonna Need It") and to overestimate the cost of future refactoring if it does. A good example is copy-and-pasting: It's generally fine to copy and paste a chunk of once or even twice - only on the second or third copy should you start to refactor it. > Myth 3: Constant refactoring is an effective way to produce code ... However, in practice refactoring is consuming an exaggerated amount of the efforts invested in software development There's no question that constant refactoring takes as a significant chunk of time in Agile, but not much more than the design phase in other workflow processes. And in my experience it is simply the way to maximise the long-term addition of value to the codebase. It's a bit like that old story about how the fastest man to chop down trees spends most of his time sharpening his axe. > Myth 4: Agility can be assured by following an Agile process ... However, in practice the process alone is not able to provide change-resilience Again, this simply has not been my experience. The only time I have found refactoring to be painful and difficult is when the codebase has had bits of code gingerly tacked on over the years without any refactoring - and that certainly isn't The Agile Way. > The consequence is that some teams implement new features very fast in the first iterations, but at some point their work halts and they start spending most of their efforts in endless refactorings. News Flash: It is ALWAYS easier and faster to write code on a greenfield project than a large, old codebase - dumping Agile will not change that. At the risk of sounding elitist or relying on the 'one true scotsman' argument, maybe the author has simply not worked with people who are good at refactoring. It certainly is a skill and many programmers don't have it. Here's a great quote [1] written seven years ago on this point: > "for me, a lot of the differences between the best programmers I've worked with and the worst are simply the quality of the abstractions when they pull out pieces of code to reuse. Often, even when it's clear that someone needs to build a piece of reusable code to call from many places, the results will be very different. Some people are naturally good at producing clean and elegant abstractions to reuse, while others' abstractions tend to leak and be a little hairy looking, making them harder to work with." [1] http://www.reddit.com/r/programming/comments/2d2e0/theres_no_programmer_who_does_the_work_of_ten/c2d3zb http://www.reddit.com/r/programming/comments/2d2e0/theres_no...
markbnj 12y ago
As someone who has been programming for a living for a couple of decades now I have seen more than one methodology come along and propose to solve all the "problems" with my craft. Like any young discipline we still have a lot of things to work out, however I find that as I get older I have less tolerance for the view that "the problem" lies in the way programmers do things. I think rather that "the problem" lies in the way customers treat the process of creating software. They approach it with a casualness and an indecisiveness which would not work in any other context where something expensive and custom was being built from scratch. I can honestly say that in over twenty years I have not been acquainted with a project that failed because the people who were responsible for writing the code couldn't get it done, or couldn't get it done fast enough. On the other hand I've seen lots of projects fail due to inadequate executive commitment, off-the-cuff estimates, evolving feature sets, etc.
- cageface 12y ago
  I agree with this but I think at least part of the problem is that we don't have good tools for specifying precisely what it is we intend to build. If we could create software plans as detailed and exacting as blueprints for a new building we'd have far fewer failures. Instead we toss together a few wireframes and start hacking and by the time we're done the final product is nothing like what we were originally tasked to build. As far as I can tell this just isn't the case in any other field of "engineering".
  - markbnj 12y ago
    Perhaps, but how useful are those detailed plans and blueprints to the actual consumer of the construction service? They get studied, sure, but I think the customer is still working at the level of features and their expression in the plan, not the plans themselves which are more of an internal tool for the architect and builders. It's true that we lack widely accepted formalized design tools like blueprints, but at the same time it's interesting to note that one of the recognized problems with extensive planning and design documentation in software is that it can't keep up with evolving requirements :). So again, we can't plan because the customer has been taught to think everything is open for discussion at all times.
JoeAltmaier 12y ago
User stories work when the user interacts with every part of the system. But for backends or libraries or engines, there is no user but other developers. We're not trying to delight developers probably, but to enable them. That different impulse drives different coding behaviours/ project plans than 'put up another screen for the web user'. I disagree that technical debt == bad code. That's just a cop out. Code can be golden and still not cover all the cases or perform as well as a better-but-larger-effort solution. So we cut corners, write golden but small-scale code and move on. Its a startup after all. Then later when the fires are out and we have time to breath, we'd like to spend 12 hours and put in more golden code, that takes longer to develop but performs better or covers more cases.
vpeters25 12y ago
I though this was the quarterly "why agile sucks" post on HN but instead it seems to list bad habits worth avoiding in effective agile teams. If your agile consultant is promoting any of these myths you need a different one.

71 points by ern 12y ago

One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. Developers become responsible for their own individual tasks but don't take responsibility for the project as a whole or how that task might fit into it. For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results.

wavefunction 12y ago
You need better developers and managers then. What you're describing is a personality trait, not a side-effect of adopting AGILE practices. The developers have to care about the project as a whole and the managers need to communicate upwards, downwards, and horizontally: that's how a team maintains a high-level view while implementing in the weeds.
dragonwriter 12y ago
> One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. There are no doubt methodologies that do that, and some of them are probably sold as being "agile", but there is nothing particularly agile about doing that and most writing son Agile (and its close relative, Lean) actually recommend doing the exact opposite and eliminating most role distinctions within development teams and finding ways to establish broader collective ownership of the product as a whole (different authors differ in the specific approaches they recommend trying in order to achieve this.) > For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results. That sounds like you didn't adopt Agile -- the orientation toward software development encompassed in the Agile Manifesto -- but some externally-defined canned process that some consultant slapped an "agile" sticker on to sell to people who don't know what Agile is. If your existing pattern of interactions is working effectively, "adopting Agile" shouldn't mean much change besides something like periodic discussions of how it is working, and what any pain points are in it, and how to tweak it to resolve those pain points. In fact, even if your current processes aren't working, that's what adopting Agile should look like at first -- any bigger changes should come out of what the team discovers in those discussions (which may then lead to adopting, on a trial basis, particular practices that have been defined externally that appear to be designed to address the issues that the team is having to evaluate if they work for the team, but adopting a set of canned externally-defined processes without reference to the specific needs of the team isn't adopting Agile -- its something opposed to Agile that puts process over people and interactions.)

UK-AL 12y ago

"In my personal opinion, we will have to go back to the basics: To all the wonderful design fundamentals that were being discussed in the 90’s: the SOLID principles of OOD, design patterns, software reuse," - Err, Agile is based on those principles to. Agile takes quality above all else, a task is not finished until its finished well. Agile has always been combined with software craftsmanship, especially XP style engineering principles.

adamors 12y ago

> In my personal opinion, we will have to go back to the basics: To all the wonderful design fundamentals that were being discussed in the 90’s: the SOLID principles of OOD, design patterns, software reuse, component-based software development. Many of us are doing just this while practicing Agile. It's not an either or situation. Are people really this out of touch with contemporary software development practices?

BSousa 12y ago
From experience, not many, a few. Worked with a good bunch of developers that didn't even know SOLID existed (but what do you expect when developers now a days have a 30 day bootcamp or read a Rails book and are able to get developer jobs?)

k__ 12y ago

My Software engineering Prof. Once wrote, those agile methods were first used by highly skilled teams that knew what they wanted. There has never been any evidence for them to be a silver bullet. Big planning slows down experienced engineers, but can help the unskilled quite well...

tbrownaw 12y ago
My Software engineering Prof. Once wrote, those agile methods were first used by highly skilled teams that knew what they wanted. There has never been any evidence for them to be a silver bullet. This is the case for pretty much anything new and cool. Big planning slows down experienced engineers, but can help the unskilled quite well... Plans serve (at least) two purposes. One is so that you know what you're doing. This doesn't have to be formal and can live partly inside your head. Experienced people probably do more of this, they just do it faster and don't bother writing as much of it out (because recalculating on-the-fly is faster and less error-prone than looking up last week's overly-detailed predictions). The other is so that other people know what you're doing and when you'll be done with it. For this the proper amount is whatever provides the most useful information (for all combinations of "most" and "useful"), without taking so much time as to cost more than it's worth.
richliss 12y ago
This times a thousand. The reason Agile worked is because skilled professionals who wanted to do software better did it properly. Sadly there was lots of money to be made by certifying unskilled professionals who suddenly flooded the market and couldn't do software better but made it hard to find the good guys. I knew there were serious issues when at an Agile meetup recently I had attendees having a go at me for daring to suggest that some process might be needed for dealing with staff who are either inexperienced, or unprofessional.

lostcolony 12y ago

Agile requires a bit of fudging around the edges, but it already admits that that is required (people > processes). Yeah, YAGNI and its ilk may apply, but sometimes you -do know you're going to need it-. That story is in the pipeline, your users are demanding it; to design and code only to the current story, dismissing the design considerations that that future story would impose upon the current one, is shortsighted and self-defeating. You shouldn't be delivering -features- from that story yet, but by all means recognize that "Oh, we'll need a hook for that, and it would make sense for me to implement this with an event manager so we can add subscribers, and keep these decoupled, rather than just make a direct method invocation", etc, so you can easily tackle that future story when it comes up. Oh, hey, the build and deploy process sucks, and that has no direct user value, and thus no story. Well, deal with it anyway; you -know- that is costing you time, and being able to rapidly iterate = faster development time = less cost = desirable to the user. Etc. Really, agile always seemed to me to be two different things. One was a series of processes. The other was a series of values (among which was people > processes). And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around. EDIT: I've also seen teams that take the values as excuses to ignore the processes, which also fails hard. "People over processes? Okay, no process then, everyone just code! Get shit done!" The point is to take on the processes, modify them in accordance with the values as experience leads you. Something doesn't work for your team? Change it. As someone mentioned elsewhere on this thread, that's what retrospectives are for.

tbrownaw 12y ago
And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around. The problem is, that's how it's being sold. The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.
- lostcolony 12y ago
  I'd not go so broad as that, though I tend to agree. Bringing in outside consultation can help when the team is fractured, or when there's a disconnect between the team's needs and what management is willing to allow (that is, an outsider saying to management "Look, you've already agreed to be agile; that means you have to give the team autonomy to try this" can be more effective than the team saying "We want to try this"). But yes, there's a lot of snake oil salesmen, "Agile is good for what ails ya!"

scottlilly 12y ago

I think that one problem has been with some people promoting TDD by saying to write "the simplest thing possible to get the unit test to pass". I've seen "Uncle Bob" do his bowling game demo, without using the expected classes for Game, Frame, etc. It's an interesting exercise, but would be a horrible way to write any large-scale business application. However, some people walk away from that with the idea that they should write quick "hacky" code, instead of doing any thinking about design. When I write a program, I use my [constantly-evolving] set of "best practices", based on what I've experienced when writing other applications. Writing a factory method for object instantiation is not "the simplest thing possible", but I've seen it come in very handy at times, so that's what I'm doing in my projects now. After all, aren't retrospectives, and modifying your process based on what you've learned during your project, one of the huge points of Agile - even though I've rarely seen them done, let alone done well.

cageface 12y ago
This is a classic and hilarious series of posts on the foolhardiness of the TDD approach to software design: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ Personally I prefer Rich Hickey's "Hammock Driven Development": https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc

planetjones 12y ago

Fair points, for the most part I think. To write good software, you need good people who know what they're doing. Whatever process you follow without that you're always in trouble (requirements, design, coding, testing, etc. all those need good people). What I really hate about the Agile consultants, etc. is that many say switch to Agile and the world becomes a better place. Not with bad people it doesn't. However, I think a lot of the Agile stuff can really help get the best out of the good people. For the bad people I have seen it work the opposite way - they lose the safety net of structured requirements analysis, design, etc. and end up creating a mess. Best part for me was the link to the anti agile manifesto: http://antiagilemanifesto.com/ http://antiagilemanifesto.com/

darkxanthos 12y ago

With any story like this there's always one bit that's understated. There's agile as it is practiced and agile as it is described by the founders. They're quite different. Agile as described by the founders is so squishy it can almost never be wrong. How so? There is no process. There is no explicit denial of waterfall process. There's only values and stated preferences. If an agile project fails one can always say "Why didn't you choose a better process for the people?" Ultimately the whole point was to deliver working software and optimize for change. That hasn't died as far as I can tell... We just achieve it in many different ways. What could be more agile than that?

sramsay 12y ago

I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people, and in which a certain set of predictable inputs will reliably produce an assured set of outputs. Of course, whether "other areas of engineering" are like this is another question (I suspect that when there's a five billion dollar cost overrun on a bridge, we have our answer about predictable processes). But in the larger sense, I think this is the dream of every geek -- a process, a system that works independently of the people involved. We're going to keep chasing that one down for as long as our business is around. I think Agile changed the way we all work, but it didn't fundamentally change the nature of the endeavor, which is full of guessing, hunches, miscommunication, dropped balls, and overreach, as well as insight, heroism, eleventh-hour refactors, and (above all else) lessons learned through bitter experience.

IanCal 12y ago
> I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people I don't know where you got that idea from, given this vital line in the original manifesto: > Individuals and interactions over processes and tools http://agilemanifesto.org/ http://agilemanifesto.org/ The entire point was to get past the "one size fits none" solutions and just build some stuff.
- dodyg 12y ago
  Would you like some Certifications with that?
- sramsay 12y ago
  A manifesto written after the first burst of agile enthusiasm (and the first major public "failure)." Do you really read, say, the original Extreme Programming book as being in line with that manifesto?
pinaceae 12y ago
that's because there is no engineering yet in software development. it is at the stage of middle ages production, a manufacture in its original sense. client says 'i need a shoe' and developers start from scratch, everytime. it's as if you're tasked with buidling a house and first you design bricks, nails, ... (libraries, frameworks, languages). the fact that shit like i18n to this day is not natively handled by the frameworks itself and does break software in 2014 is amazing. oh you entered a date with saudi locale and their business days do not match ours? oh shucks. outside of large scale public infrastructure projects construction is entirely predictable and safe now. it all starts with education and there is no software engineering one - engineering is all about known entities, process and safety margins. best practices, gathered for hundreds of years. it also explains these massive successes with software right now - it is a very young industry, public utilities do neot exist yet. you can reap massive rewards by offering sewage removal in a better way (facebook).

atlantic 12y ago

>Now the question is: what will guide Agile through the “slope of enlightenment”? Ditch the Agile consultants. Let each team build its own understanding of Agile principles, and implement Agile in its own way. Once Agile stops being an over-hyped cash cow, it may again bring some benefits to software development. In other words, and as the author says, back to basics.

vannevar 12y ago

This is a poor argument. The first three "myths" in the article are all straw-men. First, Agile isn't a design process, it's an implementation process. How you arrive at those user stories is up to you, and nothing in Agile proscribes using OOD, SOLID, patterns, or any other software design process your heart desires. And please show me the Agile article that says that you should constantly refactor working code, or that technical debt should be accumulated freely because it can always be repaid. Myth #4 might make the basis of a good article (and has), but it hardly means the end of agile to suggest that just blindly following agile rituals doesn't guarantee agility.

darkxanthos 12y ago
Show me where in the agile manifesto ANY process is recommended: http://agilemanifesto.org/ http://agilemanifesto.org/ This is the entirety of the issue. Once one refers to it as a process their entire argument is flawed.
- fennecfoxen 12y ago
  You click the 'twelve principles' link and go to http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html For instance: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Oh hey! It's a process! Heck, it's like a meta-process, even. THE meta-process.
  - walterbell 12y ago
    Heinz von Foerster has spoken about the interaction between properties of the observer and the observed. In the quote below, one could replace "obscene" with "agile" -- each is impervious to objective measurement. http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cybernetics_cybernetics_hvf.pdf http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cyb... "There is at aperiodic intervals a ritual performed by the supreme judges of this land in which they attempt to establish once and for all a list of all the properties that define an obscene object or act. Since obscenity is not a property residing within things (for if we show Mr. X a painting and he calls it obscene, we know a lot about Mr. X but very little about the painting), when our lawmakers will finally come up with their imaginary list we shall know a lot about them but their laws will be dangerous nonsense."

programminggeek 12y ago

The thing I see every time someone decries the death of agile is that they fail to mention or probably aren't doing retrospectives after every sprint. Good retrospectives aren't complicated and don't take that much time, but they are arguably the most important part of a successful agile team. Most of the best ideas in agile come from lean manufacturing concepts and arguably the most important part of lean manufacturing is continuous improvement. Continuous improvement in software process comes from retrospectives. When teams fail to do retrospectives, they fail to learn from their mistakes and discuss ways to improve. I don't care what your process is, if you do retrospectives consistently and commit to take action after each retrospective, you can make any process more awesome. Teams that don't improve their process end up with a crappy process that nobody likes. This is not an agile specific problem.

bayesianhorse 12y ago

The article to me feels like the author has a high appreciation of his own understanding of software development - and maybe even very rightly so - but doesn't want to put this in a certain language other people developed (in this case "agile" methods). I don't believe technical debt can be avoided. And it seems counter to the "debt metaphor" that you take time away from working on current demands to save time later. There seems to be no real evidence that time spent now is necessarily worth more time later (beyond reasonable planning or avoiding really stupid decisions). The debt metaphor would actually mean that time now is worth more than time later (time value of time, if you will). Probably it depends on where the time for "avoiding technical debt" is actually taken away from...

MarkMc 12y ago

Agile may be dead, but not for any of the reasons the author describes. The first first two 'myths' are not something that Agile claims, and the last two 'myths' are in fact true. > Myth 1: Good design will emerge from the implementation of user stories ... However, in practice the code does not have this tendency to self-organize. Code may not self-organize, but a small team of programmers can. It is not the implementation of simple user stories that produces good code but rather the ability and willingness of the team to constantly refactor the code. The main point of Agile development is that you get better quality code written faster if you take a somewhat messy codebase and refactor it, instead of try to come up with a great design before writing any code. > Myth 2: It will always be possible to pay the technical debt in the future ... However, in practice it is not so easy to pay the technical debt. Agile doesn't claim it's always possible to pay technical debt in future, otherwise there would be no need to refactor code. What it does say is that programmers have a tendency to overestimate the chance that the chunk of code they are working on will need to be clean and flexible in future (ie. "You Ain't Gonna Need It") and to overestimate the cost of future refactoring if it does. A good example is copy-and-pasting: It's generally fine to copy and paste a chunk of once or even twice - only on the second or third copy should you start to refactor it. > Myth 3: Constant refactoring is an effective way to produce code ... However, in practice refactoring is consuming an exaggerated amount of the efforts invested in software development There's no question that constant refactoring takes as a significant chunk of time in Agile, but not much more than the design phase in other workflow processes. And in my experience it is simply the way to maximise the long-term addition of value to the codebase. It's a bit like that old story about how the fastest man to chop down trees spends most of his time sharpening his axe. > Myth 4: Agility can be assured by following an Agile process ... However, in practice the process alone is not able to provide change-resilience Again, this simply has not been my experience. The only time I have found refactoring to be painful and difficult is when the codebase has had bits of code gingerly tacked on over the years without any refactoring - and that certainly isn't The Agile Way. > The consequence is that some teams implement new features very fast in the first iterations, but at some point their work halts and they start spending most of their efforts in endless refactorings. News Flash: It is ALWAYS easier and faster to write code on a greenfield project than a large, old codebase - dumping Agile will not change that. At the risk of sounding elitist or relying on the 'one true scotsman' argument, maybe the author has simply not worked with people who are good at refactoring. It certainly is a skill and many programmers don't have it. Here's a great quote [1] written seven years ago on this point: > "for me, a lot of the differences between the best programmers I've worked with and the worst are simply the quality of the abstractions when they pull out pieces of code to reuse. Often, even when it's clear that someone needs to build a piece of reusable code to call from many places, the results will be very different. Some people are naturally good at producing clean and elegant abstractions to reuse, while others' abstractions tend to leak and be a little hairy looking, making them harder to work with." [1] http://www.reddit.com/r/programming/comments/2d2e0/theres_no_programmer_who_does_the_work_of_ten/c2d3zb http://www.reddit.com/r/programming/comments/2d2e0/theres_no...

markbnj 12y ago

As someone who has been programming for a living for a couple of decades now I have seen more than one methodology come along and propose to solve all the "problems" with my craft. Like any young discipline we still have a lot of things to work out, however I find that as I get older I have less tolerance for the view that "the problem" lies in the way programmers do things. I think rather that "the problem" lies in the way customers treat the process of creating software. They approach it with a casualness and an indecisiveness which would not work in any other context where something expensive and custom was being built from scratch. I can honestly say that in over twenty years I have not been acquainted with a project that failed because the people who were responsible for writing the code couldn't get it done, or couldn't get it done fast enough. On the other hand I've seen lots of projects fail due to inadequate executive commitment, off-the-cuff estimates, evolving feature sets, etc.

cageface 12y ago
I agree with this but I think at least part of the problem is that we don't have good tools for specifying precisely what it is we intend to build. If we could create software plans as detailed and exacting as blueprints for a new building we'd have far fewer failures. Instead we toss together a few wireframes and start hacking and by the time we're done the final product is nothing like what we were originally tasked to build. As far as I can tell this just isn't the case in any other field of "engineering".
- markbnj 12y ago
  Perhaps, but how useful are those detailed plans and blueprints to the actual consumer of the construction service? They get studied, sure, but I think the customer is still working at the level of features and their expression in the plan, not the plans themselves which are more of an internal tool for the architect and builders. It's true that we lack widely accepted formalized design tools like blueprints, but at the same time it's interesting to note that one of the recognized problems with extensive planning and design documentation in software is that it can't keep up with evolving requirements :). So again, we can't plan because the customer has been taught to think everything is open for discussion at all times.

JoeAltmaier 12y ago

User stories work when the user interacts with every part of the system. But for backends or libraries or engines, there is no user but other developers. We're not trying to delight developers probably, but to enable them. That different impulse drives different coding behaviours/ project plans than 'put up another screen for the web user'. I disagree that technical debt == bad code. That's just a cop out. Code can be golden and still not cover all the cases or perform as well as a better-but-larger-effort solution. So we cut corners, write golden but small-scale code and move on. Its a startup after all. Then later when the fires are out and we have time to breath, we'd like to spend 12 hours and put in more golden code, that takes longer to develop but performs better or covers more cases.

vpeters25 12y ago

I though this was the quarterly "why agile sucks" post on HN but instead it seems to list bad habits worth avoiding in effective agile teams. If your agile consultant is promoting any of these myths you need a different one.