also helps prioritize since features can be built without considering which knowledge is available. To coordinate between people with the same skills who are sitting in different teams you can have virtual team meetings as often as needed.
Scrum is best for beginners
I know, you can do all those things even when doing Kanban but they are optional and since they are optional you might just not do them just because you are too lazy to challenge the usual procedures or structures of your company. If you are new to Agile development it's better to have a method guiding you to do the right things. Just read the book and implement it. Later when you get used to it you can start experimenting and eventually get better performance. If you start experimenting too early you might end up with waterfall or chaos but still calling it Agile. Kanban is more advanced because you need to make a lot of decisions without having many facts.
This is why I prefer Kanban
Now it's time to take off the Scrum-T-shirt and put on my "I love Kanban"-hat.
Kanban is based on Lean principles
Kanban is Lean and has been around for 50 years and has shown to be successful. Things are seen as a flow without iterations. Not many rules. It's just a focus on reducing work in progress, strict prioritization and limiting demand after capacity. Besides that you have the normal Lean principles of:
- Just-in-time (decisions and facts just when they are needed)
- Short lead-time (quickly from concept to cash),
- Kaizen (continuous improvement)
- Minimizing waste (everything that is not adding value to the customer)
No meetings if it's not adding value to the customer. Most of those things are fine with Scrum but I can sometimes think Scrum has some waste. Here I will mention some areas where Scrum practices might be waste.
Estimations might be waste
If a product owner knows what needs to be done and the only goal is to have it done as soon as possible, why spend time on estimating? In Scrum, estimations are needed for a team to know how much to commit, to calculate velocity and for the product owner to decide on prioritization. If none of this is needed, it's waste and we shouldn't do it. If you like to measure velocity you can instead count the number of stories done per week or month. While talking about measurement why not look at something the customers are interested in, lead-time. That is, the time it takes for the customer to get what he or she ordered.
If the team is done with a story and there is not enough time left in the sprint to complete the next, it's likely no one works hard the remaining time and that's waste. Kanban is trying to get a steady and non-stressed but high flow of work running through development.
Sitting with people that can help you
In Scrum a team is cross-functional and sits together with the people working with the same project and not with the ones with the same knowledge. Let's say you work with sound effects for a computer game. Then it's not much help to have a java-programmer beside you. It would be more valuable to sit with people doing the same things as you do who can help you with tools and practices.
No possibility to commit
In Scrum, the team commits which does not work very well for a team with support issues. They get a lot of disturbance and commitment is not worth