3

We're finally looking into utilizing scrum for one of or products, and we're trying to figure out what to do with all of the people on the team. We have the following people:

  • Developers
  • Testers
  • Customer Support
  • Content Writers (nontechnical website copywriters)
  • Designer
  • Adwords Marketer
  • Product Manager

We know we'll have developers, testers, and a designer on the scrum team. We know the product manager will move into a product owner role, and we know someone from the team will be a scrum master.

However, where do support, content writers, and marketers fall in on the team? These are all people who are dedicated to this product and are currently part of the team in its pre-scrum configuration.

Can these folks be part of the scrum team? Why or why not?

2

As with all things agile, "it depends."

A Scrum Team has two often conflicting goals.

  1. A vertical slice of the organization that can independently release working, tested software. This often requires a broad set of skills.
  2. Cross-functional "no roles" team. Scrum team individuals are also espoused to be able to do more than just "their job". Anyone can take a story, anyone can test, etc.

So with that dichotomy in existence, it first matters what your organizations priority is on the above.

From my experience here is what I would do:

Customer Support: If you're a big enough company to have customer support interacting with development like this, then you're probably big enough to have a product owner team (POT). Where the Scrum Team owns delivery of the prioritized backlog, the POT owns creation of the backlog. The Scrum Team ships product, the POT ships a backlog. Putting customer support on the Product Owner Team gives them a voice in the design up front. Having been in this role before, I was able to help head off customer issues by providing field experience. I wrote on this a while back on my blog and have a whole talk around creating well formed backlogs and product owner teams

Content Writers: I'm assuming this is different from documentation writers. If the product can't ship without the work of the Content Writer, then they need to be on the Scrum Team, even if they can't do any other work (coding, testing). This is because "Done" requires them. The alternate is to make them part of the Extend Scrum Team. This is the concept of contributors that are not required every Sprint. A Database person may only be needed every few sprints, so they sit in the extended team and often are a resource to more than one team. If the Content Writer isn't needed every sprint, try this.

Marketers: Product Owner Team. Same concept as Customer Support.

  • Interesting. We were actually thinking a support person would make a good PO. In our current pre-scrum configuration, they already work closely with the product manager to discuss and prioritize features based on support interactions with users. It sounds like you're suggesting we keep doing what's already working well for them. – jmort253 Jun 3 '15 at 18:19
  • The content writers are not solely documentation writers. They may update helpscout docs in the public user knowledge base, but they also write content for the website, which oftentimes requires understanding of features that were recently built by the scrum team. We were thinking a DoD could be to have the copy on the website as well, but we can also see how that could be a separate unit attached to marketing. If DoD involves help docs, then I think that makes a stronger case for including them on the actual scrum team. – jmort253 Jun 3 '15 at 18:21
  • 1
    If your product manager can't find the time to be the Product Owner, then a technically savvy Customer Support person would make an excellent PO. They already are used to being a voice of the customer. Based on what you're describing for Content Writers, I'd also put them on the team. Might try and give them some cross-training in test to help them be more collaborative. – Joel Bancroft-Connors Jun 3 '15 at 19:38
2

I would say that you should probably not put all these people in the same team. Although it would be an interesting experiment.

I'm going to have to imagine your product and team setup a bit, but usually I have found you get:

Developers - you want them to implement features for your product

This is the backbone of your scrum team because you have introduced scrum to either stop them doing whatever they think is good today, or to cut down on a overly long waterfall process

Testers - you want these guys to be your acceptance test for the features

You can put testers in a scrum team and many people do. But I find it moves them away from the 'acceptance of feature' role and into a test automation role. This puts pressure on the PO to write detailed specs rather than relying on test to pick up problems and raise them as bugs

Designers - you want these guys to sell you their cool designs

You can put these guys in the team, 'Design page X' is a nicely scrum-able task

Product Manager - you want this guy to think up how to improve the product

You should put them on the team as the product owner

Support - you want these guys to keep customers happy

I wouldn't put these guys on the scrum team. I don't think you can tell customers to wait for their help request to go in the backlog and be prioritized, and if you did you would need a team to do it nicely.

Content writers - you want to update the content on your website

I wouldn't put them on the scrum team. one of the features of your product should be 'Content management interface' once this is complete the content writers should be able to use it to do their stuff regardless of the scrum.

  • It would be great if web development frameworks included ways to easily separate content from the actual code, but I've not come across anything like this. Implementing such a feature, from what I know of our corporate culture, would not be perceived as valuable as they're very user-focused. – jmort253 Jun 6 '15 at 9:58
  • ??content management is a pretty basic feature, WordPress, sitecore, sharepoint – Ewan Jun 6 '15 at 11:05
  • True.... but we're using Java and Google App Engine and not using anything that plays nice with those things and vice versa... These are also apps, not blogs or marketing websites. – jmort253 Jun 6 '15 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.