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 optionjust “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:
- 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.
- 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.
- 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.