14 ms·

This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their

• robertlagrant 4y ago
  Pretty much every rant like this is a straw man rant overfitted to the writer's worst experience of what someone called "agile" in one of their companies once.
  • izacus 4y ago
    One of these days we might even hear of an example where following "agile" actually panned out. The question is - before year of the Linux desktop or after?
    • pwinnski 4y ago
      It pans out more often than not, which is why it's the default. For now. Eventually something better might come along, but until then, this is working for many, many, many productive teams. Including mine.
      • closeparen 4y ago
        Strict Scrum is really not the default in tech. "How Big Tech Runs Tech Projects and the Curious Absence of Scrum" is good reading here & matches my experience. https://newsletter.pragmaticengineer.com/p/project-management-in-tech https://newsletter.pragmaticengineer.com/p/project-managemen...
        • robertlagrant 4y ago
          The category error of thinking scrum is the same as agile is a big contributor to the complaints.
        • pwinnski 4y ago
          Who said anything about scrum? The comment was about "agile," of which scrum is only one possible implementation[0]. Sprints are not only found in scrum, but also in other agile approaches, like kanban. Two-week sprints seem to be the default in tech, although I've worked at a company that very successfully used one-week sprints. That's completely separate from how strictly companies try to follow "scrum," if at all. I've run into kanban more often than scrum, personally. 0. https://en.wikipedia.org/wiki/Agile_software_development https://en.wikipedia.org/wiki/Agile_software_development
    • pacifika 4y ago
      The tale of the project launch that wasn’t missed because the client was onboard with iterative delivery?
    • thwiv 4y ago
      I've worked at 3 different companies now where the system worked well and teams moved quickly and created great software. Unfortunately, that story is incredibly boring and goes against the tech blog hivemind.
      • _joel 4y ago
        This, boring things don't tend to be reported on as much.
      • hirvi74 4y ago
        Was it Agile that made this possible, or perhaps the organizational abilities of the companies that made this possible? In other words, if the same organizations used a different methodology do you think the results would be completely different? I am a firm believer that one, "does not get chicken salad out of chicken shit." Thus, well ran and well organized companies would produce similar quality of products regardless of methodology, and in the same vein, poorly ran and disorganized companies will produce garbage regardless of the methodology.
    • marmarama 4y ago
      Essentially every project I've worked on in the last 9 years has been agile, most of them Scrum, and almost all of them succeeded in achieving their goals. There's a clear correlation on all of them between the skill of the project manager at applying the agile approach, and how difficult the delivery was. Prior to that, I worked (as did most people) on waterfall-style projects, and the success rate was only about 50%.
      • AstralStorm 4y ago
        Usually when agile approaches (kanban or scrum) fail it is because there's an unsolvable bottleneck. Typically too small team, lacking knowledge or skill for the scope, problematic environment (development or socially) or someone is pushing "done" work causing skyrocketing development debt that quickly comes to a head - typically a prototype remains in production, switching too early to maintenance mode for business reasons. Waterfall cannot identify those risks without huge experience. Scrum tends to exacerbate some of them. Kanban with sufficient number of phases tends to expose the problem, but not necessarily fix it.
    • pydry 4y ago
      Agile is a nebulously defined cosmic aura surrounding all software projects in the world that go well. Scrum/sprints are kind if like the bureaucratized and ritualized version of that. The Catholic Church to Agile's Christian cult.
    • joshuacc 4y ago
      Most of my career has been working at places using scrum/kanban. And the vast majority of those projects delivered valuable software to customers at the estimated pace. The ones that didn’t were easily attributable to outside factors or specific problems like an exceptionally bad PM.
  • aqme28 4y ago
    And every rebuttal is about how well it goes in the (seemingly rare) case that everything goes as its supposed to. Both are overfits of a sort.
  • jjslocum3 4y ago
    In the same way that few ReST implementations are truly ReSTful, few agile implementations are truly agile. The Agile Manifesto came into style, then predictably a cottage industry of small companies grew up around it, with the business model of charging Fortune 500s huge amounts of money to train their Engineering departments. I've sat through such training before, and I can say without doubt that the day our company took "agile training" was the day we stopped being agile. We overlaid an efficient process with a ton of bureaucratic busy work. We came out the other side of it with an army of PMs (read: Jira configuration experts). Engineers had less time to engineer, with constant flow-interrupting meetings where they became trapped in a morass of Gantt Charts, "deliverables" spreadsheets, etc. We had many employees for whom English was a second language, and interestingly none of those I talked to realized that "agile" was an actual word, meaning "nimble, quick, dexterous." Nothing about the new process conveyed any of those qualities. It was basically classic waterfall, with stand-up meetings thrown in. Rigid project management methodology is definitionally opposed to agility.
    • carlivar 4y ago
      I tend to think of communism as a comparison. Aren't proponents of "agile" similar to those saying "we've never had real communism"? Both have manifestos. I think there are certain systems that make sense and can be executed properly but human nature eventually mucks it up.
      • jjslocum3 4y ago
        Well put... Animal Farm is really about Agile. All engineers are equal, but some are more equal than others!
      • robertlagrant 4y ago
        No one's saying we've never had real agile. Philosophically, agile is more like democracy/capitalism: it decentralises control to teams, where the information and expertise are. Failures in agile are things like "I didn't like using story points". Waterfall is more like communism: it centralises control away from the people doing the work. Failures in waterfall are things like "we spent millions and got nothing out of it".
• kixxauth 4y ago
  Why do we need predictable deliveries? Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.
  • sneak 4y ago
    If you’re post-launch, you need predictability so that you can ship the new code often. Otherwise your HEAD might be unshippable for weeks, which would be bad from the “written but unshipped code is a waste like excess inventory” standpoint.
  • iLoveOncall 4y ago
    Actually it is predictable, the majority of software engineers predict it at work every day (or every 2 weeks in sprint planning). Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
    • throwaway284243 4y ago
      > Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for. Yep, at the end of the day, the whole world can't run if everyone is a professor emeritus just freely exploring random possibilities, even if it would be hundred times more efficient to just "get out of the way".
      • stitched2gethr 4y ago
        In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this. Especially considering how often we're wrong even when we define sprint boundaries and point all the stories.
• mihaaly 4y ago
  Predictable delivery depends on the quality and not on the form. Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits. If the breakdow is carried out badly or the big picture is formed carelessly then the chain of sprint breakdowns will also deliver rubish! If one lives on and focuses on atomic deliveries only and cares no other then I agree. But that is rarely a product, sometimes not even a feature. Also complexity (symphony of small tasks) has to live somewhere and unpredictability of the big project will not go away with week based planning cycles. But I too know better actually. : ) Except probably all the others if everything is done with suitable care and attention.
  • quadrifoliate 4y ago
    > Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits. From some hard-won experience working with a variety of different teams, I have unfortunately found that good quality planning and execution are far harder to attain than you perhaps imagine. Some of these articles seem to paint software developers as magically perfect beings, with managers being pulled straight from Dilbert. The reality is far more complex. Sometimes one of the people on the team is being an asshat and hoarding knowledge. Sometimes they have overly-strong opinions on languages and frameworks that they're super familiar with, or go to the other extreme and work on only bleeding edge ones that were posted on Hacker News. I strongly suspect that Agile is used at companies because it's a mildly effective way of curbing these dysfunctions in a team. If you spend time and money hiring the perfect team, then you probably won't need Agile. Think of a situation you do find somewhat commonly where you often have hackers smoothly churning out work with a team they selected perfectly for – early-stage startups. Good early-stage startups are often very picky about who they bring onboard, because an unproductive hire can literally cost you the company. It's possible to reproduce that on a team, but imagine telling your next boss at a run-of-the-mill that you're going to hire slowly over 18 months and very selectively.
• rob74 4y ago
  And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what you wanted to have. To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...
  • astura 4y ago
    If you have subpar project managers, product owners, and lead developers on your team would you really be better off without structured sprints? I guess, I'm asking, is there something specific about agile that makes a subpar team worse?
    • ethanwillis 4y ago
      It can make them believe they're good.
      • the_af 4y ago
        In what sense? If they keep missing the planned sprint so that they must take less and less work each following sprint, isn't this telling the company there's something wrong somewhere? (Not necessarily the developers, mind you).
        • mgkimsal 4y ago
          > In what sense? In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything". If you missed estimates without agile/sprints, and now miss estimates with agile/sprints, you may think "well, at least we're doing industry standard practices now - estimates are always gonna be missed anyway, but now we're more agile". But now you have the attendant overhead of planning/meetings which is using up time that could be better spent somewhere else. Something not necessarily mentioned too much that I see, is that if you actually have all those people (PM, PO, tech/dev lead, etc), is that they all have to be good/skilled and generally on the same page. If two are good and one is bad, it's all bad. The system is only as good as the weakest participant.
• melling 4y ago
  Yes, people like predictable. Tell management every project will take a month, and meet that expectation, then management will be happy. While someone else who takes the same work and says it’ll take one week then is consistently 2 days late will be viewed as less effective. So, by squeezing people into a guaranteed timeframe, in a mini death march aka sprint, you are forcing people to make [very] conservative estimates. For larger companies this might be preferred, but I would argue, smaller companies should try to move faster.
  • roflyear 4y ago
    The issue is management rarely is looking 1-2 months out. They are looking 1-2 years out. On those scales it is impossible to estimate anything. "Oh, yeah, the rewrite will be done in 1yr, no worries" One year passes, and you haven't started!
    • tstrimple 4y ago
      I wish it was the norm for management to be looking 1-2 years out. Sometimes that tries to happen at the C level, but even then it doesn't seem to work its way down to line managers who are almost always focused on the next immediate deliverable. Future looking managers are the exception, not the rule in my experience.
      • roflyear 4y ago
        I'm not saying it is good forward-looking. Can be bad.
  • agumonkey 4y ago
    This is a strange law of human groups. Only caring about negative slip. That's why everybody inflates everything to shield themselves from the backlash.
    • TuringTest 4y ago
      That's a good reason why sprints work well so often. They limit the amount of inflation that is possible.
• sswaner 4y ago
  In my experience, the “predictable deliveries” delivered by agile are based on behavior changes induced by the methodology. Specifically, focusing on stable point velocity per sprint focuses the team on creating sprint plans that safely deliver. This reduces the potential accomplishments of the team - they reduce throughput and delivery to a level that can be safely accomplished every 2 weeks. I have yet to find a startup that successfully launched using agile. I am sure there are examples, but most seem to be focused on the true goal of software development: releasing features to production.
  • ngrilly 4y ago
    Linear.app is an example of a startup that "successfully launched using agile" and focused on "releasing features to production", while working with 2 weeks cycles (not "sprints"): https://linear.app/method https://linear.app/method
    • nightpool 4y ago
      Right, this is exactly what GP is talking about. When you prioritize "doing predictable sprints" and a stable point velocity over releasing features to production, you reduce your team's throughput and productivity. When you prioritize shipping features to production over "predictable sprints", then things can be successful. You're proving GPs point, not contradicting it.
      • robertlagrant 4y ago
        You're contrasting two different types of thing. If part of something being "done" is deploying it to production, then it will be useful to have the "deploy to production" bit of it managed by a sprint process that tries to account for all the work needed to do something.
• EugeneOZ 4y ago
  Nice way of arguing: “this is nothing but a strawman” - and 0 counter-arguments, 0 quotes, 0 attempts to be polite. Brilliant.
  • robertlagrant 4y ago
    I suppose OP will be pleased with your comment. Imitation is the sincerest form of flattery, and all that.
• PaulHoule 4y ago
  I've worked in places where the cycle to integrate work was more than six months. In a situation like that you often don't really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months. It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.i. model. This had a bit of Gannt chart character in that it had to be managed in terms of calendar time instead of punchclock time. If you didn't start the database build early enough you would predictably blow the sprint. At the same place there were a few different teams with their own sprint schedules and the system was able to turn a 1 day delay into a 4 week delay as one blown sprint caused another blown sprint. Another problem is how you organize work that has a pipeline structure. Is a tester expected to test work in the same sprint it is being developed in? What does a developer do when a feature is under test? What really kills teams is a lack of trust. With the six month build cycle you can put off conflicts that a sprint cycle forces you to confront every two weeks. I think sprints are popular with some because it gives developers some space to be inflexible, but it is harmful for the business. Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.
  • ebiester 4y ago
    Sprints are meant to correlate with frequent releases. Yes, sprints are a bit weird when we are talking about such large horizons. That sounds like a square peg, round hole problem.
  • hurril 4y ago
    Yeah, I've tasted all of those pain points myself. At $work our app developers expect a working API with all the new routes and endpoints from day 0. We manage this, of course, since we're all adults by simply talking to each other. But... yeah.
    • robertlagrant 4y ago
      Day 0 is presumably agreeing the API contract, day 2 is mocking that, day 3 is implementing tests, day 4 is coding? Hopefully they know that? :D
• jmull 4y ago
  You start with dismissing this out-of-hand... which is weird, because you pretty much agree: > ...probably not the best method and maybe it's not even good It doesn't sound like you believe in sprints either, but can't imagine something better.
• jibe 4y ago
  I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.
  • Kalanos 4y ago
    Love it. Lots of agile benefits for devs. Less hand-wavy requirements. You get to say how long your work is going to take
    • hirvi74 4y ago
      We have vastly different agile experiences, my friend.
      • Kalanos 4y ago
        i've seen a lot of ppl do it wrong and claim it doesn't work. it's like not obeying the rules of the road and getting mad when things get chaotic
  • groestl 4y ago
    As a senior dev I hate this. Of course I'm going to drop everything, if what I do stops making sense on an org level. Why would I do anything else.
    • deleted 4y ago
      [deleted]
    • Spoom 4y ago
      Maybe you've never had a project manager whose whims change with the wind, and interrupts the sprint to add yet another high priority bug in the middle that absolutely-needs-attention-right-fing-now... every sprint. Scrum tries to stop that. Of course, if your project management listens to you and trusts you, you don't have this problem, so I understand your take.
    • 4y ago
• odd_noises 4y ago
  Yeah as an ex-engineer and recent product manager I was very confused how the author expected things to get done in an predictable manner of nobody knows when it'll be done. Engineers also rarely interact with the sprint process. We do sprint planning with the engineers to make sure they know exactly what they're building, how much time it'll take, and give any opinions/questions they have on the ticket. That meeting lasts for an hour (maybe less) every 2 weeks. Our daily standup is 15 mins (usually like 8-10) and the point isn't to track engineers like an overlord. It's so that if you have any blockers we can reach out to the right parties for you so the engineer can continue coding without distractions. Plus, the product manager isn't your boss to be tracking you. Your engineering manager is your boss
• taylodl 4y ago
  Sprints are waypoints on your product delivery journey. They ensure you're not wandering too far off course.
• ageofwant 4y ago
  I absolutely have to 'like' it because I have to do it. Scrum masters and Product Owners love to inflict Agile bullshit, but they do not suffer from it. They have little understanding of the process of software development and imagine themselves to be capable of 'adding value'. Agile is a failed experiment kept alive by people who have no skill other than working the work.
• tcgv 4y ago
  I also sensed this piece to be an emotional criticism to sprints, backlogs and tickets, lacking structure, evidence and logical arguments. For instance: > (...) they’re designed for managers who don’t trust their employees (if your manager needs to look at Jira to figure out what work you’ve done for your review or what’s shipped lately then they’re not paying enough attention to the team). I disagree. Visibility and documentation of work are important for having everyone working in a project on the same page in an efficient manner, and definitely not a sign of lack of trust on the team. From checking the author's information I found that he's a "writer and web designer". So maybe he comes from a different background that led him to develop this pessimistic views on scrum. I'm personally more attracted to Kanban than to Scrum, even so I can see value in Scrum when run in a disciplined manner.
• debrice 4y ago
  Yes, sprints on paper are what you describe, but in reality, they rarely ensure deliveries or predictability, they even tend to hinder productivity as they narrow the body of work of a whole team. Think about it, after a week, what is usually the distribution of work of your team? For me, it was always very unbalanced, where people where working overtime and others (best case scenario) would be looking for some work to do. I understand the author's heated post, because I've been there so many times, and I think THIS IS THE POINT of this article, the point that you are missing. Good manager shouldn't rely as much on a set tools that are broken or unfit for their team. I my opinion, not enough people question Sprints and their viability and benefits. And he's right, backlogs are by far just a list of the things you wont do. If your tool cannot fix your issues, the manager should. Use post-its, emails, spreadsheet, large whiteboards, hang a TV screen in the room, pdf, discussions... There is endless possibilities, be creative.
  • boredmgr 4y ago
    I guess all will agree that every successful product is an outcome on number of iterations and to perform progressive iterations there has to be a way / tool which can be one language across the board. That's why these tools such as Sprint exists. And I am sure if you are a good manager ( a future self ), you would sure not giving yourself a suggestion of using "post-its, emails, spreadsheets, large whiteboards , hang a TV screen, pdfs" as the preferred way of managing iterations.
    • debrice 4y ago
      I'm a manager, and post-its, tv screen in the room, extremely large whiteboards (all 3 walls) and spreadsheets have been my secret weapons for a long time... that and going on a long walks with my engineers 1-on-1 to discuss ideas and problems. Tools and methodologies are guardrails, use them at the beginning as you learn the craft, get ride of them as you grow and always put meaningful conversation above all
  • robertlagrant 4y ago
    > backlogs are by far just a list of the things you wont do Scrum even has a ceremony for fixing this: backlog refinement.
• xxEightyxx 4y ago
  It's all about how everything is implemented. I've worked in places where sprints were hard deadlines and there was no acceptable reason for missing said deadlines. We worked 12-15 hour days, including working weekends to try and meet our release schedules. Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements. We engineers had two business analysts, a scrum master, and two managers that resided "above" us in rank all working to keep the "flow" of the sprints alive to help ensure we meet our deadlines. It was the most stressful tech job/environment I've ever been part of and everything was micro-managed by said 5 people to the point that they were blockers to our progress - scheduling multiple meetings everyday that would easily consume 3-4 hours. Our backlog would grow everyday as everyone scrambled to finish tasks and our architecture was a patch-work of systems that only one person truly understood because he had been with the company since it's inception. I was hired as a senior engineer along with three other mid-level engineers - all three quit within four months. I left after six. Sprints/agile/scrums are generally a good thing IF and ONLY IF you have a capable manager/scrum master leading and organizing the team who truly understands time management and finnicky nature of software development. Otherwise, it quickly falls off the rails and leads to churn and burn.
  • negamax 4y ago
    This sounds like an organizational failure rather than sprint/agile/scrum. It works beautifully when lead in/by tech teams.
    • hirvi74 4y ago
      > It works beautifully when lead in/by tech teams. What software development methodology does not work well under these circumstances?
      • negamax 4y ago
        Fair point. Too much managerial bandwidth is a red flag in a tech org.
  • jamal-kumar 4y ago
• commandlinefan 4y ago
  > they're a tool to get more predictable deliveries No, they're a tool to get the illusion of more predictable deliveries. As always, comforting lies are more welcome than harsh truths.
• slowmovintarget 4y ago
  Sprints, at their best, are interruption buffers. They provide a preset time before which, engineers shouldn't be interrupted from getting stuff done by whipsawing to new priorities. That big new product is still going to take three months to deliver, regardless of sprints, but you don't get to pull the team off working on it for some new idea until next sprint.
• vladsanchez 4y ago
  May be a strawman, but his frustrations are real and I share his sentiment. Sprints et al have been a mixbag for me, but the last 7 yrs (current team) have been plain utter BS. All the ceremonies too, retros are nothing but waste, because they only serve to praise undeserved credit with no product to show for most of that time period. I credit the OP for his courage to raise his voice to shame those/any bullshitters behind the Agile movement.
• stjohnswarts 4y ago
  Sprints are for middle management to keep projects from getting out of hand, they aren't for programmers or programmer freedom. When you understand this simple principal it all makes a lot more sense. It's really no deeper than that. All the stuff grafted on top of that as "support for" is pretty much all feel good fluff and unproven social theory.