I would even argue that points, stories and sprints are not things you need. If you go kanban, you don’t need sprints. You still need to be producing and you probably want to get a feel for complexity so you can prioritize, but that can be done without points.
Stories are also very scrum specific and you can turn them into whatever format you want. I usually still call them stories, but they’re basically just a little card that describes the context (why do want something) and the deliverables (what will be implemented to meet that want).
which I’ll fire back and say should all be team decisions. Usually with my teams I try to persuade them to go sprints at first while they’re getting to know each other, but Kanban is always a possibility. Thing with Kanban is that you need a lot of trust within the team and a lot of honesty, things like “This story is really really stuck and idk what I’m doing wrong” vs letting it sit there holding up the WIP count.
Oh, it should absolutely be the team’s decision and you’re also totally right that Kanban requires a more mature team. People indeed need to be able to recognise and ask for help when they’re stuck (which means being vulnerable, but also simply being able to formulate the right questions). People also need to be able to give feedback to their team members when they feel or see that someone is struggling or not delivering enough.
To facilitate I always have some form of retrospective in my teams, even when doing Kanban. Sometimes only once every other month, sometimes every two weeks. Highly depends on the maturity of the team and customer.
I would even argue that points, stories and sprints are not things you need. If you go kanban, you don’t need sprints. You still need to be producing and you probably want to get a feel for complexity so you can prioritize, but that can be done without points.
Stories are also very scrum specific and you can turn them into whatever format you want. I usually still call them stories, but they’re basically just a little card that describes the context (why do want something) and the deliverables (what will be implemented to meet that want).
which I’ll fire back and say should all be team decisions. Usually with my teams I try to persuade them to go sprints at first while they’re getting to know each other, but Kanban is always a possibility. Thing with Kanban is that you need a lot of trust within the team and a lot of honesty, things like “This story is really really stuck and idk what I’m doing wrong” vs letting it sit there holding up the WIP count.
Oh, it should absolutely be the team’s decision and you’re also totally right that Kanban requires a more mature team. People indeed need to be able to recognise and ask for help when they’re stuck (which means being vulnerable, but also simply being able to formulate the right questions). People also need to be able to give feedback to their team members when they feel or see that someone is struggling or not delivering enough.
To facilitate I always have some form of retrospective in my teams, even when doing Kanban. Sometimes only once every other month, sometimes every two weeks. Highly depends on the maturity of the team and customer.