3 ms·

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 th

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.
    - robertlagrant 4y ago
      > OK, I take it your answer for visibility is management reporting, I am not sure about predictability Not reporting. Reporting is an internal function. People would like to know what's happening and what's going to happen, so that they know roughly what to expect for planning purposes elsewhere in the business, e.g. marketing. Not just reporting for its own sake.
      - js8 4y ago
        If you want to know how long it will take to develop a feature, just create a task for this research/design/planning and schedule it as usual in Kanban. Still, no sprint required.
        robertlagrant 4y ago
        I'm not saying a sprint is required. You were asking why visibility and predictability would be a good idea. Sounds as though I've convinced you!
        js8 4y ago
        > Sounds as though I've convinced you! Not really.. The PP asked how to do visibility and predictability without sprints. I asked, what do you need it for? You said, they are imposed externally. I said, well, if they are imposed externally, figure out the minimal requirements and do that. No need to do any extra bureacracy, they are not required for SW development process.
- deleted 4y ago
  [deleted]
- arnvald 4y ago
  You need visibility, because if something is done, but nobody knows about it, it's almost as if it wasn't done at all. You need predictability, so that people who depend on your work can make future plans (and I'm not talking about promising the day of delivery, but simple "this week / this quarter / this year / probably never") And yeah, Kanban is a good alternative, but the article does'nt mention it at all
kortex 4y ago
This is the best criticism of agile, and jira in particular. A lot of software work just doesn't box well. I've always struggled with "when is a ticket actually done?" Merge to main? Well we don't go straight to prod, we have a single staging env, so it usually cooks in staging for a few days before going to prod, and often testing has to be in staging due to the nature of our product. But tickets are usually "done" after merge. Then you gotta remember to QA. Honestly we need about 20% more screen real estate and 1/2 more columns for staging/prod qa.

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.
  - robertlagrant 4y ago
    > OK, I take it your answer for visibility is management reporting, I am not sure about predictability Not reporting. Reporting is an internal function. People would like to know what's happening and what's going to happen, so that they know roughly what to expect for planning purposes elsewhere in the business, e.g. marketing. Not just reporting for its own sake.
    - js8 4y ago
      If you want to know how long it will take to develop a feature, just create a task for this research/design/planning and schedule it as usual in Kanban. Still, no sprint required.
      - robertlagrant 4y ago
        I'm not saying a sprint is required. You were asking why visibility and predictability would be a good idea. Sounds as though I've convinced you!
        js8 4y ago
        > Sounds as though I've convinced you! Not really.. The PP asked how to do visibility and predictability without sprints. I asked, what do you need it for? You said, they are imposed externally. I said, well, if they are imposed externally, figure out the minimal requirements and do that. No need to do any extra bureacracy, they are not required for SW development process.
deleted 4y ago
[deleted]
arnvald 4y ago
You need visibility, because if something is done, but nobody knows about it, it's almost as if it wasn't done at all. You need predictability, so that people who depend on your work can make future plans (and I'm not talking about promising the day of delivery, but simple "this week / this quarter / this year / probably never") And yeah, Kanban is a good alternative, but the article does'nt mention it at all

kortex 4y ago

This is the best criticism of agile, and jira in particular. A lot of software work just doesn't box well. I've always struggled with "when is a ticket actually done?" Merge to main? Well we don't go straight to prod, we have a single staging env, so it usually cooks in staging for a few days before going to prod, and often testing has to be in staging due to the nature of our product. But tickets are usually "done" after merge. Then you gotta remember to QA. Honestly we need about 20% more screen real estate and 1/2 more columns for staging/prod qa.