8 ms·

Why do some developers consider Agile development to be nonsense?

• zimpenfish 11y ago
  The micromanagement - if management doesn't trust you to get on with work without having to justify what you've done every single day, why did they bother hiring you in the first place?
  • AndrewDucker 11y ago
    People aren't perfect. It's easy to get distracted, get off track, think that you'd be able to get back on track if only you could get your head down for a couple of days, and suddenly two weeks have passed, you're miles behind, and the people waiting for your work are all thrown off track because it's not there yet. Spending 15 minutes per day making sure that everyone knows how the team is doing strikes me as a very easy way to avoid that. Heck, it can be significantly less than that, if you use a tool to keep your tasks up to date and can just say "I got the frobulator finished, and moved on to the doohickey. Dave's giving me a hand with a small holdup there, and it should be finished on time." at the standup then the whole thing should take less than five minutes total, except when there _are_ issues that need to be dealt with.
    • mooreds 11y ago
      I think that standups are one of the best parts of Agile, if they are time boxed and moderated well ('let's take this [larger issue] offline' should be heard fairly often). Super easy to implement, and very helpful. I've only worked with small teams (less than 8 folks), but I don't think it'd scale well.
  • UK-AL 11y ago
    It's not meant to be for that. It's meant to be let people know whats going on, because someone might know something that would save you time. I.e Collaboration.
    • zimpenfish 11y ago
      I've been in a lot of standups and that's never come up. (Yes, I know, the plural of anecdote is not data.)
      • Serow225 11y ago
        OT, but I'm stealing that quote! Made my morning :)
        • zimpenfish 11y ago
          http://freakonomics.com/2010/04/29/quotes-uncovered-whats-the-plural-of-anecdote/ http://freakonomics.com/2010/04/29/quotes-uncovered-whats-th... (I prefer "The plural of anecdote is Gladwell" but that's because I can't stand his lame books.)
      • IanCal 11y ago
        As a different anecpoint, that happens quite regularly for me.
• unwind 11y ago
  The title is completely mangled. The original (rather long) title is "Why do some developers at strong companies like Google consider Agile development to be nonsense?", and it seems it was shortened. There's a spurious "at" left in there now which breaks it.
  • jacquesm 11y ago
    This happens when people try to shorten their titles to fit 80 characters.
• UK-AL 11y ago
  IF teams are using Agile like that there doing it wrong. It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house. If your goal is to use Agile to push developers to their limits, you've already failed the Agile Test. You can twist Agile, based on your vision of good team is. So you have to get the right people to implement it. You have to approach it from the idea of it being a collaborative, friendly, no blame etc for it to work. I've only ever used estimates in story points to prioritize things(That's why its so abstract), not to monitor and push developers. If I wanted that, i'd use actual time. The idea of everyone is junior is also bad implementation. It means even the most junior person is capable of contributing using their solution over a senior persons solution. The right idea wins, not the right person. I can understand why this pisses of senior people though.
  • jackmaney 11y ago
    > It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house. The vast majority of work environments cannot be described as relaxed and friendly (hell, most of them probably aren't all that collaborative). Far more could be described as pressured hot houses.
    • UK-AL 11y ago
      That's the point. Managers often use management techniques that encourage that. It works if your on simple assembly tasks. I.E Worried if you gonna be fired if you don't make 200 widgets. Doesn't work if you're on knowledge work. A lot of people approach agile as its an extension of those approaches. When in fact it was a reaction to it, by trying the opposite approach.
      • jackmaney 11y ago
        So, what are you saying, then? That Agile isn't suitable for the majority of workplaces?
        • UK-AL 11y ago
• bbody 11y ago
  The thing that I don't understand about the way Agile development is treated is that it is often treated like a silver bullet. As the article points out agile has use cases where it is effective but many treat it as a "Waterfall Killer".
• couchand 11y ago
  This article cements in my mind the issue: devs tend to take away from agile what they expect to find, rather than taking the time to understand the motivations and whole scope of activities. Historically, most software development methodologies are excessively top-down, so people somehow still expect that from agile. Most devs are the sort that couldn't stand doing group projects in school, so the idea of organizing with teammates to produce something bigger and better than I could on my own is totally foreign. If you don't explicitly name your development methodology, you still have one: you're practicing something called ad-hoc development. Unless you and your entire team are superheroes, there's an awful lot of knowledge being leaked away. Here's the secret: software development isn't really about making computers work, it's about organizing knowledge. If your process focuses more on making the computers work than your institutional knowledge you're making a critical mistake. Don't confuse some company's crappy engineering practices for agile just because they call them that. Stand ups are short. Period. If it feels like a "permanent PIP" your team could use some improvement. If it feels like a surveillance state it's probably not a very good implementation of agile. Agile development is about making connections to your team members: individuals and interactions over process and tools. It sounds like the author's experience (as well as many other devs') is unfortunately in an organization that doesn't pay heed to that very first, most important agile principle.
  • father_of_two 11y ago
    "permanent PIP" -- didn't got this part, can you explain? that couldn't stand doing group projects in school Hm, how did you found that about me? :-)
    • couchand 11y ago
      I'm assuming the author meant Performance Improvement Plan, which is business-speak for "we're going to fire you in a month."
  • calibraxis 11y ago
    I agree devs carry many dysfunctions. But big-A Agile is a management school with its own dysfunctions. It diverges from small-a agile, which is basically a set of principles to help critique yourself with. When you hire a manager (or "Scrum Master" whatever), they must convince top management to give them a job. Which is why Scrum Masters brag about their bosses "believing in" Agile, like a bishop happy that the king loves god. Then they impose some system which requires their highly visible involvement. (That said, the Agile described in this article diverges from my personal experience.)
• dccoolgai 11y ago
  The term has been hijacked. It is useless. There is merit in the idea that it once encapsulated, but it has long since been co-opted to mean something almost completely the opposite of its original intention.
  • fennecfoxen 11y ago
    Yeah, this nonsense isn't a problem of agile. It's a problem of people who don't know what they're doing, on both sides of the equation. Which isn't to say that it's not a problem for agile -- it definitely is. I'd say that it's analogous to Gresham's law: when people can't tell the difference (until it's too late) bad "agile" drives out the good.
  • kabdib 11y ago
    Yeah. Scrum doesn't make management disappear, it amplifies it. I saw meetings with middle managers (people who hadn't shipped anything significant in a decade) in daily meetings, going over burn-down rates of individual engineers and "expressing concern" through channels that someone was off their schedule by a couple of days. The daily scrums were just half-hour status-in-a-ring and some public shaming if you couldn't say that you did anything, so a lot of people made stuff up, or at least hedged by saying they'd completed 50% of the work or that tests were "nearly passing" (code for: my stuff is broked). Oh, and in the mean time the build system we devs were using had been on fire and broken for three weeks and it was nearly impossible to get a working build. WTF? I said, "We don't need Agile. We need an earthquake to collapse that wing of the building" (where the managers were; they liked to cluster). We had Ken. Ken was there at the beginning for maybe a week, and for the next few weeks after that it was great. But we forgot that middle managers are still gonna manage, and that you have to fire them or they're still going to be there, you know, managing stuff, because that's all they know how to do. And with the right tools, Scrum can be turned into the perfect surveillance state. (I stole that from another response in this thread, thanks).
    • dccoolgai 11y ago
      The problem is that, to them, "Agile" is Candyland: No responsibility or accountability for their own job (making stable plans/requirements), but hyper-accountability/scrutiny for the devs that have to spring to their every half-baked whim. It amounts to a DDOS attack on the dev process. It's just waterfall without the top part of the waterfall where they are responsible for requirements. I'd rather go back to waterfall.
• someengineer 11y ago
  One thing about Agile that I don't see mentioned much is that it provides a way for bad managers to marginalize the effects of low performers among their groups, though at the expense of high performers. Every company has "cowboy" programmers who break shit and ruin their coworkers' lives with massive 1am check-ins, and a lot Agile seems designed specifically to put up road blocks to prevent this from happening. Managers love it because it provides an escape from dealing with problem employees directly. Most of the vehemently anti-Agile people I've worked with were grossly overconfident in their abilities and difficult to work with, which I think supports this idea. Unfortunately, the only way for this non-management technique to be effective is to do it dogmatically with no deviations (otherwise the cowboys will always have some excuse for why it shouldn't apply to them), and this is where things start pissing off the actual talent.
• outsidetheparty 11y ago
  This matches my experience. We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-software part of the company much more difficult, because they keep getting hung up on the jargon; we have to slice up tasks arbitrarily to get them to fit into "sprints," which go out of date minutes after the morning standup when the first non-planned bug report lands. Sizing is frequently an exercise in post-facto book-cooking: 'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass. The short timeframes encourage everyone to twiddle around the edges of things instead of doing real feature development; the arbitrary milestones serve mostly to make everyone feel like they're constantly falling behind. I've discussed this with a bunch of people. Everyone seems to agree that we're doing Agile wrong, but even the strongest proponents of the methodology seem to be in complete disagreement on what the "right" way to do it is, or how that would be an improvement over the way we were doing things before. So yeah. Not a fan.
  • throwaway1979 11y ago
    "Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.
    • UK-AL 11y ago
      It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
      • 11y ago
• bitwize 11y ago
  Agile is like CrossFit: the techniques are sound, but the techniques really aren't the point. The point is to create a revolution by wrapping sound techniques in an us-vs.-the-world ideology that has strong emotional appeal. This makes it easier to sell trainership certifications, which are where the money is.
• chillingeffect 11y ago
  An eager beaver at one of my client's is introducing Agile as a "Waterfall silver bullet." I see right away one Agile defect: It prefers near-term "user story success" over long-term investments like creating debuggable architecture. Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration? Why write "gdb" when "gcc with printfs" will work fine, even if it simply requires more sprints?
  • lostcolony 11y ago
    If you're doing SCRUM, hopefully, when planning, you're building in slack for the devs already. Your sprint commitments should always be conservative. If something ends up taking more time than you planned, then, it'll just take up some of that slack. With that slack, then, when things go right, you have time for dev priority tasks. You hit your sprint commitments two days before the sprint ends? Great! Time to work on some of those long term investments. You can also scope stories based on dev priorities. You want to add a feature to part of the code that is in need of refactoring? Scope the story to include that refactoring. Etc. If using Kanban or something, it's a bit harder; you can easily take time for dev tasks (since you're not making commitments), but finding the right balance of taking them on but still getting feature work done is harder.
  • dragonwriter 11y ago
    > I see right away one Agile defect: It prefers near-term "user story success" over long-term investments like creating debuggable architecture. Neither the Agile Manifesto nor even the far more specific Scrum Guide even refers to user stories. A particular organization using Scrum may decide that architecture-related concerns are not important in the definition of "done" for items in their product backlog, and focus only on "user story success", but, to the extent that that's a problem, that's not a Scrum (and much less, Agile) problem, its an organization problem. Agile is about what concerns you favor in figuring out how to get work done, Scrum is about how a team gets work done and defines the work it is to do within the framework provided by the wider organization, but the specific definition of quality standards for work is not directly addresses by either. > Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration? Why wouldn't an organization have maintaining (or improving) the overall architectural standards of the work a priority for every iteration -- in Scrum terms, part of the Sprint Goal -- unless there is a conscious decision to take on technical debt to meet some other goal? Agile, or even Scrum, doesn't tell you what goals to set, and you shouldn't blame them for you choosing to set the wrong goals.
• ctdonath 11y ago
  Every methodology fails from pretty much the same reasoning. The saving point of Agile is breaking tasks into reasonable sizes, long enough to actually get something done and short enough to rearrange as needed sooner rather than later, and to delay interruptions until they can be evaluated and other tasks completed. I can't get to what I need to do if the relentless onslaught of self-important "do this _now_!" interruptions are handled as they occur; Agile provides a sane way to say "get in line" such that important issues are addressed in a timely manner relative to other issues and without compromising other stuff that also needs doing (those that never reach the top of the interrupt stack, but without which long-term progress won't happen).
• agilecontard 11y ago
  Agile as dogmatically crapped out by the so-called agile consultant-tards, is what kills agile in the hearts and minds of developers.
• davidgerard 11y ago
  The free e-meter at every desk is a valuable job perk! The Kool-Aid tasted a bit funny, though. Scrum-English Dictionary: * "sprint": artificial crisis * "end of sprint": abandonware * "Scrum master": resume credit for my planned escape to a new company * "stakeholder": someone you can't get away with externalising your costs onto * "simplified": doesn't implement any of the actual business requirements * "lightweight": doesn't implement any of the actual business requirements, but does so much more elegantly than the version that works * "easy": project was born circling the drain (and doesn't implement any of the actual business requirements) * "legacy": the version that works and implements the actual business requirements, even if no sane human wants to touch it * "velocity": a speed with a direction, so skittering about following marketing's random hairpin turns counts * "retrospective": blamestorm incoming! * "stand-up": getting the blamestorming in early * "We'll put that on the backlog": hahaha fuck you I do enjoy some of the jargon. "empowered": do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that yourself." Seriously: every good idea is turned into a bad one by the relentless management quest to Taylorise clue.
  • depr 11y ago
    The first and last definitions I find are very accurate. Do more! (Retrospective, velocity, stand-up.)
    • davidgerard 11y ago
      :-D Done, also "stakeholder". What's the proper Scrum jargon for "maybe bong hits will fix my makefile"?
    • davidgerard 11y ago
      "Inspect and Adapt": maybe bong hits will fix my makefile "Project Manager:" a job that no longer needs to exist in the astounding new world of Scrum. (Pay no attention to the project owners, product owners, story-writing users above you in the org chart or Scrum Masters behind the curtain.) Blog version: http://reddragdiva.dreamwidth.org/594955.html http://reddragdiva.dreamwidth.org/594955.html
• chuckcode 11y ago
  Experienced engineers have seen a lot of "magic bullets" both on the process side and the product side. Generally they turn out to not be a substitute for hiring good people and getting good leaders to define a quality product and focus the team on what is important both short and long term.
  • davidgerard 11y ago
    +1. Attempts to Taylorise clue shall forever be with us.
• agilecontard 11y ago
  How do you know someone is an agile believer? They tell you! (every single day at the stand up)
• dbg31415 11y ago
  So instead of Agile we should use, what? Fully understand that process is a technology. If Agile is so bad, what's better?
  • depr 11y ago
    I am interested in this as well. Who's using a different process?
    • kabdib 11y ago
      Why do you need a capital-P Process? Does it need to have a name? Best teams I've been on have been self-organizing, with a few senior engineers who did heavy-lifting and some less experienced engineers learning new stuff. Management was minimal (the more we had, the more things sucked). - Minimize management. Minimize management. Minimize management. Management exists to set very high level directions and to remove obstacles. - Make sure that different teams talk. A lot. - Get real. Don't blow smoke up people's asses. Making a schedule with a granularity of a day on a six month project is fucking bullshit. Just stop it, okay? You might be able to do this a week out, but not much more than that. If that deadline is important, be clear on why. (I've been on projects that have been absolutely killed because someone felt they had to ship on magic date X, when shipping a few months later would have saved the product). - If you are working steady 60+ hour weeks, you are doing it wrong. If you are doing regular 80+ hour weeks then you will burn out and leave. - It's done when it's done. Ship it, and iterate.
      • dbg31415 11y ago
        > It's done when it's done. Ha. Ever have a client? "Dear Enterprise Customer, We'll get it done when it's done. Cool? Can we have the gig?" Yeah no. That's not at all how the world works. We have process because we have deadlines, commitments, responsibilities... and there needs to be an easy way for people to come and go inside of an organization without having to invent the wheel each time.
• compbio 11y ago
  Agile done wrong destroys more than Agile done right can fix. If you feel too good, or too senior for a programming methodology like Agile, then you are bound to not like it. Is that a fault with Agile, or a fault with your attitude? A cowboy coder is not micro-managed, does not seem to need atomized tasks, does not need a direct line with the customer and decides on the complexity of the problem and the solution all on his own. They are also terrible to manage and hit-and-miss when it comes to actually shipping something with business value. Bluntly spoken, Agile is there for the project managers, not the project developers. Agile should be implemented for as long as productivity increases, customer feedback loops create desirable features, and iteration cycles become tighter and shorter. If you know a way to increase those stats without Agile, then write your own methodology (http://programming-motherfucker.com/ http://programming-motherfucker.com/ is taken) and join management. If you don't care about those stats, and feel too good/senior for Agile, then start your own company and proof it to yourself. You don't start to measure a project's success by first counting the number of developer complaints. You could probably keep the complaints at zero, and never ship anything of impact.
• passive 11y ago
  I don't know how the author is doing Agile, but it doesn't match my experience. I've implemented "Agile" processes on four different teams, and while certain aspects were more successful than others in different contexts, nothing was at all like what is described in the article. For starters, a very significant part of the article relates to performance anxiety over story points. Over 6 years of doing this, I've had two instances where people were called out for not putting points on the board, both of which came from outside managers not familiar with Agile. Besides that, one of the core tenets of Agile is that you adjust the processes to work for the people involved. Trying to enforce some arbitrary subset of Agile processes on a team is a recipe for failure and frustration. This reads to me like "bad managers are bad at managing Agile processes".
• fsloth 11y ago
  If scrum metrics are used to identify low performers then that's so bad it's not even wrong. The whole point of agile estimates is to teach the team to estimate and pay attention to it. It's a learning tool for the team.
• fsloth 11y ago
  "Agile and Scrum, however, single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it." Holy crap, how wrong can some orgs go? The team should own the process. If there is R&D that does not match with scrum then the team should have a) a r&d framework or agreement in place b) the authority to say this is r&d. The process does not own the team. The team owns the process.
• cmdkeen 11y ago
  To go through some of the points I fundamentally disagree with: "There is no place for an actual senior engineer on a Scrum team" - There absolutely is, who is peer reviewing the code, working with the BAs to design the architecture, identifying the technical dependencies in the backlog? Scrum is not a methodology for writing code, it is for getting a series of tasks done. All the things a senior dev needs to do on top of code can be broken into tasks, Scrum adds a weekly "is this still the most important set of things to be doing?" meeting into the mix. "It's aggressively short-term, by design" - The whole post talks about 6 week projects. Scrum is terrible for that as it imposes far too many meetings. Scrum works for the complex space where you say "12-36 months" as your gut feel estimate. It is a reaction to the waterfall world where you'd discover 2 years in you weren't building what the business wanted. "It has no regard for the programmers' career needs or desires" - Stories make for excellent opportunities for juniors to "own" bits of work from initiation to completion. Old school projects provided very little opportunity for juniors to work on requirements gathering and thus a big chicken and egg problem for promotion. It also offers plenty of opportunity to interact with your customers, which is almost always a good way to get promoted. "The story points are there to track productivity" - Oh noes the people paying you want to know how long the project is going to take to be done. The talk of many status meetings seems decidedly anti-Scrum and is an excellent example of the sort of thing that people should be screaming about in retrospectives. "It punishes R&D" - Ironically it can be a really useful opportunity to conduct R&D. Scrum makes you have something measurable and a time frame in which to conduct it, which makes for an easier sell than an open ended request. I think what annoys some is when they get shut down too quickly, or are forced into taking a less technically interesting approach that delivers enough business value. Scrum isn't there for pure research into the theoretical, but then no-one is claiming it is. Killing businesses - Much like every tabloid headline everything can kill you. Value destroying mergers exist in abundance, and poor leadership/management is a real killer. Plenty of companies do very well out of Scrum, especially when they are in a cost centre environment. I might sound rather "no true Scotsman" when it comes to Scrum but there are only a few things you need to do to be "doing Scrum". What it does give you is a powerful question to ask, and a regularly mechanism to raise it via the retrospective - "why are we doing X when it isn't in Scrum?".
  • jackmaney 11y ago
• Delmania 11y ago
  Reading over his points make me think the OP is a PM who doesn't understand Agile nor his role in it. The number of misconceptions he presents reads like someone who has never bothered to research agile, but only knows what consultants have taught him. I think the number 1 misconception is the sprints. He seems focused on 2 weeks as being the requirement, when it's on the recommendation. Some team have gone as long as 4 weeks. The whole point to a sprint is that dedicated time to a delivery with fast feedback from the customers. It's mainly so you can fail early, ail often. It's much better to spend 2-4 weeks building the wrong product than 6 months. Second, his claims that product development, research and design, and architecture don't belong in a sprint are also misinformed. The focus on user stories to remind people that they need to focus on users, not gold plating. In any technical project, there are a plethora to improve on the design. People can (and have) sat down and refactored and "rearchitected" for days and days. At the end, they build beautiful systems that don't offer any advantage to the customers, or have implemented a number of features the customer didn't want, or have fixed a series of concerns the customer wasn't concerned with. There is give and take of course, as the engineers needs to give feedback to help the customer understand the benefits of the feature or risks of not fixing the issue, but those need to happen first before people go off and construct digital masterpieces. Third, micromanagement. If you have endless meetings in agile, you're definitely not doing it right. The 3 big meetings, planning, retrospective, and demo, are ones that take the most time. Standups take no more than 15 minutes. The other tasks, meaning, backlog grooming and prioritization should not involved your sprint team. Those need to be done offline by the product owner. Agile may be about teams, but you still need strong leadership. The only point of his that has any relevance is the last one, where consultant firms have made big bucks spinning out variations of agile because people just can't understand how simple it is.
• phamilton 11y ago
  I always try to differentiate between Agile and agile. Agile (proper noun) is the overly defined practice of scrums and points and backlog grooming etc. agile is the practice of continuous iteration at all levels. Agile is a great starting point, but if you aren't challenging the prescribed format and iterating on your process itself then you are missing the point of agile. We have found, for instance, that the 3 questions of standup are pretty useless. They make each person feel like they are justifying their existence at the company. By dropping those questions and framing it in terms of a deliverable we found the meetings to be far more productive and better for morale. We've decided to give ourselves 1 day into the sprint to better guage progress so we can define achievable sprint deliverables, as we don't often know enough information during sprint planning. Each of these is set up as an experiment, designed to solve an identified problem with our workflow. And the results are great.
• notacoward 11y ago
  I've seen many criticism of agile/scrum as they (don't) apply to long-term or systems-software environments, but another disconnect I think people need to know about is with open source. Here's the "upstream first" development model typically used by Red Hat (my employer) and others. (1) Company decides to devote resources to a feature. (2) Developer writes code and submits patches upstream (e.g. to the Linux kernel). (3) Upstream takes some indeterminate amount of time to get patches into a release. (4) Company defines a downstream (i.e. commercial) release based on a particular upstream release. (5) The possibly-pristine but also possibly-unrecognizable code from (2) is pulled from the upstream release into the downstream tree. (6) More testing, debugging, tweaking, etc. on the downstream tree yields an actual release. Just in (3) we see one part of the problem: upstream quite likely isn't agile/scrum themselves. Often they don't care about a particular vendors' release schedules; if they do, then someone would argue they're "dump and run" fake open source, and not a true independent upstream. They're almost certainly not going to give a crap about sprints or story points or anything else about the local agile/scrum process. These methodologies pretty much don't work unless everyone is completely committed, and with separate upstream/downstream that's just not the case. Even with everyone on board, the disconnect between (2) and (4) is a problem. Pushing code upstream and pulling it downstream are two separate tasks, even if they're done by the same person, and there's this big gap between them. At best, this makes scheduling more complicated. More often, it makes agile/scrum style fine-grain scheduling and tight coordination impossible. Measuring "velocity" and all that isn't possible when there's so much externally imposed variability. For something that's long term and systems-oriented and open source, these methodologies are practically useless. Actually they're worse than useless, as they misdirect effort and interrupt useful work. YMMV.
  • davidgerard 11y ago
    And the hilarious (fsvo) thing there is that "agile" was an attempt to port open source at its best to corporate development.
• glenbo 11y ago
  Pretty spot on, I think. The most problematic part of SCRUM (and the first thing to start killing productivity) are the interminable meetings it facilitates. The SCRUM master is constantly trying to gauge scope on this or that feature, and everyone feels like they need to bring up what they've been working on during the standup in order to feel like they're not appearing to be slacking off. I've abandoned SCRUM in favor for a Kanban approach that puts the onus on the Product Owner to manage and estimate scope and deadlines, thereby leaving us developers alone to focus on our work. I've written more about my approach here: https://medium.com/@glenelkins/agile-is-good-for-managers-but-bad-for-developers-73bcddac5fe https://medium.com/@glenelkins/agile-is-good-for-managers-bu...
  • cozuya 11y ago
    Its your prerogative of course but peppering your blog posts with stale meme gif after gif is an easy way to get me to not read your content. I don't understand this trend at all for talking about a professional concept. What you did this weekend, sure, but this?
    • glenbo 11y ago
      Know your audience, I guess. I enjoy gifs, and enjoy getting a sense of the author's personality when I read an article. I don't think I've ever bounced from an interesting article because of a handful of cheerful gifs, but hey, that's just me. To each his/her own I say.
• dragonwriter 11y ago
  First off, Agile isn't a software development methodology, its a set of principles for an organization to apply in selecting/developing in its own software development methodology (you could call it a software development metamethodology.) Scrum is more of a methodology (and, while it may have emerged from the people involved applying Agile principles in the context in which Scrum was developed, and has features designed to support use in an organization applying Agile principles, there is nothing fundamentally Agile about Scrum -- or any other development methodology; if some decisionmaker is sold on Scrum by some consultants and adopts it as a top down practice, that organization may be doing Scrum, but they aren't doing Agile -- in fact, they are doing exactly the thing that Agile is a reaction against.) Almost any time someone uses the phrase "Agile/Scrum" they either mean Scrum or something that is neither Agile nor Scrum. In this case, the criticism seems to be of something that is neither Agile nor Scrum, though it may be related to the latter (but not at all the former.) As to the specific points: 1. Here, the claim is: There is no place for an actual senior engineer on a Scrum team. The only way to move up is to become a "Scrum Master", a bullshit management role that involves responsibility without power. There are several errors in this description: First, "Scrum Master" isn't management role, its a facilitation role focusing on expertise with making Scrum work in the particular organization. The only quasi-management role on (or related to) a Scrum team defined in the Scrum Guide [0] is the Product Owner (which does have authority to go with that responsibility.) Either of those is a role a team member could develop into; the idea that the SM role is the only "way up" on a Scrum team is incorrect even within the narrow bounds that are defined by Scrum. OTOH, Scrum itself intentionally -- to support its use in organizations using Agile practices -- defines only a narrow slice of practice, particularly, a basic model for operation of individual development teams. It does not prevent having different roles outside of the defined interactions within the Scrum guide for members of different seniorities or specialties, it only requires that for the purposes of the interactions it defines, only a narrow set of roles ("Team Member", "Product Owner", "Scrum Master") matter. So, consistent with Scrum, there can be room for moving up on a team. And real organizations using Scrum on projects greater than a single 3-9 member team use complementary practices like the Scrum of Scrums [1]; being a Scrum team's representative on the Scrum of Scrums and thus playing a larger role in the coordination of the overall work of the project is one way for a technical contributor on a Scrum team to move into a role with broader scope and exposure. 2. Here, the claim is "It's aggressively short-term, by design" and "if you carry this way of working on for months or years, you get a lot of technical debt and you get low morale." It is certainly the case that Scrum, specifically, largely addresses tactical-level, short-term processes. This is because Scrum isn't a full-stack methodology, its a narrow set of practices designed to adopted as part of a larger set in an organization working in an Agile manner, and to be relatively neutral to the other practices. Certainly, if you apply Scrum alone with no higher-level strategic processes that set standards that constrain the definitions of "done" for work done in sprints to avoid technical debt, there is a lot of potential for an organization applying only what is in the Scrum guide to lack long-term focus and development technical debt. 3. The claim here is "It has no regard for the programmers' career needs or desires." Agile, as a set of principles, certainly does; Scrum, as a particular set of practices, does not, for much the same reason addressed in the previous point. Largely, though, this seems to be a restatement or alleged further consequence of the first complaint about lack of a way to move up (it essentially seems to be, "because of #1, Scrum leaves me nothing interesting to put on my resume"), and so the response to the first complaint above largely addresses it. 4. There's a lot here that deserves separate responses, so I'm going to break this one up. > "It's micromanagement." No, Scrum is the opposite of micromanagement, since the "management" is done almost entirely by the team. > "User stories and backlog grooming are there to control what the engineer works on." Sure, those things exist to define work, but they are done by the team, so can hardly be viewed as micromanagement of the team. > "The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking." Scrum defines four kinds of meetings: the Sprint Planning meeting, the Daily Scrum, the Sprint Retrospective, and the Sprint Review. Of them, the Sprint Review is the closest thing to a "status meeting", though even their the focus is demonstrating the concrete deliverables for the Sprint rather than status reporting. All of the rest are primarily action/planning meetings. "Status" of a sort plays a role in those meetings as an input to the planning aspect, but if they become status-focused meetings rather than planning-focused, you've definitely lost the defined purpose of the meetings in the Scrum guide. > "The story points are there to track productivity (in some superficial, inaccurate way)." Story points (in methodologies where they are used; they aren't part of Scrum) exist as a planning tool for the team, not a productivity measure. 5. The claim here is "At identifying low performers, it has an unacceptably high false-positive rate." Scrum (and, a fortiori, Agile) is not a process for identifying low performers, or for performance evaluation at all -- its completely out of scope. Its not that it is good or bad at it, it doesn't even address the issue. 6. The claim here is "It punishes R&D, and it hurts the best engineers the most" because "Agile and Scrum [...] single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it." Research is a separate domain than product development, and there is no reason that the use of Scrum as a product development methodology should have any impact on how research is done. Of course, Scrum is a generic enough process that you could use it to manage research efforts as well, but the backlog items, associated definition of "done" for those items, sprint length, etc., would all likely be very different for a research effort than a product development effort. You could mix research items into the backlog of a team also doing product development, but then you probably have a problem defining work items that are appropriate for the product development sprint length. (This is less of a problem for non-Scrum methods that use a flow method for backlog management rather than a timeboxed Sprint cycle, because then its easier to mix items that have a longer-than-usual time involvement into the same backlog; the sprints used in Scrum place an effective upper bound on the size of work items.) 7. The complaint here is "I have actually seen it kill companies" backed by a single non-specific anecdote and the assertion that it generalizes. From the description, this appears to be a top-down all-at-once conversion to a new defined methodology. If one has processes in place, for the same reason one adopts incremental change to a software system where you've got an existing, functional system unless there is some reason you can't do incremenetal change, the same thing should be done to a software development organization. Failure of an organization (or many organizations) to manage a big-bang change rather than incremental change doesn't invalidate the methodology they sought to change to any more than failure of an organization to manage a big-bang software system replacement invalidates the technology they sought to change to. [0] http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US... [1] https://www.scrum.org/Blog/ArtMID/1765/ArticleID/12/Resurrecting-the-Much-Maligned-Scrum-of-Scrums https://www.scrum.org/Blog/ArtMID/1765/ArticleID/12/Resurrec...
• carsongross 11y ago
  Agile development is another tick in the long series of desperate attempts by management to avoid The One Thing That Actually Usually Works™: Hire great developers, pay them a ton of money and give them a lot of freedom and time.
  • tsotha 11y ago
    I don't see how this makes sense. If I hired a bunch of great developers at great cost I would have even more incentive to maximize their output than I would if I hired a bunch of mediocre people at a lower cost.
• pan69 11y ago
  Any methodology in the wrong hands will be a terrible experience. Let's face it. There is no methodology that will make all software development projects around the world go smoothly and fun to work on. If you work with, or for, a bunch of dicks, you won't enjoy what you will be doing all day. No methodology is going to change that. I would like to go as far to say that "any" methodology used by great people will automatically result in great things.
• prostoalex 11y ago
  If you get stuck in an agile environment, here's a survival guide: 1) Attack the lowest-priority and easiest stories to shoot for quantity, not for quality. This way you'll be closing stories in no time, pleasing the scrum master and product owner during the daily standup. Leave the largest and most complex problem for last - if nothing else, you can kick the can down the road by claiming it's tougher than it seemed, requires more points and should be moved into the next scrum. 2) Do not worry about the quality of your work. In fact, the lower it is, the more stories you'll have to fill in the next scrum - "widget for feature X" with some effort can become "fix bug Y with feature X", "improve widget performance when more than 1 user uses the product", "improve logging and monitoring of widget X" and tons of other, lower-priority, but higher-quantity stories (see point 1 of this). You'll likely be closing a story a day, earning points way ahead of the other suckers who choose to focus on long-term critical design/architecture issues.
• ckrailo 11y ago
  Dave Thomas (one of the original agile signer peoples), gave this amazing talk criticizing modern, commercialized agile instead of the developer-focused way of "developing with agility". Give it a watch: http://www.thoughtworks.com/talks/the-death-of-agile http://www.thoughtworks.com/talks/the-death-of-agile Blog post version: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/ http://pragdave.me/blog/2014/03/04/time-to-kill-agile/