One of the areas that I have been trying to grapple with since starting to understand the DevOps approach is - how does business strategy keep pace in the world of continuous delivery?
While we are all still coming to terms with what DevOps is and how it impacts our businesses, we also need to understand how this continuous delivery approach influences our ability to sustainably drive strategic directions. Achieving outcomes quicker is great, but how can we measure whether we are making the right changes, and not just pushing change through because we can, rather than because it will add value to the business?
What does business value look like in the modern era of DevOps?
This introduces a theme that I feel needs to be discussed further; namely what does Business Value look like in the modern era of DevOps? While I would love to take credit for this thinking, fortunately smarter people than I exist, and in this case it is Mark Schwartz (of IT Revolution fame) in his new book The Art of Business Value, were he offers an interesting approach to understanding and dealing with Business Value.
Business strategy models are generally relatively simple (but more difficult in execution). First you create a Business Vision and Mission (a purpose for why the organisation exists), then define a strategy and the steps required to execute this purpose. This is done by establishing the gap between where you are now and where you want to go, and then create objectives to get you to your destination. These objectives create programs of work, and once in progress we are continually challenged to determine if our approach is achieving the desired outcomes. But in reality the key challenge is knowing if your strategy is right, and if you are making the right decisions and choices to correctly execute on that strategy.
When the objectives involved IT, then under the Waterfall model at least, we would spend months if not years going through the SDLC process only to realise the assumptions made up front may not have been correct, or worse, the market has changed and we have been to focused on what we had agreed and not on the change that the customer demands.
Now in this new era where ideas can be quickly converted into reality we need to create governance models to monitor the changing business needs and then create processes to quickly deliver and adjust accordingly. Agile project delivery is one approach, but this method generally follows a static vision and objections and provides a scrum product owner that is the holder of the truth. This approach is an obvious improvement and it drives quicker change, but still has limitations as the agile delivery teams only have one version of the Business Value truth.
Making business value the hypothesis
Mark, in his recent book, suggests that while the definition of the Business Purpose approach remains consistent, determination of Business Value on the other hand becomes a hypothesis rather than a formal statement. He then suggests two key changes – the first is that after every change (no matter how small) the business value achieved is harvested and reviewed to confirm if the direction remains within the proposed hypothesis. If the change hasn’t achieved the desired results, then a review process is undertaken and planned objectives are modified to steer the ship back on track.
To achieve this agile approach, teams need to further expand their structure to establish more inclusive relationships with business owners especially in determining requirements and reviewing the harvested results from each release. Mark’s second suggestion is achieving this through the introduction of Complex Adaptive System (CAS) teams, which are self-organising project teams with non-linearities and complex interactions - one in which leadership can influence, but not control, outcomes. These teams need to break away the line ownership of the scrum project owner and allow the expanded team members the ability to collaborate with a wider business audience to allow them to define requirements then drive the required outcomes.
Is DevOps still too siloed?
Whilst I’ve tried to provide a succinct summary of Mark’s key messages from his book (and I do recommend a read), it does make me wonder if the current DevOps approach of merging Development and Operations teams is still too IT siloed and if it should be expanded to include a more business voice. Let’s call it “BusDevOps”.
So to answer my question from the beginning; “how does business strategy keep pace in the world of continuous delivery”? I suggest this approach can be achieved by starting to define business value through hypothesis rather than absolutes. We need to maintain closer working relationships with our business owners, take an iterative approach to delivering our business goals, and review the outcomes of each change and adjust our direction accordingly.
While the DevOps model is a great opportunity for us to review how we, as IT, deliver business value to our businesses and ultimately to our customers, the quicker nature of introducing change now means we do become even more collaborative with the business audience. This is of course all encapsulated by the need for strong governance and the development for a new approach to change management – but they sound like great topics for future blogs.