10 ms·
Acephalic Agile: Worse than Waterfall?
- deleted 8y ago[deleted]
- Nomentatus 8y agoI think the author left out something. Agile involves getting the customer deeply involved from the start, so that after one or two spins of cycle, they have a more sober view of what the magicians are doing, and how little they, the customer, get to ask for in the real world, if they want the project to be done this century (and they do.) Done well, it's the equivalent of sticking your dog's nose into the mess they made on your rug; where dog=client.
- djstein 8y agoInteresting perspective on what Agile is supposed to accomplish. From my anecdotal experience, it does not however, nor do I believe it will change.
- s73v3r_ 8y agoThe issue is one of buy-in. For it to work, everyone involved, client, management, development, qa, design, everyone has to be on board with the agile way of doing things. Without that, you have development working in the agile manner, believing in good faith that everyone else is too, and then the second a snag gets hit, then that all goes out the window, and development is usually the one left holding the bag and punished with overtime.
- Nomentatus 8y agoRight. Sturgeon's law, I guess. Agile Theatre is more common than Agile, just as security theatre is more common than security. So I'd say both above comments are accurate.
- jiveturkey 8y ago> I think the author left out something. He made it quite clear, it's his conclusion: Now, each iteration offers not only the chance for project management to be exercised, but more specifically, to ensure that it is exercised by capturing the appropriate, timely information from all the appropriate stakeholders. Emphasis mine.
- Nomentatus 8y agoNot only is that vague, it's not the same thing. Polling stakeholders isn't embedding or involving.
- deleted 8y ago[deleted]
- Spooky23 8y agoThe magic of “agile” is that partnership with the customer and shared accountability. That’s difficult to codify, especially in contracts for delivery. “Agile methods” more often than not translate into hiding a complete lack of planning in a bunch of mumbo jumbo.
- abritinthebay 8y agoIt doesn't have to. It would be ideal of course. The point is that there are always stakeholders and product owners - it just makes that explicit. If the PO is acting as a proxy for the stakeholder (customer in this case) that's ok. Of course the PO might be wrong... but with small iterations that should be found out quickly and adjusted for.
- Nomentatus 8y agoPrinciple 4 of twelve: "Business people and developers must work together daily throughout the project." https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/ https://www.agilealliance.org/agile101/12-principles-behind-... It would be odd if "business people" just meant the developers' upper management within their firm; supervising costs and parking spaces; but not those without a stake in using the software that results, say.
- abritinthebay 8y agoBusiness people doesn’t mean customers however. Which was my point. In fact the only time the customer is mentioned is in principle one: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Business people absolutely should be involved - product owners & stakeholders (or a proxy for them). That’s fundamental but again: business people != customers. You seem to think stakeholders/product owners are devs direct managers too. That’s rarely the case, if ever, on any functioning agile team I’ve seen. They’re orthogonal to each other.
- Nomentatus 8y agoI think I answered this possible objection, but you've ignored that. Also, I made a distinction between stakeholders and devs direct managers, rather than conflating them. I don't believe I can be of further assistance to you.
- abritinthebay 8y ago
- coldacid 8y agoQuite the editorialized headline compared to that of the actual article.
- jiveturkey 8y agoHN title is clickbait. Article title is much better. The article makes a very reasonable argument, however I wish he wouldn't try to introduce some new term, Agile "governance". He's just describing what we already know -- that Agile isn't Agile and care must be taken to institute it correctly. via "governance" as he calls it but this isn't a new revelation.
- bb88 8y agoMods, please fix the title.
- greglindahl 8y agoThe entire thing is a thought experiment; of course it's easy to think up nightmare scenarios for Agile development. It would be much more interesting to read about actual disasters.
- amiga-workbench 8y agoIts a hypothetical that I have experienced on several projects now, project managers can have a totally warped understanding of agile in that they think they can change course at any point and it won't have any resulting costs in either time or complexity.
- greglindahl 8y agoSounds like you could have written a much better article than this one, then! Cautionary tales are much better when they're real and not imaginary.
- sctb 8y agoThanks, we've reverted the submitted title to that of the article.
- madeofpalk 8y agoIm curious, what was the original headline?
- dfischer 8y agoDevelopers should abandon agile: https://ronjeffries.com/articles/018-01ff/abandon-1/ https://ronjeffries.com/articles/018-01ff/abandon-1/
- connorelsea 8y agoNot the real title at all. Hope mods change it
- snarf21 8y agoOne thing I've learned over the years about process is that a "bad" process that is followed consistently and with buy-in from everyone involved will always out perform the "good" process that is followed haphazardly or with only lip service buy-in. I liken this to diets. Paleo suggests not eating bread (among other things). However, not eating bread doesn't mean you are doing Paleo. The benefits of Paleo are intended to be realized via a systemic application. So whether it is agile or diets, make rules that work for you (and yours). Then stick to them. Periodically review if they are working. If they aren't change the part that isn't into a new rule and then repeat. There is no one size fits all in these things.
- rvense 8y agoAgile is a religion: Some smart, well-meaning people write down a couple of brief, broad suggestions on how to do better, and a few years later it's been twisted into an industry of people who want me to pay them for telling me that I'm living my life wrong.
- diminoten 8y agoYes, and much like a religion, there are people who refuse to see any positive elements to it, despite those elements being numerous and obvious. Also, there are larger truths that live at its heart which make discussions about the topic difficult because if you're seen as disagreeing with some of it, you're seen as disagreeing with all of it, even if you don't. What a good analogy!
- rvense 8y agoDefinitely agree! I often quote from the manifesto. Especially when dealing with Jira. I've been meaning to read the original Waterfall article as well, I've heard it's good.
- hinkley 8y agoIf you ask the home run king how to hit more home runs, you'll get a lot of advice. Some of it may actually be accurate. But I believe that if you really want to know how to hit home runs, you want to talk to the king's trainer, not the king. The king has no perspective. He has mostly only worked with himself. To put it bluntly: he's too wound up in his own bullshit to be objective. Software Developers don't have trainers. Ask a successful person how they got that way and they have a sample size of one, or a handful. All you'll get is speculation.
- draw_down 8y agoMan, what a shit idea of what religion is.
- sailfast 8y agoI liked this article until it got into the charts and didn't really outline what the governance points actually entail in terms of work. I'm also missing how the bottom part actually gets you closer to the goal at the end unless you explicitly make setting that goal part of your governance / planning / project start which wasn't really mentioned. I gather from the article's initial paragraphs that these "Governance" point is really the team getting input from all the normal stakeholders and creating the backlog of work themselves? This makes all the sense in the world - getting technical folks involved in discussions is key. What I would like to see added are concrete steps / workflows that these technical teams have found that help make these governance points effective without eating up a lot of time, and what practices they used to ensure that the project goal / direction / outcomes were decided upon up front. I personally think Agile Roadmapping / Storymapping with the whole group can go a long way toward ensuring whatever you build is going in the right direction. From there, you'll want the team to work with the product owner folks and keep a tighter grip on the backlog toward that direction and good things can happen.
- jcelerier 8y agoMore generally : for any given X and Y, there will be enough instances of X being better than Y and Y being better than X to feed both sides of internet debates
- majke 8y agoPerhaps I'm not an expert, but I always felt there are things left out by the more popular methodologies. This article scrapes the surface: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ https://michaelochurch.wordpress.com/2015/06/06/why-agile-an... > "The worst thing about estimates is that they push a company in the direction of doing work that’s estimable. This causes programmers to favor the low-yield, easy stuff that the business doesn’t actually need but that is 'safe'". > "Good engineers want to work in engineer-driven firms where they will be calling shots regarding what gets worked on, without having to justify themselves to 'scrum masters' and 'product owners' and layers of non-technical management" > "Scrum [is] tailored toward the body shops where client relationships are so mismanaged" > "Open-plan offices are the most egregious example. They aren’t productive" > "[Scrum is] Like a failed communist state that equalizes by spreading poverty" There is more. In "pure scrum" it's not obvious how to account for refactoring, developer experimentation, improving infrastructure (or creating one from scratch!), making tests better. Product driven things - sure, can be driven by scrum. But what to do when work is driven by engineering?
- gaius 8y agoRight, Agile is for outsourced/offshore teams cranking out intranets or shopping carts or adding another minor feature to an existing codebase written by someone else. Like maintenance on a legacy app. The kind of work that good engineers thrive on - a hard problem starting with en empty Emacs buffer - is something that the methodology merchants have never experienced themselves. The only product they ever shipped is the methodology itself! I say this as a one-time “certified scrum master”.
- prepend 8y agoThis is a pretty tough statement to defend. Take a look at the myriad of open source projects, or just limit it to Apache’s http://apache.org/index.html#projects-list http://apache.org/index.html#projects-list and you’ll see a bunch of “empty emacs buffer” projects with a long audit trail of agile development. Not necessarily scrum.
- williamdclt 8y agoThe article foundation is fair: "Agile tools provide a steering mechanism, not a homing device". But I'm not sure what point it's trying to make after that? "Use an Agile framework"? Just "be aware of it"?
- rossdavidh 8y ago"At least in Waterfall if you did a good job of designing the project, and if you stuck to the spirit of the method, you were to some extent insulated from management noise..." I think it's an interesting article, with good points, but fundamentally I have to disagree with this statement. Empirically, it just isn't true, in my experience. It just means that all those changes by the customer to what they wanted, that the devs object to and management (which has to meet the customer face to face) always in the end agrees to, happen at the end, when they are more difficult, because up until that point the project wasn't "real" to the client, and they really couldn't tell you what they wanted until they saw that what you built wasn't it.
- vannevar 8y agoPeople constantly confuse agile development with software design. Agile is not, and was never intended to be, a way to design software. It is a way to implement software. How you design it is up to you, though agile certainly encourages you to involve all stakeholders from the beginning, and to make design changes incrementally throughout development as circumstances warrant. But it is not a design methodology.
- vannevar 8y agoIt might be useful for the anonymous downvoter to contribute to the discussion. Why do you disagree?
- maxxxxx 8y agoThis is the same extreme reaction people had previously to waterfall. Any methodology fails if it gets applied blindly and wrongly. You have to be willing to adapt it to your specific environment until it works for you. It would be a huge mistake to go back to waterfall just because people perverted Agile into a micromanagement method. The same people who can't make Agile work will also fail (and have failed for a long time) with waterfall or any other method because they refuse to adapt to reality and instead want work instructions they can follow without any thought. The same thing goes on with OOP. It started out as a good addition to other programming styles, got turned into a religion ("you can't do this. It's not OOP.") and now into a pariah (FP is next to go through this cycle). In the end stupid people will mess up anything they touch and good people will adapt things until they work.
- monocasa 8y ago> This is the same extreme reaction people had previously to waterfall I mean... there's no correct application of waterfall. The whole waterfall process comes from a paper as an example of how not to run an engineering project.
- maxxxxx 8y agoI have seen projects where there was a very good specification upfront and the developers pretty much just had to work through it. This is not always possible and requires a very good understanding of the problem but it can work really well.
- jaggederest 8y agoIt comes down essentially to that understanding. For well-understood problems waterfall might even be the best possible method. It's only for not well understood problems that it fails so completely. In software, in my opinion, fewer problems are well understood at the moment, and so we tend to avoid waterfall. However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems. The same is true for many other real life "waterfall" processes, like buildings, or bridges.
- vannevar 8y agoYou can maintain a waterfall-style project plan and use that to feed stories into your agile sprints. If something needs to change, then you feed that back up into your master plan, just like you would if you missed a milestone. The difference is that, with agile, you get more continuous feedback and you explicitly model iteration in your plan (since if you're doing it right, you're delivering progressively more capable versions of the entire system and not just components to be integrated at the end). Nothing in agile precludes long-range planning, or taking deadlines into account.
- billysielu 8y agoShocker. Managing requirements well results in successful projects.
- joker3 8y agoStill no silver bullet, huh? Who would've thought?
- Robin_Message 8y agoI definitely agree with the author. Agile is increasingly being used to justify having no plan and just getting devs to do whatever seems most important to a "product owner" each sprint without the real customer feedback that is an essential part of agile. I blame scrum for commodotising and cargo-culting all the good stuff out of agile. I'm writing a blog series on the problems with Scrum here: https://www.lambdacambridge.com/blog/2018-05-how-scrum-destroyed-agile https://www.lambdacambridge.com/blog/2018-05-how-scrum-destr... Interestingly, DSDM, which the author uses, doesn't get much attention, but was there from the beginning of the Agile movement.
- madeofpalk 8y agoDon't you think the blame here on the methodology is misplaced? It just sounds like a bad team/company, that'll perform just as poorly with "waterfall"
- amiga-workbench 8y agoA bad team will always find a way to pay lip service to any process or workflow you throw at them and still fall back on their old dysfunctional habits. Its never the process at fault, its the gaping disconnect between the specification of that process and the implementation.
- s73v3r_ 8y agoI don't disagree, but I have to think that agile/scrum with a bad company just exacerbates the pain.
- maxxxxx 8y agoTotally agree. Bad management will mess up any methodology and good management will make almost any methodology work. Good people will just adjust things until they are OK.
- mianos 8y agoThe key is, if the 'product owner' is not the end user, they are not the customer. They are often beholden to the more senior management and are more focussed on making their bosses happy with progress reports and demonstating how well they are performing. All this, while playing a theatre of customer centric focus and high velocity.
- dragonwriter 8y agoCurrent HN title is both not the source title and a misrepresentation of the point of the article. Both the title and body criticize “acephalic Agile”, which the author defines as the use of Agile tools without Agile governance. This is not arguing that “Agile is worse than Waterfall”, but at most “a particular mode of quasi-Agile is worse than Waterfall”. (Given that the Agile Manifesto doesn't say anything directly about tools but entirely lays out a philosophy addressing governance, I'd actually argue that “Agile” tools without Agile governance aren't anything like Agile, and aren't even really Agile tools; Agile tools are tools chosen for a particular tasks through Agile governance, at a level higher than the governance level this price addresses, and applied within an Agile governance process at the level this piece addresses, which is not to endorse the particular governance approaches in this article or it'd horrendous strawmanning of Waterfall, which inasmuch as it is a real model, is an iterative model of exactly the type this piece is advocating.)
- skybrian 8y agoThe author of the article is missing a negotiation essential to XP, at least: the customer can change his or her mind, but the scheduled tasks are based on developer estimates on how long they will take. You can't make these estimates with any accuracy without the customer and at least some developers talking. Furthermore, customers aren't likely to pick something that the developers have estimated will take a long time, unless it really is that important to spend that much time on it. Also, large tasks need to be broken down into smaller tasks to get decent estimates, which means knowing roughly what needs to be done. If the job isn't obvious, something quite like traditional planning needs to happen there. The planning difference is really for smaller changes that don't have far-reaching consequences.
- simon_000666 8y agoClassic consultant move. Trash talk current status quo, rebrand old solution and package it as the holy grail and make $$$ selling your services. What he proposes will also always fail because it is a process dictated from the top down - hire expensive consultants to tell management what to do then dictate solution to rest of org. Unless the solution emerges bottom up it won’t make jack of a difference.
- Yhippa 8y agoI was on board with the article, head-nodding all the way, until I got to that part.
- davidkhess 8y agoI'll never understand why the software development community as a whole seems to have such an NIH attitude to software project management. Meaning, why aren't our people studying what works in other industries and figuring out how to apply it to our industry? Is it some conceit that software development is somehow truly unique compared to the problems and concerns faced by other industries? That's dumbfounding to me if so. Our industry is barely 70 years old and hardly anybody seems interested in stealing the best ideas and practices from other industries that in some cases have been around for thousands of years.
- mattmanser 8y agoIsn't that what waterfall was? Replicating building a house? Gather requirements, design it, plan it, build it.
- davidkhess 8y agoPartially. But I think waterfall has (at least) two major weaknesses. The requirements are textual. They should be visual like a blueprint. A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete.
- davidkhess 8y agoIn other words, waterfall didn't go far enough. Instead of discarding it, we should have continued to improve it.
- balfirevic 8y ago> A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete. May I suggest you look into this agile thing?
- nartz 8y ago"In what follows I’m assuming that we’re talking about a project rather than merely a production line for rolling out bug fixes and features. In the latter case you can use Agile tools like Scrum to deliver code incrementally, and come to no great harm. In talking of a ‘project’ however, I’m thinking of a larger program of work in which an entire solution has to be designed and delivered, (more or less) complete. Such projects have distinct beginning, middle and end phases, all of which must complete successfully if the project is to succeed." This doesn't make any sense and is contradictory. It seems you admit that Agile works for "Rolling out bug fixes and features" and to "deliver code incrementally" without "coming to great harm". Then you say that this is somehow different from "an entire solution [that has to be] designed and delivered". What precludes "an entire solution" from being developed in an Agile fashion? Presumably, agile would be to build out the skeleton, and incrementally add small working features over time in increments such that at the end, you had working software that was what you wanted. You'd put your skeleton it into beta use as soon as possible once it provides any value, and get frequent feedback to iterate.
- dfee 8y agoWe’ve entered the trough of disillusionment, for sure. https://en.m.wikipedia.org/wiki/Hype_cycle https://en.m.wikipedia.org/wiki/Hype_cycle
- wink 8y ago> but at least this way if the developers are working a late shift because of a rash promise they’ve made, they are the authors of their own misfortune, which is easier to bear. It’s a social contract: we give people control, they accept responsibility. Congratulations, your lead developer is now a middle manager. I've never been a fan of "committing to a certain amount of stuff done by the end of the week" as in scrum sprints. It's a zero sum game. Sometimes you do 3 days' worth of work in an afternoon and sometimes finding an extra semicolon takes 2 days...
- accnumnplus1 8y agoTo your first point, I had a very productive project where instead of as in the article the devs become managers, our project manager was brought very much into the dev team, almost as a tester, using the product daily. He became attuned to the pace of development and never over-promised anything. To your second point, I've had projects where I simply assigned a day to every task, and it turned out remarkably accurate.
- InclinedPlane 8y agoIt's impossible to talk about Agile vs. alternatives today because the fundamentals of Agile development are just the de facto way all software is developed now. Continuous integration, regular builds, iterative development cycles, etc. Even people who think they would be doing "Waterfall" today would do so still using these techniques. The reason why Agile techniques were created was due to a serious crisis in software development. Projects were failing, lots of them, in ways and with a severity that few software projects today fail. At its core Agile is very simple, it's a system of hedges against failure: Always have software that is in some sense in a usable state (builds, runs, passes smoke/BVT tests). This makes it very difficult to complete a project without anything to show for it. Integrate early and often, don't wait until the last minute. Integrate skeleton frameworks together and then iteratively add features. This helps avoid having a huge amount of unknown risk due to integration failure at the end of a project, mitigating that risk translates to more schedule reliability and higher chances of project success. Also, working iteratively helps ensure that progress is constantly being made rather than potentially wasting lots of dev-cycles on work that may not be ultimately viable. Keep the "customers" in the loop. With a version of your software that actually runs they can keep up to speed on the latest features and capabilities as they are actually implemented. This makes it much more difficult to ship something that is wholly different from what the customer actually wants. This isn't a sure-fire recipe to avoid shipping the wrong thing, but it is one of the most reliable, achievable, and cheapest ways of doing so. It's certainly preferable to getting a room of lawyers and engineers to hammer out a contract that embeds a precise specification for the software to be built. Besides which, a lot of software today is not built on contract, it's built for the market. The cult of Agile is a serious problem, and people who think that any management technique can actually protect them from not doing any management work is an even bigger problem. Agile's core problem is that it can serve as a conduit for micro-management and it can make it hard to sell doing research or expensive (but valuable), long-term investments. But the solution isn't to abandon the concept, the solution is to work better.
- spking 8y agoI think Zed Shaw proposed the best system: http://programming-motherfucker.com http://programming-motherfucker.com
- geebee 8y agoI always refer back to the original agile manifesto when I read about how badly things have gone. http://agilemanifesto.org http://agilemanifesto.org What a beautifully simple document, written in clear and plain language. Now consider a paragraph like this one: "How are matters improved by Agile? The benefit of Agile is that, by splitting the project into sprints, we have more opportunities to tweak the project vector, to exercise governance, altering the project’s course. Each sprint offers new control points (during both planning and acceptance), at which we can amend direction. Splitting the project as a whole into a series of such sprints offers us a corresponding number of opportunities to reorientate. Each iteration offers more chances to retune the project. We have much greater granularity of control, and more opportunities to exercise that control." This blog post is, frankly, full of this sort of language. "tweak the project vector". "exercise governance". "control points to amend direction". opportunities to "reorientate" (reorientate? yes, it is a word. it means, according to the OED, reorient). I'm kind of curious, this is HN, there are dev here. Does this sort of language make you eager to sign onto a development team? I understand that lots of things have gone wrong with "agile", but the language we use to talk about it seems to have degraded badly, and in many ways, this tells the story better than almost anything else.
- amriksohata 8y agoAgile has become a recruiters and highwr management's marketing term, look we're agile join us. But they never have real buy in or understand what it means.