DevOps, like many of the terms we have seen over the years in the evolution of IT, is not a new concept. The term comes from joining the words Development and Operations. In most IT organizations, one team is responsible for developing software and a separate team is responsible for supporting the operations once the software is deployed to production for users. However, DevOps is more than just joining the teams of Development and Operations. DevOps expands Agile principals and creates a single team responsible for envisioning the product, building the product, testing the product, and running the product. In this case, a product may be a system sold to users or an application used internally in an organization. In most organizations this flow looks something like Product > Development > QA > Operations. Maybe we should rename DevOps to ProDevQaOps. Okay, maybe not.
In fact, startups operate in the DevOps world and have so for decades. Startups did not implement DevOps because they figured out the most efficient way to run an IT organization. They did so because they had no other options. Often, a team of less than 4 people manage sales, IT, product development, finance, HR, and everything else in a small enterprise. This typically means one person is responsible for managing technology development & operations: requirements, development, testing, and support.
Traditional organizations tend to operate in a shared service model. See below:
The traditional model incentivizes and causes organizational focus on a discipline rather than a product. Similar to waterfall development (SDLC) where the emphasis is on phases of development (requirements, build, test) rather than working software in an Agile world.
Some organizations evolved to dedicate product management teams to specific products but the rest of the teams remain shared:
DevOps aims to take this to the next level. A dedicated product team with laser focus on delivering and enhancing a quality product:
DevOps product teams do not necessarily have to be 100% dedicated individuals who do not work on multiple products but the DevOps model works best if they are. However, they do need to be dedicated to the product team to which they are allocated. The incentives and motivations of a DevOps team must be product focused.
Along these lines, organizations should consider reorganizing teams around products if they are serious about DevOps. This means structuring incentives, organization charts (teams), and processes all around a new product centric approach. For most organizations, this is a challenge as they have operated in the silo model for years. Making such a shift happen would mean completely overhauling processes, org charts, incentives, and most importantly, team culture.
While not practical for every organization, if the goal is truly to put out a world class software product, why not organize your people around this goal?
