Connect your DevOps innovation project to your product innovation strategy

This blog post reflects on a Front Five engagement that involved a process innovation project disruptive to a medium sized organisations value chain activities during a period where their core software product was entering the top of its established S curve life cycle and where the product’s success was driving a consequential rapid expansion of the market. A major reflection for me has been to consider the appropriate execution timing of a process innovation project (in this case a Continuous Delivery project) that can significantly disrupt the available resources operating the existing value chain activities of the organisations business model. In this example a client has limited resources that predominantly work on BAU development and support as well as having an overriding focus on ‘market-pull’ to properly understand changing market trends and to feed this into the pre-paradigmatic design stage of an architectural product innovation with the goal of jumping their product S curve and moving through a product discontinuity to compete in an expanding market. Front Five did an evaluation of the organisations software development and delivery capabilities via the use of an outside-in assessment technology transfer (DORA, 2017).  The use of this excellent assessment technology was a mode of enquiry to search for the weakest software development and product delivery capabilities that mattered and that could be targets for innovation. Capability change areas were selected from the assessment outputs and a process innovation project to develop a subset of ‘Continuous Delivery’ (Humble and Farley, 2010) technology commenced. Our goal was to implement an innovation prototype based on this technology that could be evaluated for readiness before being developed further and then... read more

Front Five become certified DORA partners

Earlier this year the Front Five team traveled to Portland, Oregon for the inaugural DORA partner summit. There we met with peers across the industry to talk all things “DevOps” and to be immersed in DORA. Nicole, Jez and Gene facilitated and led the training, providing DORA orientated practice advice. The Front Five team are proud to be amongst a few certified partners in the EMEA region and DORA is now a key technology that we use for our client assessment and baselining processes. Roadmaps are built to address the clients constraints and our consultants work with the clients teams to address these areas before re-assessing every six months. Find our more at 1. Take the Survey 100+ people from across development, testing, infosec and IT operations take the 20minute survey. Because DORA gathers data from practitioners, they get a complete picture of your organization’s capabilities. 2. Baseline Your Performance DORA have years of data from Global 2000 companies worldwide. Benchmark your performance against the DORA database and discover where you’re ahead of your peers and where you’re falling short. 3. Target Your Investment You need to know where to invest in order to deliver higher IT performance. The DORA proprietary analysis reveals precisely where a lack of capability is holding you back. 4. Develop your capabilities All customers receive access to DORA’s exclusive knowledge base, curated by industry experts Gene Kim and Jez Humble. As DORA certified partners the Front Five team are here to accelerate your... read more

Communities of Practice – Creating DevOps and ITIL Social Learning Systems

This blog post draws extensively on concepts from other authors and I will reference major themes with a brief citation throughout the text. A list of reference texts is far below. Talking past each other Like me, you may have come across disparaging debates pitting DevOps against ITIL. There can be a tension between DevOps practitioners and the longer established practices of ITIL of which there may be up to 26 domain process areas. Traditions of understanding (Ison, 2010) differ with DevOps practitioners having an agile heritage emphasising collaboration, automation and lean practice while ITIL practitioners focus on joined up process areas interacting across a service lifecycle. When theses debates ensue I often think to myself that people can talk past each other. An opinion based on a single individuals trajectory of experience (Blackmore, 2010) is useful but it is narrow. It is very much like a story – fascinating and entertaining – but is it truth? This lack of objectivity is common to all of us – and especially the most highly opinionated – because when we talk about our problem situations as the observer we are in fact part and parcel of them :  Second-order Cybernetics. Although we can create such an illusion, we do not and can not see situations in a wholly objective way. Our view of them is always influenced by our person. However if we examine a multiplicity of perspectives with an open mind while being critical of our own individual worldview we can broaden our lens, making it a wide angle and we can learn. We can learn and we can innovate. I think... read more

ITIL and DevOps – Tales Around The Campfire

This material was presented with an alternative narrative at the CA IT Management Symposium in Johannesburg, South Africa. The slides and narrative to that presentation are available here : A Systemic Approach to Transformation with DevOps Stories told around the warm crackling glow of a camp fire. This sharing activity has gone on for probably as long as man has known how to make fire. Its a bonding experience, developing relationships and strengthening our collective understanding in an environment where different perspectives and world views can be shared passionately as stories. This blog post uses a campfire tales metaphor to explore the views of a group of three professional individuals (Gene Kim, Charles Betz and Rob England ) by using a fictional scenario where they have gone on a camping trip and are discussing the problems that they have encountered when trying to apply or integrate ITIL and DevOps within their areas of practice. The perspectives of the individuals are drawn from various publicly accessible blog posts and the strategy also draws on my perspective and experiences in managing Application Engineering teams. The situation of interest is any large service provider where IT service management is perceived to be operating in a dogmatic way by zealously applying a few reductionist ITIL process silos. It is important to note that ITIL need not be implemented this way (The author has studied the ITIL lifecycle extensively) but unfortunately it often is and for the purposes of exploring how to think strategically to plan improvements this is a stated and dysfunctional starting point. Some of the consequences of this starting point are... read more

Getting the CISO to embrace DevOps

The following is a case study demonstrating the use of Peter Checkland‘s Systems Thinking tool, Soft Systems Methodology (SSM), which is being used to think strategically about a problem situation where the Information Security function/group in a large corporate is being perceived by some members of an executive board to be slowing down the delivery of product and services into a competitive market. The concerns are being expressed by the directors of product and engineering who have recently had success in laying a foundation for highly collaborative DevOps practice. This foundation has matured over the last year with the result that a number of emerging Continuous Delivery pipelines are now operational for the businesses most strategic online products and services. This case study describes a problem situation that may be occurring in many large contemporary corporates that have implemented Continuous Delivery and DevOps practice. This is a part of a series of my blogs on how Systems Thinking tools and methods can be used in a trans disciplinary way within an area of practice. SSM is of interest in the context of DevOps and IT Service Management as it is a systemic method of enquiry that can be used in a learning cycle to get an ever deeper understanding of a perceived problem situation. A situation where one party imposes their view on the others usually leads a degree of animosity but it also derails a vital cycle of understanding and learning by the entire group. To avoid this common unilateral mode of operation from undermining a learning cycle, SSM looks to use its method to seek accommodations that are... read more

Using the Viable Systems Model to reduce Shadow IT

The following is a case study demonstrating the use of Stafford Beer’s Systems Thinking model, the Viable Systems Model (VSM), which is being used to think strategically about a problem situation where Shadow IT is increasing in a medium sized organisation. The rise of Shadow IT is becoming a risk to the stability of the organisation and has the potential to create a death spiral dynamic if there are sudden unexpected changes in the organisations external environment (such as legislative changes or data breaches on organisational data which has been stored in external shadow IT SaaS tools). The VSM is a method that can be used to model the principles or axioms that make a system viable, that is, an adaptive system (in this case an organisation) that can survive changes in its environment over time. It can be used in a normative diagnostic sense to plan a strategic intervention, as demonstrated in this case study, or it can be used to design a viable system from scratch. This is a part of a series of my blogs on how Systems Thinking tools and methods can be used in a transdisciplinary way within an area of practice. The VSM is of interest in the context of DevOps and IT Service Management as it can be used as a tool to model problem situations throughout this area of practice and is useful for thinking strategically about design or intervention by doing viable sense checks. In order to properly understand the VSM, the reader will need to be familiar with the VSM’s 5 recursive systems. Here is some brief background reading as a... read more

Successful Application Migrations. A Systems Dynamics Model

I have become increasingly interested in learning about Systems Thinking approaches in order to be able to apply a transdisciplinary skill set to my DevOps Engineering Management and Lean IT Service Management practice. I have decided to share these insights from my study of the subject as I think they may be useful, especially to the DevOps community. Specifically, I want to show how making use of a Systems Thinking approach at my client helped me to better understand a failing application migration project. Something to keep in mind as you read through the post, Systems Thinking encourages holistic feedback thinking rather than linear event based thinking and warns against the traps of dogmatism (the disregard of other perspectives when exploring a problem situation) and reductionism (the tendency to take a silo view on the problem). There is a third thinking trap, dealing with holism and pluralism. This is a trap whereby the system thinker may become convinced that the system, or systemic intervention that is being designed to effect a strategic change is whole. That it has considered all interrelationships and all interdependencies. Also, that it is in no way partial, that it has absorbed every single perspective and claims to be all things to all people in its system boundary judgements. This is of a course a trap as no design can make a claim to complete holism and complete pluralism. Context : I have been working with a client who has been doing a number application migrations from external DC (DataCentre) providers to internally managed data centres. The business driver for this activity is application security remediation and... read more

Designing the Service Provider – ITIL and DevOps

I am often asked by fellow practitioners and clients whether DevOps is compatible with ITIL? Whether the practices are complementary or if it is a case of mixing oil with water? When I think about these questions I often think to myself that they emerge from a fundamental misunderstanding of what ITIL is or at times from a narrow reductionist understanding of ITIL – typically a limited process orientated perspective. ITIL makes claim to a volume of ‘Best Practice’ guidance for IT Service Management which can then be used as a yardstick to guide the high level holistic design of a service provider. The key is to explore ITIL from a more holistic perspective in order to gain a better understanding and to consider how DevOps may be integrative. When I originally published this blog post in 2015, Charles Betz challenged the appropriateness of ‘Best Practice’ in the context of a Service Provider, referring to David Snowden’s CyneFin context typology and implied that problem situations that IT Service Management attempts to intervene in do not always fit into ‘obvious’ / ‘simple” contexts appropriate to tackling with ‘Best Practice’. I agree, problem situations within Service Management can often exist in the Complicated or Complex contexts of the Cynefin model. One needs supplementary approaches to explore and be effective in dealing with those more complex contexts. Probing and sense-making approaches which I think can be effective are Systems Thinking approaches and in particular Systems Dynamics, Viable Systems Model, Strategic Options Development and Analysis (SODA), Soft Systems Methodology and Critical Systems Heuristics. They should be used iteratively to inform ongoing intervention methodologies, the... read more