An agile transformation
I probably don’t have to explain why organizations are transforming towards the agile way of working. In nearly every enterprise, agility has evolved from optional ambition to inevitable necessity.
The far-reaching adoption of Scrum, the most dominant agile product development methodology, has triggered the emergence of product owners. The product owner, being a true business representative conveying the voice of the customer, decides on fluctuating priorities continuously, leading the development team towards the desired product. Many organizations see the paradigm shift from project thinking to product thinking as a major challenge in their struggle for agility. But this is the wrong battle. The shift should be towards ‘service thinking’, not ‘product thinking’.
DevOps – A strategic asset
The DevOps movement has caught fire for a reason. Organizations striving for agility were painfully confronted with the shortcomings of agile thinking being restricted to software development. Potentially shippable products piled up in front of operations’ door, resulting in long cycle times, dissatisfied users and customers, and frustrated IT staff. Not only startups and small companies, but also, more recently, large enterprises have started adopting DevOps practices and competencies. Organizations that have adopted this new way of working are now a magnet for highly skilled and innovative IT people. A DevOps culture has become a strategic asset.
Next to DevOps-specific technology, behavior and governance, embracing the DevOps philosophy entails a different take on ownership as well. A DevOps mindset involves thinking in terms of non-functional requirements just as much as functional needs. With IT becoming the business, instead of merely being a technology supplier, organizations start moving from product-dominant logic to service-dominant logic. This transformation is visible, for instance, in the banking sector, where their original financial products have evolved to mobile payment services or investment services. With service-dominant logic, ever more organizations rely on intangible resources and relationships to co-create value. A beautiful example is the Dutch airline KLM, who actively apply social media to co-create value with and for their customers.
More than just ‘product’
So, in a service-dominant world, how logical would it be to maintain ownership at product level? Service owners are far more effective here. Service owners do not only have a focus on customer experience and end-to-end effectiveness, but also on the complete service lifecycle, maintainability, and all other aspects that determine the overall value delivery. This leads to ‘definitions of done’ which are actually ‘definitions of use’, where the end result is actually usable, instead of ‘definitions of medium rare’. All too often I see the latter in scrum implementations, resulting in potentially shippable increments that deliver no value at all. A service owner is not only accountable for the realization of an end result (e.g. a car), but also for its effective use (e.g. driving). This involves a much broader scope than the product alone. More information on DevOps and its use can be found here.
Moving from product owners to service owners is not just a semantic issue. Of course, I am aware of the true intention of the product owner role: to be value-driven. And I do realize that bad service owners are just as deficient as bad product owners. Nevertheless, in creating an end-to-end collaborative mindset throughout your organization, a fundamental shift in thinking and acting in terms of services instead of products is highly recommendable.
Introducing the operations professional
In my experience, a great first step in achieving this change, is introducing an operations professional in all your agile teams. This team member helps the product owner decide on functional and non-functional priorities, adds operational knowledge and capacity to the team (e.g. monitoring, logging) and thereby gradually introduces a service mindset in the team as a whole. This is only a first step in adopting a DevOps philosophy and ownership on end-to-end services in your organization. But if you succeed in this, the rest of the DevOps stuff is just a piece of cake.
