3 ms·

Interesting, what I like about kanban is that (in my opinion) it explicitly recognizes that work proceeds through specific stages, and therefore tickets go thro

Interesting, what I like about kanban is that (in my opinion) it explicitly recognizes that work proceeds through specific stages, and therefore tickets go through a mini-waterfall. Waterfall is great with a small enough batch size. In contrast, scrum seems to pretend that design, development, code review, QA, etc, all happen at once throughout the sprint.

doctor_eval 4y ago
We are probably on the same page here but I would describe it differently. For me, there is a whole separate prioritisation and design process that runs ahead of the Kanban board. So by the time work arrives on the board, we have a pretty good idea of what we need to build. The difference is that in waterfall, by definition, we would build what we’re told. But implementation of a design should instead be an ongoing conversation/negotiation between the high-level designer and the low-level implementor. And that can result in big changes to the high level design as problems, inefficiencies or new ideas come up. That is the “hands on” management I mentioned. My way of working is heavily influenced by DDD. Design can only get you so far, and any process that imposes a top-down structure is IMO likely to fail.
1123581321 4y ago
They do happen at once if the stories are working slices of software, and they’re all in different stages. Agile planning has used kanban-style stage notation for a long time. It’s just not always laid out in a grid.
- satyrnein 4y ago
  On day 1 of the sprint, aren't they all in the same stage?
  - 1123581321 4y ago
    Not in our case. We’re breaking work into small stories that are self-contained improvements that can (usually) move into production independently of anything else. Typically an individual or team can complete more than one in a two week period. But either way, we won’t break them any smaller than that atomic “completeness” to fit into an arbitrary time interval. The sprint is just for automatic estimating of when we’ll get to a story, how often to demo progress to interested parties, etc.
    - satyrnein 4y ago
      In that case, we might only be differing on terminology. In my understanding, scrum's defining feature was the fixed time box. What you described sounds like kanban to me!
      - 1123581321 4y ago
        I would say we are using a mix of kanban tools and the scrum process to practice agile software development philosophy. We aren’t really using the kanban process since teams shepherd their stories to completion regardless of WIP at any step. And user research is more based on the continuously evolving end goal than what is being pulled in by openings in the kanban board. But yes, we are not trying to define two weeks of work up front, just noting what gets done every two weeks.

doctor_eval 4y ago

We are probably on the same page here but I would describe it differently. For me, there is a whole separate prioritisation and design process that runs ahead of the Kanban board. So by the time work arrives on the board, we have a pretty good idea of what we need to build. The difference is that in waterfall, by definition, we would build what we’re told. But implementation of a design should instead be an ongoing conversation/negotiation between the high-level designer and the low-level implementor. And that can result in big changes to the high level design as problems, inefficiencies or new ideas come up. That is the “hands on” management I mentioned. My way of working is heavily influenced by DDD. Design can only get you so far, and any process that imposes a top-down structure is IMO likely to fail.

1123581321 4y ago

They do happen at once if the stories are working slices of software, and they’re all in different stages. Agile planning has used kanban-style stage notation for a long time. It’s just not always laid out in a grid.

satyrnein 4y ago
On day 1 of the sprint, aren't they all in the same stage?
- 1123581321 4y ago
  Not in our case. We’re breaking work into small stories that are self-contained improvements that can (usually) move into production independently of anything else. Typically an individual or team can complete more than one in a two week period. But either way, we won’t break them any smaller than that atomic “completeness” to fit into an arbitrary time interval. The sprint is just for automatic estimating of when we’ll get to a story, how often to demo progress to interested parties, etc.
  - satyrnein 4y ago
    In that case, we might only be differing on terminology. In my understanding, scrum's defining feature was the fixed time box. What you described sounds like kanban to me!
    - 1123581321 4y ago
      I would say we are using a mix of kanban tools and the scrum process to practice agile software development philosophy. We aren’t really using the kanban process since teams shepherd their stories to completion regardless of WIP at any step. And user research is more based on the continuously evolving end goal than what is being pulled in by openings in the kanban board. But yes, we are not trying to define two weeks of work up front, just noting what gets done every two weeks.