9 ms·

Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefi

Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky enough to work on a team that switched from Kanban to Scrum, and then, mercifully, blissfully, back again. To be fair, I think we actually worked quicker after the return, though I don't know if that could be attributed to having actually learned some lessons from Scrum, or out of a fear that we'd one day return to it.

cjbgkagh 3y ago
“The process is the punishment”
leetharris 3y ago
Yes but raw velocity is not the only thing that matters. For some projects it is, but for many the accountability of Scrum + the grouping helps with dependency management across an organization.
- deleted 3y ago
  [deleted]
- emeraldd 3y ago
  Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it. Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...
  - irjustin 3y ago
    > It creates the illusion of accountability while creating artificial touch points I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless. > The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ... This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.
    - paulmooreparks 3y ago
      > This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible. It's interesting that you use this analogy. I've always compared Scrum to Communism or faith healing: If it doesn't work for you, you either didn't implement it correctly or you didn't believe in it enough.
      - enraged_camel 3y ago
        Right, exactly. In other words, the claims it makes are unfalsifiable, because if they don't come to fruition then clearly there must be some other factor in play.
    - emeraldd 3y ago
      > If your org treats accountability as "an illusion" then it's doomed to fail regardless. That was a reply to "...but for many the accountability of Scrum..." in the parent comment. There's an idea that Scrum creates accountability by making it possible to measure how well a team is meeting their commitments. It really doesn't. The metrics that Scrum exposes are little more than semi-random numbers. You're asked as a team to "commit to completing" some mostly arbitrary total of these numbers that has been determined to be your teams "capacity". The entire premise of this kind of estimation is fallacious on face. It completely ignores the skill level, overall capabilities, and specializations of your developers and effectively equates them to an common minimum of mediocrity. Worse, it pre-supposes that your team fully understands all of the places that a particular task can go sideways which is almost never the case. About the only way I can see it working is a situation where you know exactly what needs to be done, step by step, from or near the very beginning of a project. Otherwise, all you're doing with Scrum is forcing the team to make decisions on a Sprinted cadence rather than at natural break points along the completion of a project. This creates artificial delays, particularly when other teams are also working on sprinted cadences because you're likely to be requesting things that won't make it into some other teams sprint. Creating at least a sprint long delay before your team can complete their work, and well, breaking your sprint goals, etc.. Sigh ... Hence the accountability and predictability that's supposed to come out of Scrum is illusory at best and usually self deception.
- throwawaysleep 3y ago
  Thanks for confirming that Scrum is really for flogging.
bedobi 3y ago
What you're describing has been my experience as well across multiple teams and workplaces.
crazygringo 3y ago
But velocity of code written is not the same as velocity of value delivered. In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows. That's the whole point of agile, to deliver value rather than code.
- rqtwteye 3y ago
  To be honest I have never seen this materialize. Usually you get some input from product management, the devs estimate it and then do it. I have never seen feedback from estimation to requirements.
  - irjustin 3y ago
    Isn't that because the product manager is gathering requirements from other orgs/users? > I have never seen feedback from estimation to requirements. Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.
    - lazyasciiart 3y ago
      Yea, they tell you that they don't believe your estimates and stop asking for them before setting the deadline.
      - crazygringo 3y ago
        Then that's not agile. The entire point of agile is that a PM can't do that. Large estimates force a PM to go back to stakeholders and revise the desired features to something that engineers have consensus that should be deliverable within the next sprint given their historical velocity. If you're not doing that, then you're not even in any conversation about agile/scrum.
    - kqr 3y ago
deleted 3y ago
[deleted]
whitemary 3y ago
> Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. As an engineer on a team using scrum, this is my favorite part.
esafak 3y ago
If I am being generous, Scrum is for service teams, which can benefit from some of Scrum to temper unreasonable requests of senior stakeholders by providing a social contract on what is going to be worked on. More autonomous teams don't need it.
- Tagbert 3y ago
  I’ve always considered Kanban’s lack of sprints to be well suited to service teams where individual requests are not naturally tied to each other and there is no benefit of delaying delivery into sprints.
  - esafak 3y ago
    Everybody wants their ticket serviced ASAP. Scrum helps manage that expectation. If a sprint is underway, new requests have to wait for the next sprint unless an agreement is reached to drop an existing ticket.
    - 1123581321 3y ago
      Cycle time on a board gets you that as well.
      - esafak 3y ago
        This provides more visibility and granularity, increasing confidence and satisfaction of customers.
        DangitBobby 3y ago
        How? How is pulling 10 points of work into every two week sprint "more visible" or "granular" than pulling anything as it comes up at a velocity of 5 points per week? I'm not even being contrarian, I truly don't understand how sprints could be better than knocking down a work queue.
gre 3y ago
I did scrum once and we were literally always sprinting. The daily standup consisted of trying to think of excuses why the multiweek task wasn't completed (like they expected) and one dude who "zereo'd his inbox" every day.
- ptmcc 3y ago
  That the iteration unit of scrum/agile is called a sprint is a huuuuge pet peeve of mine. Sprinting is definitionally an unsustainable pace. I know, I know, it's just a label applied to the cycle time of the process but labels matter and I think it subtly and subconsciously poisons the whole thing. Especially when managers and PMs start making sprint cycles into hard deadlines.
  - seniorThrowaway 3y ago
    >making sprint cycles into hard deadlines One of the tipoffs that you are working under fake agile not real agile. I have the same problem with using the word "sprint" as well, but I think the true issue is that most orgs claim to be "agile" when they are actually doing some variety of waterfall with agile verbiage thrown in. The best test for fake agile is if you can't cancel the daily standup, even for a couple of days, via the retro.
- detaro 3y ago
  who is "they" here?
josephg 3y ago
I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. The sad truth is that most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. Especially if nobody can actually quantitatively measure the loss of efficiency.
- ptmcc 3y ago
  I agree. In my experience that outside visibility is mostly a mirage. Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years. In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.
  - rightbyte 3y ago
    Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all. -"It is impossible to do accurate estimates" -"You will get better at it" I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". Do anyone else share this experience?
    - emodendroket 3y ago
      Estimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?
      - gilbetron 3y ago
        Constructions remains a terrible analogy for software development, as it always has been.
tysam_and 3y ago
I've seen Kanban work well on smaller scales, and Scrum work well on larger scales. I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me. I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not. It's a case by case kind of situation, I think. That said I highly prefer Kanban personally for an number of reasons.
- Double_a_92 3y ago
  The commitment to sprints was literally the first thing that got dropped in our company. It's so nonsensical to create completely arbitrary deadlines without any real urgency. We now have long sprints (~1 months) for reviews and retrospectives. Which are usually well received. You get to see what all the other teams have been doing, and you also get a formal chance to talk about any problems.
  - kqr 3y ago
    Sprints and timeboxing more generally is not about enforcing deadlines. That's such a common misconception and I wish it would die. Timeboxing is about committing only a small amount of time and money at a time, so you can choose to double down on winners and stop investing in losers, rather than suddenly finding yourself having sunk 3 months of time into something that turns out wasn't that good after all. The question is not "How much can we definitely complete in two weeks?"; it's "What things are promising enough that we are willing to dump two weeks into them, with no promise of ever making a profit?" If one month counts as a small amount of time and money for your organisation, then you're doing it right!
    - 988747 3y ago
      [dead]
    - seniorThrowaway 3y ago
      It's not a misconception when it's what many organizations are actually doing. Any that implement SAFe, for instance.
fnordpiglet 3y ago
I have the software engineering uncertainty principle. The more you try to measure and estimate and predict software velocity and delivery the more you slow it down. I think this is probably true of any largely creative and problem solving task, but compounds because most of the uncertainty derives from dependencies requiring those dependencies to likewise measure and slow down. The more complex and interconnected an effort is the more scrum hurts it.
- hnick 3y ago
  This sounds a lot like the coastline paradox. The more precisely you try to measure a coastline, the harder it gets due to its fractal nature. Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire the latter.
  - moring 3y ago
    I think that analogy is broken. Measuring a coastline more precisely doesn't just become more complex (measuring precisely often does), but actually increases the measured length towards infinity. Unless you wanted to say that the same is true for software estimation, e.g. due to the measurements taking up more and more time.
    - hnick 3y ago
      Yes, I meant the time taken estimating. The act of measuring estimated hours becomes more complex because the closer you look, the more you see, you could do it forever and have to stop somewhere. But maybe instead of infinity, it's better to say estimation can take longer than the work itself which has been the case a few times for me.
throwawaysleep 3y ago
The only way better insight would happen is if the devs behaved like product managers/owners. We don’t want it. I can actually see predictability improving, but mostly because we will ship whatever at the end of the sprint and let any issues come back as bugs later. We always ship on time at one Scrum job, but the quality is very low.
BillyTheKing 3y ago
I think one key issue here is that Scrum without Extreme Programming and rigorous iteration can become a shallow process. Often, products that don't undergo much iteration are broken into arbitrary two-week windows under the guise of iteration. However, Scrum doesn't make much sense if you don't continuously iterate. Another symptom of this is people measuring velocity instead of value created. To properly implement Scrum, you actually need to measure the impact of the work completed in the past two weeks. Unfortunately, most teams don't do this, instead they focus on measuring velocity since it's easier and within their control. It's worth noting that it's completely fine for teams not to constantly iterate and change direction (including high-performing teams), and in those cases, Scrum simply isn't the best tool for the job imo. I must admit that I personally prefer Kanban for almost all workloads.
jrockway 3y ago
Is Scrum supposed to increase velocity? I always view these processes as a consistency enhancer. "What can we accurately promise 6 months out" vs. "how can we get the most done possible?" This is important because the big risk is that you do 80% of 10 projects, rather than 100% of 1 project, especially if you have a team and not just a couple of individuals. Lots of stuff pushes organizations in the direction of doing 80% of 10 separate projects, and it's a killer. This is good reading in this domain: https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213
Gareth321 3y ago
As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers. Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at odds and not communicating the pieces they're developing. A huge one for me is stakeholder alignment. Without scrum it's awfully common for developers to build things the stakeholder doesn't want. Scrum forces regular check-in and demonstration which otherwise rarely happens organically. A big part of scrum is accountability. As I touched on, when people aren't pulling their weight, it hurts everyone. Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other. Sometimes it's just agreeing on what they find acceptable behaviour and work. Sometimes it's adapting to different ways of work, or neurological issues with a team member. You might be surprised to learn that a lot of developers are on the spectrum. Scrum forces these conversations to the fore and provides a tested framework for conflict resolution. We also gain transparency. This is really important so that all the other supporting business functions can operate. Sales can communicate with customers about important updates and new features. Marketing can plan campaigns. Support can prepare. Finance can ensure adequate budget for new infrastructure and FTEs. Sure it's annoying, but this planning is essential for a business. It just doesn't happen organically. Scrum forces developers to work to some kind of schedule, offering short-term (but flexible) estimates on what can be delivered, when. In a perfect world, none of this is a problem, and all of it happens organically. I've just never seen that happen. The sacrifice in velocity is worth the increase in value output to the stakeholders.
- re-thc 3y ago
  You make it all sound like a factory and blame developers for going rogue. That’s not how it works. It’s as though developers are dumb and can only execute if you tell them to do exactly as needed. Rather where’s the leadership and direction? Perhaps that’s not clear or the developers don’t even agree with what’s going on. You statement is so 1-sided. If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems. I’d argue alignment is useless as most of the time developers are told to implement useless features. Perhaps with some guidance and direction what the developers come up with is better than product. It’s sad but product is like a theory machine that’s often impractical. So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year? Even if they do go off for a few months on their own it’s more than worth it. The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.
michaelcampbell 3y ago
> Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. This has been my experience. I've seen more than once management teams happier with numbers and estimates that weren't met than actually getting software out quicker at an unanticipated rate. They'd rather have estimates that they could yell about than revenue generating software through (presumably) happy customers. <shrug>

cjbgkagh 3y ago

“The process is the punishment”

leetharris 3y ago

Yes but raw velocity is not the only thing that matters. For some projects it is, but for many the accountability of Scrum + the grouping helps with dependency management across an organization.

deleted 3y ago
[deleted]
emeraldd 3y ago
Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it. Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...
- irjustin 3y ago
  > It creates the illusion of accountability while creating artificial touch points I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless. > The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ... This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.
  - paulmooreparks 3y ago
    > This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible. It's interesting that you use this analogy. I've always compared Scrum to Communism or faith healing: If it doesn't work for you, you either didn't implement it correctly or you didn't believe in it enough.
    - enraged_camel 3y ago
      Right, exactly. In other words, the claims it makes are unfalsifiable, because if they don't come to fruition then clearly there must be some other factor in play.
  - emeraldd 3y ago
    > If your org treats accountability as "an illusion" then it's doomed to fail regardless. That was a reply to "...but for many the accountability of Scrum..." in the parent comment. There's an idea that Scrum creates accountability by making it possible to measure how well a team is meeting their commitments. It really doesn't. The metrics that Scrum exposes are little more than semi-random numbers. You're asked as a team to "commit to completing" some mostly arbitrary total of these numbers that has been determined to be your teams "capacity". The entire premise of this kind of estimation is fallacious on face. It completely ignores the skill level, overall capabilities, and specializations of your developers and effectively equates them to an common minimum of mediocrity. Worse, it pre-supposes that your team fully understands all of the places that a particular task can go sideways which is almost never the case. About the only way I can see it working is a situation where you know exactly what needs to be done, step by step, from or near the very beginning of a project. Otherwise, all you're doing with Scrum is forcing the team to make decisions on a Sprinted cadence rather than at natural break points along the completion of a project. This creates artificial delays, particularly when other teams are also working on sprinted cadences because you're likely to be requesting things that won't make it into some other teams sprint. Creating at least a sprint long delay before your team can complete their work, and well, breaking your sprint goals, etc.. Sigh ... Hence the accountability and predictability that's supposed to come out of Scrum is illusory at best and usually self deception.
throwawaysleep 3y ago
Thanks for confirming that Scrum is really for flogging.

bedobi 3y ago

What you're describing has been my experience as well across multiple teams and workplaces.

crazygringo 3y ago

But velocity of code written is not the same as velocity of value delivered. In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows. That's the whole point of agile, to deliver value rather than code.

rqtwteye 3y ago
To be honest I have never seen this materialize. Usually you get some input from product management, the devs estimate it and then do it. I have never seen feedback from estimation to requirements.
- irjustin 3y ago
  Isn't that because the product manager is gathering requirements from other orgs/users? > I have never seen feedback from estimation to requirements. Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.
  - lazyasciiart 3y ago
    Yea, they tell you that they don't believe your estimates and stop asking for them before setting the deadline.
    - crazygringo 3y ago
      Then that's not agile. The entire point of agile is that a PM can't do that. Large estimates force a PM to go back to stakeholders and revise the desired features to something that engineers have consensus that should be deliverable within the next sprint given their historical velocity. If you're not doing that, then you're not even in any conversation about agile/scrum.
  - kqr 3y ago

deleted 3y ago

[deleted]

whitemary 3y ago

> Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. As an engineer on a team using scrum, this is my favorite part.

esafak 3y ago

If I am being generous, Scrum is for service teams, which can benefit from some of Scrum to temper unreasonable requests of senior stakeholders by providing a social contract on what is going to be worked on. More autonomous teams don't need it.

Tagbert 3y ago
I’ve always considered Kanban’s lack of sprints to be well suited to service teams where individual requests are not naturally tied to each other and there is no benefit of delaying delivery into sprints.
- esafak 3y ago
  Everybody wants their ticket serviced ASAP. Scrum helps manage that expectation. If a sprint is underway, new requests have to wait for the next sprint unless an agreement is reached to drop an existing ticket.
  - 1123581321 3y ago
    Cycle time on a board gets you that as well.
    - esafak 3y ago
      This provides more visibility and granularity, increasing confidence and satisfaction of customers.
      - DangitBobby 3y ago
        How? How is pulling 10 points of work into every two week sprint "more visible" or "granular" than pulling anything as it comes up at a velocity of 5 points per week? I'm not even being contrarian, I truly don't understand how sprints could be better than knocking down a work queue.

gre 3y ago

I did scrum once and we were literally always sprinting. The daily standup consisted of trying to think of excuses why the multiweek task wasn't completed (like they expected) and one dude who "zereo'd his inbox" every day.

ptmcc 3y ago
That the iteration unit of scrum/agile is called a sprint is a huuuuge pet peeve of mine. Sprinting is definitionally an unsustainable pace. I know, I know, it's just a label applied to the cycle time of the process but labels matter and I think it subtly and subconsciously poisons the whole thing. Especially when managers and PMs start making sprint cycles into hard deadlines.
- seniorThrowaway 3y ago
  >making sprint cycles into hard deadlines One of the tipoffs that you are working under fake agile not real agile. I have the same problem with using the word "sprint" as well, but I think the true issue is that most orgs claim to be "agile" when they are actually doing some variety of waterfall with agile verbiage thrown in. The best test for fake agile is if you can't cancel the daily standup, even for a couple of days, via the retro.
detaro 3y ago
who is "they" here?

josephg 3y ago

I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. The sad truth is that most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. Especially if nobody can actually quantitatively measure the loss of efficiency.

ptmcc 3y ago
I agree. In my experience that outside visibility is mostly a mirage. Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years. In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.
- rightbyte 3y ago
  Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all. -"It is impossible to do accurate estimates" -"You will get better at it" I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". Do anyone else share this experience?
  - emodendroket 3y ago
    Estimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?
    - gilbetron 3y ago
      Constructions remains a terrible analogy for software development, as it always has been.

tysam_and 3y ago

I've seen Kanban work well on smaller scales, and Scrum work well on larger scales. I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me. I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not. It's a case by case kind of situation, I think. That said I highly prefer Kanban personally for an number of reasons.

Double_a_92 3y ago
The commitment to sprints was literally the first thing that got dropped in our company. It's so nonsensical to create completely arbitrary deadlines without any real urgency. We now have long sprints (~1 months) for reviews and retrospectives. Which are usually well received. You get to see what all the other teams have been doing, and you also get a formal chance to talk about any problems.
- kqr 3y ago
  Sprints and timeboxing more generally is not about enforcing deadlines. That's such a common misconception and I wish it would die. Timeboxing is about committing only a small amount of time and money at a time, so you can choose to double down on winners and stop investing in losers, rather than suddenly finding yourself having sunk 3 months of time into something that turns out wasn't that good after all. The question is not "How much can we definitely complete in two weeks?"; it's "What things are promising enough that we are willing to dump two weeks into them, with no promise of ever making a profit?" If one month counts as a small amount of time and money for your organisation, then you're doing it right!
  - 988747 3y ago
    [dead]
  - seniorThrowaway 3y ago
    It's not a misconception when it's what many organizations are actually doing. Any that implement SAFe, for instance.

fnordpiglet 3y ago

I have the software engineering uncertainty principle. The more you try to measure and estimate and predict software velocity and delivery the more you slow it down. I think this is probably true of any largely creative and problem solving task, but compounds because most of the uncertainty derives from dependencies requiring those dependencies to likewise measure and slow down. The more complex and interconnected an effort is the more scrum hurts it.

hnick 3y ago
This sounds a lot like the coastline paradox. The more precisely you try to measure a coastline, the harder it gets due to its fractal nature. Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire the latter.
- moring 3y ago
  I think that analogy is broken. Measuring a coastline more precisely doesn't just become more complex (measuring precisely often does), but actually increases the measured length towards infinity. Unless you wanted to say that the same is true for software estimation, e.g. due to the measurements taking up more and more time.
  - hnick 3y ago
    Yes, I meant the time taken estimating. The act of measuring estimated hours becomes more complex because the closer you look, the more you see, you could do it forever and have to stop somewhere. But maybe instead of infinity, it's better to say estimation can take longer than the work itself which has been the case a few times for me.

throwawaysleep 3y ago

The only way better insight would happen is if the devs behaved like product managers/owners. We don’t want it. I can actually see predictability improving, but mostly because we will ship whatever at the end of the sprint and let any issues come back as bugs later. We always ship on time at one Scrum job, but the quality is very low.

BillyTheKing 3y ago

I think one key issue here is that Scrum without Extreme Programming and rigorous iteration can become a shallow process. Often, products that don't undergo much iteration are broken into arbitrary two-week windows under the guise of iteration. However, Scrum doesn't make much sense if you don't continuously iterate. Another symptom of this is people measuring velocity instead of value created. To properly implement Scrum, you actually need to measure the impact of the work completed in the past two weeks. Unfortunately, most teams don't do this, instead they focus on measuring velocity since it's easier and within their control. It's worth noting that it's completely fine for teams not to constantly iterate and change direction (including high-performing teams), and in those cases, Scrum simply isn't the best tool for the job imo. I must admit that I personally prefer Kanban for almost all workloads.

jrockway 3y ago

Is Scrum supposed to increase velocity? I always view these processes as a consistency enhancer. "What can we accurately promise 6 months out" vs. "how can we get the most done possible?" This is important because the big risk is that you do 80% of 10 projects, rather than 100% of 1 project, especially if you have a team and not just a couple of individuals. Lots of stuff pushes organizations in the direction of doing 80% of 10 separate projects, and it's a killer. This is good reading in this domain: https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213

Gareth321 3y ago

As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers. Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at odds and not communicating the pieces they're developing. A huge one for me is stakeholder alignment. Without scrum it's awfully common for developers to build things the stakeholder doesn't want. Scrum forces regular check-in and demonstration which otherwise rarely happens organically. A big part of scrum is accountability. As I touched on, when people aren't pulling their weight, it hurts everyone. Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other. Sometimes it's just agreeing on what they find acceptable behaviour and work. Sometimes it's adapting to different ways of work, or neurological issues with a team member. You might be surprised to learn that a lot of developers are on the spectrum. Scrum forces these conversations to the fore and provides a tested framework for conflict resolution. We also gain transparency. This is really important so that all the other supporting business functions can operate. Sales can communicate with customers about important updates and new features. Marketing can plan campaigns. Support can prepare. Finance can ensure adequate budget for new infrastructure and FTEs. Sure it's annoying, but this planning is essential for a business. It just doesn't happen organically. Scrum forces developers to work to some kind of schedule, offering short-term (but flexible) estimates on what can be delivered, when. In a perfect world, none of this is a problem, and all of it happens organically. I've just never seen that happen. The sacrifice in velocity is worth the increase in value output to the stakeholders.

re-thc 3y ago
You make it all sound like a factory and blame developers for going rogue. That’s not how it works. It’s as though developers are dumb and can only execute if you tell them to do exactly as needed. Rather where’s the leadership and direction? Perhaps that’s not clear or the developers don’t even agree with what’s going on. You statement is so 1-sided. If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems. I’d argue alignment is useless as most of the time developers are told to implement useless features. Perhaps with some guidance and direction what the developers come up with is better than product. It’s sad but product is like a theory machine that’s often impractical. So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year? Even if they do go off for a few months on their own it’s more than worth it. The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.

michaelcampbell 3y ago

> Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. This has been my experience. I've seen more than once management teams happier with numbers and estimates that weren't met than actually getting software out quicker at an unanticipated rate. They'd rather have estimates that they could yell about than revenue generating software through (presumably) happy customers. <shrug>