How to integrate DevOps people into a Scrum Team?




  • NB: In our company's https://pm.stackexchange.com/questions/33903/how-to-integrate-devops-people-into-a-scrum-team/33906#comment42367_33905 , "DevOps" is a role set by our company that means "infrastructure and operations person" rather than standard DevOps. I know it's more of a culture thing but I missed clarifying it in my original question due to company speech blindness.


    Reading through https://pm.stackexchange.com/questions/33335/should-a-designer-or-a-devops-be-a-member-of-a-scrum-team + https://pm.stackexchange.com/questions/10508/including-ux-in-scrum there seems to be a general consensus that UX/Infra/Ops people should be full scrum team members.

    Our teams currently have 2-3 backend developers, 2-3 frontend developers, and 1 infrastructure/operations person.

    Trying to accomplish that in our team we face issues during the planning phase of a sprint:

    • Most of our User Stories don't require Ops/Infra work, which leads to issues when planning a sprint for the whole team.
    • There are Ops/Infra tasks/stories that have no relation to development stories for example: "update library/service X on beta"

    This leads to issues where frontend devs are not happy because they have to estimate "server stuff" and Infra/Ops are not happy because they have to estimate "refactor JS service XY" during Sprint Planning.

    I think the ideal long term solution would be to have all people on the team learn and expand their knowledge but that is just not the current state. I'm not sure if everyone in the company is committed on making everyone capable of working on all tasks.

    Should we just accept the "overhead" that exists in those meetings until enough knowledge is shared or should we plan ops/infra tasks outside the Sprint? Should maintenance stuff be separate, or are there any other practical solutions for this?



  • There's no such thing as "DevOps people".

    DevOps is an organizational culture. Like how Agile brought the business and developers into a close, collaborative relationship, DevOps is about a close and collaborative relationship between development and operations, with the end goal of making it faster and easier to make a change and put that change into production, while ensuring the overall quality of a system. The result of a shift to a DevOps culture is the elimination of silos and hand-offs between a development organization, who is responsible for eliciting requirements and building a system, and an operations organization, who is responsible for putting changes into production and supporting (monitoring, maintaining) the system.

    Just like in development, there are many roles associated with operations. A few examples of operations roles include help desk or technical support staff, network administrators, database administrators, network architects, various security and incident management roles, among others.

    From a team's perspective, good teams moving toward agility should be trending toward being cross-functional. That means that the team, to the extent possible, has the knowledge necessary to take on work from start to end in the workflow. But some skills are highly specialized or not needed on a day-to-day basis, so it may be more about teaching the basic skills to multiple members of the team while making sure that there are sufficient experts to support the teams as needed. It doesn't necessarily mean that each team has an expert in every possible subject matter area.

    There's no one-size-fits all answer. In the immediate term, you need to support the teams with the people that you have. For the longer term, you need to decide which skills will be embedded on the team and which skills will exist in a shared pool available upon request. You can also identify people who may be interested in developing new skills, and how the existing experts can serve as teachers so teams can have some knowledge internally and rely on the shared pool of experts for more difficult tasks.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2