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.
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.