5

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?

4

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.

  • Thank you Tiago... your suggestion makes sense. What is your view on this part "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)" – SSR Feb 7 at 9:53
  • @SSR, what is the reason they are not working on the same product? Is it knowledge or the nature of the tickets at that moment? – Bart van Ingen Schenau Feb 7 at 11:55
  • Hi @SSR, expanded my answer - hope this covers your question. Cheers! – Tiago Cardoso Feb 7 at 14:12
  • @BartvanIngenSchenau, its primarily the inflow of tickets that has caused the team to be designed that way and as a result the knowledge too – SSR Feb 8 at 6:15
  • @TiagoCardoso, Thank you! yes it does cover my questions. – SSR Feb 8 at 6:15
3

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!

  • You have opened up few more interesting threads in the conversation on Kanban. Not sure if I am allowed to deviate from my original topic (newbie in the forum), but I will still do it to keep the thread alive and learn more from your feedback, until someone chucks me out :) – SSR Feb 8 at 6:21
  • 1. We moved to Kanban because I was curious to find optimization scope in a high performing team. I call it a high-performance team because, they already practice the “pull” method and reorganize work based on a implicit WIP limit. When I proposed an explicit WIP limit, indicating the advantage of minimized context switch, one of the concerns raised was that we might actually slow down the through put by putting explicit limits. – SSR Feb 8 at 6:44
  • One possible answer – here we are attempting to move our way of work to the process and tool so that it does not depend on the people to drive and hence can be sustained over a period of time. – SSR Feb 8 at 6:45
  • 2. We moved to JIRA from Whiteboard because the team felt uncomfortable with their work being in the open on whiteboard and I wanted to give them the confidence that the action items that we retrospect on will be actioned! The team feels they already work together well. So I need to be very vigilant on what improvements Kanban is bringing, so that we can sustain this method. I have asked the team’s cooperation to pilot this for a quarter to really see the benefits. – SSR Feb 8 at 6:45
  • Thanks for your explanations @SSR :) - appreciate it! Some of the issues you have faced with your team regarding their discomfort with explicit WIP limits and having their Kanban board on public display perhaps indicates a low-trust environment. That means you have a bigger challenge on your hands. One more topic that I'd recommend you to see if it might help is the "Kanban Agendas", written by Mike Burrows (infoq.com/articles/kanban-agenda-part1-sustainability). Here is also a webinar with Mike that covers this topic- here (digite.com/webinar/kanbans-3-agendas) – Mahesh Singh Feb 8 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.