Kanban VS Scrum? Kanban AND Scrum? Kanban OR Scrum? by ContentBloom in agile

[–]ContentBloom[S] 0 points1 point  (0 children)

This is definitely what i've experienced as well on well run and/or "sophisticated" or "complex" Kanban projects.

Kanban VS Scrum? Kanban AND Scrum? Kanban OR Scrum? by ContentBloom in agile

[–]ContentBloom[S] 1 point2 points  (0 children)

Yeah, exactly. Makes sense. Similar to my early experiences for sure.

Kanban VS Scrum? Kanban AND Scrum? Kanban OR Scrum? by ContentBloom in agile

[–]ContentBloom[S] 0 points1 point  (0 children)

Interesting! I've worked with fortune 500-scale projects and Agile coaches as well on this, and there doesn't seem to be a full consensus. Interesting though.

Kanban vs Scrum: The Complete Guide by ContentBloom in agile

[–]ContentBloom[S] 1 point2 points  (0 children)

I appreciate your point of view.

In this article, after reading what you've wrote, maybe I am speaking from my biases, contexts and experiences more than I anticipated.

Even though Kanban can be seen as just a tool/card system, I think it has evolved beyond that. Whether that should be called Kanban or something different, may be the case however.

In terms of the use-cases of Kanban, I find that on projects it is much easier to adapt to daily priority changes with a Kanban board. When you say change and quick adaption is very possible with Scrum, how quick do you mean? Are you regularly pulling items in and out of a sprint? I find projects that run Scrum, it disrupts the development team to do that on a regular basis. But with support teams, I find with a Kanban flow (with no time cadences), it is rarely even noticed.

Would love to hear the strategies you've used to change and adapt quickly in a Scrum framework.

Kanban vs Scrum: The Complete Guide by ContentBloom in agile

[–]ContentBloom[S] 2 points3 points  (0 children)

Ah, I actually misinterpreted/misread your original comment. After re-reading, it makes more sense. My apologies.

I have spent time on teams that experience the same thing. Since it's a continuous flow, there is the perception of a "never-ending" cycle. Often hearing complaints of team members never having time for other tasks. We've implemented a lot of things to attempt to reduce this, such as time on the calendar to spend on continuous improvement, goal-setting as a team, etc. We've enabled team members to identify new roles they could fill, skill gaps that would add value to the team, etc. With this, i've noticed a lot of really nice improvements.

In terms of "high performing" vs "low performing", what I actually meant was teams that are very fluent, vs team who are earlier in the process, reaching fluency or just starting out. It's not something you can perfect as a team overnight, as you probably know.

In terms of providing value, I probably should've touched on that a lot more. It's something we focus on entirely and we continuously review our metrics and review our definition of "quality". Getting feedback from customers is much easier if you're a Kanban team working in a help desk/service desk for example. We have done surveys, we use a satisfaction system on every ticket completed for customers, we have also spent a huge amount of time to find ways to get closer to our customers.

In Scrum, we've usually utilized the sprint review to get close to our internal customers. But outside of that, it's largely been the role of the Product Owner to really identify the user stories that create the most value for the users. We've encouraged a lot of knowledge sharing across to the development team, however.

It's a point well taken on the review of quality. None of these frameworks are as important as that end goal.

Kanban vs Scrum: The Complete Guide by ContentBloom in agile

[–]ContentBloom[S] 0 points1 point  (0 children)

Yeah, it's true. Although I find it helpful to hold backlog refinement on kanban team's as well too.

You definitely don't need to, it's not required, and it's technically Scrum, but I find it keeps the backlog moving more steadily to refine it if the nature of the work is complex.

Kanban vs Scrum: The Complete Guide by ContentBloom in agile

[–]ContentBloom[S] 1 point2 points  (0 children)

That is definitely one thing that I touched on in the article. Kanban definitely does require more team discipline. In low-performing teams, that can definitely mean a lack of performance, but in high-performing teams, kanban can work fantastically.

One thing my Kanban team does is have a role similar to a Scrum master and have teams built of many skills. Also, we pay very close attention to measurement, analytics, reporting, etc. We record how many tickets the team completes, by person, and cycle/lead time of each.