Epicor ERP Software
Search
Serving on Multiple Scrum Teams Simultaneously

A few posts back, Dawn wrote about writing technical documentation in a Scrum environment. She provided an excellent overview of what Scrum is and how to navigate it as a writer, so I won’t retread her ground here. Instead, I would like to address an aspect of Scrum development that seems unique to writers: serving on multiple teams at once.

Ideally, the way Scrum works is that everyone on a team is a 100% dedicated resource. While developers and QA analysts might have some other small tasks to do while working in Scrum, their primary focus is the team. However, a technical writer might be split between two or more teams, sometimes as many as four or five. When that happens, keep the following in mind.

1. Let it be Known
Your Scrum master has an expectation that all the people on his team are there to work on his team 90% or more of the time until the close of the last sprint. If you’re on multiple teams, you can’t do that. Let your Scrum master know this at the team kickoff. It’s important he knows this.

2. Pick Your Meetings
Scrum is a meeting-intensive development method. Scrum prioritizes its backlog into “must haves” and “nice to haves.” In a pinch, you can apply the same to meetings. Every team has the following meetings:

    • Daily Standup – 15 minutes in which everyone says what they did yesterday and what they plan to do today.
    • Story pointing – 2-4 hours in which the product owner explains the stories (features) that the team will be addressing, and after a brief discussion the team assesses its work effort. Occurs at the beginning of the sprint, and pops up again when non-assessed stories are considered later in the process.
    • Sprint Planning – 1-2 hours in which the team determines which stories they will address in the coming sprint. Occurs every two weeks at the beginning of a sprint.
    • Retrospective – 30 -60 minutes in which the team goes over what went right and what went wrong and how processes can be shored up to make the team better. Occurs every two weeks at the end of a sprint.
    • Demo – 30-60 minutes in which the team presents the work it completed in the last sprint to stakeholders. There is often an internal demo first, followed by one for customers.

That’s quite a list, but it’s manageable, and a lot of these only happen bi-weekly, so it’s a little hiccup in the work schedule and then back to it. . .  until you double it, or triple it, or more. At that point you will spend all of your time in meetings and none of your time actually writing anything. If you’re going to have any time to work, you may have to skip some meetings. But which ones?

Story pointing meetings are a must. Of all the meetings, this is close to the top of importance. Remember, Scrum uses no specs. Since everyone (except you) is only working on this team’s work and in constant contact with one another, there is little written material for these features. That’s what you’re there for. So, the best way to get a handle on what the features are and what they do is in the story-pointing meetings.

The other essential component as far as meetings go, is the standup. I’ll admit that I work through most of mine; when developers start talking about the particulars of code they’re not having a discussion I need to be a part of. However, by being present at the standups you establish yourself as a member of the team. This is vital for building your relationship with everyone else and putting the idea in everyone’s mind that yes, there is a writer here, and yes, we need to tell him when we change something. And things will change; that’s why it’s called agile.

As for the rest of the meetings, it’s always better to go if you can, but you’ve got documentation to produce, and that takes time too. You have a responsibility to your teams to complete the doc tasks for each story. Sometimes that means you can’t attend every meeting. This is part of the discussion to have with your Scrum master when you explain you’re not an exclusive asset.

3. Focus and Float
Did you know that every time you receive an email it costs you 3 seconds? That’s assuming you don’t open and read it. From the time you see the notification that you have new mail, it takes 3 seconds to reorient your brain back to the task at hand.

The moral of this story is that to be truly effective, you need to focus and shut other things out. No, I’m not telling you to kill your IM channel and close Outlook. But I am suggesting to you that doing one story for one team and then one story for another is slower than taking a chunk of related stories for one team and working on only them for the day, or even the week, and leaving the other teams’ tasks for another time.

Yes, this means that you’ll be going to most your standups and saying: “I have nothing to report today.” That’s fine. Do that.

Understand this might also mean that a sprint may close without your doc tasks complete. How the team handles this logistically depends on the Scrum master. Most of the ones I’ve worked with will pull those stories into the next sprint with a “doc only” tag on it, meaning everything else is done.

Scrum purists might be gnashing their teeth at this, but if you’re willing to give it this little bit of flexibility and break from the ideal of the process (because really, if this were implemented ideally, you wouldn’t be on more than one team), I can promise you this works. While all of my teams regularly carry doc only stories from sprint to sprint, I also always finish ahead of development before the final sprint.

4. Educate Your Scrum Master
When I first started writing for Scrum teams, the Scrum masters would create the same array for each story: a programming task, a QA task, and a doc task. However, not all stories require a doc task. Speak up in the sprint planning meetings and let everyone know what does and doesn’t have to receive documentation so that your workload is accurately reflected in your team’s tracking tool. If you have to miss a sprint planning meeting and you find a story with a doc task that isn’t needed, bring it up with your Scrum master and explain why. Eventually they’ll learn, or at least default to the behavior of asking you first.

Serving on multiple Scrum teams takes some juggling, but it’s certainly manageable. In fact, I’ve come to prefer serving on two at the same time. However, when doing this it’s important to understand that you’re not in the same position as the rest of your teammates, and so you need a different set of rules to be effective.

Posted by Cliff Horowitz, Prophet 21 Content Team Lead, Epicor University

Comments

There are no comments for this post.

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Body *


Captcha *

 

Attachments





© Epicor Software Corporation Home |  Investors |  Partners |  Privacy
Terms of Use |  Privacy Policy Industries |  Solutions |  Products |  Company |  Customers |  Services |  Careers