How do you differentiate between Product & (Dev) Ops activities for an Agile project?

Question

I have worked with various sizes of organisations and everyone has had a way of seperating between DevOps (Engineering) activities and Product (Functionality development) activities. Some had different team doing it others alternated between sprints, some injected functional stories with Ops activities.

Today I see a wide array of activities are needed to successfully develop an Agile project iteratively. They include Continuous Integration Setup, Build, Release, Deployment as well as and meat on the bone Actual Product development itself. Then there is UX, AB Testing, Feedback loop generation and Analytics.

Is there an official guideline in any Agile methodology as regards to how to seperate Ops and Product Development activities ?

Answer 1

It does make sense to have some differentiation, however, the proposed differentiations don't make much sense to me.

First, it seems like you're using "ops" and "DevOps" interchangeably when they aren't.

Operations is a type of work. Operations, or ops, means different things to different organizations. I see it as the set of work needed to take a designed system and make it useful to stakeholders. Ops includes packaging the software, building infrastructure, deploying the solution, configuration, and monitoring the hardware and software.

DevOps is a mindset or culture that is designed to consider operations earlier in the systems development life cycle. Rather than a software team building something and going through a hand-off procedure, the ability to package, deploy, configure, and monitor the system is considered early in the initial requirements and architecture decisions. This helps to prevent rework and reduce the burden of operationalizing the system.

There are many ways to achieve DevOps. Some organizations embed operations expertise on development teams on a full-time basis. Other organizations may have an operations team that supports the development teams by conducting training or lending specialists as needed. There isn't one organizational structure needed for DevOps, as long as operational concerns are considered throughout the design and development process.

Second, there probably shouldn't be a distinction between engineering activities and functionality development activities.

Operations is a part of product design and development, as long as the organization that is designing and building the system is the same as the organization operating the system. Not all organizations do both. For SaaS solutions, the same organization will likely build, deploy, and operate the system. However, for some on-premises software, one organization will build the solution while another deploys it into their infrastructure and maintains it.

For organizations building and running the software, operations is usually a part of the engineering organization, which includes the development and product quality organizations. Engineering tends to be a part of a larger product organization, which may include product management, project/program management, and user experience organizations. Depending on the organization, groups such as technical support, sales, and marketing may or may not be part of the product organization.

I find that a better way to look at the work is to divide it into two or three sections. If you wanted two divisions, I would consider "discovery" and "delivery".

Work like software architecture, software design, software construction/implementation, build, integration, test, release, deployment, and monitoring are all part of "delivery". Requirements engineering, user experience design (which includes analysis of AB testing and other analytics), and software architecture are all part of discovery. The two blend around software architecture and design, where the identified needs of stakeholders are transformed into something useful.

There are other ways to divide up the work, but generally speaking, separating operations from other product delivery work doesn't make sense. The only case where I can see it making sense is if you have an operations team that is supporting multiple products made by product delivery teams in production. Since multiple delivery pipelines are feeding into an operations structure, you may need to have a clear distinction between delivery and operations.

If you want to understand more about separating these activities, it's often referred to as "dual-track agile" (see 1, 2, 3). However, you won't see the separation of ops and product development, but more about the separation of different product discovery and ideation from the design and delivery components.

Answer 2

I don't think the separation you are describing is a fundamental one. CI setup is something you can expect to do only once per product and while a different team may be needed to help with that it doesn't necessarily have to be differentiated on the backlog. I'm not sure what you mean by Build, Release and Deployment in this context since the point of having a Dev Ops pipeline is that those things become automated or trivial tasks. If you have separate backlog items or a separate team for those tasks then I would ask myself whether you are really doing Dev Ops at all.

Testing and feedback should not be separate backlog items because testing is supposed to be part of the Definition of Done.

Answer 3

DevOps is a corporate culture more than a specialization, so that is why each company has its own style, no guideline of how to separate it 'carved in stone'.

From my experience of large enterprise projects (plus from the point of view of a business analyst) with DevOps taking a part in it:

1. Infrastructure shared between the projects as a shared source is in DevOps area of responsibility. The infrastructure should be prepared and maintained to be understandable to work with and manageable to deploy the code - manageable from the Software Engineering point of view. But from company to company as people have a different mindset, they have a different zoo of systems in the infra and different systems they work on, DevOps style may differ from company to company.
2. Understanding of how the code is built and how it has it be deployed, maintained, supported is in the Software Engineering area of responsibility. They use then infrastructure DevOps prepare and get a consultancy from DevOps team how best to set up the infrastructure, what are the points of improvement, etc. So if DevOps exists in the company or on a particular project, then Software Engineers are in it by using and multiplying the benefits this culture gives.

Therefore, any DevOps guidelines can only be introduced at a company level, in relation to its own ecosystem by the Technical management following best practices accepted by the community. Same re Agile - it's adapted by needs following Agile manifesto statements.

Answer 4

Short answer: there is not and official guideline. One could argue (and I often do) that the wording of the Scrum Guide is directive here:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

I would argue that it doesn't say all the skills necessary to hand the product off to the next team. Therefor, I would be inclined to include all of the skills in the Scrum Team and not separate anything. This of course requires broader knowledge on the parts of the team members.

That said, I have to admit that the wording here is vague and, of course, Scrum is not the only means to be Agile. There are plenty of organizations that create DevOps teams. In theory, this is an enablement team and the work of those teams should speed other teams. In practice though, I don't think I've ever seen it deliver on this promise. If you wanted to try this way, I think you would have to find a way to make the speeding up of other teams a primary, measurable success metric for that team.