Maybe take two steps back.

– why do you need to “convince” your team of anything?
– what is the problem that you, as a team, are trying to solve?

At a point, you are part of a team; you might have some specialist knowledge and specific accountabilities, but you are not the boss. Servant leadership doesn’t mean trying to force your team in a given direction.

Scrum, Kanban and Lean ways of working are empirical. We are data-driven, not opinion based. In fact we want to shift the whole organisation away from the “highest-paid-person’s opinion” (HIPPO) model and towards an environment where people are curious, open, and want to experiment.

And that starts with us. Exhibit the behaviors we want to see in others, is my counsel.

You have a solution “the team should swarm on tickets”, and yet what we are trying to move towards is the business bringing the team problems to solve, not solutions to be implemented.

Rather than convince the team of any given agile practice or process, I would suggest

– surface issue ideally in a data-driven way with your team in the retrospective
– work with the team to evolve a problem statement
– take that problem statement into an Ishikawa fishbone analysis with the team
– get to a revised problem statement from what they think is the biggest root cause
– brain-storm solutions together, which is where you can add your opinion
– determine what solution you want to try, as a team
– develop a hypothesis – what you will measure to determine success or failure
– do the experiment
– if the original problem still exists or resurfaces, redo the Ishikawa analysis

In doing this you give the team agency and autonomy, teach them problem solving techniques and have an opportunity to bring your knowledge to bare as part of the solution, without acting to control or steer them too much.

Giving a team solutions all the time, or forcing them in a direction you believe to be correct creates a dependency on you. That’s robbing them of an opportunity to grow..