29 ms·

The Death of Agile [video]

threepipeproblm 12y ago
I really enjoyed this. One detail that stuck out at me is that after Thomas makes the claim that the single metric that matters in software is how easy it is to change, he moves on to show a balancing robot. Now he doesn't directly connect those concepts, instead he talks about the PID algorithm. But what struck me is that Moshe Feldenkrais defined good posture almost exactly in the same way that Thomas defines good software, although he is talking about humans rather than robots. Specifically, Feldenkrais says that good posture in a given context is that which makes it easiest to move into the next desired position (or a spectrum of potentially desirable next positions).
- michaelfeathers 12y ago
  In the early XP days, we spoke about code's equipoise.
- cmdkeen 12y ago
  "the claim that the single metric that matters in software is how easy it is to change" Not if you have actual business people that you work for, then you're delivery ratio (things achieved per person/unit of time) is key. Because that delivers predictability and enabled planning. It lets you have discussions about what level of quality to deliver, staffing requirements, manage delivery expectations and plan releases. The key thing is that it demonstrates the cost of change to them, so after being burned they come to appreciate the benefits of building in flexibility, but it also affects how they interact with the business. Delivery, and the burnup/down it allows, is the way we as developers can train product owners to predict the risk in what is coming and use their expertise to reduce it. I've seen far more time saved, and lost, due to the business learning to ask the right questions, and raise the right stories, than due to building flexible software to handle changes. No matter how flexible your software is the really huge changes always bring massive pain - and as developers we don't have the domain knowledge to necessary to identify those whereas business people can.
slowmovintarget 12y ago
Now if we can just get management to sit down and watch this... I keep watching Cargo Cult "Agile" turn every project into a galley, developers at the oars with the scrum master merely manning the drum and shouting "row!" Two lashes for failing to update your task in the system, no matter that the work got done... We really need to get back to the real measure of working software instead of "are we going to have a demo or not?"
- pcurve 12y ago
  I think we all need to watch this video, particularly business and project managers. I'm shocked at the complete lack of understanding of what agile is by virtually everybody working on any project these days.
- wallflower 12y ago
  For management, it's not really about the process du jour per se. It is about standardization, frameworks, and control. Read 'Seeing like a state' From Ruby Rogues 184 RR "JESSICA: Alright. So, I am going to echo one of Greg’s picks because it was on my list but for a different reason. ‘Seeing like a State’ is an amazing book. And I think it’s drastically changed the way I look at software, not for the same reason as Greg talked about but because it shows why what we do is hard. ‘Seeing like a State’ talks about all the subtleties of human systems and human interactions at the local context level. It talks about all the improvisation that everyone does on a day-to-day basis and how in real human communities, we’re constantly changing the system to adjust to a slightly different reality, to corner cases we hadn’t seen before but now we have. It’s shifting and it’s not well-defined. And suddenly it makes complete sense that the hardest part of software is figuring out what we want to do. That’s it. It’s a great book." http://www.amazon.com/Seeing-like-State-Certain-Condition/dp/0300078153 http://www.amazon.com/Seeing-like-State-Certain-Condition/dp...
  - myth_drannon 12y ago
    Funny how one comment on HN can bring a relatively old and unknown book from obscurity to top spot on Amazon sales chart (it's a sub-section but still). Of course it's just an assumption that there is a correlation between.
pmoriarty 12y ago
Anyone have a direct link to the video? I'd like to watch it, but it requires me to run some Flash plugin, which I'd like to avoid.
- devmach 12y ago
  It looks like they have html5 player too, which plays the following file http://embed.wistia.com/deliveries/05b7d508543a1e8f7de01e27b8db61a26e7cb5c1/file.mp4 http://embed.wistia.com/deliveries/05b7d508543a1e8f7de01e27b... (900Mb, HD) edit: Although, I don't know if they allow you to "Download" the video in sense of the licencing...
  - pmoriarty 12y ago
    I should have said that I didn't want to run any embedded players, Flash, HTML 5, Javascript, or whatever. Thank you for the link!
tunesmith 12y ago
For those that are allergic to snark like me, skip the first fifteen minutes - it doesn't start getting constructive until then.
- tunesmith 12y ago
  For those downvoting, here's a quick summary: 4:00 - Middle-aged white guys at a conference to figure out how to sell fear by turning agile into a "noun" 5:00 - Make agile more difficult-sounding with lots of terms so you can manipulate companies out of time and money 6:00 - Sell unnecessary roles like "scrum-master" to further manipulate companies out of time and money 8:00 - Agile plot to mock developers who don’t “fall” for the previous manipulations. But again, the tone changes after the first fifteen minutes, so I intended that comment for those who would watch the first few minutes and think that it's just someone invested in making fun of "Agile" the whole time.
- pmoriarty 12y ago
  I don't know what you're talking about. The first part was the best part.
  - imanaccount247 12y ago
    The part where he makes fun of the agile snake oil salesmen despite the fact that he was one of the biggest offenders?
    - pmoriarty 12y ago
      He did seem like a hypocrite for trying to tell the audience how to "do Agile" (or, in his terms "develop with Agility") immediately after a satire on people who do just that. Further, I doubt he was giving the talk for charity. He's clearly making money off Agile just like everyone else. Nevertheless, the first part was entertaining satire, no matter its source. The rest can be skipped.
rebelshrug 12y ago
Not everything about agile software development is bad. Planning poker is a great team exercise if you replace the planning part with a deck of playing cards, poker chips and beer.
pmoriarty 12y ago
I'd like to show this to my company, but I'm afraid I'll offend coworkers who make their money at the company "doing Agile" and I'll get lynched, not to mention fired.
- rebelshrug 12y ago
  Fired for voicing an opinion? Sounds like a company worth leaving.
  - pmoriarty 12y ago
    Not just an opinion, but a sharp-tongued poke at a sacred cow. I would be singled out as negative, not a team player, a troublemaker. I'm welcome to have an opinion, as long as I don't make waves. Keep your head down and do your job is the motto. The "leaders" set the tune and you march. If they tell you to jump to Agile, all you're welcome to ask is "how high?"
    - enraged_camel 12y ago
      >>Not just an opinion, but a sharp-tongued poke at a scared cow. Well, yes, poking a scared cow would not be nice. I think you meant sacred? :)
      - Gigablah 12y ago
        If it wasn't scared before, it is now.
  - calibraxis 12y ago
    Most corporations will fire you for voicing certain (non-oppressive) opinions, since ideology is important. You see it in schools too, not to mention cults. You're allowed to get to the next rung by not seeing it, already having the right attitudes, or faking it. (Consider some meanings of "cultural fit".)
    - 12y ago
capkutay 12y ago
Not to sound lazy, but I'd like to make a humble request for a TL;DR? I can skim long papers, but you can't do that for long videos!
- rebelshrug 12y ago
  here's Dave Thomas' blog post on the subject: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/ http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
  - capkutay 12y ago
    Thanks!
- disputin 12y ago
  The theatrical form of agile as it has been peddled with all of its prescribed practices is nonsense piled onto the idea of agility so that it appeals to managers, for sale by consultants, and that agility is important in its toned back form, without the annoying rules that have no regard for context. I hope this means the death of scrum.
Toine 12y ago
I'm really surprised by this video. I'm a junior developer who just got out of college. I knew the software industry isn't as mature as some other industries, but I kinda thought as a whole we were moving towards a more professionnal, more robust, less amateur industry. This guy, if I heard correctly, participated in writing the Agile manifesto, which is basically software's 10 commandements written by the Agile gods. In this talk, he basically says : "Yea actually we were kinda wrong, you shouldn't listen to anyone telling you to do anything, just run free in the jungle and you'll be fine." So after all those years of trying to find a solution to how to do software correctly, this is his answer? Why would you say something like that? How do you teach people then? Where can i learn how to do my job correctly? The 4 steps he give cannot be taken seriously...can you imagine medical students being taught "yea just try something and see what happens, hopefully your patient doesn't die and you'll learn something for the next patient."
- walshemj 12y ago
  Welcome to the real world where software is never as simple and clear cut as university problems.
  - UK-AL 12y ago
    Many engineering and operational jobs have fairly standard techniques. However in software no standard practice seems to form.
    - curiously 12y ago
      I think with embedded systems that has no physical constraint can be mutable and I think this is why software can get so complicated to put a simple process through. Rather it seems like a collection of developer experiences and practices that are mutually beneficial to the stability of their jobs, if a developer's experience and views negatively impacts their stability or enjoyability of their development job, it is incorrect by whoever is paid the most. Rather when software fail, it's actually because the social dynamics have failed in that environment.
    - 12y ago
mathieuh 12y ago
I'm in university at the moment and we're learning about Agile. Next year I've managed to get a year long placement with a big local software company and their interview and technical assessment mentioned Agile loads. The year after that, I have half a module (worth 8% of that year's available marks) based solely on Agile. I've also attended talks by big names like Citigroup and also local startups which were almost entirely about using Agile. So is it in fact the case that in The Real World Agile is starting to go out of favour?
- rebelshrug 12y ago
  No - companies invest a lot of resources into their software development processes, and changing processes often involves a significant investment of it's own, not to mention a slow down in productivity.
- radicalbyte 12y ago
  > So is it in fact the case that in The Real World Agile is starting to go out of favour? Nope, it has finally crossed the line into being "main stream". On the technology adoption lifecycle* it has hit the late majority. It has been taken up by the "software development as career"-types who're only in it for the money; it's now a "requirement", just another box to be ticked. Sad, but on the plus side it's better than the "waterfall" processes which preceded it. * http://en.wikipedia.org/wiki/Technology_adoption_lifecycle http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
deleted 12y ago
[deleted]
- wavefunction 12y ago
  Pair programming is not part of "agile," it's "extreme programming." I don't see a lot of value from regular or formally instituted pair programming sessions. You're also only supposed to have one "standup" a day under "SCRUM/Agile." Agile is all about autonomy of the team over what you're describing, which is a mish-mash of a lot of different strategies.
guiomie 12y ago
I keep hearing the word "agile" from vendors, consultants and non-software related stakeholders at my work (a telco). For me it is a buzzword, thus I have been quite reluctant toward it. Seeing also one of the original authors thinking so, means I'll stay even more away, and perhaps take people using the word with skepticism.
- DanielBMarkham 12y ago
  "Agile" is a marketing term: it brands various best practices in iterative and incremental development. You go to a bookstore and want to read a mystery? They have a whole section labeled "Mystery" where you get all kinds of good stuff. You want to learn how groups of people work well together in tech? Go to the "Agile" section. I like this, but it's tough for many people to grok, because it's not a detailed instruction book, like some other methodologies. If you want to stay current in how people are doing cool stuff, consume Agile material on a regular basis. But take it all with a grain of salt: you learn stuff and then try it. What works in one situation won't work in another. One of the things practitioners learned early on is that tech is 95%+ about people, not bits and bytes. People tend to be a few orders of magnitude more difficult than, say, C++
  - pjmlp 12y ago
    Many developers would learn a lot if they improved their soft skills instead of yet another programming language/framework.
    - DanielBMarkham 12y ago
      I would hire people with good aptitude and attitude over people with good technical chops any day of the week. It's not even close. I've seen too many teams of great people walk into a project not knowing any of the tech involved -- and kick ass. I've also seen a tremendous number of highly-skilled teams create a death march/miserable existence for themselves where they could get nothing done at all.
      - 12y ago
fpp 12y ago
Also read his interview on the topic in Dr Dobb's earlier this year http://www.drdobbs.com/architecture-and-design/dave-thomas-interview-the-corruption-of/240166688 http://www.drdobbs.com/architecture-and-design/dave-thomas-i... The diagram he shows in the presentation around 5min is from Scaled Agile that is trying to formalise the use of agile development approaches within the enterprise context (online at http://scaledagileframework.com/ http://scaledagileframework.com/ ) I believe some the key messages from Dave are: * Use common sense and focus on the goals and what you're planning to deliver - the approaches provide you with the agility to more likely arrive there. * People and working solutions before processes and approach * Collaborate, explore and adjust to change vs follow a predefined fixed plan Some negative examples I've seen: "Funny and ridiculously expensive certifications" - Job adverts making it a key requirement to have a "scrum master" certification instead of looking for people who successfully delivered solutions (within change / complex environments) Note: It takes 1-2 days from absolute beginner to being a "certified scrum master" and it costs a stunning £1,200 in London. "Process over common sense" - Within a company of some of my friends when they asked me to help to turnaround a critical situation with their key development team - besides 2 developers all others had left because of conflicts with their line managers, one of them now standing in as "scrum master" and prescribing to continue and do daily stand-ups like before with two 6 people teams - sometimes only one developer together with the manager.
placebo 12y ago
Watching this, my first thought was how an aerospace engineer or a structural engineer or any engineer/manager of any complex established engineering field outside the software development field would react to this video. Probably with horror, shock and disbelief :) Though I haven't given this too much thought, I think it boils down to the fact that the software engineering process is not like (and who knows if it will ever be like) older well established engineering fields, and this could be due to a combination of: a) The unbelievably vast number of degrees of freedom and therefore infinite ways an engineer has to achieve a working model. Aside from the requirements and the hardware limits, the only limiting factor is the engineer's imagination and creativity. b) The mind blowing complexity of a large software project. The space shuttle, definitely one of the more complex machines built by mankind, is built from about 2.5 million separate parts. The Linux kernel (from 2012, according to wikipedia) has 15.9 million lines of code, and it is by no means the largest software project. c) The relatively young age of the field vs. the exponential rate at which new technologies are devised and introduced in it All this I feel currently puts software development somewhere between an engineering and a form of art. However, I'm sure many people would find it unsettling to think they have to trust a form of art when flying in a commercial jet at 30,000 feet, launching a $500M space mission, or endless other modern operations that depend on software to succeed. The fact is though, that it does succeed. I doubt the same methodologies are used in every large software project around the globe, but the bottom line is that whatever methodologies are used (not taking into account different levels of effectivity or cost) most apparently appear to succeed getting the job done without a established "standard".
- tonyedgecombe 12y ago
  Most software projects fail.
  - placebo 12y ago
    What do you mean by 'fail'? fail financially or fail technically? If you mean the former then that's a no brainer, as I assume most projects fail financially whether software or not. If you mean fail technically then I'd be interested to see numbers. It's certainly not my experience.
bane 12y ago
If there's a truism, it's that Agile is and always will be a reactionary process to older Waterfall style methodologies adopted from other engineering principles. That means it suffers from some of the kinds of problems reactionary "we'll do the opposite of that old broken stuff" ideas have. For example, I'm afraid that in many environments, Agile ends up meaning "directionless or micro-directioned iterative development" e.g. just start building stuff, nobody has any real idea what the ends state is supposed to look like or work, but we'll iterate into something at some point. Probably when we get close to running out of money. Old fashioned honest engineering is tossed out while the framework/technology of the month gets absorbed into this or that sprint cycle and when problems preventing what feels like forward motion are discovered, crap just gets thrown against the wall until something moves forward a step. Things ship late, nobody can schedule anything, budgeting and hiring plans are a mess. One of the defining aspects of being human is that we're capable of thinking a few steps ahead and formulating a plan. The way Agile works in most shops returns us to being mere beasts of coding. Of the places I've seen, the difference between success and endless-iteration-failure-followed-by-multiple-rewrites-from-scratch-before-delivery-because-look-at-all-the-lessons-we-learned-along-the-way is that somebody sat down before any work started and defined the goal, timing, budget and expectations. There's some planning, some mockups, some interaction prototypes, etc. at the start that's hard work to do, but defines the goals and vision the work effort should be going towards...the "shape" of the work. Goal driven development is something that seems to be missing in too many shops. It's hard though, because you don't want to end up in the waterfall trap again, but you don't want to end up in an directionless iteration morass either. It takes experience and lots of road miles to understand that balance and succeed.
- UK-AL 12y ago
  Agile is planned, just on a shorter time scale and gets more vague over time. Sprints have end goals, and so do epics. Waterfall had big upfront design, which meant every time a manager asked for a change it screwed up the design and had to modified which took a lot of time. So people didn't ask for changes and the resulting software didn't do what they really wanted. Iterative development tries to embrace change, it's an attempt at controlled change.
- enraged_camel 12y ago
lifeisstillgood 12y ago
For me, and I think i just worked this one out, Agile can only work in a collaborative, open, high trust environment. If you have that, pretty much anything you do will be agile. If you don't there is bugger all you can do to get to agile without fixing it. Personality conflicts, leaders who shut down discussions, developers who just want to do what they are told and collect a pay check, this and more will screw you up. So go for slow development, constant learning, some humility, and a company that won't fire you for looking like you are just "thinking about it"
- tonyedgecombe 12y ago
  This is true, I suspect that companies that fail with agile will fail with any and every methodology.
InclinedPlane 12y ago
For those who aren't aware or didn't pick it up, Dave Thomas is one of the handful of originators of the "Agile Manifesto". Other than the obvious (profit motive in selling snake oil) there are some common problems that make evaluating and applying process difficult. One of the biggest problems is actually the effect of highly talented teams. If you have a team of skilled folks then they will often succeed independent of process. If they are burdened with unworkable processes they will quite often work around them, bend them, or ignore them and get shit done regardless. Which makes it difficult to tell when you've got a good process in place as well. Another major problem, alluded to in the video, is the desire for brain death in management. People want silver bullets, they want universal advice, they want policies that don't require effort or thought to achieve results. You see something similar in tech security, everyone wants to hire a unicorn/jesus who swoops in and fixes everything, like a landscaper who comes in on the weekends to do yard work or something. The reality is that development, and security, requires effort at every level. It requires conscientious application of skill and judgment to get good work done, and that's true at every level. You can't simply apply one or another process and then switch your brain off and hope for the best.
- mattmurdog 12y ago
  Very well said.
ItsMattyG 12y ago
Agile is good in uncertain environments with frequent project changes, but not in other situations... Simon Wardley has a good model that seems to work reasonably well: http://blog.gardeviance.org/2014/11/how-we-used-to-organise-stuff.html http://blog.gardeviance.org/2014/11/how-we-used-to-organise-...
chriscareycode 12y ago
I love this talk by Erik Meijer on the topic http://vimeo.com/110554082 http://vimeo.com/110554082
oldpond 12y ago
I think I know who Dave is making fun of, and yes, there are plenty of stakeholders who are hopelessly lost and willing to "buy agile" to make it look like they are doing something. Just get all the useless project managers to call themselves scrum masters and hold daily stand-ups (which in the old days we called micro managing) and hope and prey that something works... I've been in this business since the 80's and a consultant since '98, and I can say that although I love the agile approach, busted organizations and "enterprise" consultants are killing the ideas. Agile is a software development approach, not an organization development methodology. The last gig I was on the customer tried to "go agile". All the departments started holding daily stand-ups which quickly became silly repetitions and micro management kill-zones. Picture this, the daily help desk standup: "Yesterday I answered phones, and today I plan to answer phones again." Everyone was doing 'agile' except the software development teams. Maybe Dave is right, all you can do is laugh about it. And then put it all on the cloud.
- InclinedPlane 12y ago
  At one of my past jobs we did "agile" or "scrums" or whatever they called their bastardized version of an agile process. At one point this involved standups which included over a dozen people and typically lasted between 45 minutes and an hour and a half. Everyday.
  - deleted 12y ago
    [deleted]
  - EdwardDiego 12y ago
    Gah. So let me guess, the "stand-up" ended up with a bunch of people sitting down, because after all, you can't stand up for that long...? ...the number of people who miss the reason for standing up (to force brevity) is astounding.
    - InclinedPlane 12y ago
      Nope. Everyone stayed standing the whole time. This was at a multi-billion dollar online retailer who shall remain nameless (though it's pretty easy to figure out).
InclinedPlane 12y ago
(As much as I hate to post twice on a thread, I've had some thoughts that I haven't seen expressed yet.) I think a lot of folks are missing some important perspective on the origin and rise of "agile" and the current state of process in the software industry. So let's take a quick trip back to the bad old days before agile to get a sense of what software development was often like back then. First off, a lot of software was developed "out of house" so to speak, as works for hire by consultancy type companies. There would be extensive negotiations between the customer and representatives of the development company, the end goal of this process was typically a specification and a timetable that was then mutually agreed upon, through a legally binding contract, as to what would be built. Next, the development company would take that specification and come up with a design that would be able to match the specs. Then that design would be sliced up and handed out to various teams and eventually down to individual devs. After the individual coding was done it'd be integrated together and compiled into a working product. The product would then be passed off to QA to test in order to make sure it didn't have any bugs and that it matched the spec. After that the product would then be passed on to the customer to use. And everyone lived happily ever after. Of course, there are a few problematic aspects to this process. Namely: everything. Usually what would happen is that the spec and/or the design would be unrealistic or impossible to implement, and wouldn't be what the customer actually wanted regardless. Often this was handled by acrimonious bouts of negotiation, often involving lawyers. Meanwhile, attempting to build anything that worked at all using this sort of process was a nightmare. When the software was integrated only at the last minute there were always a million new problems discovered. With such "big-bang" integrations a lot of effort is spent spinning away just getting the software to build and work at all. Meanwhile, when QA is the last step before handing the product off to the customer that means that defects, especially design defects, have had the greatest amount of opportunity to fester and take the most effort to remove. And, of course, the chance that the project would chew up many staff-years of effort without actually producing anything of use whatsoever was quite high with this model, since actually building software was a fairly late step. In the face of all these very fundamental problems with the venerable "waterfall" process model a lot of new process ideas started to gain traction, more or less culminating in the "agile manifesto". The core idea of agility is to use iterative development, continuous integration, and open lines of communication to keep on track. The "customer" (or "stake holders") can see the direction of the product mid-stream and have many chances to correct communication errors or even errors in their original conception of what they wanted. The software is always being built and always being tested so integration overhead costs are much less severe and defects are spotted much closer to where they are introduced, making them easier to fix. The software is routinely in a "shipable" state with a continually evolving subset of the "final" featureset, this lets the customer see how close the developers are to the schedule and also dramatically reduces the risk of not shipping anything at all. The developers can always time box the release and ship something of value, even if it wasn't what was originally intended. And so on. The thing is, today we live in a fundamentally agile world of development. Waterfall is so far from the norm it's essentially extinct. The very idea of futzing around with nothing but requirements and specs for months or years before bothering to write a line of code is so anathema to the current standards of software development it seems ridiculous. Everyone knows you start with a skeleton and you flesh it out iteratively. The idea that you'd have your code base in an unbuildable state, let alone an unusable product state, for more than a few hours or days at most is similarly seemingly preposterous. The fact that the basic principles of agility are now so ubiquitous that they are like a mold infecting every nook and cranny of the software industry is still unsatisfactory for a lot of folks. Management wants a process they can sink their teeth into. They want something that requires no effort on their part but seems like a silver bullet that can solve any problem. They want gadgets and tools. They want a process that they can leverage to justify all of their bad behaviors while removing accountability from themselves. And that's what agile-the-noun has become. Not agility, but rather an excuse for micro-management. A way to plan without planning. A justification for short-sightedness and disengagement. A convenient rolodex of excuses for why everyone but management is at fault for being late or building something bad or broken or that no one wants. You either die a hero or you live long enough to see yourself become the villain.
serve_yay 12y ago
He is quite a speaker, but really the first 15 minutes is a standup comedy routine for project managers. You can skip that part.
dmux 12y ago
I'll just leave this here: http://seir.sei.cmu.edu/sheard/Life%20Cycle%20Silver%20Bullet.pdf http://seir.sei.cmu.edu/sheard/Life%20Cycle%20Silver%20Bulle...

I really enjoyed this. One detail that stuck out at me is that after Thomas makes the claim that the single metric that matters in software is how easy it is to change, he moves on to show a balancing robot. Now he doesn't directly connect those concepts, instead he talks about the PID algorithm. But what struck me is that Moshe Feldenkrais defined good posture almost exactly in the same way that Thomas defines good software, although he is talking about humans rather than robots. Specifically, Feldenkrais says that good posture in a given context is that which makes it easiest to move into the next desired position (or a spectrum of potentially desirable next positions).

michaelfeathers 12y ago
In the early XP days, we spoke about code's equipoise.
cmdkeen 12y ago
"the claim that the single metric that matters in software is how easy it is to change" Not if you have actual business people that you work for, then you're delivery ratio (things achieved per person/unit of time) is key. Because that delivers predictability and enabled planning. It lets you have discussions about what level of quality to deliver, staffing requirements, manage delivery expectations and plan releases. The key thing is that it demonstrates the cost of change to them, so after being burned they come to appreciate the benefits of building in flexibility, but it also affects how they interact with the business. Delivery, and the burnup/down it allows, is the way we as developers can train product owners to predict the risk in what is coming and use their expertise to reduce it. I've seen far more time saved, and lost, due to the business learning to ask the right questions, and raise the right stories, than due to building flexible software to handle changes. No matter how flexible your software is the really huge changes always bring massive pain - and as developers we don't have the domain knowledge to necessary to identify those whereas business people can.

slowmovintarget 12y ago

Now if we can just get management to sit down and watch this... I keep watching Cargo Cult "Agile" turn every project into a galley, developers at the oars with the scrum master merely manning the drum and shouting "row!" Two lashes for failing to update your task in the system, no matter that the work got done... We really need to get back to the real measure of working software instead of "are we going to have a demo or not?"

pcurve 12y ago
I think we all need to watch this video, particularly business and project managers. I'm shocked at the complete lack of understanding of what agile is by virtually everybody working on any project these days.
wallflower 12y ago
For management, it's not really about the process du jour per se. It is about standardization, frameworks, and control. Read 'Seeing like a state' From Ruby Rogues 184 RR "JESSICA: Alright. So, I am going to echo one of Greg’s picks because it was on my list but for a different reason. ‘Seeing like a State’ is an amazing book. And I think it’s drastically changed the way I look at software, not for the same reason as Greg talked about but because it shows why what we do is hard. ‘Seeing like a State’ talks about all the subtleties of human systems and human interactions at the local context level. It talks about all the improvisation that everyone does on a day-to-day basis and how in real human communities, we’re constantly changing the system to adjust to a slightly different reality, to corner cases we hadn’t seen before but now we have. It’s shifting and it’s not well-defined. And suddenly it makes complete sense that the hardest part of software is figuring out what we want to do. That’s it. It’s a great book." http://www.amazon.com/Seeing-like-State-Certain-Condition/dp/0300078153 http://www.amazon.com/Seeing-like-State-Certain-Condition/dp...
- myth_drannon 12y ago
  Funny how one comment on HN can bring a relatively old and unknown book from obscurity to top spot on Amazon sales chart (it's a sub-section but still). Of course it's just an assumption that there is a correlation between.

pmoriarty 12y ago

Anyone have a direct link to the video? I'd like to watch it, but it requires me to run some Flash plugin, which I'd like to avoid.

devmach 12y ago
It looks like they have html5 player too, which plays the following file http://embed.wistia.com/deliveries/05b7d508543a1e8f7de01e27b8db61a26e7cb5c1/file.mp4 http://embed.wistia.com/deliveries/05b7d508543a1e8f7de01e27b... (900Mb, HD) edit: Although, I don't know if they allow you to "Download" the video in sense of the licencing...
- pmoriarty 12y ago
  I should have said that I didn't want to run any embedded players, Flash, HTML 5, Javascript, or whatever. Thank you for the link!

tunesmith 12y ago

For those that are allergic to snark like me, skip the first fifteen minutes - it doesn't start getting constructive until then.

tunesmith 12y ago
For those downvoting, here's a quick summary: 4:00 - Middle-aged white guys at a conference to figure out how to sell fear by turning agile into a "noun" 5:00 - Make agile more difficult-sounding with lots of terms so you can manipulate companies out of time and money 6:00 - Sell unnecessary roles like "scrum-master" to further manipulate companies out of time and money 8:00 - Agile plot to mock developers who don’t “fall” for the previous manipulations. But again, the tone changes after the first fifteen minutes, so I intended that comment for those who would watch the first few minutes and think that it's just someone invested in making fun of "Agile" the whole time.
pmoriarty 12y ago
I don't know what you're talking about. The first part was the best part.
- imanaccount247 12y ago
  The part where he makes fun of the agile snake oil salesmen despite the fact that he was one of the biggest offenders?
  - pmoriarty 12y ago
    He did seem like a hypocrite for trying to tell the audience how to "do Agile" (or, in his terms "develop with Agility") immediately after a satire on people who do just that. Further, I doubt he was giving the talk for charity. He's clearly making money off Agile just like everyone else. Nevertheless, the first part was entertaining satire, no matter its source. The rest can be skipped.

rebelshrug 12y ago

Not everything about agile software development is bad. Planning poker is a great team exercise if you replace the planning part with a deck of playing cards, poker chips and beer.

pmoriarty 12y ago

I'd like to show this to my company, but I'm afraid I'll offend coworkers who make their money at the company "doing Agile" and I'll get lynched, not to mention fired.

rebelshrug 12y ago
Fired for voicing an opinion? Sounds like a company worth leaving.
- pmoriarty 12y ago
  Not just an opinion, but a sharp-tongued poke at a sacred cow. I would be singled out as negative, not a team player, a troublemaker. I'm welcome to have an opinion, as long as I don't make waves. Keep your head down and do your job is the motto. The "leaders" set the tune and you march. If they tell you to jump to Agile, all you're welcome to ask is "how high?"
  - enraged_camel 12y ago
    >>Not just an opinion, but a sharp-tongued poke at a scared cow. Well, yes, poking a scared cow would not be nice. I think you meant sacred? :)
    - Gigablah 12y ago
      If it wasn't scared before, it is now.
- calibraxis 12y ago
  Most corporations will fire you for voicing certain (non-oppressive) opinions, since ideology is important. You see it in schools too, not to mention cults. You're allowed to get to the next rung by not seeing it, already having the right attitudes, or faking it. (Consider some meanings of "cultural fit".)
  - 12y ago

capkutay 12y ago

Not to sound lazy, but I'd like to make a humble request for a TL;DR? I can skim long papers, but you can't do that for long videos!

rebelshrug 12y ago
here's Dave Thomas' blog post on the subject: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/ http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
- capkutay 12y ago
  Thanks!
disputin 12y ago
The theatrical form of agile as it has been peddled with all of its prescribed practices is nonsense piled onto the idea of agility so that it appeals to managers, for sale by consultants, and that agility is important in its toned back form, without the annoying rules that have no regard for context. I hope this means the death of scrum.

Toine 12y ago

I'm really surprised by this video. I'm a junior developer who just got out of college. I knew the software industry isn't as mature as some other industries, but I kinda thought as a whole we were moving towards a more professionnal, more robust, less amateur industry. This guy, if I heard correctly, participated in writing the Agile manifesto, which is basically software's 10 commandements written by the Agile gods. In this talk, he basically says : "Yea actually we were kinda wrong, you shouldn't listen to anyone telling you to do anything, just run free in the jungle and you'll be fine." So after all those years of trying to find a solution to how to do software correctly, this is his answer? Why would you say something like that? How do you teach people then? Where can i learn how to do my job correctly? The 4 steps he give cannot be taken seriously...can you imagine medical students being taught "yea just try something and see what happens, hopefully your patient doesn't die and you'll learn something for the next patient."

walshemj 12y ago
Welcome to the real world where software is never as simple and clear cut as university problems.
- UK-AL 12y ago
  Many engineering and operational jobs have fairly standard techniques. However in software no standard practice seems to form.
  - curiously 12y ago
    I think with embedded systems that has no physical constraint can be mutable and I think this is why software can get so complicated to put a simple process through. Rather it seems like a collection of developer experiences and practices that are mutually beneficial to the stability of their jobs, if a developer's experience and views negatively impacts their stability or enjoyability of their development job, it is incorrect by whoever is paid the most. Rather when software fail, it's actually because the social dynamics have failed in that environment.
  - 12y ago

mathieuh 12y ago

I'm in university at the moment and we're learning about Agile. Next year I've managed to get a year long placement with a big local software company and their interview and technical assessment mentioned Agile loads. The year after that, I have half a module (worth 8% of that year's available marks) based solely on Agile. I've also attended talks by big names like Citigroup and also local startups which were almost entirely about using Agile. So is it in fact the case that in The Real World Agile is starting to go out of favour?

rebelshrug 12y ago
No - companies invest a lot of resources into their software development processes, and changing processes often involves a significant investment of it's own, not to mention a slow down in productivity.
radicalbyte 12y ago
> So is it in fact the case that in The Real World Agile is starting to go out of favour? Nope, it has finally crossed the line into being "main stream". On the technology adoption lifecycle* it has hit the late majority. It has been taken up by the "software development as career"-types who're only in it for the money; it's now a "requirement", just another box to be ticked. Sad, but on the plus side it's better than the "waterfall" processes which preceded it. * http://en.wikipedia.org/wiki/Technology_adoption_lifecycle http://en.wikipedia.org/wiki/Technology_adoption_lifecycle

deleted 12y ago

[deleted]

wavefunction 12y ago
Pair programming is not part of "agile," it's "extreme programming." I don't see a lot of value from regular or formally instituted pair programming sessions. You're also only supposed to have one "standup" a day under "SCRUM/Agile." Agile is all about autonomy of the team over what you're describing, which is a mish-mash of a lot of different strategies.

guiomie 12y ago

I keep hearing the word "agile" from vendors, consultants and non-software related stakeholders at my work (a telco). For me it is a buzzword, thus I have been quite reluctant toward it. Seeing also one of the original authors thinking so, means I'll stay even more away, and perhaps take people using the word with skepticism.

DanielBMarkham 12y ago
"Agile" is a marketing term: it brands various best practices in iterative and incremental development. You go to a bookstore and want to read a mystery? They have a whole section labeled "Mystery" where you get all kinds of good stuff. You want to learn how groups of people work well together in tech? Go to the "Agile" section. I like this, but it's tough for many people to grok, because it's not a detailed instruction book, like some other methodologies. If you want to stay current in how people are doing cool stuff, consume Agile material on a regular basis. But take it all with a grain of salt: you learn stuff and then try it. What works in one situation won't work in another. One of the things practitioners learned early on is that tech is 95%+ about people, not bits and bytes. People tend to be a few orders of magnitude more difficult than, say, C++
- pjmlp 12y ago
  Many developers would learn a lot if they improved their soft skills instead of yet another programming language/framework.
  - DanielBMarkham 12y ago
    I would hire people with good aptitude and attitude over people with good technical chops any day of the week. It's not even close. I've seen too many teams of great people walk into a project not knowing any of the tech involved -- and kick ass. I've also seen a tremendous number of highly-skilled teams create a death march/miserable existence for themselves where they could get nothing done at all.
    - 12y ago

fpp 12y ago

Also read his interview on the topic in Dr Dobb's earlier this year http://www.drdobbs.com/architecture-and-design/dave-thomas-interview-the-corruption-of/240166688 http://www.drdobbs.com/architecture-and-design/dave-thomas-i... The diagram he shows in the presentation around 5min is from Scaled Agile that is trying to formalise the use of agile development approaches within the enterprise context (online at http://scaledagileframework.com/ http://scaledagileframework.com/ ) I believe some the key messages from Dave are: * Use common sense and focus on the goals and what you're planning to deliver - the approaches provide you with the agility to more likely arrive there. * People and working solutions before processes and approach * Collaborate, explore and adjust to change vs follow a predefined fixed plan Some negative examples I've seen: "Funny and ridiculously expensive certifications" - Job adverts making it a key requirement to have a "scrum master" certification instead of looking for people who successfully delivered solutions (within change / complex environments) Note: It takes 1-2 days from absolute beginner to being a "certified scrum master" and it costs a stunning £1,200 in London. "Process over common sense" - Within a company of some of my friends when they asked me to help to turnaround a critical situation with their key development team - besides 2 developers all others had left because of conflicts with their line managers, one of them now standing in as "scrum master" and prescribing to continue and do daily stand-ups like before with two 6 people teams - sometimes only one developer together with the manager.

placebo 12y ago

Watching this, my first thought was how an aerospace engineer or a structural engineer or any engineer/manager of any complex established engineering field outside the software development field would react to this video. Probably with horror, shock and disbelief :) Though I haven't given this too much thought, I think it boils down to the fact that the software engineering process is not like (and who knows if it will ever be like) older well established engineering fields, and this could be due to a combination of: a) The unbelievably vast number of degrees of freedom and therefore infinite ways an engineer has to achieve a working model. Aside from the requirements and the hardware limits, the only limiting factor is the engineer's imagination and creativity. b) The mind blowing complexity of a large software project. The space shuttle, definitely one of the more complex machines built by mankind, is built from about 2.5 million separate parts. The Linux kernel (from 2012, according to wikipedia) has 15.9 million lines of code, and it is by no means the largest software project. c) The relatively young age of the field vs. the exponential rate at which new technologies are devised and introduced in it All this I feel currently puts software development somewhere between an engineering and a form of art. However, I'm sure many people would find it unsettling to think they have to trust a form of art when flying in a commercial jet at 30,000 feet, launching a $500M space mission, or endless other modern operations that depend on software to succeed. The fact is though, that it does succeed. I doubt the same methodologies are used in every large software project around the globe, but the bottom line is that whatever methodologies are used (not taking into account different levels of effectivity or cost) most apparently appear to succeed getting the job done without a established "standard".

tonyedgecombe 12y ago
Most software projects fail.
- placebo 12y ago
  What do you mean by 'fail'? fail financially or fail technically? If you mean the former then that's a no brainer, as I assume most projects fail financially whether software or not. If you mean fail technically then I'd be interested to see numbers. It's certainly not my experience.

bane 12y ago

If there's a truism, it's that Agile is and always will be a reactionary process to older Waterfall style methodologies adopted from other engineering principles. That means it suffers from some of the kinds of problems reactionary "we'll do the opposite of that old broken stuff" ideas have. For example, I'm afraid that in many environments, Agile ends up meaning "directionless or micro-directioned iterative development" e.g. just start building stuff, nobody has any real idea what the ends state is supposed to look like or work, but we'll iterate into something at some point. Probably when we get close to running out of money. Old fashioned honest engineering is tossed out while the framework/technology of the month gets absorbed into this or that sprint cycle and when problems preventing what feels like forward motion are discovered, crap just gets thrown against the wall until something moves forward a step. Things ship late, nobody can schedule anything, budgeting and hiring plans are a mess. One of the defining aspects of being human is that we're capable of thinking a few steps ahead and formulating a plan. The way Agile works in most shops returns us to being mere beasts of coding. Of the places I've seen, the difference between success and endless-iteration-failure-followed-by-multiple-rewrites-from-scratch-before-delivery-because-look-at-all-the-lessons-we-learned-along-the-way is that somebody sat down before any work started and defined the goal, timing, budget and expectations. There's some planning, some mockups, some interaction prototypes, etc. at the start that's hard work to do, but defines the goals and vision the work effort should be going towards...the "shape" of the work. Goal driven development is something that seems to be missing in too many shops. It's hard though, because you don't want to end up in the waterfall trap again, but you don't want to end up in an directionless iteration morass either. It takes experience and lots of road miles to understand that balance and succeed.

UK-AL 12y ago
Agile is planned, just on a shorter time scale and gets more vague over time. Sprints have end goals, and so do epics. Waterfall had big upfront design, which meant every time a manager asked for a change it screwed up the design and had to modified which took a lot of time. So people didn't ask for changes and the resulting software didn't do what they really wanted. Iterative development tries to embrace change, it's an attempt at controlled change.
enraged_camel 12y ago

lifeisstillgood 12y ago

For me, and I think i just worked this one out, Agile can only work in a collaborative, open, high trust environment. If you have that, pretty much anything you do will be agile. If you don't there is bugger all you can do to get to agile without fixing it. Personality conflicts, leaders who shut down discussions, developers who just want to do what they are told and collect a pay check, this and more will screw you up. So go for slow development, constant learning, some humility, and a company that won't fire you for looking like you are just "thinking about it"

tonyedgecombe 12y ago
This is true, I suspect that companies that fail with agile will fail with any and every methodology.

InclinedPlane 12y ago

For those who aren't aware or didn't pick it up, Dave Thomas is one of the handful of originators of the "Agile Manifesto". Other than the obvious (profit motive in selling snake oil) there are some common problems that make evaluating and applying process difficult. One of the biggest problems is actually the effect of highly talented teams. If you have a team of skilled folks then they will often succeed independent of process. If they are burdened with unworkable processes they will quite often work around them, bend them, or ignore them and get shit done regardless. Which makes it difficult to tell when you've got a good process in place as well. Another major problem, alluded to in the video, is the desire for brain death in management. People want silver bullets, they want universal advice, they want policies that don't require effort or thought to achieve results. You see something similar in tech security, everyone wants to hire a unicorn/jesus who swoops in and fixes everything, like a landscaper who comes in on the weekends to do yard work or something. The reality is that development, and security, requires effort at every level. It requires conscientious application of skill and judgment to get good work done, and that's true at every level. You can't simply apply one or another process and then switch your brain off and hope for the best.

mattmurdog 12y ago
Very well said.

ItsMattyG 12y ago

Agile is good in uncertain environments with frequent project changes, but not in other situations... Simon Wardley has a good model that seems to work reasonably well: http://blog.gardeviance.org/2014/11/how-we-used-to-organise-stuff.html http://blog.gardeviance.org/2014/11/how-we-used-to-organise-...

chriscareycode 12y ago

I love this talk by Erik Meijer on the topic http://vimeo.com/110554082 http://vimeo.com/110554082

oldpond 12y ago

I think I know who Dave is making fun of, and yes, there are plenty of stakeholders who are hopelessly lost and willing to "buy agile" to make it look like they are doing something. Just get all the useless project managers to call themselves scrum masters and hold daily stand-ups (which in the old days we called micro managing) and hope and prey that something works... I've been in this business since the 80's and a consultant since '98, and I can say that although I love the agile approach, busted organizations and "enterprise" consultants are killing the ideas. Agile is a software development approach, not an organization development methodology. The last gig I was on the customer tried to "go agile". All the departments started holding daily stand-ups which quickly became silly repetitions and micro management kill-zones. Picture this, the daily help desk standup: "Yesterday I answered phones, and today I plan to answer phones again." Everyone was doing 'agile' except the software development teams. Maybe Dave is right, all you can do is laugh about it. And then put it all on the cloud.

InclinedPlane 12y ago
At one of my past jobs we did "agile" or "scrums" or whatever they called their bastardized version of an agile process. At one point this involved standups which included over a dozen people and typically lasted between 45 minutes and an hour and a half. Everyday.
- deleted 12y ago
  [deleted]
- EdwardDiego 12y ago
  Gah. So let me guess, the "stand-up" ended up with a bunch of people sitting down, because after all, you can't stand up for that long...? ...the number of people who miss the reason for standing up (to force brevity) is astounding.
  - InclinedPlane 12y ago
    Nope. Everyone stayed standing the whole time. This was at a multi-billion dollar online retailer who shall remain nameless (though it's pretty easy to figure out).

InclinedPlane 12y ago

(As much as I hate to post twice on a thread, I've had some thoughts that I haven't seen expressed yet.) I think a lot of folks are missing some important perspective on the origin and rise of "agile" and the current state of process in the software industry. So let's take a quick trip back to the bad old days before agile to get a sense of what software development was often like back then. First off, a lot of software was developed "out of house" so to speak, as works for hire by consultancy type companies. There would be extensive negotiations between the customer and representatives of the development company, the end goal of this process was typically a specification and a timetable that was then mutually agreed upon, through a legally binding contract, as to what would be built. Next, the development company would take that specification and come up with a design that would be able to match the specs. Then that design would be sliced up and handed out to various teams and eventually down to individual devs. After the individual coding was done it'd be integrated together and compiled into a working product. The product would then be passed off to QA to test in order to make sure it didn't have any bugs and that it matched the spec. After that the product would then be passed on to the customer to use. And everyone lived happily ever after. Of course, there are a few problematic aspects to this process. Namely: everything. Usually what would happen is that the spec and/or the design would be unrealistic or impossible to implement, and wouldn't be what the customer actually wanted regardless. Often this was handled by acrimonious bouts of negotiation, often involving lawyers. Meanwhile, attempting to build anything that worked at all using this sort of process was a nightmare. When the software was integrated only at the last minute there were always a million new problems discovered. With such "big-bang" integrations a lot of effort is spent spinning away just getting the software to build and work at all. Meanwhile, when QA is the last step before handing the product off to the customer that means that defects, especially design defects, have had the greatest amount of opportunity to fester and take the most effort to remove. And, of course, the chance that the project would chew up many staff-years of effort without actually producing anything of use whatsoever was quite high with this model, since actually building software was a fairly late step. In the face of all these very fundamental problems with the venerable "waterfall" process model a lot of new process ideas started to gain traction, more or less culminating in the "agile manifesto". The core idea of agility is to use iterative development, continuous integration, and open lines of communication to keep on track. The "customer" (or "stake holders") can see the direction of the product mid-stream and have many chances to correct communication errors or even errors in their original conception of what they wanted. The software is always being built and always being tested so integration overhead costs are much less severe and defects are spotted much closer to where they are introduced, making them easier to fix. The software is routinely in a "shipable" state with a continually evolving subset of the "final" featureset, this lets the customer see how close the developers are to the schedule and also dramatically reduces the risk of not shipping anything at all. The developers can always time box the release and ship something of value, even if it wasn't what was originally intended. And so on. The thing is, today we live in a fundamentally agile world of development. Waterfall is so far from the norm it's essentially extinct. The very idea of futzing around with nothing but requirements and specs for months or years before bothering to write a line of code is so anathema to the current standards of software development it seems ridiculous. Everyone knows you start with a skeleton and you flesh it out iteratively. The idea that you'd have your code base in an unbuildable state, let alone an unusable product state, for more than a few hours or days at most is similarly seemingly preposterous. The fact that the basic principles of agility are now so ubiquitous that they are like a mold infecting every nook and cranny of the software industry is still unsatisfactory for a lot of folks. Management wants a process they can sink their teeth into. They want something that requires no effort on their part but seems like a silver bullet that can solve any problem. They want gadgets and tools. They want a process that they can leverage to justify all of their bad behaviors while removing accountability from themselves. And that's what agile-the-noun has become. Not agility, but rather an excuse for micro-management. A way to plan without planning. A justification for short-sightedness and disengagement. A convenient rolodex of excuses for why everyone but management is at fault for being late or building something bad or broken or that no one wants. You either die a hero or you live long enough to see yourself become the villain.

serve_yay 12y ago

He is quite a speaker, but really the first 15 minutes is a standup comedy routine for project managers. You can skip that part.

dmux 12y ago

I'll just leave this here: http://seir.sei.cmu.edu/sheard/Life%20Cycle%20Silver%20Bullet.pdf http://seir.sei.cmu.edu/sheard/Life%20Cycle%20Silver%20Bulle...