How can the L2 support team gain knowledge about the product? - Scrum framework

Question

This may vary from company to company. but in general, how is this done? Or, how should this be done?

This question is somewhat related to this and this. But not the same.
We have 5 dev teams and a support team (L2). L2 works on a roster, and for them, technical knowledge (related to the product) is a must. However, obtaining that knowledge has been a challenge. Since we have 5 separate dev teams (4 to 6 devs each), many changes happen frequently. Dev teams can arrange a meeting and give KTs (or, invite them to their meeting), but the problem is, the L2 team is working on a roster and can't get them together on one call. If we force them to attend the meeting regardless of their roster, it will not be fair to several members as they will have to sacrifice their off days.

So, since they don't have technical knowledge, they have to get support from the dev team even when they are off. Sometimes even in the middle of the night. Also, since this happens all the time, it becomes difficult for the dev team to achieve their goals.

We have dedicated dev members to support with L2, but that doesn't address the main issue. Although dedicated devs can provide knowledge transfer (KT) to L2 members on that day, sometimes KT between L2 can also be difficult due to the roster.

So, how can we avoid this? How can they stay up to date?
We have documentation, but it's mostly technical plans. Even if we add every little piece of information, in the long run, it may not be practical.

Answer 1

Before getting into development I worked for a number of years in a 2nd level support role. There are several things that come to mind right away:

1 - Documentation

We have documentation, but it's mostly technical plans.

It seems like your organization hasn't really given a serious attempt at documentation yet. If all you have are some some technical plans, you are bound to be disappointed if you just hand the support phones over to a support team and expect problems to get solved. Each system your support should have it's own wiki or knowledge base that is easy to search and use.

Even if we add every little piece of information, in the long run, it may not be practical.

Yes, it's going to be impossible to document every little thing. Start with the biggest problems that occur most frequently. It's is going to cost time/money from the development team, but it's a trade off from spending time on documentation and spending time having developer do support work directly.

2 - Specialization

We have 5 dev teams and a support team (L2).

I'm not sure of the size of your support team, but it does seem like that is a pretty high ratio of developers to support staff. Try breaking up the support staff into specialized roles. To start have each person specialize in one or two systems, not five. Everyone can't be an expert in everything. It's better to have support folks who are really good in a couple areas rather than really bad in all five areas.

3 - Managing Expectations

So, since they don't have technical knowledge, they have to get support from the dev team even when they are off. Sometimes even in the middle of the night. Also, since this happens all the time

It's unlikely you are going to come up with a system that 100% eliminates the need for developers to do at least a little bit of the support work (If you do call me!). Your goal should be to reduce the frequency of situations described above.

Use the support team to handle common/routine issues, not oddball issues that require extensive troubleshooting. I think my points 1 and 2 will help reducing the frequency of the issues, but it's a fact of life that sometime they will have to get developers involved to solve the issues.