Scrumban (?)

Customers “not responding” is a problem when they see little incentive to do so. In your situation, what incentive do customers have to respond to you, once work has reached the far right of the board? Closing out a ticket, for example, may give them no clear advantage and it might be seen as your problem, not theirs.

Try limiting WIP for each customer, ideally to single piece flow. No new work will be initiated for them until their currently in-progress ticket is resolved. This will help to build a leaner pull-based system, as opposed to an overcrowded one where work is pushed in.

Make your policies explicit, and support them with appropriate metrics such as throughput, cycle time and work item ageing. When multiple customers are involved, each may expect a certain quality of service, and hence you will need to guard against flow debt building up.

Thank you very much for your reply, Ian.

A bit more questions here.

So, the Customers should know the metrics and, hence, QoS rules, right? Then they could expect some sort of behavior from our side and that makes them more involved. Should we tell the Customer "1 request at a time" explicitly? What to do if technical debt tickets are blocking Customer request tickets in this case and this request is postponed because of some urgent fixes? What if several "not easy to do" fixes are required along with their request?

Should the Customers know about each other (and about each other's requests in this case)? Is it a risk from your point of view?

So, your proposal is - not to throw out crashed parts of the actual workflow chain, but to repair them.

And last question - if we use Kanban with WIPs, how could we give the Developers some sense of cycles, which are present in Scrum? Probably, to use the Scrum board (I know, Jira is only a tool, but still)? We are preparing the release system (which will provide cycles), but it is not ready yet.

My advice is that you should define your workflow, whatever it is, and make the policies by which it operates explicit. Start there. Examples include:

• deciding on single piece flow for each customer, or for the whole system
• limiting WIP in some other way, such as one item at a time for technical debt mitigation and one for customer requests
• there might be an expedite lane with a clear policy for its use
• service levels may be determined by product rather than by customer
• establishing a clear policy for how work is triaged, and by whom
• establishing a clear policy for when work is determined to have started and to have finished

Customers should know what the Service Level Expectation currently is, and any policies they must observe. They don’t necessarily need any metrics, but the Development Team will. They’ll need metrics to ensure that each SLE is being satisfied and optimized and that flow debt is being managed.

Thank you very much, Ian. That sounds perfectly reasonable for me.

Also, what is your opinion- should the Customers know about all the bugs, which are being fixed in parallel with their requests? 

If they are stakeholders in the product for which defects exist, then yes. Perhaps a slightly better question to ask is whether there is a good reason to reduce transparency at all.

Good question and, actually, I had just that in my mind :)

But let's imagine the situation, when Customers do not expect, that the Developers need to put significant efforts to handle technical requests (refactoring, etc.) - not their business requests. Transparency is a good thing. And I myself is proponent of transparency. But is 100% transparency a good thing? I have my doubts here.

One empirical approach may be too start with 100% transparency. If that causes problems, you should be able to inspect those problems and adapt the amount of transparency you offer.

If you begin with no transparency with your customers, it's much harder to inspect the problems you will encounter.

Of course there are lots of excuses and traditional practices that reduce transparency. In principle, some of these exist for valid reasons, but if there is low risk from making something transparent, I recommend you at least try it.

Hello, Simon. Thank you so much! You are right - transparency does provide the opportunities for inspection and adaptation. Just to repeat: I'm not against transparency. I was just curious how to find the balance. Because 100% transparency could be in one case helpful, in another case - harmful. Your reply -"at least, to try", probably, would be good first step.

Ian, thank you very much! All the replies were very helpful! I will think on the implementation. 

Have a nice weekend!

Best Regards,

Boris Kamenetskiy

What Simon suggested above, for me, marks the difference between the kind of open communication found in succesful agiles teams and the kind of secret-keeping I've encountered in hierarchical organisations.

Whereas hierarchies often work with a "need-to-know" approach, agile teams go for openness and transparency and only reduce it if problems arise.