No problem! Any questions you have, just ask us =)

Cool, thanks for the insights. As long as that works for you, that’s great. I was just curious to learn more details about your process. 🙂

Hey! So yes, in our clients we usually have a P.O. to the projects. We usually do the Daily, Retrospective and Planning (or Replenishing) with Kanban. However we don’t like to call it Kanban (or any other name), since we don’t follow any methodology by-the-book.. We try to implement practices that will improve the process, and not only follow a methodology.

The feedback loop on delivery and process is not long at all. Since we keep metrics of the process, and follow their behaviour everyday, we always have a clue on how the process health is.

About the P.O. being present, they usually are, but sometimes they don’t see the big picture and look at the whole backlog to reprioritize everything.

And this is not a ceremony that should always be used. If you don’t need it, that’s perfect! It means that all your other meetings are being transparent and efficient enough to deliver the information to the business area. And that is awesome! We ourselves don’t use it in all of our teams/clients… But the idea is to pass the knowledge of this kind of ceremony so, when someone has the problem where the business and technical areas are unaligned, they can act on it with a more focused meeting. Does that make sense? 🙂

Hey hey! Thanks for your reply. Do you have an On Site Customer (XP), or Product Owner how Scrum wants to call it, that represents the business and is available to the team? Do you do any other regular events like planning and retrospectives with Kanban and how long is the loop until you get a measurable feedback on the delivery and the process? I get the impression that the “Reality Check” is kind of a reactive meeting that happens at some tipping point vs having proactive meetings that could potentially deliver more continuous improvements but only if they are short, efficient and avoid waste. 🙂

Hey Dalibor! Thanks for your comment
Actually, the idea is far from being to weigh commitment levels, and it is good that you said that, because I may have lacked details on how to handle it. The questions that we make, on how confident the team is with finishing those stories, are to bring everybody to the same page on whether it is or not possible to finish that work, not talking exactly if they will indeed do it. After all, we are dealing with real people, real projects and real money, therefore if all tasks won’t be covered before the deadline, we may need to adjust the deadline or the scope, and it needs to be done asap.

So the idea is to bring transparency to the business side of the flow, in order to adjust the strategy. However, it is good to mention that, in order to avoid overwork and overtime like you said, it is good to remove all the “retaliation culture” that some teams have when they say something that may differ from the original plan. For example, if a dev thinks that something won’t be finished, he/she must say it and he/she must not suffer by saying it.

Besides that, when we use Kanban we not necessarily apply Sprint Planning meetings. So if you use Scrum, you indeed could do this reality check during the ceremony, however it could take much longer than necessary.