Should a designer or a devops be a member of a Scrum team?

Question

Usually such specialists as a designer or a devops-engineer are not permanently required (as opposed to developers and QA-engineers) to perform development activities (they are engaged in some tasks as needed). So it's usually not reasonable for each scrum team to have its own designer or devops-engineer.

Let's say we have several Scrum teams (developers and QA) working on the same project or maybe different projects. What about designers and devops-engineers? Should we have a Designers Department and a Devops Department in a company (in this case these departments can, and often do, easily become bottlenecks for the scrum teams)?

Answer 1

Externalizing Key Resources is a Common Anti-Pattern

What about designers and devops-engineers? Should we have a Designers Department and a Devops Department in a company (in this case these departments can, and often do, easily become bottlenecks for the scrum teams)?

No. A Scrum Team should have all the required skills required to build the Product and produce each Product Increment. If you externalize essential resources, you create bottlenecks in your process.

Companies that choose to do that are making a business decision to accept bottlenecks, increased process friction, and reduced productivity in return for (theoretically) lower labor costs through reduced headcount. This almost never works, but people with a certain type of business school background seem to keep trying it despite the empirical evidence that this simply doesn't work well in IT or with knowledge work in general.

You have a few choices, but none of them are the ones you likely want to hear. They are:

1. Invest in more "specialists" so that each team has all the essential resources it needs throughout the entire product development lifecycle. Note: This comes at the cost of higher headcount.
2. Invest in training your I-shaped team members and specialists in becoming T-shaped people, and leverage your subject matter experts to form communities of practice so that the knowledge is shared more widely. Note: This comes at the cost of higher overhead (and possibly the perception of reduced productivity) as non-experts expand their skill sets.
3. Accept the reduced productivity, higher friction, and longer lead times inherent in a system with high or critical external dependencies. Note: This is a key reason that 68% of IT projects fail. Plan on being a statistic.

There is no silver bullet, but externalizing key resources is almost always the worst possible solution. You are very likely setting yourself, the team, and the project up for failure with #3, but so long as executive leadership accepts full responsibility for the consequences of choosing this option, it is at least a legitimate business decision and therefore deserves a mention.

Answer 2

Ideally, a Scrum team should have all the needed roles to build the product within the team, and not dependent on external resources or people. So ideally, the designer and devops engineer should be part of the team even if they are not fully utilized all the sprint (although you can always have a designer handle UX/UI research to improve the product or the devops engineer spend more time automating stuff or increase monitoring for the live servers for ex to make the life of the team easier).

But as you mentioned yourself, having someone be only sometimes required or needing to be kept busy with some work to be fully utilized doesn't sit well with companies. That's because there is a prevalent way of thinking about people as resources which need to be fully used (just like you wouldn't want to have some machine just sit on the plant floor unutilized for half of the time) and think they can get the maximum benefits with 100% utilization, which is a myth in fact.

Sometimes also, someone is very skilled at their job and the company wants to have them give their input on multiple projects so that each benefits, but the end result is the same, which is introducing dependencies and possible bottlenecks.

If you are in such a situation, the team needs to plan accordingly (often having to coordinate with other teams for the same person) to make sure the dependency is minimized and bottlenecks are avoided. And that involves also the person participating to Scrum events to make sure there is still some continuity for the person, even though they work in multiple projects.

So to answer your question:

Should a designer or devops be a member of Scrum team?

Yes, they should. But often aren't.

Answer 3

Yes . Designers and DEVOPS should be part of scrum team. Their timelines would affect the overall timeline for the project delivery

Answer 4

Be very careful what you refer to as "a bottleneck." To state it simply, "it doesn't matter how fast you're driving down the road if the bridge ahead of you is out."

You therefore very much need at least the input of designers (who help the team identify what is actually required), and devops people (who help the team identify how the finished system will be deployed). Even though these people undoubtedly will not be directly involved in the manufacture of work-product and therefore should not be included directly in those counts.

When these people contribute something that in-effect says, "slow down!", you should be very careful that your measuring strategy does not mis-identify that as "a bottleneck," hence "a negative thing to be avoided." As your team "sprints along" doing things, it is nonetheless critical that they are doing the best, most-informed thing at all times. The best way to deal with a torn-out bridge is to timely change course as necessary.