How to manage Scrum and the Loaner Specialist

Multidisciplinary teams are fine and all that, but how to go about true specialists in the project … where do they fit in? I would like to talk a bit about Specialists who are required to do work for the team, but do not have enough tasks or time to actually be part of the team. First I will show why it is just not practical or feasible to make some people fulltime team members. After that I will drop some ideas on how to handle these situations. After some time, most organizations will get the concept of multi-disciplinary teams. The advantages of having teams consisting of designers / analysts, developers and testers become apparent pretty soon after trying this. Total project time goes down and quality of deliverables goes up. Of course having multi-disciplinary teams makes resource allocation much simpler than doing it the usual waterfall way where the developers could not start before the designers were done and the testers should be allocated after the developers did their thing. Nowadays, doing it Agile, all disciplines can be allocated about the same time for much of the same duration! But … there are projects out there which are doing Scrum in a cool and multidisciplinary environment, (so far so good); however, from time to time they need a specialist to do some work for the team. Such a task is specific in a manner that no one on the team has the skills (or authority!) to perform the task. An example could be that you need someone with knowledge about some (legacy) system to interface with. Ideally you would want one or more team members to learn that skill. In reality though, this is just not always feasible, e.g. would require expensive training for just a few tasks, interferes with another department’s turf (!!!), etc. . . There are several ways to handle this organization wise.

One option

just “loan” the specialist to do the task at hand and give him back to his normal department / job after the task is done. This option has the advantage of the specialist being distracted from his or her normal job the least while the team can continue with the other, “normal” team tasks, in the mean time. There are some drawbacks though:

1. Resource allocation!You might get a resource allocation problem since the specialist’s main responsibilities are in his / her day-to-day work. This would introduce a major and maybe even reoccurring impediment for the team, since the specialist is not always available to do work for the team when required. This problem can be dealt with by reserving some time in the specialists “normal” schedule, so helping out another team doesn’t conflict with his / her day-to-day tasks. Another thing is to try and identify the specialist task well in advance (maybe even a sprint in advance) so the required time can be allocated.
2. Is the specialist committed (enough)?Another risk is that the specialist is not as committed to the projects results as are the other team members. The commitment problem should ideally not be there at all, since all people within the company hopefully share the same company goals. It would be obvious that the project results contribute to the company’s results, thus anybody committed to the company results should be committed to the project results. Note that a lack of commitment usually is a result of people being called on not getting “their own” work done and / or do not get credit for lending their specialist services to (other) projects. So this can be helped by freeing up some time to help out your colleagues.
3. Task switching is a major form of waste!As most of us know: task switching consumes lots of time and should be avoided as much as possible. Therefore: try a save up several tasks for the specialist which can be done sequentially. You won’t avoid task switching all together, but at least you can try to minimize it.

For this option you’ll have to make very sure all prerequisites for the specialist’s task are met before the specialist starts. In general people find it very annoying having to lend their services to a team when the task is not yet completely outlined.

Another option

Add the specialist to the team for one or more sprints. This requires the specialist to be exempted from his normal duties of course, but immediately gives him the much needed focus to do the job right. Biggest problem with this solution is: who’s going to do the specialists “normal” job while he is busy helping out with the project. Usually this is something that can be worked out with other specialists or a department manager just fine. As long as the period the specialist is unavailable for normal duties is not too long and plan able.

Overall

For both options it is best if the specialist can work in the team-room for the duration of the task / sprint. This encourages communication, minimizes distractions from the “normal” job and gives the specialist the feeling of being part of the team. Whatever for you choose, make sure to evaluate it! During retrospections and other feedback moments, find out whether the chosen solution works for both the team and the specialist and find out whether you can improve on it. You might find that some skills can be learned by the “regular” team members after all or you need more of the specialist’s time so he / she can be added to the team.

Conclusion

in some cases it is just unavoidable that you need a specialist to do some tasks that the “normal” team members are just not trained for or skilled at. I like the solution best to add the specialist to the team for one or more sprints until the specialist job is done. But loaning the specialist for the duration of the tasks at hand can be more practical when there is just not enough work for the specialist to fill a sprint. Beware of task switching though! It is one of the majors forms of waste!