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.
More About #Estimating&Planning
Sprint Goals: Why the Plan Matters Less Than You Might Think
This information will help you take a BIG step toward having product dev, service, and support teams be self-managing. (Yes, really!)
Sprint Goals: The Key to a Well-Executed Sprint
Sprint goals are key to a successful Sprint. They help keep the Scrum team on track and moving together in one direction. Without Sprint goals, the Scrum team can easily lose focus and get sidetracked. In this blog post, we'll discuss what sprint goals are and how they can help your Scrum team stay focused
How do you Plan for Support Time in a Sprint? #AskArtisan
Many Scrum Teams ask how to plan for support work in a Sprint. Can you plan the unplanned? There's no simple answer, but there IS an answer!
Can One Sprint Have Multiple Goals? #AskArtisan
Can you have more than one Sprint Goal in a single Sprint? I actually recommend it! In this video, I'll explain how it can improve Scrum team productivity.
How Are Product Goals and Sprint Goals Related? #AskArtisan
I'm often asked about Scrum goals; specifically Sprint Goals, Product Goals, and how they relate to each other. In this video, I'll tie them together for you.
What’s a Sprint Goal? #AskArtisan
Ever been out shopping only to get home and realized you didn't actually get what you needed? This is what happens to Scrum teams without a Sprint Goal!
What’s a Product Goal? #AskArtisan
The 2020 Scrum Guide introduced a new concept called the Product Goal, and many are still confused about the purpose and function of Product Goals.
What is Scrum?
The most popular Agile Development framework, Scrum, can be explained in many ways. If you're just trying to understand what Scrum is, this post is for you.
The Importance of Value to the Product Owner
Understanding outcome value isn’t just beneficial, it’s critically important. After all, delivering value is our priority!
Leave A Comment