ฝัง
- เผยแพร่เมื่อ 29 ส.ค. 2017
- What’s your reaction to the following statements?
- Scrum is for product teams; Kanban is for service teams.
- Scrum is for complex work; Kanban is for simple work.
- Our Scrum team has evolved to become a Kanban team.
- We do ScrumBan.
- We do Kanban because we can't plan out for an entire Sprint.
- Scrum is revolutionary; Kanban is evolutionary.
If you agreed with any of these statements, this webinar will teach you concepts that will challenge how you view both Scrum and Kanban.
The webinar covers the following:
- How to improve your Sprint forecasting using common Kanban metrics.
- How to improve your Kanban team’s kaizen with Scrum’s events, roles and artifacts.
- How combining the Kanban practices with the Scrum Framework will enhance the collaboration across your teams. - วิทยาศาสตร์และเทคโนโลยี
When I was introduced to Scrum in 2007 it was an eye opening experience. In my team we not only wanted to create great products but also get better at how we did it.
We started talking about "waste" and our desire to limit it. We started talking about value and focusing on it. From that came the realisation that what we wanted to do was to limit the work in progress (all without knowing about Kanban or WIP-limits). If everyone in the team could focus on the highest priority item in the Sprint Backlog and we could quickly get that done we would be delivering a piece of value. This seldom worked for everyone so ofc we had more than one item In Progress at once. But having this mindset helped us to limit waste which would have had a high likelihood of existing if everyone started working on different items and we had the entire Sprint Backlog "In Progress" but not much actually made it to Done in the sprint and got us to actually deliver valuable pieces of functionality faster.
I've listened for only 39 minutes so far and it may be covered later but START anytime and improve rather that start with perfect practice or process. Don't try and setup all tools, processes, charts, burn down records, etc perfectly before you start. Start knowing you will improve.
Saying that one can pull aspects of one or the other is not the same as using one or the other: "Scrum/Kanban is for..." is still valid.
It's 2017, why is the term "Scrum board" still a part of the discussion?
The comment regarding about the meaning of the word "kanban" is extremely relevant. It's the reason that "capital K (tm)" exists.
The criticism of the term ScrumBan and the message throughout that they work together seamlessly is ~interesting~.
The word estimate appears nine times in The Scrum Guide. The responses barely address the questions instead discussing reviews and separate metrics.