4 ms·

I used to work at Rally, who's product is literally to facilitate Scrum. We did not use Scrum. At one point we thought we needed to dog food better and tried us

by city41 3y ago

I used to work at Rally, who's product is literally to facilitate Scrum. We did not use Scrum. At one point we thought we needed to dog food better and tried using Scrum, and that lasted a few weeks. We used Kanban instead, and it worked pretty well. I think it's more realistic, doesn't get in the way as much and allows coordination and prioritization to more naturally happen. The downside is Kanban takes skill and experience to pull off well, which could be said about Scrum too.

regularfry 3y ago
Sometimes I think of Scrum as the thing that teaches you why (and how) you actually want Kanban.
sgarland 3y ago
Kanban requires either a team who is mature enough to know what is important to work on, or a leader who is able to translate business requirements to tickets, and to gently guide the team in that direction. My current company's SREs switched from Kanban to Scrum shortly before I was hired, allegedly because they were working on things that were fun instead of things that were necessary. Conversely, at my first SRE job, we did Kanban and it worked great. We met once a week, where my manager would discuss in broad strokes what needed to get done. Sometimes our Principal Eng would write a ticket to explicitly do something, but mostly we'd just figure it out on our own. Never once did anyone accuse us of being slow, missing work, etc. I love Kanban. It's the only tracking system where you get treated like an adult.
- brightball 3y ago
  Prioritizing what to work on is the same problem in Kanban or Scrum. This isn’t a differentiator between the two.
  - sgarland 3y ago
    In Scrum, I have to argue during a meeting why something in the backlog is important, and if I can successfully convince others, I then have to apply an abstract, unitless measure of complexity to that task, keeping in mind that not everyone has the same skillset. Worse, if the team completes all of their tasks ahead of time, we have to revisit Step 0 to decide what to pull into the sprint, and then discuss during the retro why we underestimated the length. In Kanban, I get shit done, and when it's done, I get more shit done.
    - gwynforthewyn 3y ago
      This is by one the dudes who invented story points, and is really worth a read: https://ronjeffries.com/articles/019-01ff/story-points/Index.html https://ronjeffries.com/articles/019-01ff/story-points/Index... It explains what they were aimed to solve, and acknowledges their modern day abuse. If you read Extreme Programming Explained ed 2, you see Kent Beck acknowledging them as an early experiment that they decided wasn’t useful.
    - brightball 3y ago
      The only difference between Scrum and Kanban in terms of work priority is that with Kanban you prioritize the backlog and take the next thing off the top. With Scrum you prioritize the backlog and try to forecast the volume of items from the top of that backlog that you'll be able to work into the sprint based on past velocity. You're not wrong about the arbitrary estimate. Prioritization is a function of the company and/or product team. If you need to do something in the sprint that you didn't know at the start of the plan, yes there are definitely scrum teams that would try to stop you because they are too strict with their process. Don't get me wrong here, this perception is a standard antipattern that you see in scrum shops. I've only seen a scrum team once in my career that was actually effective and I'm a huge Kanban advocate because of it. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355 But prioritization still happens at a higher level than the team itself. It has to because it defines the direction of the company. Most importantly, deciding what you're NOT working on so you can focus on what matters.

by city41 3y ago

regularfry 3y ago

Sometimes I think of Scrum as the thing that teaches you why (and how) you actually want Kanban.

sgarland 3y ago

Kanban requires either a team who is mature enough to know what is important to work on, or a leader who is able to translate business requirements to tickets, and to gently guide the team in that direction. My current company's SREs switched from Kanban to Scrum shortly before I was hired, allegedly because they were working on things that were fun instead of things that were necessary. Conversely, at my first SRE job, we did Kanban and it worked great. We met once a week, where my manager would discuss in broad strokes what needed to get done. Sometimes our Principal Eng would write a ticket to explicitly do something, but mostly we'd just figure it out on our own. Never once did anyone accuse us of being slow, missing work, etc. I love Kanban. It's the only tracking system where you get treated like an adult.

brightball 3y ago
Prioritizing what to work on is the same problem in Kanban or Scrum. This isn’t a differentiator between the two.
- sgarland 3y ago
  In Scrum, I have to argue during a meeting why something in the backlog is important, and if I can successfully convince others, I then have to apply an abstract, unitless measure of complexity to that task, keeping in mind that not everyone has the same skillset. Worse, if the team completes all of their tasks ahead of time, we have to revisit Step 0 to decide what to pull into the sprint, and then discuss during the retro why we underestimated the length. In Kanban, I get shit done, and when it's done, I get more shit done.
  - gwynforthewyn 3y ago
    This is by one the dudes who invented story points, and is really worth a read: https://ronjeffries.com/articles/019-01ff/story-points/Index.html https://ronjeffries.com/articles/019-01ff/story-points/Index... It explains what they were aimed to solve, and acknowledges their modern day abuse. If you read Extreme Programming Explained ed 2, you see Kent Beck acknowledging them as an early experiment that they decided wasn’t useful.
  - brightball 3y ago
    The only difference between Scrum and Kanban in terms of work priority is that with Kanban you prioritize the backlog and take the next thing off the top. With Scrum you prioritize the backlog and try to forecast the volume of items from the top of that backlog that you'll be able to work into the sprint based on past velocity. You're not wrong about the arbitrary estimate. Prioritization is a function of the company and/or product team. If you need to do something in the sprint that you didn't know at the start of the plan, yes there are definitely scrum teams that would try to stop you because they are too strict with their process. Don't get me wrong here, this perception is a standard antipattern that you see in scrum shops. I've only seen a scrum team once in my career that was actually effective and I'm a huge Kanban advocate because of it. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355 But prioritization still happens at a higher level than the team itself. It has to because it defines the direction of the company. Most importantly, deciding what you're NOT working on so you can focus on what matters.