How can I foster more T-shaping within a Scrum team?

Question

As a Scrum Master and Agile Coach, how can I foster more T-shaping and elimination of silos within a single team?

All the team members are open-minded so I am sure they would let me try anything.

One person feels it’s her obligation to always do the dirty work even though she would like to be doing other work in upcoming work. And even though it’s the dirty work she actually seems to cling to it and not let others help.

The other person is different - he clings onto a specific type of work always and doesn’t ask for help even when stuck and doesn’t pick up a variety of work for some or other reason.

My initial idea was simply to be frank with each person in a 1 on 1 and tell them my observations.

Second idea was to find some kind of method or game or technique to use day to day with the team, during planning or something.

Does anyone have ideas how I can change this for the better?

Answer 1

I have held coaching roles in business for 30 years, and I find workplace coaches fall into two categories, which I call "life coaches" and "sports coaches." Life coaches say, "Have you considered trying this?" Sports coaches say, "You're going to try this." Very often people need to see the benefits of a change before they are willing to adopt it long-term.

So allow me to support your approach, speaking as a sports-style coach: There is nothing wrong with a coach pushing people to try something different. Sports coaches do it every day. The original human "coaches," believed to have been 19th-Century test tutors who borrowed the term from horse-drawn vehicles, absolutely told people what to do to pass the tests. (Thus the coach "drove them" to success!)

So, yes, retros and group discussions are the way to start. But if that doesn't work, it is perfectly appropriate for you to have a 1:1 conversation with someone. Again, sports coaches do it all the time. Second, it is also appropriate to say in a Sprint Planning, "We seem to have an ongoing problem with (whatever). We've discussed it a couple of times without making changes. So here is what I'd like us to try..." Emphasize it does not have to be a permanent change, but "let's try this for a couple of sprints and see what we think."

In this case, for Person A, start rotating the dirty work. For Person B, work with your PO to add user stories for cross training. I do not use the "T-shape" concept for psychological reasons: many people want to be acknowledged as experts at something (especially in companies that reward individual expertise in their appraisals/compensation). Instead I use a "head-and-shoulders" metaphor: retain your preferred expertise, but have at least two people who can do some of what you do. Pose it as a danger to the team. If a specialist wins the lottery and leaves, the team and customers will suffer. Here's my approach (free and open-source): Cross-Training.

Answer 2

Well, first, "t-shaping" is just abstract theory. It's not a goal that one can grasp. It's not something to achieve. It does not produce anything, earn anything or make anything better. So to change something, you first need to figure out what t-shaping means for your team. What benefits does it grant? Then, make suggestions to gain those benefits, so people can see you are not after a theory or buzzword box to tick, but you want to improve their lives.

As an example, you could say "Alice, I see you are the only person able to configure our reports. The business needs reports biweekly, and we have nobody who could do that. Bob, you are the only person that knows how to get that test harness to work in a production-like environment and we all know that production bugs are highly prioritized. As it is today, I have a hard time seeing anybody taking a nice, long vacation. This is a problem. I want our manager to be able to just sign off on vacations, without worrying how to get the results - and in the worst case denying you your vacation. So what about this: Bob takes the next reports and Alice fixes the next production Bug. Help each other out, get to know the tasks, so we can stand in for one another and nobody gets their vacation denied for silly reasons".

Obviously, this actually needs to be a problem. Don't make up a problem. If nobody got vacations denied ever, it doesn't seem to be a problem that you aren't t-shaped.

Find the problem that you solve through t-shaping, then fix the problem.

People will be on board when you fix their problems instead of hunting buzzwords.

Answer 3

It's important to realize that, in a coaching role, you should not "try anything" or "change this". You can point out the opportunity for improvement to the team, help them brainstorm potential ideas, and share your thoughts on the different options. However, in order to have a self-organizing and self-managing team, the team needs to decide to change and what methods they want to try.

In your situation, I would bring this up in a retrospective to the whole team. As a coach, you should be observing the team and their processes and interactions, and sharing those observations. Your observation is that people on the team tend to cling to certain types of work and your experience tells you that doesn't promote a cross-functional team. You can also explain the benefits of having a cross-functional team and/or the risks of not having a cross-functional team. Once you share this observation, it's on the team to decide if and how to take action on it.

As a coach, you can't make the team take action. Sometimes, the team won't see the problem with their way of working until something happens to make it obvious. If the team decides not to take action on this problem, that's their choice, as a self-organizing and self-managing team. I would recommend making a note and if problems arise from the lack of cross-functionality, continuing to bring it up at the appropriate retrospective.

Answer 4

how can I foster more t-shaping and elimination of silos within a single team.

By going ahead and doing it.

t-shaping means that people do stuff out of their comfort zone. Next time you need a DB problem fixed, ask anyone else but the DB expert to do it. Of course, he can pair up with the resident DB expert if he cannot work it out themselves. Allow for additional time, of course.

Elimination of silos means that people do not work alone within their mystical realm. Next time some component needs a new feature, make a conscious choice that it will not be implemented by the person that always did it, but by someone new. This is a great chance to find out whether the documentation that exists in your documentation system is enough for a new person to figure it out.

"You" means "the team". As the Scrum Master, you can send impulses as you see fit; depending on how open the team is it may be enough to get initial buy-in in the general ideas, and then gently remind them if and when they forget about it. If you want to take a more active approach, then that's just fine - i.e., ask a bit more insistently to switch the work around, and ask them to really give a good reason if they do not want to do it.

I've seen both work just fine; the biggest issue really usually was that things do take longer at first (which, at the core, is one of the reason why anti-t-shapes and silos are created, in the first place, since everybody always wants to be so efficient...). So what you also can do is to make sure everybody knows why t-shapes and not-silos are a good idea in the first place.

Answer 5

One thing you could suggest is for the team is to do more pairing.

For example, the team could have a rule that if only one person knows how to do a particular task they should pair with somebody else when ever they do that task. That way, over time, the team becomes more T-shaped as the knowledge spreads.

Answer 6

Many actual teams, quite without realizing it, are "lone wolves, in a pack." Their most natural mode of operation is therefore "pantsing" – as in "do it by the seat of yours."

And if you're not careful, your own role becomes just that of a "supervisor." Bad move.

A few ideas that have worked well for me have been to, first of all, each day ask the team to list every one of the things that they perceive that they need to do today. And then I prompt them, "so, could you tell us all a little more about how you plan to do it?" And, "can we help?"

A second idea is to ask people to "keep a Captain's Log." To write down what they're doing, are about to do, or see the need to do. And, in a private field of each closed "ticket," to document exactly what they did. I stress the need to make these entries right away.

In my own projects, I inevitably find this "Captain's Log" to be a valuable resource: "oh, I remember doing this, but how?" Well, I look back through my own logs and smile in appreciation at my former self, who at the time wrote down exactly and in detail what I no longer remembered. In a bigger projects, keep each one of these journals publicly accessible to the team.