A great query came through this morning:
Hey Nick, I have a question for you. We’re going through some org changes, and have put together a DevOps team. Traditionally, we’ve only had an Ops team. Right now, the DevOps team is made up of devs, and the idea is for them to work collaboratively with the Ops team (but Ops is still a separate team). Is that how most other organizations structure their DevOps team? Or is it more common for the DevOps team to be made up of both devs and ops people?
—
Chris
My response:
Morning Chris,
When I see this working well it is always Dev *and* Ops. Or, you put Ops on the product team and make everyone responsible for the shared definition of done – similar to incorporating QA, just extending the Definition of Done through to production.
At the end of the day the name doesn’t matter so much as the individuals working together. A shared definition of done really helps drive that alignment and collaboration.
How are things otherwise? Are the teams delivering frequently? What is the goal of the DevOps team vs the Ops team (as it stands today)?
Is your VP Eng on board?
Thanks Chris,
Nick
This is based on what I have seen from visiting other Atlassian customers. I am keen to get your thoughts.
How is your approach to continuous delivery and DevOps structured? Share your views in the comments below.
Hi Nick,
I very much like what you say about the Definition of Done. Regarding the original query, the term “DevOps team” does not hit the point and is misleading, in my opinion, especially if that team only consists of devs. With DevOps, in my experience, you often have a team of different experts, including devs and ops. But it must not necessarily be one single team which was designed by drawing some PowerPoint slides or setting up a new department. Actually, this will not work without the underlying mind shift and collaboration in a holistic way. It is even more important that devs and ops have the same agreement on their approach to work, what quality means, and what’s the Definition of Done. Besides that, aligned goals (e.g. improving the cycle time) and shared processes as well as tool chains are crucial aspects. As a result, a real team may form automatically not depending on any concrete organizational structure.
Cheers
Michael
Great point Michael. If the team isn’t behind the change, supporting and driving it, then the team is unlikely to be successful.
So what is your definition of a devops team here A team that does the whole “infrastructure as code” song and dance (chef, puppet etc), or is your definition broader than that
I think it is broader than simply the tooling aspect. While many teams fixate on that tooling piece exclusively I think DevOps is a culture that we can try to foster. The more successful teams I meet, the more I recognise that pattern.