31 ms·

Agile's early evangelists wouldn't mind watching Agile die

• tabelle 6y ago
  why are people still talking about agile?
  • werber 6y ago
    Because we’re still dealing with it everyday. I can’t even count the number of basic trainings I’ve gone through and then seen everything they preach go directly out the window
  • Glyptodon 6y ago
    Because many companies are still transitioning to the realization that software is a core part of their business even if their product is physical.
  • 0x262d 6y ago
    it's fully mainstream. my company (mid sized tech company far from any coast) is adopting it for everyone right now.
  • Frost1x 6y ago
    As many pointed out, unfortunately most businesses employing 'agile' don't seem to be 'agile' at all from management side, so we still have all sorts of broken practices used industry wide which are absolutely idiotic. I'm working with a team that the PM follows Agile like its a silver bullet solution but is obviously terribly flawed.
• viburnum 6y ago
  Corporate agile is a mixed bag but Extreme Programming is still good though.
  • swagtricker 6y ago
    I fully agree. In general, any flavor of agile for software development that doesn't include the engineering focus that Extreme Programming's technical practices bring in (fast feedback, refactoring, good testing & design, CI/CD deployment, team ownership of the solution - weather you pair program or not) is doomed to become intractable legacy after 12-18 months at the most optimistic.
• jahaja 6y ago
  I guess it's hard to keep methodologies from being co-opted by management for their own ends, since they do after all have the "power".
  • kradroy 6y ago
    I implemented Agile scrum on my team at the behest of my organization. I did it enthusiastically at first, because I thought it might make a difference. My opinion changed within the first 6 months. I think it's a waste of time. Our stand-ups are pointless because they're just status updates. Not much of consequence can happen in 10 minutes anyway. I ignore our metrics at the end of each sprint. They're meaningless. Our retrospectives are largely useless other than giving shoutouts to team members. I feel the sprint structure leads to Parkinson's law. This situation, however, is perfectly normal because Agile advocates "people over processes." My team doesn't give a shit about the Agile process, so it's mostly like forced physical training but without the fitness benefits.
    • swagtricker 6y ago
      Scrum should at best be viewed as training wheels for agile teams. Not the end state. Good teams abandon scrum for Kanban / Lean concepts once they start building good collaboration structures, better communication with business, earn trust by delivering and recognize (as you point out nicely) that the sprint timebox is artificial B.S. in practice. I think the Parkinson's law can be a common trap for teams to fall into with the Sprint timebox malarkey.
      • vpeters25 6y ago
        This 100%. One of the reasons people hate Agile is because they miss this point and keep micro-managing.
  • corpMaverick 6y ago
    Managers trying to control engineers. I don't know how we are OK when people in charge don't understand what they are managing. Agile was an attempt to take control back to engineers but it was co-opted.
• aeturnum 6y ago
  If you should meet Agile along the road, destroy it!
• raiyu 6y ago
  Can we just replace agile, and every modern management practice with some mix of common sense, talking to the customer, talking to the team, and being able to voice concerns to upper management where people actually listen instead of running their own agenda? =]
  • hn_acc_2 6y ago
    But this is the root of all these issues... Because everyone has a different perspective that underlies their "common sense," so this system of unspoken agreement just falls apart. When you throw in the incentives of compensation and career advancement, politics and human nature are bound to corrupt the process further. This is why codified process will always be better in the long run for most companies, because it's the only tool possible for combatting this
    • asplake 6y ago
      ...until codified process becomes the problem. It never ends!
      • brazzledazzle 6y ago
        People that corrupt a process are often the ones it’s designed to stop. It’s not even done with ill intent more often than not. How do you create a paradigm or process that can be amended adapt to a persistent threat without that amendment process itself being used as a tool to corrupt it?
        • asplake 6y ago
          I completely agree that you don’t need to assume ill intent. But by that same token, the fact that a paradigm or process isn’t invulnerable does not mean that it shouldn’t be used. Bureaucracy, heavyweight process, and all rest are ways that systems protect themselves. Wasteful though, which is why new paradigms such as Agile come along. Now the Agile ecosystem has become corrupted by a process not comparable to all the above. Not solvable by those means either. It’s a toughie.
• AzzieElbab 6y ago
  Here is the talk by Dave Thomas https://en.m.wikipedia.org/wiki/Dave_Thomas_%28programmer%29?wprov=sfla1 https://en.m.wikipedia.org/wiki/Dave_Thomas_%28programmer%29... https://youtu.be/a-BOSpxYJ9M https://youtu.be/a-BOSpxYJ9M
• fourseventy 6y ago
  I like the development methodology laid out my David Cancel in his book Hypergrowth. I like it because he has founded several large successful companies and actually used this methodology successfully. Unlike most of these "agile gurus" who have never sold a product to a customer in their lives.
• empath75 6y ago
  I was saying in a team meeting the other day that using jira stories as any kind of performance metric is wrong-headed and counterproductive and metrics should focus on the business value provided by the team and people looked at me like I grew a second head.
  • adamsea 6y ago
    Two heads are better than one! ;)
  • bob33212 6y ago
    I had a situation where the CEO was bringing up complains from the PM to me about how there were so many Jira issues in the back log that I should have been hiring more people. I said that it would take me 5 minutes to go into Jira and close out all the existing issues if that is what they are worried about?
    • deleted 6y ago
      [deleted]
    • karatestomp 6y ago
      I've written something similar on here recently, but to repeat: I am, at this point, pretty sure that trying to combine manager-facing and team-facing planning/tracking/task/reporting tools into one thing is fundamentally a bad idea.
      • empath75 6y ago
        The problem is that jira gives you a unified interface into all the stories that all your teams are doing, while not doing anything to track the business value they’re providing.
• brightball 6y ago
  Ultimately, people need agreed upon terms for communicating planning and expectations. That's it. The more people are involved, the more complicated the process gets and all of these approaches evolve out of trying to find an agreeable and effective way of doing it so that everyone doesn't have to figure out a new solution every time. As much of a buzzword hell as it is, I really believe that Scaled Agile Framework (SAFe) is the closest thing to the right balance of trade offs.
• RcouF1uZ4gsC 6y ago
  > At the time, software development was suffering from a mistaken belief: that building things fast and building things well were fundamentally opposed. I thing “good, fast, cheap; pick 2” is still generally valid.
  • namdnay 6y ago
    Sometimes I’m not sure you can have just good and fast, however much money you throw at it. Some things just take time to work through.
  • koonsolo 6y ago
    Developers are your biggest cost, so I never understood why fast and cheap would be opposed to each other. And if you buy off the shelve, most of the time it's both faster and cheaper than building it yourself. So I always felt that fast and cheap go hand in hand. I think the triangle is: - features - quality - cost (=both price & time) Edit: I forgot to mention that you cannot just throw more engineers at a problem to make it go faster. There is such a thing as an optimal team size. Another edit (sorry it's Friday evening here;)): The faster you can get it done, the cheaper it will be.
    • EdSharkey 6y ago
      We have to peg quality with rigorous testing or else cost (time spent) will be variable upwards to infinity (due to accumulation of untenable technical debt). Therefore, if cost must be pegged due to limited time/funds and quality must be pegged due to existential risk then quantity/richness of features must float and be flexible. All good product owners will learn this truth eventually.
    • OrangeMango 6y ago
      > Developers are your biggest cost This is unlikely to be true. Bad decisions are your biggest cost. An employee has a "return multiplier" - for every dollar you spend on them, what is the return to the business? Sometimes it is high. If so, the developer is very cheap. Sometimes is it low, or negative. If so, the developer is expensive. Why would it be high or low? Part of that is developer skill, but mostly it is how well your organization runs itself and makes decisions.
• vbtemp 6y ago
  For the past several years now, each time I join a new team or project, my first objective is to detach and destroy the "Agile" process workflow. When you finally liberate a team from Agile, it's just breathtaking how much you can focus on delivering working software that gets deployed with quick iterations that's closely aligned with the business and customer's needs. When free from the tyranny of Agile, teams can be effectively self-organize, remove micro-managers, and quickly adapt to changing needs and requirements. My experience is that staff are usually much happier, more productive, and less stressed once agile is gone. I mean contemporary Agile as pushed by corporations and those awful "coaches" (who never seem to be actual developers) --- if you were you design a system whose end goal was making great developers unhappy, unproductive and locked into a dysfunctional system, Agile would be it.
  • trimbo 6y ago
    > it's just breathtaking how much you can focus on delivering working software that gets deployed with quick iterations that's closely aligned with the business and customer's needs That's literally the agile manifesto. "Scrum" is one implementation of what agile was trying to achieve. Maybe that's what you're thinking of?
    • vbtemp 6y ago
      > That's literally the agile manifesto. I know, that's the irony. Agile as pushed today ends up with the compete anithesis of that. It's the difference between "Agile" (Capital A), and "agile"
    • balfirevic 6y ago
      Parent's post so closely resembles the agile manifesto that it's got to be on purpose.
    • Jtsummers 6y ago
      There's Big-A Agile and agile. The manifesto is really the latter, the former is a set (different depending on where you are) of very specific practices that neglect the principles in the manifesto (though, typically, they were derived from them originally). Read SAFe Distilled or SAFe 4.5 Reference Guide for what happens in large enterprises (god SAFe is a fuck up). It consists of some good ideas, but also some very explicit practices that don't help in every effort (and sometimes hurt). It is literally the opposite of Agile, which is supposed to be about flexibility. If you want to hear about its "success", just remember it was used for F-35's software... Big-A Agile is based on the belief that adoption of practices is sufficient, and that deep understanding is unnecessary. This is the realm of cargo cults.
• 0x262d 6y ago
  Agile/software engineering practices broadly suffer a lot from the fact that not only is selling software a business model, selling Agile is also a business model, and when you buy Agile consulting it's impossible to disentangle whether it's being sold to you because it works or because it makes that person money. They don't even know because it's their job and they convinced themselves of its usefulness. It can still be evaluated on the merits but IMO this greatly pollutes the speed at which software devs as a broadly conceived community can come to consensus understanding of this. Also I think the comparison to lean manufacturing has always been very shallow. I get the metaphor, I just don't think that human resources in engineering can be optimized like manufacturing processes. This quote is the best part of the article: > "You’d never hear anyone say, 'We help mechanical engineers be agile. That would be silly. And I mean that in the worst possible sense of the word". As for the rest of it, I'm not dying to hear what the person who invented Agile thinks we should do next lol.
  • drewcoo 6y ago
    You lost me at "software is a business model."
    • allover 6y ago
      If you're genuinely confused, I assume they missed out the word "selling" before "software".
      • 0x262d 6y ago
        This is correct and I edited the post to avoid this sort of criticism.
  • thaeli 6y ago
    > “You’d never hear anyone say, ‘We help mechanical engineers be agile." I have literally heard this pitch.
    • ashtonkem 6y ago
• james-mcelwain 6y ago
  I don't know if something is wrong with me, but I simply cannot "decompose" a single feature into 500 different sub-task Jiras. I understand why it would be super cool if software worked like that, but I have to iterate on features holistically and sometimes speculatively. At least for me, software development has never been able to be so cleanly broken down into "first, implement the button" type tasks. But maybe I'm just dumb.
  • virgil_disgr4ce 6y ago
    > but I have to iterate on features holistically and sometimes speculatively. YES. THANK YOU! I've been trying to tell people this for ages. Maybe other people are somehow capable of perfectly predicting every conceivable edge-case and consequence without even starting to work on something, but I can't. I have to start building something in order to see it clearly. And this ENRAGES certain kinds of managers, I have found.
    • deleted 6y ago
      [deleted]
    • anon9001 6y ago
      Managers just want you to deliver on a predictable schedule. Here's how you can solve your problem: Make as many tickets as you can think of, it doesn't really matter if they contain the essence of the problem or not, it just matters that there are many tickets associated with the task. Once you have your tickets, estimate them with as much padding as possible. If the manager complains that you're padding a ticket too much, make two tickets and split the estimate. Once you have a big pile of tickets and estimates, you've bought yourself enough time to do the work. Go do the work, then mark all the tickets as complete. You'll figure out the edge cases as you go, as long as you've made enough tickets and time to do the job at a reasonable pace. If you have extra time left over, get started on the next thing, improve your tooling, or try to help someone else with their tasks. If you don't have extra time left over, make more tickets next time.
      • 6y ago
• commandlinefan 6y ago
  I don't want it to die, I want it to become what it was originally supposed to be.
  • swagtricker 6y ago
    This.
  • kerkeslager 6y ago
    Agreed. As far as I'm concerned, "agile" refers to the principles on this page[1], and ONLY the principles on this page. Not Scrum, not Lean, not Kanban, not Xtreme. The problem is, it's hard to sell a set of principles. To understand people and interactions takes months of working with people: it's much easier to sell them a process or a tool and leave. Customer collaboration requires building a relationship: it's much easier to negotiate a contract for your client and leave. Responding to change requires you to stick around and see what changes happen: it's much easier to sell them a plan and leave. And to arrive at working software you have to get a lot of things right: it's much easier to sell a bunch of documentation for software that doesn't exist, and then leave. Money ruins everything: the reason agile had to explicitly deprioritize the things on the right side of the list in the first place is that all the incentives in a software company push you toward the wrong priorities. The things on the right side of the list are all quick, easy wins that look good on a quarterly report. There are companies who I've worked with who do agile (the principles) well. There's nothing wrong with looking at Scrum/Kanban/whatever as inspiration, as long as you realize that they're just processes: individuals and interactions matter more. There's nothing wrong with using Pivotal/Jira/Trello/whatever, as long as you realize they're just tools: individuals and interactions matter more. [1] https://agilemanifesto.org/ https://agilemanifesto.org/
• flohofwoe 6y ago
  Call me jaded, but that's probably because the cow stopped giving milk, and they need to come up with a new cult/religion/ideology to continue selling books and conference tickets (and consulting gigs of course).
  • drewcoo 6y ago
    Or a new metaphor to sell milk?
  • baryphonic 6y ago
    I think Zed Shaw had the best (or at lest most entertaining) take on being jaded about "agile." Though, fair warning, it is even more vulgar than the URL indicates. http://programming-motherfucker.com/ http://programming-motherfucker.com/ He subsequently gave a talk comparing agile (and open source and consulting and startups and...) to fascist propaganda. https://www.youtube.com/watch?v=c5Xh2Go-jkM https://www.youtube.com/watch?v=c5Xh2Go-jkM I'm not promoting it or saying I agree with it (I actually disagree with quite a bit of it), but it is entertaining.
• tremoloqui 6y ago
  The terms "agile" and "Agile" have two separate meanings. Big 'A' - "Agile" is waterfall re-branded - an excuse for corporate empire building and business as usual. It involves lot's of meetings and not trusting those who build software to do the right thing. Small 'a' - "agile" is the implementation of the manifesto, which basically comes down to smart people figuring out how to work together towards a goal, often by taking small steps. Until the terminology is sorted out the discussion can't help but be confused.
  • deleted 6y ago
    [deleted]
  • a_c_s 6y ago
    Agree 100%: agile practices can be great. Hiring a consultant to teach 'Agile' is easy: the change of practices from something completely top-down to something that empowers the people at the bottom is the hard part and some orgs aren't capable of changing. Too many orgs are built around micromanagement, they don't know any other way.
    • tremoloqui 6y ago
      To these orgs it's a matter of trust and power.
  • Frost1x 6y ago
    Since businesses are the ones who employ software developers, 'Agile' is the only Agile that matters because that's the definition the people who pay money use. We can talk all day about principle philosophical differences and what is/isn't 'agile,' but there has been a consensus from businesses in industry that 'agile' is 'Agile.' Agile has become an excuse for terrible planning and offloading more and more work with ever increasing responsibilities to developers. At some point, enough professionals will reject following these terrible frameworks through different mechanisms. We're definitely not there yet, unfortunately.
    • tremoloqui 6y ago
• vpeters25 6y ago
  Every time I see an "agile sucks" post, I take the time to read it and every time (so far) I have found they blame the process for some key part of agile they missed. Quote from the article: “Way too much of Agile has been not about technology, but about people and about managing things and about getting stuff done — not necessarily getting the right stuff done.” This is the whole point of agile: progress on iterations, inspect and adapt at the end of each iteration. Your team might build the "wrong stuff" for an iteration, realize it (inspect), then make a course correction (adapt). If you end up delivering the "wrong stuff" is because you didn't follow this very core principle of agile. I find it hard to believe these so called "Agile Early Evangelists" can make such a statement. Their background in lean development should have made the familiar with empirical process controls, from where lean and agile come from. My guess the author quoted them selectively to fit the "agile sucks" narrative of the article. Edit: expanded last 2 paragraphs.
  • interactivecode 6y ago
    With these things the reality of agile is within corporate constraints. The Big managers will want to steer the company and dictate deadlines or goals. While the pure form of agile might work the reality of agile causes a lot of friction. Keep in mind though problems also show up with waterfall or young small startups. Its just which flavor of friction/pain project issue you are willing to deal with
  • ebiester 6y ago
    So, it gets complex. I have been privileged to work in a company that really thought about and worked to prioritize the four values on the left. I would follow those agile coaches to any place they wanted. I have been a staunch defender in real life and online, because I've seen it work very well. I also have been on teams with other processes and seen how much worse it can be. I will take the values of agile and push for those, and I'll take the lessons learned such as quick feedback loops, continuous integration, relative estimation, automated tests (which came from people like Kent Beck and Robert Martin pushing them so hard alongside agile), and the good stuff. However, after seeing how badly it can be weaponized against developers, I'm certainly ready to throw out the bathwater, and I think this is what they're talking about. I've seen far too much cargo cult agile and far too much command and control with a light layer of SCRUM. We have agile "coaches" who have never learned to code! They take a set of color-by-number technical practices but don't understand how or why they matter! I had to correct someone's slide that got the four values wrong, and their consulting group apparently had been copying and pasting them incorrectly from presentation to presentation! The values and principles of agile are great. The current implementation has some serious debt. (And while we're at it, we could update it. Too many people misunderstood the documentation part. Continuous attention to technical excellence needs to be upgraded to a value. Delivering frequently today means days instead of weeks.)
• mindcrime 6y ago
  Agile's early evangelists wouldn't mind watching Agile die It's easy to say that, but the obvious follow-on question is "and replace it with what, exactly?" Maybe the answer is in TFA, but I didn't read it yet. I hope they have something to propose, otherwise this discussion is pretty vacuous.
• Yhippa 6y ago
  Nearly everywhere I've worked the quarterly earnings report is the problem. Due dates mean that time has to be managed so any attempt to use a methodology seems to regress to some not fun way of developing software. In places I've worked without the pressure of the quarterly earnings report I've seen that developers tended to use whatever methodology worked best. It could be Agile, pair programming, or just walking over to each other's desks and talking on IM.
• redisman 6y ago
  In my experience "Agile" whatever that means is still the best of all the bad options. Is there really a better methodology? I feel like it works pretty well as long as management doesn't pick and choose the easy parts of it and then add their own layer of BS on top, which is very common.
• deleted 6y ago
  [deleted]
• Someone1234 6y ago
  Agile is the worst form of Software Development Methodoloy, except for all the others. Which is to say: To all the people jeering for Agile's demise, please provide a superior alternative. I came from a world dominated by Waterfall, and I never want to go back to that. A lot of companies get Agile wrong, and it isn't a panacea, but it is much closer to what developers are naturally inclined towards (e.g. rapid incremental improvements) than Waterfall ever was. So I challenge anyone who wants to replace Agile, please lean into how developers work rather than trying to mold their work onto your rigid front loaded methodology. Trying to bring in ideas of other industries, like engineering or architecture, that build physical goods and only have one shot at is a folly.
  • CraigJPerry 6y ago
    Yeah people have short memories of the pre-agile role demarcation and wasted handover time between them. It was utterly frustrating to be powerless to improve specification quality and find out you built exactly what was asked but you were asked for the wrong thing. The silos were horrible. Devs were often as bad as BAs, dev’s just were just crapping on the testers instead. Spare a thought for the production ops person at the very end of the chain. Here comes 3 months of developer work in one weekend and no it doesnt work but we’re still going live because the entire tech org is invested in this release. Now you have smaller squads, you can postpone a release without it looking bad on the top person and thus affecting your career prospects. In agile models you have the power to fix crap processes that don’t work. You can call out any BS on the retrospective and make it super visible when things are being swept under the rug.
    • Spooky23 6y ago
      This. I worked on the customer delivery side of a $750M software project that was a steaming pile of shit, with critical defects that were known for a year with zero effort to address. The integrators were paid to deliver a spec, and it took about a year to get change orders created to diverge from the spec. The old school waterfall outsourcing models are truly awful, but you don’t really understand how bad unless you’ve lived it. Stupid agile religious practices are dumb for any startup type org, but are probably better than the alternatives in many big enterprise scenarios, where the goal is chunk up the work so marginally qualified people can do something.
• csours 6y ago
  If you consider that science advances, what did Agile improve on, and where has Agile been been improved upon?
• projektfu 6y ago
  I agree with the title but find the reasoning hard to follow. It seems like the author keeps changing playing fields and tries to stitch a single narrative.
• illuminated 6y ago
  The main issue my teams have been facing with Agile methodologies is the number of the workflow interruptions built in. The only team members happy with those interruptions were Scrum Masters and PO's but that's because those were parts of their flows, so they had to have them in order to have their job done. The only long term solution for us was to have days dedicated to Agile ceremonies and days where no team member can be interrupted based on an agile ceremony need (there were few exceptions, like critical bug discovery, etc.). In weekly sprints, we had at least 3.5 days of uninterrupted time and in two-week sprints we had 7-7.5. That changed a lot the pace of those sprints as people had a lot of time to do their job and everyone was happy.
  • anthonyrstevens 6y ago
    By "ceremonies", are you referring to daily standups? And/or something else?
    • illuminated 6y ago
      Everything but the daily standups... We had each day to begin with it, and it was great as it provided a more broad visibility into what is being done, if there are any issues, etc. But every other agile related meeting was a ceremony we have tried to manage as best as possible while not blocking its benefits.
  • projektfu 6y ago
    Scrum has always been the problem, IMO.
• robjan 6y ago
  The site has blocked Hong Kong (and possibly other) IP addresses for some reason. Here's an archive link https://archive.is/wip/OFF0F https://archive.is/wip/OFF0F
• _jal 6y ago
  Having been through "agile conversion therapy" at two different companies and then having seen what the companies actually did several months later, I think most of the value of 'agile' has been realized. To get much more out of it, you need some combination of a more capable culture and better disciplined people. And I'm not talking about just engineering - I'm mainly talking about customers and management. Most of the gains come from tighter feedback loops between engineers and other stakeholders than tend to happen without an intentional effort. This works because it is simple - tell teams to talk amongst themselves every day, get feedback from customers more incrementally than you otherwise would, etc. Most of the rest of the promised gains need better disciplined customers and managers - ill-defined specs, dropping projects to pick something else up, only to switch back a couple months later, managers who don't pay enough attention to what's being done until it is too late, etc. Perhaps the problem is that it is a management fad aimed at engineers. It needs a v2 aimed at nontechnical people, "become competent at asking for what you need".
  • dropit_sphere 6y ago
    In practice, this can only happen in a few ways: - development becomes a 1st-class "business" activity a la accounting, sales---not that you necessarily do it as aanger, but you're looked down on if you can't - a culture of "ask about the internals" becomes prevalent, where anyone who bought software without knowing how it worked was looked on as an idiot - developer coup
• mjfisher 6y ago
  This seems like as good an excuse as any to share a link to "Modern Agile" again: http://modernagile.org/ http://modernagile.org/ I think it's probably a good reinterpretation of the original manifesto that is a bit more fundamental and a bit more direct. I like the concepts a lot.
• helen___keller 6y ago
  I've come to best appreciate agile by calling "agile" whatever practices work best for my team. Sometimes we move things in and out of a sprint mid-sprint because new information came up and it's high priority? It's not ideal (and we'll discuss it in retro) but that's agile. We've sat a fat 5-point ticket in our backlog for 3 sprints straight because it needs a decent sum of meeting time and dedicated attention from multiple engineers who keep facing higher priority work and not quite having time for it? That's fine, we're being agile. Our backlog grooming meeting ended after 8 minutes because we had nothing to discuss and we're all focused on delivering? Very agile.
  • HeyLaughingBoy 6y ago
    Three sprints? LMAO. I've had tickets that sat "In Development" for the better part of 6 months because higher priority stuff kept coming up, but no one wanted to acknowledge that we had more pressing work to do :-)
  • joejerryronnie 6y ago
    Each of the things you mention sound perfectly fine if it works for your team and you are able to deliver your customer’s highest priority items while keeping your team happy.
• d--b 6y ago
  One thing that's for sure is that Agile completely shifted the culture of software engineering, and generally in a good way. I am very thankful for that, and I think that this is where Agile has done its job. Then, the problem with frameworks like Agile is that smart people will use them wisely, and less smart people will try to apply the concepts without really grasping the ideas and not really gain anything out of it. But you can't really prevent people from reading the book, and do stand-up scrum meetings and sprints and shit... Unless someone comes up with something else (which most likely will be equally twisted) Agile is here to stay. I just wouldn't mind watching conversations about Agile die.
• at_a_remove 6y ago
  I was exposed when it was still eXtreme Programming (back when "extreme" was the most nineties adjective you could have) and didn't much care for it then. I keep hearing it touted as this kind of universal cure-all but I just do not think it is applicable everywhere. On a personal level, the more any given thing is touted to me as the solution for any and all problems, the more suspicious I grow. The more fervor, the more I draw away. The more cultish it seems (convert, adhere, rituals, special names, and then finally the narcissism of small differences in practice as exemplified by that old Emo Williams routine), the less I want to participate. The more I have seen it shoehorned into places where it seemed ill-suited, the more this was revealed to me, yet the evangelism continues. Nothing like watching the tape backup guy, suffering from a flare of gout, hobble over to a room to perform his "stand-up" routine to hammer that home. Of course, we "probably weren't doing it right," but the more I have seen the slavish adherence to the strictures of Agile the more it seemed like this was an exercise in polishing a boss' resume so that he could say he had done The Things when he went elsewhere. Reader, he did. Perhaps the Agile that can be critiqued is not the eternal Agile.
  • MattGaiser 6y ago
    The project where extreme programming came from. https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... Not a good start
• legitster 6y ago
  There are many fingers to point here, but I point mine at bigger consulting firms like Accenture. I have first hand experience with their miserable "agile" process at Microsoft. If you want a stapler, you have to schedule a meeting 3 weeks in advance with 2 team leads and 3 contractors who decide what sprint "getting a stapler" will be assigned to. Then "getting a stapler" gets pushed back two sprints because some priority came along (a vice president somewhere just learned that his binder was on hold for four months). An Accenture contractor from India informs you that a hole punch is on the way. Apparently you checked the wrong box on the stapler requisition form, so you have to start the process over again. Then the Accenture quarterly deck shows they met 97% of all stapler demands for the quarter! Isn't life so much more easier and more measurable now? But they will need to hire more contractors to keep up with capacity.
  • MattGaiser 6y ago
    That is Agile as a religion.
• shaunxcode 6y ago
  Csp should replace it. Dog food and turtles all the way down. If you can’t model your workflow in terms of processes and typed channels with buffers what business do you have implementing anything more complex (conways law etc.) THAT said agile was a breath of fresh air at the time and it got us to question a lot of assumptions related to how we specify and develop software.
  • temac 6y ago
    You want to replace Agile with CSP? Interesting. Why not replacing Agile with FSMs, though? Or continuations? Or monads?
• kitotik 6y ago
  A lot of the bastardization and commercialization of the Agile core tenets could have been mitigated by the early pioneers broadcasting the dirty secret: To deliver any real business value following these philosophies requires an extremely mature, experienced team. Not just great engineers, but also great communicators that actually care at least a little bit about the mission/product/goal. This simply does not scale and is a complete antithesis of 99% of organizations culture and hierarchical structure.
• jayd16 6y ago
  Did anyone actually read as far as the sub-header? "Agile" is used to scapegoat a lot of issues but gender equality is a new on me. Pigeonholing women into non-technical roles is a problem but I don't see how dumping agile would solve it.
  • bdcravens 6y ago
    Agile as it is practiced has created a new set of roles, like "scrum master". However, if not agile, that role would probably be called "project manager", another role that female engineers are often pushed toward.
    • therealdrag0 6y ago
      Are they pushed towards it or do they gravitate towards it?
      • bdcravens 6y ago
        It seems to me those are two sides of the same coin. After all, gravity is an external force that takes significant effort to work against.
• mywittyname 6y ago
  I've been through three full-fledged "agile transformations" in my career. I hate agile so much. I hate it because it encourages dogmatic behavior instead of rational behavior. I think it has survived so long because it provides its practitioners with two ace excuses: when things fail, they say, "what we did wasn't really agile," and when somebody proposes and improvement they don't like, it's always, "that sounds like waterfall." A team can't recover from their agile transformation until both of those phrases disappear from the team lexicon. > “Way too much of Agile has been not about technology, but about people and about managing things and about getting stuff done — not necessarily getting the right stuff done, but getting stuff done — rather than what engineering is about,” I'm not sure agile was ever designed to fix this. The whole process is really handy-wavy about the actual engineering: "we'll just make this a spike." The process also demonizes documentation and design work, which is antithetical to most engineering. That being said, I love iterative development, and I like the concept of stories as descriptions of functionality. But I do think agile, as taught by most consultants, is really designed for consultants who build CRUD web-based applications. Sprints are timeboxed so consultants can charge by the spring, and stories lack implementation details because companies hiring consultants don't want or need to know how their sausage is made. The further away your product is from that area, the less effective agile is; some companies really need to design their sausage well, up front, because they are going to be eating it for years. A process that's built up over years has become the way it is typically for good reason. And in my experience, teams forced to transition to agile will end up shoehorning their existing process into "agile" and calling it done, so most executives don't really see how their "transformation" failed.
  • woutr_be 6y ago
    > I've been through three full-fledged "agile transformations" in my career. I hate agile so much. I hate it because it encourages dogmatic behavior instead of rational behavior. I'm going through that right now, in fact for the past two years our team has been transforming into agile. Although when I say team, it's more the developers that are forced to work in an agile way. The business is still very much waterfall, but for them it's okay. If they want to throw a new story into the sprint, they'll just call it being "flexible", and adjusting to business requirements. It's not because they can't plan two weeks in advance. There's also way to much time spend on story points, I always assumed these were estimates, to get a sense of how much can be achieved, if a story runs over, so be it. However here, these are seen as deadlines, a 3-point story shouldn't take longer than a day or two. Our "scrum master" is constantly asking wether we can achieve all our stories this sprint, what's the point of even estimating if you're going to do that. And recently, we now have to plan our two week sprint, day by day, committing to 2 week plan before the sprint even starts. There's nothing agile about that to me.
• temac 6y ago
  > At the time, software development was suffering from a mistaken belief: that building things fast and building things well were fundamentally opposed. Mary knew this to be untrue from her work in product development and manufacturing, where the ‘lean’ practices that sprung up in Japanese car factories and subsequently spread across the globe often ruled the day. If that's part of the original reasoning, then it was very random. R&D has not much to do with manufacturing. So I would greatly prefer an actual example from "product development" rather than car factories... I mean what build our software is e.g. gcc. I don't know if gcc is feeling lean, and actually I don't care much :)
• xnx 6y ago
  One of the all-time most cursed diagrams I've seen: https://www.scaledagileframework.com/ https://www.scaledagileframework.com/ . I could not believe it was not parody.
  • cs02rm0 6y ago
    This has been following me around recently, I can't seem to get away from it. SAFe is everything that has ever been wrong with the software industry rolled into one terrible thing that is anything but agile. I can't fully express here quite what I think of it!
  • karatestomp 6y ago
    Message aside, that is a terribly organized diagram. It looks like someone dumped all the things they wanted in it on the screen, moved them around just enough that they weren't overlapping, then simply... stopped, having done no actual organization.
    • MattGaiser 6y ago
      > having done no actual organization. So it was done using agile diagram methods?
  • peteri 6y ago
    Anywhere that does SAFe is somewhere to avoid. The other issue that agile conferences don't have developers anymore.
  • Ididntdothis 6y ago
    I still remember when a PM distributed this diagram as recipe for ultimate happiness. I only could think "are you kidding?". when you look at details nothing makes sense or it's just a bunch of words that sound and look good. Tech guys like to do the same. One director once showed the "architecture" of the next big thing in our department. It was a bunch off boxes with "authentication", "JSON", "distributed", "NOSQL", "JSON", "Roles", "reliability" and twenty other buzzwords. He asked for estimates how long it would take. after asking what this means and what it's supposed to do I was out of the planning. Two years later there are still two guys developing it but nobody knows what it does.
• zwieback 6y ago
  I thought it was dead already. The people that pushed agile where I worked already moved on the next hot thing twice. Now programmers may have a chance to go back to the roots of agile and do it right, without micromanagement from evangelists.
• koonsolo 6y ago
  There are only 2 things your agile team needs: a retrospective and a manager that wants to improve the process. Everything else can flow from there.
• MattyRad 6y ago
  I think the spirit of the article is summarized by Putt's Law https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successfu...
• arminiusreturns 6y ago
  I recently listened to a lecture about the future of programming, and there was a sentence that really stuck out to me. The speaker said something along the lines of "If you go to an agile conference, there aren't that many devs there and it's mostly management.* As an ops type usually only on the peripheral of sprints etc I feel I don't fully grasp the nuances of the different methods enough to really comment, but that just really got my attention for some reason. Found the video, linking at the timestamp that includes the manifesto for agile (which I think has some obvious flaws) https://youtu.be/ecIWPzGEbFc?t=3678 https://youtu.be/ecIWPzGEbFc?t=3678
• charles_f 6y ago
  Agile is not a methodology or a process, it is literally[1] a set of values and principles which can be summarized by "stop being stupid and trying to reproduce what they do in construction engineering, and start discussing about the why and collaborate, doing things that matter, and being flexible, since after all, we're doing _soft_ware. The set of methodologies and processes that ensued, as well as the entire industry of coaches, consultants, evangelists and "practitioners" was probably coming from a good place - trying to propose an implementation for how to put in place those abstract values and principles, or to help with that. The commercialization, envy and corruption that followed is what the problem is. "Agile" has become a synonym for "cargo-cult brainless implementation of sprints and stand-ups to copy something called scrum but effectively doing things in a very much waterfall and old fashion that isn't even remotely close to the original intent". The problem is of semantics order. What does need to "die" is the "agile" industry, with cargo-cultish coaches whose only value is to repeat Scrum says X, XP says Y, Agile says Z, my other customers do Ω, without trying to convey the reason behind those implements ; "agile" methodos like "safe" which have very little agility backed in and whose "Enterprise Architects" proponents usually don't get any of the intent. But take a look at the manifesto[1] and tell me that you want it to die, I feel like the arguments will be very complex. Re: the that we should become "engineers" (semantics and cargo-cult again), there's a very good reason why agile applies well to software, but not to mechanical engineers. The economic equations between those two practices are completely different[2][3], the "engineering" phase of mechanical engineering is cheap compared to the production costs and so iterations have effectively an extremely high overhead cost, whereas the "engineering" phase of software engineering represents most of the cost, and so iteration and adaptability have a very low overhead. But saying "agile needs to die" because of how the "agile industry" corrupted it is similar to saying "email needs to die" because what you see most is spam. [1]: https://agilemanifesto.org/ https://agilemanifesto.org/ [2]: https://www.developerdotstar.com/printable/mag/articles/reeves_design.html https://www.developerdotstar.com/printable/mag/articles/reev... [3]: https://www.youtube.com/watch?v=RhdlBHHimeM https://www.youtube.com/watch?v=RhdlBHHimeM
• achenatx 6y ago
  the essence of the article is that agile is mainly a project management methodology. It is for decomposing tasks into chunks that allow you to deliver something valuable in the given time frame. One of the best parts is that if you run out of time or money, you have something that is usable with what should be the most important features. What it doesnt give any guidance to is how to organize information about how to build the right thing. If a system is very large, without some methods to understand and communicate what you are building, it just becomes ad hoc. Agile is not a product management/requirements identification methodology.
• davnicwil 6y ago
  The process is invented to help to do your job. Problems begin when that gets forgotten, and following the process becomes your job -- not following the process is doing your job wrong. Always remember that your job is to build stuff, any way that works.
  • AgloeDreams 6y ago
    Spot on. The problem with much of Agile today is that Jira, the product is sold to management as effectively employee tracking tools that enable them to know who is good and who is bad and what was accomplished. It tends to turn engineers into ticket crunchers (chopping their heads off of thinking about products and isolating them from the customer) and causes planning to be incredibly near sighted or excessively structured.
• cesium 6y ago
  When something develops to an extreme, it becomes its opposite. This is true for "agile". Agile has become synonymous with "Jira", which is a direct contradiction of its original premise. The original "Agile Manifesto" states: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. Ask somebody these days what agile means and they'll tell you "Jira" or some other tool combined with heavy process. Another example of people confusing the means for the end itself.
  • temac 6y ago
    And also ask people if they really want all of "Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan." That might not really make sense in some industries... And if they really want to consider all of that in a dichotomous way. Who really does not want "working software", and why would I even have to "prefer" that? this is just too much fundamental that we could as well say: we don't want to work on garbage projects, and it is stupid to have an extremely good documentation of a pile of crap. But why jettison documentation if "working software" is not even considered optional to begin with? I fucking want stellar documentation. Because why not? I'm tired of reading source code all day to try to understand what things were even supposed to do... In some industries "agile" in its original definition can make sense. In others, not at all. Yet, tons of people will pretend they do "Agile" regardless of what it is, what they think it is, and of what they do. This is sometimes some kind of management virtue signaling; except it is not signaling positive things anymore to those who work. It really has no meaning anymore. To be honest I'm not even sure it ever had, as implemented by most, out of the industry it came from (with associated practices that were also highly contextual) People should just avoid focusing on fashionable shallow words, and skip right to the ideas: if all of Agile and even all of Scrum is what will make your project shine, just do it, but writing essays about it is not really doing it, nor is pretending it is a kind of universal panacea, nor constructing consulting services around cult practices. If you must do the complete opposite; do the complete opposite. And tell everybody you are "agile" without an once of shame, if that can help raising money or stupid shit like that -- I mean what is even more agile than doing otherwise than "Agile" if it is a better idea in your context; so you are not even lying :p
• adwn 6y ago
  > Women dominated computing professions from their inception in the 1940s all the way through the 1960s. As the scope of computers’ usefulness became clearer, however, those jobs started going to men. Bullshit. Back then, the term "programmer" didn't mean what it means today. A "programmer" was someone who entered a program into a computer, or even earlier, plugged in wires according to a schematic. The actual development of the program was almost exclusively done by men, even more so than today (this is not supposed to be a value judgement, nor do I want to justify the situation back then or today). It's really disappointing to see this tired myth of a supposed "Golden Age of women in computer science" repeated in the article.
  • raarts 6y ago
    Related: the article is misguided on the women thing. I teach CS in college. I see it every day. Women on average are more interested to work with people than men. This hasn't changed despite trying to boost girls' interest in typical STEM fields for 25 years. HR departments have been pouring money into this like mad. Hasn't moved the needle. Research has shown that girls don't fare worse in math tests if they are told beforehand that girls are worse at math. In countries where the sexes are treated more equally men more often choose thing-jobs and women more often choose people jobs. Who thinks that if society would treat everybody completely equal, all occupations would end up exactly even distributed across the sexes? There are real differences between the sexes. The push towards exact equal distribution in everything is futile, hasn't worked and will not work. I think it's more important that people can choose to do what they want to do. Sounds like a rant, sorry.
    • jayd16 6y ago
      This is simply inaccurate, at least in the US. The percentage of women in STEM has gone up. The percentage of workers in the computer field is lower than the rest and declining. Your premise also confuses me as I would argue software engineering is more people focused than, say, lab work.
      • raarts 6y ago
• plughs 6y ago
  My first team, some 14 years ago, had the best experience with Agile. What made this work > During planning, everyone understood that the estimates were _estimates_. Tasks could take longer or shorter, that was OK and even expected. The goal was to improve velocity, not to accomplish every story, every time. > Engineers felt comfortable taking stories in areas they knew nothing about. A stated goal was that every engineer understand every piece of the project. > Standups were team only. Engineers felt comfortable saying they got stuck or needed help or got lost in a rathole and didn't make the progress they hoped. > Demos were important so that the team and the clients could understand what had changed and what new features were available. But it quickly got lost - managers and PMs and Directors got involved and Jira boards became published for all to see. (In the beginning it was whiteboards and sticky note). Standups and Demos were all about self-promotion. No one ever wanted to take on a task they weren't 100% certain they could do. If a task was 3 point it needed to be done in 3 days or there would be questions. When I left the last company it had gotten outrageous. Every task should be completed in three days and in production in five days - and if not that team was Doing Something Wrong. ( We were told that this was standard FAANG practice, I have no idea how true that was ) What happened was what you'd expect - shortcuts, tech debt, unit tests cynically design to pass and meet code coverage expectations instead of actually usefully testing. The reality is that any process is going to fail one senior leadership decides it's a way to evaluate engineers, not create a good product.
  • wpietri 6y ago
    Totally. "When a measure becomes a target, it ceases to be a good measure. https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law And as you say, managerial involvement is the problem. Managers and execs mostly get paid to appear to be in control, so having the appearance of control is vital to them, even if that makes the results wildly worse.
    • brightball 6y ago
      That is one of the all time best quotes that nobody is willing to hear.
• kchoudhu 6y ago
  They've all moved on to newer grifts, and don't need competition from legacy grifts.
• zabil 6y ago
  > software developers need to become what they truly are: engineers. I couldn't agree more
  • drapred7 6y ago
    What does that even mean? Its just some vague feel-good platitude like everything else in agile.
    • zabil 6y ago
      Fair point. I wish I could explain, but don't want to try. For the record, I've been knee deep in Agile.
• andarleen 6y ago
  “and it’s pushing women engineers into non-technical roles” - wtf
  • drapred7 6y ago
    Feminists are always promoting numerous and spurious explanations for why women seek out non-technical roles The qualities of women themselves being a sexist and therefor a priori false explanation.
• zabil 6y ago
  IMHO the Agile manifesto still holds good. It applies to arguments in the article around processes (and tools) to ironically fix itself.
• peterwwillis 6y ago
  The core of Agile, Scrum, DevOps, XP, TDD, etc, is just to get a developer to truly understand what it is they're doing and make a meaningful connection to the real results of it. But before they can ever begin to do that (which is a huge challenge in and of itself), the organization needs to get the hell out of their way, but at the same time, invest tons of money and effort to help them do what they should be doing. If you just "step back" from trying to control the average bunch of engineers, they will miserably fail, because they have never gone to a school that taught them how to rapidly drive business value through software. If you hire the right people, they already learned all of that, and so they'll be successful. That's how the Netflixes of the world survive. Their organization and process would seem totally insane to any "average" tech engineering organization. But it works for them because they learned how to work together the correct way, the business got the hell out of the way, and it also invested a ton in helping them do what they need to do. Agile does not give you any of that. Agile is just a promise of what should be happening, but it doesn't tell you how to get there at all. It's a pipe dream. Agile is not the problem, though. It's businesses thinking the engineers are simple tools to be used to produce widgets, and if they just shove enough extra business roles and processes around the engineers, that will end up creating value. But the solution is actually to remove all that extra crap, and get the engineers to do everything in a way that the PMs and DMs and QEs etc are no longer necessary.
  • betaby 6y ago
    Interesting perspective. Could you please explain what do you mean by 'Netflixes'. What precisely they do and don't (in contrast with less successful companies)?
    • peterwwillis 6y ago
      This talk sums it up, from a lead SRE at Netflix: https://m.youtube.com/watch?v=UTKIT6STSVM https://m.youtube.com/watch?v=UTKIT6STSVM
• winrid 6y ago
  When I was a manager I'd get the team together every quarter and we'd agree on "this is what we're going to do" - and then we'd do it, usually. At the end of the quarter we'd have to explain why certain pressures pushed things out, but usually the business cared more that we kept churn down. For over a year I pushed back on story pointing and things that felt micro manage-y to me. It was very hard on me, but it was worth seeing the productivity. Eventually I was forced to give in to Agile with the big A and left soon after. I can't get another management job because everyone wants to do Agile in a way I hate to manage - so now I'm a developer again... :)
• say_it_as_it_is 6y ago
  How many people here refused advice suggesting to go with one's strengths and instead took a different path in life, developed new capabilities, and acquired new strengths? Progress was slow and difficult. Yet, you persevered. You weren't agile, were you?
• uDontKnowMe 6y ago
  Tangentially related, has anyone tried to implement the ideas described in Juval Lowy's new book, "Righting Software" (https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy-ebook/dp/B0822XJZ48 https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy-ebo...)? His methodology of project management seems much more systematic than week-by-week sprint planning.
• deleted 6y ago
  [deleted]
• ChicagoDave 6y ago
  The Agile paradigm has been corporatized and all of its capabilities turned into heavy process and oversight bullshit. But worst of all, management rarely sees the need to get involved, especially from the financial management perspective. It's very often a zombie project management apocalypse in the making.
• alangibson 6y ago
  I'm not here to defend Agile, but one of the things people get perpetually wrong is thinking about Agile as methods and tools. Agile is actually a set of values and principles. You were supposed to fill in your own methods and tools to support Agile values and principles, but everyone basically just said 'too hard; do Scrum'
  • Buttons840 6y ago
    https://www.halfarsedagilemanifesto.org/ https://www.halfarsedagilemanifesto.org/
    • alangibson 6y ago
      > and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact This was/is literally true at a place I worked. Their official enterprise Agile process includes a long list of mandatory documents, one of which is a list of all sprints and sprint goals for the duration of the project, that must be checked into a document control system.
      • Ididntdothis 6y ago
        "we prefer the term ‘resources" I so hate the use of the word "resources". so dehumanizing.
    • kolanos 6y ago
      http://programming-motherfucker.com http://programming-motherfucker.com
  • Ididntdothis 6y ago
    You should defend Agile as described in the Agile Manifesto. Problem is that what's usually called "Agile" has nothing to do with the Manifesto.
• dragonwriter 6y ago
  The weird thing is that all the criticisms of misplaced focus in agile made in the article were criticisms commonly made by early Agile evangelists (including Poppendieck!) of pre-Agile approaches, and the things pointed to that are needed which make Agile irrelevant are the things that Agile methods were specifically advocated as superior for by those evangelists. The real problem doesn't seem to be that Agile is irrelevant, it's that Agile (and this is actually fairly quickly explicit in the Manifesto and accompanying Principles) cannot be limited to a siloed tech organization but must fully incorporate the business sponsor of the project, whether that's the firms business management for a software/services firm, whether it's an external customer for a firm doing bespoke software development, or whether it's an internal customer for an IT organization doing enterprise-internal development. And despite that being clear in the Manifesto and Principles, it very often is the case that “Agile” is seen as something the tech team is (or worse, does) that stops at their boundaries, and that fundamentally doesn't work. There are other equally serious problems, like ritualistic adoption of fixed processes being described as “Agile”, which it clearly is exactly what Agile is most opposed to; the use of the phrase “Agile (or Scrum) ceremonies” is a clear sign that an organization has been infected with this toxic mindset.
• zhenchaoli 6y ago
  Distracting snake oil. That’s what I think about when I hear agile.
• joejerryronnie 6y ago
  When I'm hiring scrum masters, seeing "Agile Coach" and "Agile Transformation" on a resume is actually a bit of a red flag for me. I don't need someone who can teach my organization how to theoretically run Scrum, I need someone who can engage with our dev teams, understand the expectations they're being held accountable for, the challenges in meeting those expectations, and tailor a methodology (probably Scrum-based) which puts the dev teams in the best position to succeed and be happy while doing it. This may be a bit different depending on the make-up and maturity of the team. Sometimes, we need daily engagement with team members and "structured" collaboration, other times we just need to make sure everyone understands the sprint goals and then get out of their way. The challenge has always been when upper management wants to see a single dashboard which boils all teams down into a set of pre-defined metrics - and then positively reinforces teams (or their managers) for hitting metrics instead of delivering solutions. Training your VP's can be exhausting.
• _bxg1 6y ago
  Agile is one of those words that's come to mean nothing at all. It can be anything from "iterate fast and do weekly stand-ups" to "spend all of your time allocating point values to planned sprint tasks so that management feels like they're in total control". It's been co-opted by the very bureaucracy it was designed to reign in.
• fukbezos 6y ago
  Agile adds so much administrative overhead
• lunias 6y ago
  IMO Agile has become regulatory capture. It's a means by which non-engineers can extract value from a booming market which doesn't directly benefit from their skills. That being said. I think there is a lot of wisdom in the original agile manifesto. The core principles are solid, but the methodology has clearly been co-opted by consultants and supported by management looking to increase the headcount under themselves. I've often struggled to understand why my team is made up of only 20% engineers with the other 80% pretending to create value by holding meetings to tell engineers what to build next when I feel like it's your clients that should be doing that. Ultimately it's engineering that becomes the constrained resource which leads to technical debt in favor of pushing out product's features. I would venture a guess that most engineers have used (critically) more software in their lives than any non-technical person driving the development of the product. Why then are engineers not the most consulted people on the efficacy and value of new features? I think there is a big myth out there that engineers are incapable of directly handling client feedback.
  • omerbensaadon 6y ago
    This completely short-sells the role of good designers in an organization. Creating the _right_ thing is extremely hard.
    • amznthrowaway5 6y ago
      Good designers can't design without a deep understanding of the engineering. Non-technical people shouldn't be driving or designing engineering projects.
    • lunias 6y ago
      Forgive my omission I didn't have designers in mind when I wrote that. Here is what I think: I would place designers closer to the engineering (necessary) side of the spectrum. Designers do in some cases build tangible things, are very technical, and they approach refinement from angles of impact that some engineers may be unaware of. I do think there are quite a few interpretations of what a "designer" does across many industries. In the field of software did you have in mind architects, UX, product, something else, all of the above? The definition of engineer includes design in both it's noun and verb form: "a person who designs, builds, or maintains engines, machines, or public works." "design and build (a machine or structure)" But the definition of designer makes no mention of engineer. As such, I would enforce that my designers are actually engineers and stay away from "pure" designers that do not have the technical foundation necessary to validate their designs. Design in a lot of ways is an emergent property of the engineering task at hand - unless we're talking about purely artistic pursuits.
• caseymarquis 6y ago
  The article mentions Agile as an attempt to bring lean manufacturing methodology to software development. I make software which is used as part of lean manufacturing initiatives (among other initiatives), and see a lot of different manufacturing environments. I want to point out that lean manufacturing is often the wrong tool for producing significantly more of something complex or ramping up production speed of a complex product. In its defense, you could say that lean should be this tool, but is usually so misinterpreted or done so incorrectly that it fails to be this tool. (funny that agile reportedly has the same problem) Generally speaking, lean is a tool for reducing various kinds of 'waste' and 'doing more with less'. That's the part people seem to focus on anyway. The problem is that people become myopic. Lean becomes the justification for premature optimization and focusing on details that don't matter. Sometimes, waste is good. Or, stated differently, not all waste is equal. If you have 5 machines that each produce $1000 of value per hour run, and you're attempting to go lean by rearranging them so you can lay off a $20/hour employee, then you are focusing entirely on the wrong thing. Lean is often pushed with the idea that employees shouldn't be standing around doing nothing, or that you shouldn't produce excess material which will sit in a pile. The problem with this is it often fails to account for needed excess capacity, and when something goes wrong, everything falls apart. The correct move (depending on margins) is usually to hire more inexpensive humans to stand around and make sure the expensive machines never stop generating value because you overburdened one of the humans. When you want to make things faster, you don't stop producing when the next machine in the process can't keep up (producing a pile of unused parts). You buy another machine that performs the next process or figure out what it needs to run faster. Lean is the methodology most people use when they can't make big changes that will have a major impact on production. It's a tool for making the existing (possibly broken) system function better. It's culturally good to focus on reducing waste, but often it's the waste you're not measuring or thinking about that's killing you. Lean isn't bad any more than optimization is bad, it's just not the tool you typically want to be starting with. I work directly with customers, have no deadlines that aren't self imposed, and couldn't tell a story point from a scrum master, so I can't say if the failures of lean manufacturing implementation extend to agile, but I'd be curious to hear if they do. A tool I find more useful than lean: https://en.m.wikipedia.org/wiki/Theory_of_constraints https://en.m.wikipedia.org/wiki/Theory_of_constraints
• jquast 6y ago
  And just like writing software, when specifications of the agile process are not clear, almost founded on a “chose your own implementation” scheme, the result is a big-ridden over-designed and terribly unclear (and endlessly debated) process. implemented differently at each and every company. Just grand. Just like the very process of software design this was meant to aid, they failed to understand the importance of clarity, brevity, and providing exacting specifications or instructions. Fuck you, agile. This is not how engineering should be done in any profession. Thousands of hours of my career has been wasted clarifying this unclear process to swarms of people who have no single resource to learn from. And each new company brings a new “we do agile, but....” exception to adapt to, and damned be if anyone ever writes a single fucking rule of this process down, so we get to endlessly debate what is this “agile” thing at each and every opportunity.
• 5cott0 6y ago
  Agile is what happens when stakeholders want a car but really need a wheelbarrow & end up with a skateboard that only has 3 wheels. Product re-brands it as a scooter and takes a victory lap & now your company culture is an extremely toxic work environment of implicit & unaccountable power structures.
• jackcosgrove 6y ago
  I never understood story points. Is it just psychological to use a different unit of time, so that managers' expectations aren't so hard and fast? Story points remind me of those weird units of work the cloud providers bill you for, or the company scrip that a coal mine would have issued 100 years ago. I call story points AgileBucks. Why not just use standard units?
  • joejerryronnie 6y ago
    I think it’s a purposeful abstraction for relative estimation of a task. Since nobody is good at estimating the exact number of days a particular task will take, story points are a way to give a general estimate of task complexity (usually people end up equating this to a rough timeframe) without having to commit to a specific number of days. In our 2 week sprints we have four possible story point values - 3, 5, 8, 13. If the story should take a couple of days, it’s 3 points. If the story will probably take the full sprint, it’s 13 points. If the story is somewhere in between, pick 5 or 8.
• S_A_P 6y ago
  I’ve worked for 2 big oil and gas firms. I don’t care much about checking agile boxes. I went from being damn near employee of the month to short list for being let go when those companies started to live and die by “agile”. I’m about 50% to blame as it’s a great demotivational tool. The other half is managers forgetting why they are running those agile projects. I left both places within 6 months of agile being gospel. Not sad at all.
• a3n 6y ago
  Ugh. I sometimes miss software development, but I don't miss any of this.
• deleted 6y ago
  [deleted]
• larkinrichards 6y ago
  I still think agile has a place as a focus for discussion when you're taking a large organization from a waterfall model (or any model that tries to commit to delivering a set of uncertain features by a specific deadline) to a more reasonable and effective process for software development. In this situation, you'd get shot down for following rigid Agile, because the process gets in the way of delivering value. What you end up doing is using the concept of "agility" to sell some agile-lean-hybrid-involve-the-stakeholders-think-small-and-demonstrate-the-value-of-delivering-value. It's not about the Method, it's about the outcome. No one needs to go black-and-white rigid Agile, that's where it went wrong. But agility is a good way to describe the concept of efficiently changing (and handling change). I just feel that every article about capital "a" Agile immediately sinks to level of pedantry that is a complete waste of time, so... I didn't read the OP.
• parasubvert 6y ago
  I’ve been doing XP for 22 years, and was on Ward’s wiki as the C2 project was being executed, watching the ideas grow in real time. I worked for Pivotal for the last 5 years. Here are my thoughts. Agile alone is insufficient to successful products, which the original proponents would tell you. It’s a body of practices. There are more practices than just those. People seem to want “12 steps to an easy rich life” and want to scream when someone offers only 6 of them. Most of the Agile practices the industry has adopted and evolved without calling them agile. So in that sense, it’s a “success”. But agile coaches often are so focused on the original 20 year old practices and they miss the bigger picture of business and products and supporting technology, and the evolution that’s taken place in each during that time. Any software method that is delivering software for users to consume has to be complemented by outcome-focused approaches like user-centered design, product development, customer development, and budgetary funding / management practices that don’t weaponize the use of openness, sharing, and metrics for political purposes that hurts people’s self worth. If you’re missing those, agile isn’t going to help you much. Ultimately just letting engineers be engineers is partly how we got into this mess in the first place. People don’t know how to organize themselves without some kind of constraints: design constraints, time, physics, customer constraints, quality, etc. Talented teams turned loose that ultimately deliver little of value is a cliche at this point. Agile tries to use time as a constraint to limit active work in progress to force the delivery of customer visible / valuable results that can be tweaked. It’s not the only way to constrain the problem space, but “cost of delay” does have a fairly universal explanatory value in showing what really matters to a business, as lean product development and manufacturing has shown. But that might not be the outcome you’re looking for. whatever process or practices you do, Agile or not, it has to be organized end-to-end to be tied to some kind of tangible mission or outcome or else it’s just a form of self-deception. For example, if we think products need to be usable and solve actual problems, and that design can evolve, then Product owners need to speak for the Customers and have the power to make decisions. Engineers need to be empowered to make the technical decisions. These seem obvious but they’re rare: committees and political strings attached are the norm. If you get both an empowered balanced team of product, design, and engineering you’ve got potential for an engine of collaboration and learning, which is the whole point. Don’t build projects, build human/techno systems that grow and improve and evolve. Agile is also not universally applicable and much of the resentment stems from a religious conversion therapy or Developer Rehab approach to marketing (even though some really could use a stint in rehab). Agile is applicable to some kinds of software (user-Centered software in particular), which happens to be a big chunk of industry. It isn’t applicable to everything, such as deeply technical components, pure or applied scientific R&D, or certain kinds of exploratory work. Nor is it applicable to jobs with set and unchangeable requirements. People are best to understand there are a spectrum of practices and processes suited to different environments and stages of organizational evolution. Or they could reject such complexity and nuance and just adopt SAFe, I guess.
• bane 6y ago
  It's gotten to the point where it seems that the projects that do more of the Agile "stuff" move much slower because they're spending so much of the working time doing that stuff than slinging code. Where I'm at, we're running something around 4 dozen projects at once and the teams that really focus on doing all the ceremonies are simply left in the dust by the teams that don't. Here's another anecdote, a couple big teams that went the full SAFe route spent 3 years building something that ended up being thrown away and replaced in 4 weeks by 3 staff working part-time who were just given some instructions, some deadlines, and told to go code. It's become repeatable, big teams toiling for years getting outpaced by smaller, more "agile", teams. The balance has gotten out of whack again and it's really time to start over again. When I go back and read the original manifesto, what I see today in modern practice looks nothing like what was intended. The point in too many shops has been to accomplish the Agile things, not to deliver.
  • jpswade 6y ago
    In your anecdote, though I don't doubt the situation, it seems to me that something has gone wrong. The manifesto itself says: > Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale I get the impression as to what you're witnessing is, water-scrum-fall... See: https://i.imgur.com/6eqk7eF.png https://i.imgur.com/6eqk7eF.png On the flip-side, your team of renegades managed to deliver in 4 weeks, while being great, I would question how sustainable that is. Also I get the impression they had skin in the game. > what I see today in modern practice looks nothing like what was intended You're 100% right. I don't think it means agile should die, I think it means people have forgot what it set out to do. Scrum existed before agile and is a framework to help people work in an agile way. However people have got too wrapped up in the orthodoxy and have forgot what agile is actually about. My mantra is simple: Release early, release often, listen to the customer When I first got into software development it was because of open source software. On the SourceForge website, under the “Promoting your project” section, you’ll see it say “Release early, release often. Frequent releases state loudly that your project is alive”. Years later, I learned that this philosophy was popularised by Eric S. Raymond in his 1997 essay The Cathedral and the Bazaar. Only, his version also says “listen to the customer”, an important part that’s all too easy to forget.
• atulatul 6y ago
  All movements go too far.- Bertrand Russel
• brainless 6y ago
  So much frustration over something that in theory is so good for building stuff. If you go over to http://agilemanifesto.org/ http://agilemanifesto.org/ and read these simple 4 sentences, it makes sense: * Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan What goes horribly wrong is managers, and their incapability. They do not work with teams, instead they use agile as a means to simply get updates at the end of week and set orders down the ranks every Monday morning.
  • nicetryguy 6y ago
    - Individuals and interactions over processes and tools - Customer collaboration over contract negotiation - Responding to change over following a plan Would any of these work for, say, building a house? I hate agile from the bottom of my heart.
    • brainless 6y ago
      I can not even try to answer that since they are not even remotely equal. How often do you change the way you walk through your house, or how the water flows or the walls look? Do you launch a new bed in your house to charge people to see every month? They are not even comparable, like at all. If all you have is hate for something sure you can not understand it.
      • nicetryguy 6y ago
        I have seen and tried to maintain the years of spaghetti code and quick hacks that Agile projects generate. It is a nightmare. I think i understand it just fine. It is a flawed premise. Projects should have concrete specifications and expectations at the get go. I shouldn't be forced to code quickly with a sprint gun to my head at all times, generating heaps of tech debt by having no time to retool unstable or inefficient portions of a project, as i am always busy scotch taping on new features that the codebase was never designed to handle. If the customer wants a horse to run 60mph backwards, and the project manager has no idea that a horse cannot possibly do that, i have to hear why my "horse" should have been designed with Agile philosophy in mind. Agile is nothing but a bunch of techno-babble that "sounds good" but offers no practical advice on how to achieve those ends. It is the scourge of the earth and would love to see it purged from collective consciousness.
• pragmatic 6y ago
  Speaking of Lean, I remember my mother telling me about their hospital adopting lean and that meant they could keep only so many supplies on hand in the lab. I remember thinking at the time "wow, isn't it a bad idea to try to limit the amount of supplies on hand at a hospital" I guess we'll have to see if we ever have a major health care crises. Wait... And we wonder why the hospitals didn't have enough PPE on hand. Did the MBA virus spread to hospitals and did they misapply methodologies like Lean where it had no place, except as short sighted cost cutting? One of the major problems in industry I've seen again and again is management, etc pretending they know more about the job and it's requirements than the people doing it. As Lean originated in manufacturing with the WORKERS making the improvements and the WORKERS being empowered (anyone could stop the line if there was a problem) it's bit ironic that a corrupted version was used later to beat workers into submission and achieve petty cost cutting versus process improvement as in the health care anecdote above.
• rafaelvasco 6y ago
  Well, every company I worked with, "Agile" was just a means for management to keep feeling they're in control, when they're not, there's no such thing as in control, or to promote themselves with the higher ups. My best team is me alone, but other than that, the best team I ever had was one in which there was no meetings, no dailies etc. It was just me and a few others, receiving the outlines of what the final product had to do, what inputs and outputs it should process, and then filling this outline with code and hard work until it was whole. It was far from perfect of course, but we weren't bothered by unnecessary processes. There was no agile back then yet.... That said, the methodologies are not the problem. The problem is peoples attitude and mentality and how they use them.
• joejerryronnie 6y ago
  The problem isn’t “Agile”. The problem is organizations which are not good at software development. Teams which fail with Agile will also fail with Waterfall or any other development methodology. Teams which generally succeed with one methodology may find a different methodology a bit more efficient, but they’re gonna be successful either way.
• KingOfCoders 6y ago
  I was a coder in the 80s and did XP in 1999 and became an early Scrum Master as a developer. Agile has been stolen from developers. The rise of Scrum came at the same time as the rise of the product manager, and the Scrum PO became a PM. From then on in many companies it was not about doing the right thing but getting the most features out of developers, to implement the PO vision, with little say. We became assembly line workers, put to comfort with high salaries.
• ghevshoo 6y ago
  In my experience the main reason that agile mostly sux in large enterprises is because it is agile in name only. Not a single one of the people who are responsible from managing the process have even heard of the “agile manifesto” let alone read it, nor have any of them ever worked as a software engineer. So in most cases it could easily be better than what it is. But I object to the authors complaint “and it’s pushing women engineers into non-technical roles.” and elevating the primacy of engineering above all else. People come in all levels of competencies and have all manner of skills. I don’t care if you are a man or a woman. I care about how good you are at doing the tasks that need to be done to get the job done. And in large companies there are big jobs that require a lot of people and a lot of coordination. I work with a woman who is not a very good software engineer, but she is good at administering and coordinating the work among other software engineers and she quite enjoys doing those tasks. While she can improve on some of her skills as a software engineer and I try to help her with those, the author’s recommendation seems to be that because she’s a woman, I should push her away from work that she likes doing, that she’s good at doing, and which is important work to do. This is objectively terrible advice, but some might accuse me now of male chauvinism. If so, fine. But I will forward this article to my colleague to ask her what she thinks and I’ll let her opinion be the ruling decision.
• postfacto 6y ago
  Agile In Their Own Words https://github.com/rayfrankenstein/AITOW/blob/master/README.md https://github.com/rayfrankenstein/AITOW/blob/master/README....
• softwarejosh 6y ago
  proper agiles a way of life, cramming the unproductive types of people into it was never going to be as good as making a team of agile people
• genezeta 6y ago
  Speed. Sometimes I wonder if people mean speed as in velocity, or if they mean the drug, seeing as they seem to obsess so much about it. > Engineering is about seeing a problem, understanding it and using the technology you’re good at to solve it as quickly as possible. Everywhere you turn to there is someone thinking that speed is the most important thing ever. Everything must be done quickly. The best way to do something is quickly. If something takes longer, it's clearly worse. Even in an article about "the problems with Agile", people still fall into the trap of speed. Engineering is clearly not about solving problems "as quickly as possible". It's about solving them in the best way possible, where you first define "good" as a balance between all the advantages and all the disadvantages of each possible solution. Speed is but one of the factors you evaluate.
  • boris 6y ago
    The need for speed is the direct result of worse is better.
• wodenokoto 6y ago
  What is the alternative to agile? Calling it a to-do list instead of user stories? Not aligning teams on where we are in the to-do list regularly and removing and adding things? Agile proponents often say "waterfall", but I have no idea how you would go about working waterfall day to day. Would you just make all your user stories/to-do's on day one and never update them and now you have waterfall? Having entered the industry long after agile became the new normal, it seems like the whole discussion is either "stand-up sucks" or people discussing variations of what is essentially "Regularly report where you are on the to-do list, often update the teams to-do list", but never "Why not this different paradigm instead". Maybe I am lacking imagination, but I am not really sure what a serious alternative is here.
• PeterStuer 6y ago
  There is a surplus of "organizer" roles in IT, call it PM's, call it Agile Coaches, call it PO's ... for every software engineering methodology. This is indeed because these roles are far more accesible than the 'hard' engineering skills in IT.
• lifeisstillgood 6y ago
  Some thoughts I wanted to get out: I think we need Outcome Driven Development- we define a metric measured in say graphite, we link a ticket to that asserting the ticket will make the metric change this way or that, and we commit code to make the metric change so we start a process of defining what we want, implementing how to measure it (there could be a null metric and the ticket is to make it not null) and then measuring our success of changing the metric this will have organisational impacts as well - no one should take a ticket without authority span to impact that metric this will start in the direction of software as literacy or the developer anarchy
• netjiro 6y ago
  Agile, as commonly encountered nowadays, is mostly just cargo cult. People chasing dogma and buzzwords with zero understanding of why and when it has great application and benefits. Just like so many other trends in the past. Way too easy to "seem" productive while actually being net negative for the project. That said, I've had excellent agile projects that have delivered huge value to the customer at cost and time well below initial estimates. These days I ask people who shout for agile to actually explain the fundamentals to me, as though I have no clue. Very rarely do I find anyone who can hit even one of the four original core ideas and values of "agile": https://agilemanifesto.org/ https://agilemanifesto.org/ And when I bring up the core ideas, and why they can work really well, I often see that the people who shout agile actually don't agree with the fundamentals.