Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
If technical skills of developer are very rare and specific and this developer hasn't full-time employment on one product, can he work with other product inside other Developer Team at the same time?
If "yes", whether he should attend on all Scrum events of both teams? What if his services are needed only for part of time of second project?
If technical skills of developer are very rare and specific and this developer hasn't full-time employment on one product, can he work with other product inside other Developer Team at the same time?
As @FrancisPeixoto pointed out, team members are most productive if they focus on one thing at a time without any distractions. Even within one team, as a Scrum Master I try to keep team members from working on too many stories at a time. In other words I set a Work In Progress (WIP) limit and keep a close watch on it. So, the answer to your above question is, no you should not plan to have team members assigned to different teams "at the same time".
Having said that, sometimes I have compromised on this for practical reasons. We had a database developer who had specialized knowledge and skills. I had him assigned to help more than one team at a time. However, as @DavidArno pointed out I had other team members shadow and learn the ropes so that we don't have to continue this practice.
If "yes", whether he should attend on all Scrum events of both teams? What if his services are needed only for part of time of second project?
If you ask them to attend all Scrum events for both teams, you will be wasting their time and they will get furstrated. In my case, I made that person a full-fledged member in one team. In the other team, I used to coordinate offline and bring them in only to the extent they are needed.
I've worked in several situations where resources were split in a matrix formation between projects, and I have to say, it's not ideal.
Developers need to be in "The zone" to be at their best. If you split them among parallel projects, you're asking them to switch contexts continuously. It usually takes about 10-15 minutes to get into "the zone", so if a developer is on 4 projects at a time, he's lost an hour a day just getting into context.
that's not including potential output quality issues. The more projects a assigned to the same resource, the more potential for mistakes and bad form you introduce. Imagine a developer who absentmindedly codes in project 2 with remnants of something he picked up on project 1. Or maybe he's distracted because he didn't really get into the zone yet, but he's being rushed by a pushy product owner.
Generally, we tried to limit the number of contexts because it also meant the devs didn't spend much of their time is as many scrum ceremonies. More meetings = less dev time.
If his skills are rare, but needed by your company, then they need sharing. So in the short-term, have him pair with people from both teams, to ensure those skills become less rare. Over time, the issue of splitting a resource across multiple products will go away and he can work on just one.
