Standup Frequency & Content for Kanban

Question

I have started the practice of Kanban (with JIRA) in my team that handles customer issues for heterogeneous products. As part of this we have daily standups to discuss: 1. How is the flow 2. Any impediments 3. Any improvements are required

The challenge is: 1. Since changes happen slowly while handling customer issues at level 3, the team finds daily standup to be redundant. They are proposing to have standups on alternate days 2. Since not all members work on the same product, (though they are all part of the same product suite or are evolution of one over another), they dont see any value in discussing their work item with others and see it as a status update to me (manager)

What is the best way to handle this?

Answer 1

Focus on delivering, not on hosting ceremonies.

The main idea of having a daily meeting (in a support / maintenance context) is to socialise what's being done and identify potential points of assistance between team members, but also to increase teamwork in general.

You did great by avoiding the "what I did yesterday, what I'll do today, any blockers" script. Based on my experience, it's great for a planned delivery routine but barely applies on projects like support / maintenance.

With that said, the standup should work as the team needs. Experiment. Agile is all about experimentation and constant improvement. Do the meeting twice a week. You could help identifying potential cases that could've been addressed quickly if there was a daily meeting.

During next retro, discuss about the experience and keep fine tunning.

Edit:

Whenever you have segregation of duties between people on the same team, is good to assess how useful is to have them in contact.

See challenges as opportunies:: In our case, we have DBAs, Unix and Bigdata experts. Each work is very specific into their area, however there's ocasionally common related tasks where they can work together. Even if the amount of shared work is low, it's still important to share a moment to create rapport. Besides, a healthy team should be willing to increase their T-Shaped skills, and having them shifting low complexity tasks is a very good way to flex some muscles on unexplored knowledge areas. In your case it's even better - having more people knowing more products is always beneficial. I'd just suggest to run away from the full stack developer, unless you're willing to invest dangerous bucks on your team.

However, if there's low engagement between parts, you may consider having standups separately (and reassess if there's a single team or not). Again, experiment > assess > rinse and repeat.

Answer 2

SSR,

I think Tiago has provided some great perspectives and solutions to try out. I will just add a few things -

1. Kanban (the Kanban Method) is an "evolutionary method" to help you improve what you were already doing. It says - start with what you do currently, implement WIP Limits and Pull, and manage/ optimize flow. So, as yourself the question, how were you doing it before? Was the team happy with the process they already had? If yes, continue to do the same as earlier until your Kanban system throws up opportunities to change and improve.

2. Lean/ Kanban is all about the need and the desire to improve. One of Kanban Method's foundational principles is "Agree to pursue incremental, evolutionary change". As you and your team got started with Kanban, hopefully, there was some discussion on why you are implementing Kanban. (If there wasn't - perhaps it was simply driven by a decision to use JIRA :) - it's not too late to revisit that and present it as an opportunity to improve, grow as professionals and as a team, and deliver greater value to your customer such as reduced lead time, easier prioritization, improved SLAs, etc.

In my own experience working with different companies, as well as our own, teams often have issues meeting daily - and they have changed it to meet as often as it makes sense for them. In some cases, they have remained at 1-3 times a week, in others, they have gradually moved to a daily frequency and found benefit in that. Our own Dev teams meet daily, but our Marketing team, which also uses Kanban, meets twice a week - and it works for them.

Depending on the size of your overall team, and the sub-teams associated with each product - as also the number of different products - it may be feasible/ desirable to do the meetings product-wise. However, as Tiago said, there is benefit in picking up cross-product skills that some of the team members might perceive. Having cross-product expertise helps you balance demand variations across products more easily. In our case, we have a team of 18 people that support 3 products. They have a single daily meeting and almost all of them are able to work on 2 of the 3 products.

As Tiago said, experiment and improve continuously, even tho' some of the changes you decide to implement as a team might cause a drop in performance temporarily. In the end, you will see improvements and greater employee as well as customer satisfaction.

Good luck!