A very common problem that many organizations have to deal with has to do with those “specialists” in the organization that are among the handful of people who have a particular skill. Common skills that fall into this category are technical writers, database architects, UI experience analysts, etc. The problem, of course, is that there aren’t enough of these folks to put them on Scrum teams.

Can you imagine a writer assigned to ten Scrum teams at the same time? Unfortunately, I can — I’ve seen it tried. No one can be productive trying to split their time across multiple Scrum teams. Here are some things that you CAN do to solve this particular dilemma:

• Cross train (by having the specialists provide some workshops) on the activities that are frequently requested but don’t require a lot of specialized knowledge to repeat. Creating triggers for common situations, creating simple views, etc. are examples.
• Develop a process whereby developers do some of these activities with the results being reviewed by the specialists with feedback that can be classed as a) must change, b) consider changing, and c) thoughts for the next time. This way, the activities get performed correctly (in the end) and the developer learns for the next time. Even better, try to schedule time effectively so that the specialist sits down WITH the developer when the work is being done. The feedback, and the learning, is immediate and effective.
• Teach the teams how to identify when the specialized skills will be needed so that, as they perform backlog refinement, they can “flag” Product Backlog Items (PBIs) that need special handling. ScrumMasters can then have up to 2 Sprints lead time to schedule a specialist to participate in the Sprint during which the flagged PBI gets committed. I had an entire organization embrace this concept with regard to their user documentation. Whenever they refined a PBI that they felt would have an impact on the user documentation, they would literally “flag” the PBI. The documentation team would see the flagged PBIs and follow-up with the Scrum team in time to join Sprint Planning. The writer would then work with the team over the Sprints during which the product changes were made and would update the documentation at the same time. When the product change was completed, the documentation would be as well. This saved weeks of delays caused by language translation because the documentation was ready when the product was.
• Avoid trying to work on multiple projects at the same time; this will help your specialists AND your teams by reducing risk and improving focus. In ANY situation, you’ll always here me arguing for better prioritization and less inter-leaving of projects. Making developers work on multiple projects at the same time always looks good on the status report but ALWAYS costs more in the end. But this is a corporate culture thing; as long as the organization believes that developers are interchangeable and context switching is not wasteful, there’s little you’ll be able to do except this…
• Try to get a rule in place where only a single project may be worked on in any given Sprint. You can still switch from project to project between Sprints (this Sprint on Project A, next Sprint on Project B), so everything will look like it’s getting done at the same time, but the developers will be engaged in significantly less context switching under these conditions.
• Shorten your Sprints to two weeks or even one week (hard to do) if necessary to carry this off.