39 ms·

I don’t believe in sprints

• 1980phipsi 4y ago
  I thought it said "Spirits" and I was like I don't either.
• ibejoeb 4y ago
  For a more cogent and compelling analysis, I recommend Florian Haas' Fragile Development talk. https://youtu.be/f-ULT_Ic4qk https://youtu.be/f-ULT_Ic4qk
• birthday 4y ago
  People hate on anything and everything. It boils down to needing a form of alignment, you can't have team members running around making it up by themselves as they go. How you achieve alignment and shipping things customers love is irrelevant, just fucking achieve it.
• lkrubner 4y ago
  I reject most of the agile rituals, including daily check-ins and weekly or two week sprints. If I personally have to check with someone, each day, to get good work from them, then my preference is to fire that person and hire someone else who I can trust. If I need to check in with a person every day, then I'm micro-managing this person, and I have to wonder why they need to be micro-managed. This is different from me being available, every day, to help them, when they need some specific help. If they are being blocked by something, they should feel free to reach out to me and ask for my help. But a daily standup assumes that they won't ask for my help when they need it, and therefore I need to force a moment of conversation each day. Again, it is easier to fire such people and hire someone else who I can trust. I'm working in the USA where it is easy to fire people. If I was working in Europe, where it can be difficult to fire someone, then I would instead seek to get people traded away from my team, and I'd see if there were others in the organization that I could get to move to my team. With senior level software developers I find it is often enough to meet with them on Monday and ask "What will you accomplish this week?" and then chat with them as needed during the week, and then on Friday check in with them and ask "What did you accomplish this week?" If they didn't accomplish what they thought they would during the week, then we can talk about why. With junior level software developers, I usually have to check in with them more often, which is fine. Usually, with each person, I figure out what is the ideal level of support that is needed. Every human being is a unique individual with unique needs, which is why the daily standup is a bad idea. It's important to figure out who is working for you and tailor your support to the needs of that individual. Direct, honest communication cuts down on the need for rituals and ceremonies such as a daily standup meeting, or grouping work in two week batches. Often, when I speak to managers of tech teams, they say the main point of two week sprints is to offer transparency to the leadership above them about what progress can be made during those two week sprints. But again, direct, honest communication with the top leadership typically does a better job of explaining what to expect, as well as to explain why something is delayed, if something is delayed. To the extent that two week sprints serve a mostly political goal, I'd rather address the politics directly. I expect people below to reach out directly when they have something to say, and I do the same to the folks above me. None of this precludes tracking how much work is being done every week, or every two weeks. If the work is being tracked in a tool such as Jira, it is still possible to add up the number of points that are being done each week. Nothing that I say here suggests that I'm against gathering metrics and trying to improve those metrics. But many of the rituals that are currently advocated for Agile development processes waste time on meetings that could more easily be worked out informally in a series of quick one-on-one conversations -- a style that is actually agile, rather than burdensome and officially Agile. In general, meetings that waste time should be reduced to a minimum. Conversations that have specific purposes should be encouraged. Large group meetings should be reduced, and one on one meetings should be favored. This style has worked well me over the last 20 years that I've been doing this. As to the details, and nuances, of getting the most from one on one conversations, I develop this theme in my book "One on one meetings are underrated, group meetings waste time."
• bkq 4y ago
  I get the hate for sprints, and the bastardisation of agile. I think however, the root cause of this is the way in which our society as a whole has been modelled, in a top down manner where control is wrested from the bottom, and perceived control is given to those in between. Each of these articles that make, valid criticisms in my opinion, always makes me think of Bullshit Jobs [1][2]. Most of our lives nowadays are inundated with menial bureaucracy, and each attempt to reform it within bureaucractic systems has simply lead to the red tape being rearranged. I think this stems from our hesitancy to have more horizontal models of ogranisation. [1] - https://theanarchistlibrary.org/library/david-graeber-on-the-phenomenon-of-bullshit-jobs-a-work-rant https://theanarchistlibrary.org/library/david-graeber-on-the... [2] - https://bullshit.ist/bullshit-jobs-how-our-modern-bureaucracy-created-them-836137ca7965 https://bullshit.ist/bullshit-jobs-how-our-modern-bureaucrac...
  • rloaderro 4y ago
    See also Yishan Wong's "Let process be implemented by those who practice it" http://algeri-wong.com/yishan/engineering-management-process.html http://algeri-wong.com/yishan/engineering-management-process...
  • Eddy_Viscosity2 4y ago
    I don't know that 'hesitancy' is the right word. It's just fundamental that people in power use it to seek more power. Even a small initial power imbalance will eventually lead to a large intractable one. Happens at pretty much at all scales of social (political, economic, etc) interactions. The only solution I see is to set up systems that make power accumulation more difficult coupled with a constant struggle to rebalance when it inevitably lopsided.
  • abricq 4y ago
    I really like your views on this problem. Never thought about it that way. I had some experiences where what you described was perfectly illustrated. It seems to me that the agile framework allows for each level within an organization (that perceives some sort 'control') to send the responsibilities to the level above, while making the decisions for the level below. Of course there are the daily meetings where this feeling of hierarchy is mitigated since everyone is included, but at the end these meetings really just focus on implementation details of the framework; and not on decisions to make the overall product better.
• arnvald 4y ago
  I agree with the title, but the article fails to deliver on the essence - saying "points are bureaucracy, backlog is bureaucracy" does not really say what is the problem, it does not explain what's an alternative to backlog that helps to solve the same problem (visibility of the work to be done, predictability, etc.) For me the biggest problem with sprints is that they force a continuous flow into discrete boxes. An extreme example I've seen was when as a mid-level developer I was told not to pick up any new tasks, because everything we start needs to be finished by the end of the sprint, and if I start a new task now, testers won't be able to complete it before the end of the sprint. Of course it was an abuse of the concept, but I hope you see the point - we shouldn't try to start every sprint with an empty board, because software development is continuous, and the fear of tasks "spilling" to next sprint, which I've seen multiple times, is just ridiculous.
  • js8 4y ago
    Why do you need visibility and/or predictability? I would say Steve Yegge's classic Good Agile, Bad Agile gives the answer - Kanban (or, more informally, a work queue).
    • robertlagrant 4y ago
      > Why do you need visibility and/or predictability? Because someone's paying you to do stuff, and they might like to know what's happening. The incredible rush of money into tech in the 2010s might have given the impression that that isn't a thing, but it is, and teams that can't self-manage (including giving visibility and predictability) are going to become encumbered with more and more people managers to compensate. What they should be doing is understanding their role, making sure it's fulfilled, and then taking that cash that would be spent on managers and spending it on engineers instead. But that won't happen if they can't communicate, or can't even see a need for communication.
      • js8 4y ago
        OK, I take it your answer for visibility is management reporting, I am not sure about predictability, you didn't really answer it. SW development is as predictable as much you're willing to invest into research/planning, and that very much overlaps (as observed in Kanban) with doing the actual work. When I started SW development in 2005, we had one meeting a week (Friday) with our boss, where we summarized what progress we made during the week. It was exactly what he and his superiors needed to know, not anything more.
• scld 4y ago
  (side note: there are no crappy teams, only crappy managers) is patently false unless the manager also has the power to add/remove people from their team or fire people.
  • asah 4y ago
    lol, there are crappy companies, crappy business models and crappy industries - any of these can make it hard or impossible to attract non-crappy staff/teams...
  • kortex 4y ago
    There are absolutely crappy teams, but I think what is more common is incompatible teams, or managers incompatible with their ICs. Many folks may be unproductive with one management style yet thrive in another.
  • bbarn 4y ago
    If that's the case, isn't that still crappy manager, if the manager below can't make the decisions necessary?
• T3RMINATED 4y ago
• hurril 4y ago
  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 very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place. Nobody has to like it, this is probably not the best method and maybe it's not even good. But the author misses the point completely.
  • 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...
• prionassembly 4y ago
  Eh. If you get ahold of a bucket of true geniuses, best thing you can do is not even give them goals and just feed them until Nobel prize/Manhattan Project level work surfaces. As you go down the scale, crisper and crisper goals are needed. This isn't an absolute either; I've been both the smartest man in the room, bogged down by scrum poker and similar inanities, on the one hand, and (elsewhere) someone with a vague understanding of the work needing some supervision to even add value to the team.
• inSenCite 4y ago
  Article seems more about management and tooling than anything else. No amount of frameworks or toolsets will solve a bad/broken management style. Agree with the other comment here about forcing cts into discrete flow. I've always seen sprints / scrum as a babystep to a kanban based method rather than the end goal from an operations perspective. But a bad management style would still trump this.
• gbro3n 4y ago
  Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2 weeks.
  • brightball 4y ago
    Wrote extensively about this a few years back and it generated a great discussion here. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355
  • LtWorf 4y ago
    In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.
    • haasted 4y ago
      Shouldn't that lead to a team discussion about why the estimates differ so drastically? In most circumstances, the reasons would be inaccurate assessment of scope or complexity. Clearing up misconceptions like that can be a great boost for productivity. "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."
      • LtWorf 4y ago
        It did. I said I would not stop doing it until he'd stop. So we just continued this way.
      • steveBK123 4y ago
        It inevitably does and then everyone slowly starts estimating everything at the middle point size in the agreed spectrum, with only 2-3 outliers
• SkipperCat 4y ago
  Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress. A good manager facilitates these items. A bad manager just throws tickets on a Kanban board. Sure, if you have a team that can do all the above without sprints, that's great. But I bet they have some other method or social structure that makes team management effective. Most software teams do not have that without some type of formalized structure, especially when new devs rotate into the team. So, I say stop criticizing the concept of a sprint and start holding your manager accountable for proper communication, effective knowledge sharing and realistic issue tracking. You wouldn't accept crap code, don't accept crap management. Do this and your sprints will add value (and the meeting will be shorter too!).
  • gilbetron 4y ago
    I'm with you about holding management accountable and avoiding crap management, but I think it is orthogonal to sprints. Sprints might be a solution for some teams, but I have seen them fail far more than succeed. Actually ... I've never seen them succeed.
    • IshKebab 4y ago
      I've seen them succeed. I think the differentiating factors were 1. everyone worked on lots of different bits of the code; there weren't bits that were "owned" by someone, and 2. the end goal was pretty obvious.
  • lelanthran 4y ago
    > Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress. The real problem, of course, is the word "sprint", which (whether you like it or not) implies something. A sprint, be definition, is unsustainable. It's Pythonic levels of hilarity that we adopted this word to describe software development. It's Shakepearean in the tragedy that so many defend it. Choose another word, like, "jog", "amble" or similar, and you won't see the same level of backlash against it.
• BirAdam 4y ago
  Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. Thing is, much like governments, these models all fall short because people aren’t great. I think that if agile isn’t working for a team they should try another method, and if agile does work for a team that’s fantastic. People, imho, shouldn’t blindly follow a methodology in religious fashion. They should try different stuff until something works for them.
  • criley2 4y ago
    The one thing agile helped here is to take that process and make it fast. The problem with "Requirements, prototype, feedback, iterate, qa, qa, qa, release" is that most large shops turn that into a 3 year process. As in, a group sits in a room for 6 months and writes some insane "Requirements Doc". Then six months of prototyping against it before any customer has seen anything. Etc etc down the line until you're a programmer looking at a 3 year old requirements doc with a thousand questions that arise during implementation but the designers who wrote the doc left the company two years ago, etc etc Waterfall was to me inarguably worse than agile. At least with agile people try to do requirements, prototyping and iterating in a very short period of time, so the feedback loop with customers actually works, and you actually release something on a regular basis.
    • deleted 4y ago
      [deleted]
  • kwanbix 4y ago
    > Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. That is agile for me. What is agile for you then?
    • websitescenes 4y ago
      I think maybe there is a conflation being made between Agile and Scrum.
• hankchinaski 4y ago
  Worked in many teams and company sizes. I prefer Kanban to scrum hands down. My hot take is that Sprints are a good tool for an incompetent manager who cannot exert pressure or plan work without a fixed structure.
• ramesh31 4y ago
  Me neither. Unfortunately my boss does, though.
• tychobrailleur 4y ago
  I wonder how in the author's world teams communicate? How do they communicate progress with other groups (potentially other teams they need to synchronise with for the release of features), how do they communicate with managers (ah those pesky managers, always wanting to know when a feature will be ready), how do they communicate with customers (ah those pesky customers. always wanting to know when a feature will be ready)? “Good teams don’t need sprints to get good work done.” No, and that's not the idea behind sprints and backlogs and tickets. It is primarily about communication.
• OJFord 4y ago
  Even just the language we use to describe it all is depressing isn't it? 'Sprint', 'tickets', etc.
• qznc 4y ago
  > Good teams don’t need sprints to get good work done. I agree. Most teams are mediocre though. A lot of processes have the goal to limit risks due to bad teams.
• marcus_holmes 4y ago
  Agree mostly. Jira is a nightmare. Sprints are pointless. But the backlog is useful. I find it amazing how what seems like a great idea when I think of it looks utterly pointless when I see it still on the backlog 3 months later. It's a useful tool to deal with our tendency to fall in love with our ideas.
  • d23 4y ago
    I don’t think backlogs are bad. The notion they’ll ever be fully groomed or in control is the pernicious fiction that makes people do weeks of useless busy work to get themselves back to the same place: a massive unwieldy backlog.
    • marcus_holmes 4y ago
      Agree completely. the idea of a backlog as a neat list of things we're definitely going to do someday is crazy ;) They're a holding pen for ideas. The good ideas get implemented immediately, the bad ones get deleted. And there's a huge middle ground of "yeah, I guess we could do that, but it's not urgent and there's other stuff to do first" that lasts forever.
• samatman 4y ago
  Rich Hickey has a great joke about sprints, paraphrasing: So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon... Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.
  • Kinrany 4y ago
    I liked the joke when I heard it. Reading it now, I'm realizing that "marathon" doesn't fit as a metaphor because we don't know the destination. Orienteering, perhaps: https://en.wikipedia.org/wiki/Orienteering https://en.wikipedia.org/wiki/Orienteering
    • petrocrat 4y ago
      Orienteering implies there's already a cartographer who made a map for you.
    • samatman 4y ago
      Marathon works perfectly to show how bonkers the idea of sprinting is. I like the idea of thinking of software development more as orienteering, if anything, it doesn't go far enough. To deliver full-featured software in time (note I didn't say on time, but there is certainly such a thing as delivering too late) is 10% velocity and 90% dependency resolution. I'm still looking for a tool which thinks primarily in terms of dependencies, and treats time as it is: fixed in the past and speculative in the future. I don't care if the person who put the information into the computer thinks something will take three weeks, I care very much if there are three projects which need completing before the main track can get past the third step.
      • klysm 4y ago
        I’ve always been confused about deps being an after thought in project management.
    • cool-RR 4y ago
• smallerfish 4y ago
  I believe in having QA as part of your software team. While developers need to own the quality of what they're shipping, a good QA person bridges the gap between engineering and product, and serves as a gating function for what gets shipped. You can't automate testing of everything, although certainly you need automatic testing where it is required or pragmatic. Blue/green is great, but when you're relatively small then avoiding any users having a shitty experience is a reasonable goal. Anyway, with a QA function, you need some kind of release cycle. I don't believe in prescriptive sprints where either developers are stressed to hit an arbitrary end of cycle deadline or developers sit on their hands because the phase of the sprint dictates no new work (which I've heard of happening in some particularly agile-diseased companies). I think a reasonably regular cycle that aims to ship what's ready fairly often is a good middle ground that keeps quality high, keeps the product evolving, and maximizes developer keyboard time (and of course you also need the ability to hotfix production occasionally.)
• Ensorceled 4y ago
  I've done waterfall, I've done Agile and I've done a couple of forms of "let the devs do whatever they want because they're really smart and only managers are crappy" I rank them as 1) Agile 2) Waterfall 3) Whatever it is this guy wants.
• senko 4y ago
  I tend to agree (prefer Kanban myself), but the article is full of assertions going in circles, without any claims to back them up. The only thing that comes close is "every efficient and productive team I’ve worked on has ignored the concept of sprints altogether". Okay, but why don't do scrum meetings, pointing, retros, or keeping Jira up to date, work. There's nothing in the article to address that.
• jpswade 4y ago
  If you have a high performing team, great, do what the fuck you want. If not, then chances are the team will need some guardrails, that’s what agile and scrum offers. It’s a place to start. Just because you don’t believe in having a system to break down work doesn’t mean it isn’t useful. Personally, I’ve seen the alternative in action and it always leads to burnout.
• youerbt 4y ago
  Sprints actually can help to do much less. If you don't do sprints, you can always be unsure if you did enough or take on more ambitious plans. With sprints, you agree to some more or less fixed delivery, so you can get it done and chill. Also helps that companies love to employ clueless people to organize the sprints and those tend to care more for jira to look good, than actual work.
• jbaczuk 4y ago
  sounds like it's not the sprints, but the managers that the author doesn't like.
• marmarama 4y ago
  Team members that are motivated by pressure and deadlines, and whose output varies day-to-day, greatly outnumber team members who diligently work through their list of tasks at a consistent and optimal pace. This is the fundamental reason why sprints exist. If you exist in an environment where all team members are highly motivated, consistent, diligent, and pulling in the same direction then yes, sprints are a distraction, but it is my experience that teams that are genuinely like that are rare as hen's teeth.
• jcmontx 4y ago
  I probably agree with some of the points of the article. However, when you're in a management position, you need some kind of measure that gives you previsibility. Not the best, not the worst. Serves a role.
  • thenerdhead 4y ago
    It would be wonderful to see more diverse management styles in the workforce and not everyone complying to a single mold. There's other ways to show progress and impact. Does it matter how productivity is shown if you can prove the former?
• lwhi 4y ago
  I don't want to be rude; but this essay really isn't useful. It's a rant. To the author: You don't like sprints or backlogs? Okay. So what's the alternative? Take step back, think about the problem that agile tries to provide solutions for. Now start thinking about new solutions .. spend some time; then write an essay that makes a difference.
  • marcus_holmes 4y ago
    Agile doesn't have sprints. Scrum has sprints. And Scrum is all about solving management problems not developer problems. You can just drop sprints without replacing them with anything.
    • lwhi 4y ago
      I'm sorry, but; no. Developers aren't the only part of a product team. You can't just drop sprints without failing to meet other objectives.
      • marcus_holmes 4y ago
        Sprints aren't the only method of agreeing objectives. You can just say "we plan on getting this done by next Wednesday". I've dropped sprints on 2 teams now, and improved our cadence both times.
        • lwhi 4y ago
          It's wholly dependent on the larger organisation. If you need to demo to gain stakeholder approval, and provide ceremonies like retros to disseminate knowledge to a wider team .. these events need scheduling. Randomly springing these on people without any regularity just won't work in most orgs.
          • marcus_holmes 4y ago
            sizing all your projects so they neatly fit in 2-week chunks also never works for every dev team I've met. There's always either some slack where the thing took 8 days not 10, or some part of the deliverable gets hacked off into another chunk so it fits. and, ofc, estimating the time to deliver is impossible, so you end up scheduling a sprint demo that might or might not happen depending on how well the project is going. Or, as I found, people are perfectly OK with scheduling demos in at short notice and being flexible about their expectations.
• onion2k 4y ago
  Sprints are like cogs. They enable teams to organise dependent tasks. If you're happy to just say "We'll write the code for this when the designs are done, and we'll finish the designs when the requirements are agreed" then you don't need sprints. If you want to say to people "We'll have this done in 6 weeks" then you need to have 'slots' where you can organise when the work is done. Those are sprints.
• filipn 4y ago
  Sprints are a good tool to transform bad teams into better teams. No amount of process and tools is going to convert a good team into being a great one. Great teams do not need additional processes to deliver value and they usually are more of an obstacle. Clear goals and a vision are much more important, as well as having an environment where the decision makers are the one implementing the solution.
  • denton-scratch 4y ago
    I've only once worked in a "great" team; it was a startup, they were all young and they weren't well-paid, but they were all intelligent, dedicated and knowledgeable. I once used to do college lecturing, and I've occasionally had a truly great class. A few star students energized the whole class, who were helping one-another and spurring one-another on. The best class was a beginner's C class, and I was eminently suitable to teach it, because I was a beginner C programmer myself /s. By week 3, they were well ahead of me. It's evidently possible to deliberately build a great team; but I have no idea how that's done. I don't know much about recruitment, and I certainly don't know how you can bring together a team like that C class.
• fosron 4y ago
  This is just a bad hot take. It does not even propose anything that's better. Just do work and it will be there? How? I'm confused. And, i, my self, don't believe sprints are 100% the best, but for us it helps to manage load, see how much we can do, and make sure everyone is on the same page. It's not a bible, it's just another tool in the chain.
• peteradio 4y ago
  My experience with agile: Sprints and standups are degrading tools to enable extremely subpar management to maintain their role. Tell me why a properly functioning agile shop even needs a manager.
  • shamiln 4y ago
    It doesn’t.
• thenerdhead 4y ago
  I don't care what anyone believes in, I respect your perspective. I think sprints and modern agile practices are an anti-pattern as practiced today especially in big tech. I've seen very few teams who operate like a well oiled machine using them though. What is important however is some type of shared vision or general plan. Not all teams are lucky enough to even have that. Some people treat their job as a job. Some people treat their job as their life's mission. Much of this definition gets lost in translation in the middle. In theory a team full of product-minded engineers / self-managing individuals don't need much to be impactful because they will know where to add value and make progress while being looped into the industry/customers.
• fooblat 4y ago
  For me this article joins a long list of "I don't believe in X" where the author has apparently only experienced bad versions of X. Most of the time with the articles, the answer to "X done poorly" is to switch to "Y done well" but doing X well would have likely worked too. Personally, my most enjoyable job as an engineer was when I worked on a project by myself in 1 week sprints. I spoke to my manager twice a week: 15-30 minutes Monday morning for "sprint kickoff" and 15-30 minutes Friday afternoon for "sprint wrap up" and how I spend the rest of the week was up to me. When a second more senior engineer joined the project it was even more enjoyable to work on it together in the same sprint format. Having a great manager also helps a lot!
• seymores 4y ago
  Why is this stupid “opinion” bubble up to the top of HN?
• wwilim 4y ago
  From the dev team's perspective, sprints are a good tool to force the business people to pay attention to you. Booking a few hours of your prospective end users' time each week helps ensure they focus on collaborating with you, think about what they want, and understand what you want to tell them.
• cies 4y ago
  Sprints and (point-based) estimations on tickets are not to improve software quality, they are to improve manageability of the software development process. If you work at a product shop, you might well be able to do without them. If you build software for clients, the planning is VERY important in order keep the client happy. Knowing ASAP that the project is going to miss a deadline/budget/feature is key to whomever manages the relation with the client. This is why we do sprints and estimations: to know how the project is going so we can update the client ASAP (or find another solution) when things are off.
  • adrianmsmith 4y ago
    Are your projects just two-week projects for the client? Or, if they're longer, do you plan out all the sprints in advance (which isn't really Scrum best practices as far as I understand?). I mean if you have a larger project (larger than two weeks) and you just plan for the next two weeks (as Scrum tells you to do, as far as I understand) how do you know that if you deliver this sprint you'll be able to deliver the project?
    • cies 4y ago
      you dont. but at least you know when you go off, and can inform the client timely.
• shamiln 4y ago
  Seems like the author is ranting hot air. I’ve worked in sprints. I’ve been a facilitator and an IC and now manager (aside from sprints). A bad team won’t improve with sprints. Similarly a good team might not always benefit from sprints. Almost every team I’ve worked with has improved with iterations and interactions. The best team I’ve worked with used sprints and communicated with stakeholders well… which in turn spoke true to the agile manifesto.
• websitescenes 4y ago
  I get the sense that the OP has never worked on a large team or massive product with a large surface area and competing goals. I get it, for a lot of smaller endeavors that only have a few devs then sprint ceremonies would be overkill. But if working on large project with many teams, the lack of structure would be almost certain death. Entertaining tirade though.
  • adrianmsmith 4y ago
    > for a lot of smaller endeavors that only have a few devs then sprint ceremonies would be overkill Nevertheless, such small teams (in my experience) use Scrum as well and it is indeed overkill.
  • denton-scratch 4y ago
    I've worked on a giant team for a massive product. 200 developers, a wall of specifications. The project was cancelled after 4 years, I don't know how many squillions it cost. It was called Global Wholesale Banking.
• vertis 4y ago
  The problem that a lot of people get to with Agile/Lean is that the actual practices deviate from the original goals. The powers that be can't actually handle agile in it's truest chaotic form. So it gets bastardised from the top down (and at times from the bottom up as well). Worse still some of the things that are advertised as 'agile' actually violate the principles. The card wall was supposed to be about as light a representation of ongoing work as you could get and facilitate the interactions with the teams. Unfortunately, tools like Jira change this to be an over-engineered process and tool (which violates point one of the manifesto). Remote work has not made this better. Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least. Leaving this to the side, I've seen sprints done well and badly. More often than not teams can't manage to point cards effectively. I've had a couple of teams where things just end up in a middle ground constantly (everything is a 3). The exercise of comparing this card to some previous representative card is too hard (and is itself prone to problems). Retrospectives, can be a useful tool, or they can be a back patting exercise. Showcases without a customer in sight (put your hand up if you're the "customer proxy"). Having said that, some of the behaviours can be really useful. Breaking down overly complex cards as a part of planning helps define the work. There are other opportunities to do this, but backlog grooming / planning sessions are one place. Having the team discuss cards and talk about complexity often reveals unknowns. I've seen a bunch of examples where things will be caught because of a dev/designer/product manager can see something that wouldn't have been identified if someone just started working on it.
  • P5fRxh5kUvp2th 4y ago
    > The powers that be can't actually handle agile in it's truest chaotic form. I would argue the word phrase 'software development' should replace 'agile' in that sentence. I liken it to boiling water. It's messy and chaotic. You'll eventually reach the goal, but until that happens you must be comfortable with a bit of chaos. Attempting to remove the chaos from software dev is like trying to tell mozart not to practice. You'll never get out of it what you think you will.
  • denton-scratch 4y ago
    > Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least. SCRUM and sprints lend themselves to "hamster-wheel management". That's an abuse, but it stilll gets labeled agile. Pair programming is amazing. Provided no pair has a total dullard (or worst: two dullards!), pairing with rotation quickly results in every member of the team knowing the whole project, so that any team member can pick up the work of any other team member. It also levels-up the skills of the whole team. Even mediocre devs can become good devs by working side-by-side with someone really good. On a per-task basis, I'm willing to grant that a pair might have lower velocity than two devs working alone. But the benefits of pairing with rotation for raising the standard of the whole team are striking. [I'm not saying that all work should be done as pairs; as in everything you have to use common sense.]
• mihaaly 4y ago
  I hate the word to begin with. Sprint. I do not want to rush through the work and squeeze into arbitrary time period but do it properly in the timeframe necessary (and not more). The hastle and rush atmosphere surrounding this word is repelling to me. As well as the 'stand-up'. Are we on exam in the school or what? Not being adult coworkers but people in entertainment or support group to present to each other? In other hand a flexible communication and progress tracking system - especially in a fairly unpredictible business like making a novelty product - is essential in teamwork and I know no better than something like this. But this childish naming makes me suspicious about the intention and goal of those coined it...
  • ISL 4y ago
    Yep. The primary bad thing about the Sprint is the name. If you call them "fortnight" or "week", things make more sense.
    • mihaaly 4y ago
      : )
• iLoveOncall 4y ago
  I don't like sprints either, but this take is so engineer-centric that it doesn't stand up on its own for one second. His ideal world works for a team of engineers that have no manager, no deadline, no collaboration with other teams, etc. Basically it works for a personal project. That's it.
• fredrikholm 4y ago
  Obligatory Rich Hickey: https://www.youtube.com/watch?v=zPT-DuG0UjU https://www.youtube.com/watch?v=zPT-DuG0UjU
• npteljes 4y ago
  Yeah, I don't believe in sprints either. IMHO the worst is actually the commitment for the sprint, the team shouldn't have that. They should just do the job, in their own pace, without being bothered by the end of the sprint, the beginning of the sprint, or caring about spillovers. I appreciate that deadlines couldn't be done away, as they are a fact of human life, but I don't see value in adding further overhead on top of that.
• unrestifarian 4y ago
  i think it's funny how speaking of Agile is like speaking of religion or politics. everyone has an opinion and it's always a spark to fiery conversation. like religion, I've seen Agile done poorly (extremely damaging and counter-productive) and done satisfactorily (not harming anyone with some mild benefit). theory is only half the equation, a big part of the equation is methodology and execution.
• trentnix 4y ago
  Sprints provide natural alignment for multiple teams trying to coordinate. They also provide data about how your team makes software, frequent (scheduled) points when change is acceptable, and repetition that allows habits to form. And for teams that struggle with it, they provide a great excuse to push back on a requirements team that refuses to provide details and struggles to break down requirements into chunks that can be addressed in the duration of a single sprint. That said, they aren’t magical. They are often misused. Not every team and every project needs them or is faced with any of the problems sprints set out to solve. And there are lots of ways to build good software.
• pammf 4y ago
  I feel most of the criticism towards Agile coming from devs misses an important point: how it’s used to show the progress of a project to the people outside of the team. Unless you are part of a completely autonomous team, you need to communicate progress in a way that’s more informative than saying “trust me and leave us alone, it will be delivered in X months”. Spending time in meetings or writing down and discussing what you think that should be done next indeed can create an overhead (even more when the frameworks is abused or done wrong), but epics, stories, sprints and demos provide a more detailed way of communicating and demonstrating progress to whoever it is relevant.
  • donatj 4y ago
    It’s horse before the cart though. It’s definitionally organizing work so it’s easy to understand and measure, rather than easy to actually work on. That’s not an optimal way to get work done. It’s metrics.
    • pammf 4y ago
      True, but metrics shouldn’t be downplayed given they are what boards/owners will be looking into when deciding to keep investing in a project or abort it - then both carts and horses become irrelevant. It is somewhat utopian to think that companies paying for the development of whatever will patiently wait for (and fund) a team for months without any evidence of progress stronger than the promise of devs/managers that one day it will be delivered.
• bsima 4y ago
  I’ve said this for a while now among friends: If I were running a company, there would be no shared ticket or todo list. Everyone can manage their own work and keep their own todo lists. The best employees already do this anyway. Basecamp’s “shape up” method is a nice way to coordinate work when everyone has their own todo list.
  • jjarvis 4y ago
    This! I am fortunate enough to belong to a small team which has mostly adopted Basecamp's "shape up" method and it has been a breath of fresh air. I think the biggest game changer is the notion of using the "appetite" (number of weeks per cycle) to drive the design of the solution. This is opposed to the usual approach of coming up with a solution and then estimating the points/time it will take to do each part of the project. SE's are bad estimators and the product manager rarely uses time as a design constraint. This is why most projects run past their deadlines IMO.
• Fredej 4y ago
  I agree to a large extent. For myself, I'm the most productive when I - Am able to influence what I work on, and choose how I solve a task - Have tasks lined up in a front of me that I can choose to work on - Am in a state of flow, where the tasks in front of me roughly corresponds to my skills. In other words - to me - a good project manager makes sure that there are plans for what to work on next and that the tasks roughly corresponds with the teams strengths. Now, that roughly corresponds with good "backlog grooming", but not sprints. Basically, I think Kanban works much better.
• sillyquiet 4y ago
  Sprints when used correctly are invaluable to a development team. Source: My own experience as a junior dev and a lead dev on teams working in this methodology. Note it's not useful in all (most?) scenarios or in all stages of a product's development. When you are in support mode for a product that's stable, standing up something from scratch, working on a POC or experimenting with frameworks or libraries - it's not useful, use kanban or something else. But when you are working on a/b tests or adding features to an existing product it's extremely useful. When done correctly: You get a two-way promise between leadership and a dev team. The dev team commits to getting stuff done within that <sprint-length> time - therefore they must carefully decompose work where that makes sense. Leadership commits to LEAVING THE DEV TEAM ALONE for that <sprint-length> time - no priority changes, no "Product Manager Chad had a dream if we implement X we get 1000% more revenue!", none of that nonsense. This means for bigger efforts, you get <sprint-length> chunks of working code "done" at time. This in practice means the devs drive how much they can get done in a certain amount of time - if a PM wants an earlier date out the door, that's <x> fewer sprints of decomposed work that gets done. The tricky thing here is the use of the term "correctly" above. Sprint-based methodology isn't a tool for management to dictate or predict performance and it's not a tool to micromanage tasking. If leadership DOES have this distorted view of it, then it is useless overhead to no benefit for anybody. It's also not useful at all if only the dev teams practice it - everybody has to respect the commitments required to do sprint correctly - if they don't, use kanban or something else.
• jordanmorgan10 4y ago
  To each their own, but... This blog post is my love language.
• cauliflower99 4y ago
  There is this notion that Scrum is supposed to automatically fix problems. It is the complete opposite - it is designed to DISPLAY problems quickly and ensure they are not hidden underneath a layer of fog. In other words, teams using Scrum will see more problems than the one that doesn't, but it's much better to see those problems than to hide or ignore them. Sprints ARE a tool used for planning, but not just by managers. A team can use their historic sprint data to PUSH BACK against their managers and say "No, we won't get this done in time. Now go away and fix your plans.". Other people mentioned this is a bad strawman...that's an understatement. But I think that's what the author wanted.
• deleted 4y ago
  [deleted]
• user_named 4y ago
  I'm a PM and PO. I have a scrum team of 5 engineers and 4 QA. Sprints are killing me. It's so exhausting. No rest, ever. And the retros are almost purely negative.
  • user_named 4y ago
    Before becoming a PM I had no idea engineers were managed in sprints. Horrible.
  • marmarama 4y ago
    PM is a full-time job on its own, and it doesn't match up well at all with being a PO! You should probably try and find someone else to do one of those roles. If your retros are super-negative, then try limiting everyone to one positive and one negative comment/post-it each per retro, and when you discuss the retro comments, talk through the negative ones first and the positive ones last so the retro ends on a positive note. Limiting people to a small number of comments forces people to consider the things that really got in the way rather than raising every little moan they have. There are lots of different ways of doing retros, and as PM you are ultimately in charge of facilitating a useful retro. If the retro is overly negative then it becomes less useful.
• jt2190 4y ago
  > Sprints don’t help organize things… You can’t talk about sprints unless you talk about the sprint demo: It’s the proof that the closed tickets actually represent completed work. > … they’re designed for mangares 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). That’s one take, but managers are just as likely as anyone else to B.S. their way through the tickets: “oh yeah that’s pretty much done”. The sprint demo clarifies what “pretty much” means. > … When you’re on [an efficient team]… then it’s easy to see how everyone else mistakes the bureaucracy around the work for the work itself. This is extremely true, and probably the main failing of any project management method. > … the backlogs, the sprints, the points—is pure bureaucracy. It gets in the way of productive folks… Again, we can’t talk about the sprint unless we talk about the sprint retrospective: It’s there to help the team identify tools and processes that are inefficient, and adjust incrementally through automation, elimination, or modification. One of the things that might get eliminated is the fixed interval sprint. Or replacing relative-size estimation techniques (“story points”) with something more rigorous. That “sprints” are used mindlessly is frequently true, but we should not dismiss them mindlessly either.
• manbash 4y ago
  Why do people excuse ideas they don't like as "bureaucracy"? It makes me sad.
• amyjess 4y ago
  My team switched from Scrumban to full Kanban last month, and it's the best thing we ever did. Everything just feels so much more natural and fluid now that we don't have sprints anymore. FWIW, Scrumban wasn't bad either, and it was way better for us than full Scrum would have been. The reason we switched was because we were basically operating like a Kanban team already, and the sprints were just arbitrary lines in the sand. We regularly had either a) tickets crossing over into multiple sprints or b) sprints we cleared out so fast that we had to start pulling tickets from the next one into the current one. And even after the switch to full Kanban we've kept the few Scrummy stuff that we like, such as biweekly retros.
• ejb999 4y ago
  in my experience - if you have a good team, it makes zero difference what methodology you use, they will deliver a decent or better product - conversely, if your team sucks, it also doesn't matter what methodology you use - the end product will be poor, if it works at all. All the ceremonies in the world aren't going to change either of those things.
• azangru 4y ago
  Oh my god! No, no, no, the author does not understand the purpose of sprints. Assuming the originator of the concept of a sprint is Scrum (and it's a big assumption; normally I'd check, but I am lazy and somebody is clearly wrong on the internet), then the purposes of sprints are: - to set a regular cadence/rhythm to work, and to set up periodic checkpoints for inspection of the done product and adaptation of the work that follows - within a sprint, to produce a done increment that brings the team closer to the product - by the end of the sprint, to allow stakeholders to inspect the done increment, to observe if anything is being done wrong or in the wrong order, to collect the feedback, and adjust, if necessary, the plans against the reality - and then to repeat the same over the next iteration, and the next, and the next
  • HelloNurse 4y ago
    In Scrum, the purpose of defining sprints is mostly, despite the name, to slow down between them, in order to allow for some planning and discussion; otherwise there would be only an endless stream of "urgent" tickets and requests.
  • JackMorgan 4y ago
    You missed one of the most important: to provide slack time. Ideally, the team will only commit to less than they can accomplish, so there is built in slack time to do research, training, tech debt, and proof of concepts.
• brycewray 4y ago
  [Michael_Jackson_eating_popcorn.gif]
• throwawaysleep 4y ago
  I have come to like sprints by not caring if the teams I am on succeed or fail. I can then collude with other devs to water down the amount of work done a sprint. Use their crappy tools against them and make sure your projects fail. You’ll be getting another job next year anyway.
• phatbyte 4y ago
  I think the author completely misses the point or never worked in a proper agile team. Imagine running a marathon without mile markers. Sprints are like mile markers they help you know and adjust your velocity and capacity to reach the end goal. Without these sorts of tools you are just running without any sense of achievement or tuning to your teams performance.
  • mobiuscog 4y ago
    Runners don't stop at every marker. Kanban can provide exactly the same information.
• neap24 4y ago
  I don't believe this is a strawman...at least from an outsider's perspective. As someone who has only ever written software independently, the very idea of agile and sprints (at least reading about them here and talking to friends) has kept me from ever wanting to work for a company that uses them. It seems like it would suck all the fun out of writing software.
• dhagz 4y ago
  Good teams don't need sprints, ergo sprints are bad is not a good argument. I'm not the biggest fan of SCRUM overall, but it exists for a reason. I saw in another thread/article here someone describe SCRUM/sprints as "training wheels for managers", and I feel that is incredible accurate. If I'm going to come in and start leading a team, I'm probably going to start with SCRUM just to get my feet under me and learn how the team works. After that, switching to kanban can be discussed, but there needs to be /some/ tracking to communicate timelines to the business at large.
• borbulon 4y ago
  Sometimes sprints are the right tool to accomplish what you need to accomplish, and sometimes they aren't. It really depends on what you're trying to accomplish. You probably don't want sprints if you're building something. You probably do want sprints if you have a release cadence.
• amadvance 4y ago
  I'm frankly puzzled how SCRUM sprints are even expected to work with a development + QA cycle. When a sprint starts, what QAs people are expected to do ? When the developers finish, and QAs start testing, what developers are expected to do ? It seems to me that this forced synchronization is just pointless and harmful. Where I work, we handle "sprints" just like checkpoints. This is in developing stage, this is in testing, this is done. It's expected that almost everything spans more sprints.
  • kiechu 4y ago
    Exactly! I have the same experience. It is a source of eternal frustration in the team. I had situations that everyone was crushing it, the team work efficiently and at the end the team had to go through the bashing on retro. There is an argument that you can always add features to the sprint, so you start small and then extend sprint with additional task. But it does not work, because tasks seem to take all the time that was planned for them. However, the rituals of SCRUM like retros and groomings taking place every 2-3 weeks is a good thing. It's like hygiene.
  • denton-scratch 4y ago
    > When a sprint starts, what QAs people are expected to do ? Dedicated QA folk are redundant! The devs write automated tests for all the code they submit. It's 20 years since I spotted a dedicated QA person in the wild.
    • mobiuscog 4y ago
      And then the tests are slowly scrapped to get the CI/CD build time down to 'seconds'. Who needs tests anyway, right ?
    • amadvance 4y ago
      We may not call people QA, but in the end each person has different skills, and the same problem will arise inside developers. Anyway, the same happens for any multi-phase cycle. Like with code review. When there are dependencies between people, you are going to need extra items to work on while waiting, and this fights with the requirement that everything should be done at the end of the SCRUM sprint.
• schwartzworld 4y ago
  I loved working in sprints. My last two jobs have used the term, but not the ceremonies, and it's not unusual for tickets to be quietly moved from sprint to sprint while in progress. Without agile ceremonies, the quality of tickets can really vary depending on who is writing them. I think there's something to be said for a group of devs looking at a task and deciding if there is a clear AC and discussing how difficult that task is. Without these sorts of ceremonies you can get into situations where you work at a task for days, put the PR up and then get told "Oh we probably shouldn't do this". This has happened to me multiple times at my current and last job. I also think that for certain types of people, the model of committing to a certain number of tickets for a certain block of time makes it easier to structure and plan that time. Certainly it does for me.
  • wwilim 4y ago
    I agree wholeheartedly, increasing quality of cooperation with stakeholders is exactly why I think it's great in certain scenarios
• aetherspawn 4y ago
  Ah yes another article that says we don’t need management tools, if only, our team was a small handful of smart people. And if the work gets too much then I guess we just work harder to the bone —- because woe us if we should possibly have to grow and delegate, let alone in a scalable, organised and structured way?
• perryizgr8 4y ago
  How is a backlog useless? Every company doesn't have an infinite supply of engineers. They can only work on a subset of the tasks you have planned. Backlog is simply the set of tasks that are not the most important thing right now. If you finish your spring early, simply pick up something from the backlog.
• agentultra 4y ago
  Ok. You don’t believe in them. You’re the lead of an 8-person team. How do you get everyone rowing in the right direction and shipping software? It sounds like you’d just leave everyone to sort it out themselves and believe they will build the right thing and ship it on time. I don’t think sprints are a required practice. I’ve used them with teams simply to help shield them from micromanagement and get them used to iteration cycles. They were held up on releasing anything until a huge batch of features was perfect. Only every deploy into production was met with a week or so of overtime fire fighting because the amount of change they were introducing to the production environment was too large and their staging environments were always under provisioned and didn’t have the same load. Sprints helped them break down work instead of crunching for months at a time. After a while they didn’t need it anymore. So you change things up. Where it goes wrong I think is when people start copying the practice hoping that following the rituals will grant them good software. You still need something though. A little planning goes a long way.
• bm3719 4y ago
  Sprints are a container of fixed size to put work into. This container can be useful sometimes, but that depends on the nature of the work being done, the humans involved, the group social dynamics, and a myriad of external factors. There are combinations of those parameters where the sprint is almost always the wrong container. As an example, take pure or applied research. I've seen such work shoehorned into sprints to the detriment of productivity, to the point of killing it almost completely. Related to this is that sprints and their associated concepts mechanize and formalize something that may or may not need such. Applying something like Scrum almost always has one engaged in motions that are disconnected or even counter-productive to the local environment. That said, it sure is a lot easier to pick a methodology off the shelf than it is to engage in sober, thoughtful, and rational assessment of your situation's organizational needs. There's also risk inherent in that too, but one effective counter to that is to incrementally add/subtract process as needed. Given the above, I consider process-heavy management to be a signal for prospective employment -- on the very much negative side. It tells me a few things, mainly about the way management's group mind works and also about what my future role in such a group would be (i.e., more part of organizational machinery than a creative agent). The last point I'll make is that I just find the experience needlessly draining. A job typically lasts years. It's more of a marathon than a sprint. If it was a marathon with a few necessary sprinting periods, that might be bearable. If you really are sprinting constantly (the next sprint starting immediately after one concludes), that's a good way to generate burnout.
• invalidusernam3 4y ago
  I generally avoid rants on HN, but I can't resist this one because this post is particularly irking. I absolutely hate useless opinion posts like this. They're incredibly vain. There is zero substance to the authors argument beyond "sprints are inconvenient". I can only assume the person who wrote this lacks much real world development experience, because anyone who has worked at multiple companies will tell you there is no one size fits all way of doing development. Post like this are pure Dunning-Kruger effect.
• user3939382 4y ago
  I've been bemused watching the rise of agile over the last (10?) years since my background is in building software for large/multinational non-tech companies. They have VPs and accounting departments with budgets and they want to know exactly how much they're spending before they spend the first dollar. Whether or not they should, they don't see the uncertainties in estimating software development as their problem. My solution to this is waterfall, and charging for a rigorous requirements analysis process up front, which I, in turn, estimate the cost of by having the client submit their requirements (as they know them so far) in detail in writing up front. I've been surprised in (the practical version of) agile how often time is wasted revising the same feature 5x that could have been done once if a modicum of time and thought was put into business and technical requirements. I am however a believer that people do things for a reason, it does probably have advantages for R&D or inside technical product companies.
  • marmarama 4y ago
    I have worked on agile projects inside large non-technical corporates and there are several big advantages to agile in such an environment. For example: 1. Much less time spent trying to chase requirements that are technically infeasible within the budget and rough timescales. This on its own normally more than makes up for iterating and throwing away proof of concept implementations of features. 2. Much better visibility of progress. Because you are delivering something tangible that stakeholders can see and feel all the way through the development process, you get better feedback from your stakeholders, better buy-in from your sponsors, and fewer canceled projects. 3. Where projects are canceled, they tend to be canceled early where they are clearly not working, before millions has been spent. The need for requirements doesn't go away with agile. If you start a project with no requirements, it will almost certainly fail. However the iterative process allows you to refine the requirements as you go, and the early and frequent feedback from your stakeholders makes the requirements better. It's easier to add or remove a requirement if you can see the software doing something wrong or not doing something it should do, rather than trying to figure it out on paper ahead of time.
    • user3939382 4y ago
• 29athrowaway 4y ago
  How else do you think a person that doesn't have any hard skills can control a team of experts?
• layer8 4y ago
  Does “pointing tickets” mean “assigning story points to tickets”? I’m unfamiliar with that usage (probably blissfully so).
  • denton-scratch 4y ago
    That's what I assumed.
• ThouYS 4y ago
  good for you dude
• the_other 4y ago
  < rant > I want to see the code produced by this non-system; and to learn its longevity, particularly beyond when key early contributors have left. I want to see the applications produced by that code and to learn the size of the teams, departments and companies around the products. This article carries little weight without some of that context. There's no meat to this article, just a rant about some management style the author doesn't like. The author goes so far as to say that only the managers can fail in software. This sounds unbelievable to me because we're all humans. Sprints, and points, are not JIRA. Points are not Sprints. Jira is not Scrum. These are all orthogonal tools that can work well together, in my experience. They don't always work well together. If you're doing Scrum well, you'll inspect what's working and what isn't, and change it. It's possible to change so far from Scrum you've moved on from it... but I haven't seen that happen and yet still found it useful in most places I've worked. People who dislike Scrum often complain that the defenders regularly say "well, you're not doing Scrum if you define it like that". They throw away the whole argument. Scrum that isn't Scrum, isn't scrum. You can't not-do a thing and then claim that thing doesn't work. < / rant >
  • P5fRxh5kUvp2th 4y ago
    What proponents of agile have a tendency to do is take anything effective and call it "agile". I've literally had people say "you're doing agile even if you don't know it!". You can't nail them down, it's always "oh that works? yeah, that's agile. Oh, that doesn't work? you're not really doing agile". --- And now let me say, I don't like scrum because it's a shitty way to write software. There's really only 2 ideas in agile that are useful. 1. iterative development, and 2. evaluate and change That's it. The rest don't matter and are often actively harmful. You don't need scrum masters, PO's, sprints, story points, ad nauseum. Can they be useful? Maybe, it really depends on the scale and needs of what you're building, but I'm going to argue that outside of business analyst, these roles should be developers that take responsibilities. yeah yeah, inb4 "scrum master should be a developer!". Ask yourself this. What is the difference between a tech lead and a scrum master? answer: scrum master is considered a career, tech lead is considered a skilled developer. The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business.
• gcapu 4y ago
  Someone my team either had a second job or quiet quit, but according to Jira he was really productive. The reported metrics can’t be trusted. The worst part is that our manager was the only one that didn’t figure it out.
• pablitoBR 4y ago
  Product in customer hands is your best sprint.
• rich_sasha 4y ago
  I think organizing software work is hard. It's easy if there are only maybe 2-5 people involved, objectives are clear and not conflicting. Usually though, you can't afford to implement every idea you have, you need to maintain old stuff while also making new stuff, teams have non trivial dependencies on each other's work, and time predictions are nebulous at best. Also software managers are generally software engineers first, not managers. Is sprint good at these things? I don't think so (though I never managed a team with sprints, only saw other teams do it badly). But is there a better blueprint? I'm not sure either. It's a hard problem, and hearing about what doesn't work isn't so insightful.
• pwinnski 4y ago
  Sprints are a great way to always have reasonable goals to work toward. They work best when there's a product team, or product manager and product owner, carefully managing the task. If you have a bad PM, or don't have one, then you're probably in bad shape anyway, and sprint might not help. I've worked with two-week and one-week sprints, and generally found them very helpful, but more helpful with better PMs.
• benreesman 4y ago
  I think the (unpopular) reality here is that there just really isn’t a lot of traction for one-size-fits-all project management. Methodology and even terminology has too much marketing budget attached to it to be trusted. There are some general guidelines, there is some amount of this that can be taught (not enough to sell a course or certificate), but mostly project management outcomes are dominated by the terms of understanding the domain in detail and the people involved as holistic human beings. Paul Graham said that the management of hackers for someone who isn’t a hacker can be summed up as “give up”. Don’t shoot the messenger please, but I agree with pg.
  • mwcampbell 4y ago
    > Paul Graham said that the management of hackers for someone who isn’t a hacker can be summed up as “give up”. Unpopular? On the contrary, I'd think that position would be popular with us hackers because it's saying what we want to hear, about how special we are. For that reason alone, I'm not sure I buy it.
• layer8 4y ago
  While I appreciate the value of timeboxing, one issue I have with sprints, at least of the 2-3 weeks variety, is that they make the process feel like an endless churn, because after the sprint-end is before the sprint-end, and the next sprint deadline is always close. It makes for a very uniform schedule with little variety, and the outlook of an endless stream of same-shaped sprints can be soul-crushing.
• talkingtab 4y ago
  The problem with stuff like sprints and agile is that you - the organization - need to understand why they are useful. If you don't then it is just cargo cultism. There are some great, as in large, problems with software development, as a result of having multiple parts developed by different groups, or even by one person at different times. The parts have to work together. It is easy, and I have seen this happen in multi-million dollars companies (plural) for groups to go off, develop their parts and for the parts not to work together. Boom. A sprint is designed to ensure that detecting this failure happens early rather than late. Can you have a sprint that does not help this situation? Yes. And if you do then the sprint is just foofaraw. The other problem is that it is easy and somewhat natural to write 90% of the code. Which does nothing. 90% of the code is meaningless. What works is the issue. No one needs or wants code. They need or want functionality. I have written some really really cool code that does nothing. It was 90% of something, but unfortunately had to be rewritten in order to be functional. The second use of a sprint is to show functionality. A sprint to have 92% code completed is nothing. Can you show (to me or yourself) that 90% of the functionality is there? The difference between 90% of the backend API's being functional (and being able to prove it) and 90% of the backend code being written is monumental. There is a final use of sprints. As a manager you can appear to know what you are doing by organizing sprints, when in reality you have no clue whatsoever as to what you are doing. If you want to be a good programmer, you will use sprints with yourself. I'm a sole developer and when I use sprints by myself I am much more productive. Much. [updated for spelling and clarity]
• charbull 4y ago
  Disagree. In one of the companies I worked for. Management decided to adopt safe agile. We had a dedicated agile coach for the whole department. Each team went to learn the safe agile principles and framework. The main focus was how do three teams get more aligned when building a solution: edge software, cloud software, application layer. I can say after 3 months of sprints. The productivity improved, people were happier and now we know which feature is used by whom. The requirements were forced to become clear so it be translated into designs and then dev work with the definition of done. When properly applied with the right intentions it is transformative.
• dbingham 4y ago
  (Sigh) This is just a religious pronouncement in a religious war. There are many processes out there - not just sprint, kanban, water fall, or "no process". Pick the process that works for your team. As an engineer and an engineering manager I have worked in strictly controlled water fall, "no process", well structured sprints, kanban, and scrumban. They all have their pros and their cons, their costs and their benefits. It's a question of what works for the team. Personally, I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say. Sprints with a heavy planning component work very well for that. But that's just my preference. Teams should decide what method they're going to use and commit to making it work. They should also be open to recognizing when it isn't working for one reason or another and be willing to try something different occasionally. The only piece of process I will always insist on is some sort of regular check in where we can introspect about the process and determine what aspects of it are and aren't working.
  • manmal 4y ago
    > I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say Are sprints necessary for knowing what other people are working on, and for having a say? I thought sprints are only tangential there.
    • droopyEyelids 4y ago
      Are you asking because you read dbingham as saying sprints were a requirement for that? I didn't interpret 'necessary' in there at all- but rather that method of organizing work tended to produce that type of result.
      • manmal 4y ago
        My question still stands - how are they related to each other? I can see what others are working on by looking at the issue board or just asking. And I haven't experienced that sprints contribute to devs having a say in anything.
• robotsquidward 4y ago
  https://ajkueterman.dev/posts/make-the-thing-better/ https://ajkueterman.dev/posts/make-the-thing-better/
  • robotsquidward 4y ago
    Actually another similar post on the front page at the same time: https://bigthink.com/progress/pessimism-is-a-barrier-to-progress/ https://bigthink.com/progress/pessimism-is-a-barrier-to-prog... It has a great opening line: > PESSIMISM SOUNDS SMART. Optimism sounds dumb. It’s no wonder, then, that pessimistic messages hit the headlines, and optimistic ones hardly get a middle-page snippet.
• mgkimsal 4y ago
  > side note: there are no crappy teams, only crappy managers I disagree. There are, in fact, crappy teams. You might argue that it's a crappy manager that either allows that team to continue in its current form, or simply doesn't recognize that the team is crappy, and does nothing, but... there are crappy teams. There are combinations of personalities and skills that are simply not suited to solving the problem at hand, and nothing short of removing actual people and replacing them with different people will 'fix' anything. Again, you can say that's down to management, but it feels like a word game. The team itself is 'crappy' for the goals at hand - management/owners (crappy or not) need to recognize and fix that.
• rs_rs_rs_rs_rs 4y ago
  I am surprised at the fact that there's so many PMs on Hacker News
• ngrilly 4y ago
  "Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles". I see them like CPU cycles, but for a team. They are a heartbeat keeping team members in sync. It's all about answering what's my next task when I'm done with the current one. If you I work alone, or in a very small team, with no external stakeholder, then I can answer that "just in time" and don't need cycles. But if I work in a larger team and/or with external stakeholders, then it's not practical to do this "just in time", gathering everyone to decide what should be the next task, every time a team member completes a task. In that case, we need to batch the planning work. That's what cycles are for. I agree with the author that too often the process feels unnecessarily bureaucratic, and I really dislike the "sprint" terminology, but I wouldn't throw the baby out with the bathwater. Cycles still have a purpose.
  • rcktmrtn 4y ago
    > "Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles". Agree. Actually, my first experience with Agile used the term "iteration" instead of "sprint" which I thought made much more sense. Everywhere else I've been has used the word "sprint". I suppose a "sprint" does includes three parts: start, run, stop; parallel to an iteration of the development cycle: branch, develop, reintegrate. My paranoid, anti-management brain still thinks the fact that sprint for most people is associated primarily with speed rather than starting/stopping is a feature, not a bug. In this case idea of always being in a "sprint" is inherently stupid and insulting. Anyway, another word to file alongside "grooming" for Agile words with unpleasant associations.
    • ngrilly 4y ago
      Yes, "iteration" is another good alternative. Good point on the start/run/stop semantic, but like you wrote, I guess most people associate sprint with speed more than starting/stopping :)
• benrow 4y ago
  Sprints really help at our place. We have a lot of different priorities and themes. Stakeholders have a variety of requirements, and cross team projects need to be aligned in time somehow. This is all hard to do IMO if there's one running backlog. The benefits of sprints I see is they're a useful time container for planning purposes. Eg: - we can allocate larger pieces of work to upcoming sprints. This is done very loosely just to get some idea of what we can take on, and when - we can allocate a fraction of each sprint to tech debt or platform improvements etc - set a goal for each sprint which is some observable step forward. This has taken practice to break down the work into appropriate chunks which can be verified done - record velocity across sprints just so we have a rough idea of what we can get done in a sprint (it will vary of course) Yes, there is overhead from the planning meetings. But this helps all of us get involved with incoming work, which I think is better than tasks coming from nowhere without context. I think the right methodology depends on the context of the business. If product teams need to work together towards something, or if there are competing project priorities, then sprints can help protect focus and provide finer structure than just "Q4".
• vinay_ys 4y ago
  In one of my past job, we were mostly pragmatic and humble engineers with strong ethos to solve most problems from first principles without ego or dogmas. We didn't have a company-wide mandate to use any particular methodology. Every week, a bunch of leads met to share their retrospectives and learnings. Without any corporate diktat, most application and platform teams were following a lightweight form of sprint. You would find whitewalls filled with vast end-to-end system flow designs and besides them there were sticky notes which roughly looked like Kanban board. These things just happened – no dogma driven push from anyone. In an even earlier job, I saw an overzealous 'scrum master' certified engineering director trying to ticketify everything with Kanban boards and burndown charts etc. Engineering teams under them hated it. It was the least productive period for a division of 100+ engineers I ever saw. Moral of the story: methodology matters a lot less than culture and talent.
• jrockway 4y ago
  I think the author got the right answer, but checking their work, I'm not sure they got it the right way. Sprints are actually really simple. You know how you work on something for a year, and then Google I/O is coming up where you're going to show it off to 3 billion people, and it's not done, so you just say "ya know what, I don't even CARE about these features we said we'd have" and you launch whatever you happen to have checked in on launch day? That's sprints! Except with sprints you do this every two weeks instead of every year.
• _8j50 4y ago
  My view as a customer: a simple change, could be changing ine character in one script will be delayed for two weeks or however long the sprint is. I would usually do all the troubleshooting and testing and basically handover the dev team a solution so that they won't keep delaying simple things for months. I like the concept but dislike the rigidity. Perhaps it might help if sprints were retroactive, that is you get shit done, create jira,etc... and it will be reviewed as things done in the sprint, instead od micro-managing tasks, set goals like "complete feature X and bugfixes".
• _shadi 4y ago
  the writer assumes that sprints are adopted to help the developers, while in fact its a tool so that product owners track progress in a way to have a shorter feedback cycle than in months. Of course its more convenient not to worry about sprints and time/points and "just work", and that is usually the case in startups or backend teams where the stakeholders are all always present in the same room, but once you add more layers to the organisation chart it becomes harder to track what everyone is focused on right now and that they are planning to do next without sprints or something similar.
• amarant 4y ago
  Personally, I also dislike sprints. I much prefer a kanban approach with just a big, prioritized to-do list, where devs just pick the top ticket and do that. Preferably a tech lead prioritizes the list together with the PM. But to be fair, I've worked like this mostly in places that have also enjoyed a continuous deployment way of working, with possibly multiple releases per day. In other places I can kinda see the point for "this is the stuff that needs to go into the next release" kind of sprints, but even then I'm not sure it's an improvement over straight up kanban. I kinda feel like Ockham's razor would cut the sprint from the ideal work method tbh.
• deleted 4y ago
  [deleted]
• gabrielso 4y ago
  I lost 3 minutes of my life on that article and will lose 5 more to let you know you can skip it. It's just a rant from someone that thinks they're too good to be managed, probably that kind of engineer that has 10 conflicts a week with everyone in the company because they won't budge on their unfounded personal opinions.
• 0x445442 4y ago
  One of the biggest problems with sprints is they’re organizationally orthogonal to CI/CD. Kanban is a much better process for an organization who’s goal is to continually deliver business value to stake holders. And it’s been my experience that pragmatic Scrum teams that just roll over unfinished work are essentially using Kanban.
• nso95 4y ago
  If you think Scrum is the "universal method for making software", you clearly haven't worked outside of applications software...
• yandrypozo 4y ago
  > software engineering has accepted as its charter "How to program if you cannot." Looks like this Edsger Dijkstra's phrase never gets old :)
• Ken_At_EM 4y ago
  My Project Manager's Response: "Nice rant. Sounds like he works with mystical unicorn teams."
• jeffersonheard 4y ago
  There are a lot of comments in here that imply sprints are a necessary evil if you want predictable delivery. I call bullshit. We don't do sprints. We don't do Scrum. We don't do story points. We have predictable, reliable software delivery on multiple products with an ever growing product development team of 65 people. It's all about measurement and mindful planning. We are strict about structuring epics vs. stories vs. tasks, and make the largest deliverable an epic. Epics set the scope of what we want to achieve. Then we describe user behaviors / experience we want to enable in terms of stories. The engineering, deployment, and design activities needed to enable those behaviors / UX are structured as tasks. We say when we want to be done with the epic and try to determine if the scope we have outlined for the epic is reasonable given the self-imposed deadline. Then we measure the growth of tasks in epics week to week. Tasks are expected to grow fast in the first 20% of a project and then start to taper off as more and more of the engineering takes shape. If we're not following that curve, we hold a retro. If we add stories or change the scope of the epic, we hold a retro. We adjust scope downwards or we change the estimate. We communicate the changes to estimates out to customer-facing teams early in these cases. The last large-scope new feature we built on our product was scheduled to take 4 months. They were behind by less than 2 weeks, and half the team were rookies. Oh, and no-one was asked to burn the candle at both ends to get us there. No saturdays. No 10pm conference calls between engineering managers and the dev team. There are better ways to do reliable, predictable software planning than sprints.
• coryfklein 4y ago
  One could write a solid critique of sprints and how they help or don't, and where time is wasted, but this article is overzealous and comes off as motivated more by anger than reasoning. If you want a well-reasoned discussion of where the waste is and isn't, I highly recommend Allen Holub's talk #NoEstimates [0]. [0] https://www.youtube.com/watch?v=QVBlnCTu9Ms&t=7s https://www.youtube.com/watch?v=QVBlnCTu9Ms&t=7s
• didgetmaster 4y ago
  Like every trade, software engineering depends on a set of tools designed to help 'get the work done'. These tools can be hardware (e.g. laptops, servers, test equipment), software (e.g. languages, compilers, source control), or methodologies (e.g. agile, waterfall). Each tool should be evaluated (and periodically re-evaluated) to see what its 'leverage factor' is for your situation. For every unit you put into it (time, effort, money) how much do you get out of it? The best tools give you a 10x or better leverage factor. If a tool gets in the way (i.e. it has a 1x or lower leverage factor) then it should be ignored. Some tools are just bad (they take more time and effort to learn and to use than they save you) and are generally weeded out. Some are great for certain situations but bad for others. If sprints (or any other tool) are not helping you and your team, then try to figure out why. Is the tool just not a great fit for our situation (e.g. using a hammer to try and fix a car engine)? Are we using it wrong? Is there something better? Too many companies and managers go for the 'one size fits all' approach. "This worked at my last company so it must work here too!"
• jbergens 4y ago
  He had me in the first half, not gonna lie.
• intrasight 4y ago
  I read as "I don't believe in spirits". Then replacing as I read was somewhat humorous. "Spirits don’t help organize things, they’re not a useful organizing tool" "Good teams don’t need spirits to get good work done."
• 9tacos 4y ago
• bartimus 4y ago
  It's true. But then also it isn't. Sprints (or Scrum) are useful when trying to force an Agile process within an organization that isn't Agile. If you're working in a true Agile company there's no need for sprints (or Scrum).
• nkotov 4y ago
  Ineffective standup and planning meetings are a waste of time, a lot of the time. But how do you truly know WHAT you should on focus and deliver without having a clear understanding of the broader picture and without breaking apart work for the week, especially with a team where everyone is at completely different steps and working on completely different things?
• hkon 4y ago
  Just read title. Me neither.
• dave333 4y ago
  Before sprints there was waterfall scheduling at the project level: requirements, design, development, testing, delivery, and maintenance. Often tasks would be late and delays would propagate resulting in the old adage for estimating how long a software project would take: think of a an amount of time it should take, then to get the actual time, double the number and then change the unit to the next longer time unit.
• alfor 4y ago
  Sprints are good to force a cycle of feedback on dev team vs customer. But they are not the problem you are trying to solve, just a tool. I like the concept of false idols in christianity: you must orient yourself toward truth and love (building something good and truthful). That must be your highest value. Money, prestige, UML charts, Sprints, those are all false idols, they will lead you astray if you worship them. Only worship truth and love.
• mbrodersen 4y ago
  Here is what works: 1. Maintain a To Do list for the project. 2. When a developer is available, he/she/it will pick the highest priority task to work on. 3. Use the To Do list when negotiating new features with stake holders. They have to decide where in the priority list the new task is added. 4. Break very large tasks into smaller step by step tasks that can be developed independently. It’s simple. It works. I have delivered successful projects most of my career using that method. As a single developer and when managing large teams of developers.