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.

FEATURED RESOURCE:

FEATURED RESOURCE:

Scrum Framework Quick Guide

Download Now!

Swipe this FREE DOWNLOAD for a Scrum framework overview.

Normally available ONLY to Artisan students, we’re offering this handy guide to you for a limited time!

More About #Estimating&Planning

Speeding up Your Scrum Teams

Effective Scrum use is more than Sprint Planning, Daily Scrums, and so on. To see a big difference in your team's Sprints, make these workflow changes.

Limited Skills, Great Demand

Specialists with a particular skill can get stretched thin! But there's ways to solve this dilemma other than assigning them to ten Scrum teams at once.

Keep Your Eyes on the Sprint Goal

In this article, we'll discuss how a team bares responsibility for the Sprint and what should be done if they can’t get everything done they committed to.

Plan Only Small Backlog Items

Bigger requirements are more complex, which typically have greater risk, which leads to more cost and/or waste. In other words, bigger is DEFINITELY not better!