Scrum with DevOps - question about teams
At the fairly large company where I work we have been doing Scrum for about a year on a few teams and we are looking to expand that. We are also trying to bring on DevOps.
Since we are still new to all of this, I am wondering how Agile/Scrum and DevOps work together. I have found plenty of reading material on both, but not enough on the integration of these topics.
More specifically, what should be done regarding breaking down the silos between Dev and Ops? Today each Dev team needs the support of several "Ops" teams in order to get to production. In fact, the development team might need to work with the VMware team, the Linux team, the storage team, the Websphere team, the network team, the firewall team, Information Security, the database team, our Release Management team and our Production Support team. The Dev team needs to engage with all of these teams and get their approval before going to production. Obviously we need to fix this. We are in the process of looking at new tools for CI/CD as well as Cloud to accelerate provisioning and technologies like Docker.
My question is more on the team front. For example, I just spoke to a consulting vendor who has a lot of experience with Agile. They said that they could easily stand up a new Agile team for us and they would recommend that it include 5 people:
- scrum master
- 2 developers
- business analyst
- QA tester
That sounds fine for Agile, but what about DevOps? With DevOps, should we add one or more Ops people to each Agile team to help the team with all of the Ops workload and to focus on accelerating software builds, streamlining deployments, setting up monitors, etc?
And, if we don't add Ops people to the Agile teams, who is going to work on that stuff? Furthermore, if we don't add Ops people to the Agile teams, how is that going to help with "breaking down the silos"?
Any help you could provide would be much appreciated!
My current program has been doing Scrum for years now and about a year or so ago jumped on the DevOps movement. We started out with multiple dev scrum teams each with a set of developers and a single QA tester. Operations was split up into silo's like you're referring to: a server team, hosting team, etc. If we needing something from an operations team it had to go through a formal Help Desk which was then routed to the correct operations team. There was absolutely no direct communication between dev and ops it was all going through a help desk ticketing system.
One thing we tried to do which I observed to be successful in breaking down the silos of the ops teams was that each scrum team was assigned a POC from each of the operations teams. So as a developer on team 1 I would know if we had any hosting issues I would go talk directly with my hosting team POC. That hosting guy wasn't necessarily a scrum team member that took tasks off our taskboard but they were part of our extended team that supported us. If in the current sprint we didn't have any need for a hosting team member involvement then they wouldn't attend any daily scrums, planning meetings, etc. Unless you have a lot of operations tasks that need to be done every sprint then it may not make sense to make them officially part of the team.
Another way to think of this is perhaps add the ops person to your team initially. Overtime they will cross train with the other members of the scrum team. If operations hasn't worked with dev closely in the past there could be benefit to dev teaching ops a few things and vice versa. Overtime, that dedicated ops person may no longer be needed as a scrum team member and they can be transitioned off the scrum team.
Many organizations are set up in such a way that they present two DevOps challenges:
Firstly there is the problem of how a product ought to be supported following deployment. This is sometimes thought of as a BAU context. It typically involves some sort of handover to a "DevOps" team who can perform ongoing maintenance.
Secondly there is the problem of having an in-team DevOps capability so increments can be deployed into production at all. This is the problem of meeting an adequate Definition of Done so increments are potentially releasable in the first place.
Hence the nature of the Dev-Ops divide can vary, and an effective bridge might require a fundamental re-evaluation of the organization's operating model. How do they intend to structure their value streams? Do they want to support products, or retain the project as a vehicle for delivering value? Achieving a DevOps capability is more than moving a few team members around and having better automation.
how to deal with only devops team no dev member in it ?