The focus more on business and value.

An article by Paul Wilkinson about how to use the Business role in the Phoenix Project simulation.
I try to make the team understand that the term DevOps is often mis-interpreted and too narrow focused. Many organizations do not realize that the original intention was ‘business, developers, operations, security etc’. Organizations new to adopting DevOps are led by the name and engage primarily ‘Dev’ and ‘Ops’ and struggle with the link with the business.

I suggest thinking ‘BizDevOpsBiz’.The business at the front specifying the VALUE required and helping teams prioritize between new features AND technical debt. Biz at the end to ensure that VALUE is being realized, if not then this becomes direct feedback as to ‘why’?

I ask teams between Round 2 / Round 3 in the Phoenix Project simulation ‘Do you know how each of the project/features relate to my strategy’? (As CEO). E.g. ‘which of those projects supports the phoenix project business initiative’? ‘Do they know what keeps me (CEO) awake at night’? Often teams are focused on sticking the projects/features/issues on the wall but have little awareness of the context.

I summarize again about ‘bad press’ and the impact on share price; summarize how we have been promising the Phoenix Project for months and not delivering or meeting promised deadlines; I explain that we cannot have non-compliance issues that may also cause bad press. I explain that customer feedback is important for loyalty and growth and introduce the business feedback, ‘we need to understand not just the financial impact of incidents not solved but their importance to customer value and customer satisfaction and loyalty’.
I stimulate them to pin up the CFO card, The HRD program card, The Phoenix program card AND the customer feedback card at the front of the board, to make the strategic ‘Business Portfolio and goals’ visible. I stress the need for IT teams to understand ‘BPM – Business Portfolio Management’. This helps answer the ‘why question’ – ‘why are we doing this’? ‘What should we be prioritizing and why is that the highest priority’?

I get the teams to understand that Value isn’t just $…often they prioritize on ‘it’s only -5000 we can ignore that’….when on the card it says ‘Unions threatening to go to press’, as CEO I confront them with this – ‘What would happen then’? what would happen to share price? What would potential new customers think about this? What risks would I face’?

I also continually stimulate CISO to ensure anything that is high RISK/Compliance, or anything to do with credit card and personal details is well tested. CISO needs to work together with testing.

At the end (in Round reflection or end of day reflection) I explain BizDevSecOpsBiz.

• BizDevOpsBiz is all about: what value to we NEED – fast deploy the solution – Did we GET the VALUE, if not why, and new input to pipeline (feedback on value loop)
• BIzDevSECOpsBiz – focuses on the RISK side of the equation.

I sometime explain the theory back ground on this in terms of the increasing importance of IT Governance.
Digital Transformation is a hot topic, the increasing importance of IT and the increasing dependence on IT and how this creates business opportunities and risk.

One framework for IT governance is COBIT
COBIT talks about VALUE creation.

Value creation = Benefits realization, Risk Optimization, Resource optimization
Product owners very often only focus on ‘benefits realization’ – new features! As an indication of VALUE.

Technical debt and security represent RISK and product owners often don’t have a focus or budget for this, often they are unaware of the downstream impact and risk of technical debt.

All DevOps teams are continually under pressure. There is, and always will be, too much work for the resources available. Therefore there must be a good priority mechanism to balance ‘resources’ against ‘benefits realization’ and ‘risk optimization’. If the issues are known (visible) AND the business impact of these issues and technical debt then the business can consciously accept the risks.

When team are starting up and ‘never pass a defect downstream’ is a far away end vision/goal, Ops teams could use problem management capabilities to identify outages and causes of outages as well as the real business / user impact, identify where in the end-to-end pipeline the issues originated and what can be done to stop it happening again, (this provides an immediate feedback loop and provides input to shifting left, building quality in and helping prevent passing defects downstream next time, as well as show the real business impact of multiple incidents to try and prioritize resources on removing this form of technical debt.

Paul