Authors: Henk Venema & Vincent Snijder
Agile ways of working have drastically extended the already big vocabulary of consultancy. Part of this new set of words is the acronym BUSDEVOPS. This is used to qualify multi-disciplined teams with representatives coming from Business, (IT) development and (IT) operations.
In this article we will argue that CUSDEVOPS should be a better term, where CUS is an acronym for Customer.
If all teams in the entire organization would always have the focus on the customer, the organization would be best equipped to act upon changing customer requirements. And ultimately it is the customer that defines your added value or ‘raison d’être’ as an organization.
Agile ways of working started in IT
Agile ways of working were once an answer by IT to drastically improve the way software is developed. Inspired by the Agile Manifesto, developers learned the added value of working within short cycles and continuously improve. In terms of products that create value for customers as well as learning in the way the team collaborates. Those teams were multi-disciplined in the sense that various disciplines in the development process were collaboratively working on the same products. Roles often recognized were people focusing on design, software engineering and testing. When SCRUM was introduced the way of working was further refined with roles as Product Owner and Scrum Master.
Although the development process itself was performed in a much better way, in a lot of organizations it still implied that the software as offered to the customer was ‘thrown over the fence’ towards IT Operations. In a lot of organizations, the non-functional requirements towards software in production are quite strict. With regulators and auditors demanding for certain thresholds.
The idea towards DEVOPS was born.
Within IT the switch was made to DEVOPS
Within DEVOPS the multi-disciplinary teams were extended with the people that used to maintain the software. DEVOPS teams carry the responsibility of design, deliver, maintain and ultimately decommission software. Responsible for the complete software lifecycle of a certain product.
This really boosted efficiency and effectivity in the teams. No hurdle to take after the software was developed but integrated in the delivery. Meeting the non-functional requirements was part of the ‘ready for sprint’ check. The quality of the software was drastically improved as a result of more sustainable and easier to maintain software.
But all of this was still IT oriented. Team composition and purpose was still derived from an IT point of view. And even if all IT delivery would be delivered by these multi-disciplinary DEVOPS teams, agility was only reached in the IT part of the organization. With the rest of the organization still working in the non-agile way was resulting in a suboptimal level of business agility. Only striving for agility within IT creates a kind of glass ceiling towards an agile organization. Not enough for organizations to be able to survive in the current volatile world.
Transfer DEVOPS to BUSDEVOPS
Based on the advantages with DEVOPS in IT, organizations started to create BUSDEVOPS teams.
In this way, working in an agile way was no longer dedicated to multi-disciplinary IT-teams. Competences like Product Management, Marketing en even sometimes Sales became represented in the agile teams. In this way the teams were able to be responsible for the full product life cycle. The migration towards BUSDEVOPS was in some organizations a trigger to adopt a new organizational model. A migration towards a new model from an HR perspective is quite impactful but also creates the opportunity to align all new functions and roles with a new HR-framework. Other organizations followed a more gradual approach by adopting BUSDEVOPS product (line) by product (line).
A remarkable aspect in the name BUSDEVOPS is that it is defined from the perspective of IT. Everything that is not IT is labeled as ‘business’. In the non-IT organization itself the term ‘business’ however is seldom used. More common in traditional organizations are terms like (business) operations, front-office or sales.
But is BUSDEVOPS delivering upon the agile promise?
The promises or benefits that an agile transformation based on BUSDEVOPS brings are commonly:
- Faster and better delivery
- Motivated teams with clear purpose
- All teams together creating the desired level of business agility.
But is BUSDEVOPS in reality delivering upon the agile promise? Sometimes it is but in a lot of cases it is not.
If the transformation to BUSDEVOPS teams is modelled against the existing model of products and services, you will still see delivery according to the same patterns. The organization still thinks and acts in terms of the existing way of pushing products and services to the customers. Because of the implementation of BUSDEVOPS you are delivering those products faster and better but not fundamentally different.
The missing link is customer focus.
The whole idea about agile ways of working is to deliver value as soon as possible. But value seen from the customer perspective and not from the organization’s perspective. Thinking in terms of integrating your products and service delivery with the eco system of your customer requires pull mechanisms.
Customer focus is key
For a lot of organizations, the switch to deliver a much better customer experience is a vital part to survive. Consider banks in general with products that are quickly and at large scale offered by non-banks. The main differentiating element for banks and a lot of order industries is ‘improved customer experience’.
If that is your main business driver as an organization it is not good enough to become better in pushing products and services to your customers. It should be a reversed pull mechanism where customers pull the products and services they need. This switch can only be made if the whole organization is focused on delivering value from a customer’s perspective.
Easier said than done.
A best practice is to use the principles of Customer Journeys. Translate all the elements of the desired customer journey into best of class services. This will impact not only the composition of the BUSDEVOPS teams. It will also change the focus of the team purpose. For every multi-disciplined team in the organization, the customer focus should be eminent.
In your planning and review activities, real customers should be able to participate. Not only in the teams on operational level but also at the multi-disciplined teams on strategic level. Everyone in the entire organization should be included if it comes to customer focus.
By ultimately transforming your complete organization into multi-disciplined teams with a clear customer focus, the desired level of business agility will be reached.
Conclusion
In our acting and thinking we should change the term BUSDEVOPS into CUSDEVOPS. The focus on the customer translated in the purpose of every team. At strategic as well as operational team level.
With customers able to pull their required services from the organization. With teams empowered within their own purpose to act as autonomous as possible. With all teams collaborating and maximizing customer value.
About the authors
Vincent Snijder and Henk Venema are experienced professionals at Inspinity with a focus on business agility.
Inspinity offers real support for organizations on their journey towards business agility. Based on our the experience, the transformation does not stop at IT or the regular box of methodology tricks. The focus is truly on implementing business agility, as a means to stay relevant as an organization for your customers.
