Succeeding with DevOps: Its a Cultural Movement, not a Siloed Team or Method

Golden Nuggets, Honest, Unbiased Thinking, Opinion, Entertaining Long Reads and Mini Guides of Practical, Pragmatic and Shared Know How from me as an Agile Practitioner to help you Accelerate your Journey towards Enterprise Agility.

Debunking Claims | DevOps 101 | DevOps Culture and 3 Ways | DevOps Architectures | DevOps ML & AI | DevOps for Everyone | Enablement Roadmap | DevOps Coaching

The aim of this article, is to cut through the nonsense and hype surrounding siloed DevOps, DevOps Teams and it being called a Method, rather than a democratised or commoditised capability at Enterprise Scale across the full Value Stream, that's doing more harm than good.

DevOps is far more than just a buzzword to kick about and abuse in the Business Change and Enterprise Agile Transformation space. I read the other day in a so called “State of Agile Culture Report” that DevOps was an Agile Method – the Onions bit, it made me cry we are still in this game. I can forgive the Agile bit as everything gets clumped under its banner, but Method no.

I guess we owe this to their misunderstanding of the Mobius Loop Diagram that’s popularised the Continuous Everything Mindset of the DevOps Movement, that the authors clearly didn’t seem to understand, nor Lean or Agile Concepts, UXD, Service Orientation Thinking, Cultures and Complimentary Practices for that matter, hence calling it and discussing it as a Project Management Method.

Conway’s Law states that People and Organisations Design Things Reflecting How they See, Communicate, and Operate. The above certainly validates Melvin’s 1965 Law and why its key to DevOps Culture, Thinking and the Movement, and we design such said things out! This goes for Agile too.

Lean has its origins in Manufacturing.

Agile has its origins in Software Development and Delivery and

DevOps embodies, embellishes and amplifies both, as Next Gen and has little in common with Project Management.

Doing more Harm than Good for the DevOps Movement

What got me even more lucid, was it was endorsed by a Business Agility Peak Body who should know better as beacon to businesses and Guild to all the domains of Agility.

This does my head in and does more harm than good, contributing heavily towards why we have so many multiple and truly failing attempts at extrapolating the best of and embedding Lean, Agile and DevOps Culture into organisations that are striving towards Business or Enterprise Agility, but are lead up the garden path.

It gets read 10x, gets ploughed into biased Social Media AI ML Algorithms and then every Tom, Dick and Harry thinks it must be true and sadly it becomes a point of reference. Fact Checkers…nope, it gets endorsed by Academia and Our Industry Institutions instead, Fake Me!

They call these folks in industry, Cowboys and Rogue Traders and I think we should bring this term into the Tech and Enterprise Agile Transformation space too and call them out, stopping those trying to cash in, get some likes, tweets, twirches, tags and mentions rather than improve Business Agility Practices for the betterment of all.

I thought we were better than that as an Business Agility Community and in having Agile Conversations, but perhaps some us balk at the first sign of discomfort, challenge back, just cave in to get the contract signed and keep the client happy, or spread misleading thought leadership at not matter the cost, even if its against our Agile Principles and Values.

Succeeding with DevOps and breaking the Anti-Patterns

If I walk into an office, and all I hear is DevOps this, DevOps that, its a big tell that DevOps is not working because DevOps is positioned as the hottest thing since sliced bread, up on the pedal stool and in the worst cases, everyone has put DevOps into their job titles, saying, but no being DevOps

It makes me want to Ban the word like Projects from the Agile Vocabulary so we get the right behaviours, language and mindset instilled and drive out those that are not genuine about all things Agility.

DevOps is my culture, Agile is my Practice, Value is my Game

From an EA point of view, DevOps is one of many Business and Technology Capability Areas to support the creation, delivery, realisation, and flow of value. Underneath this is a complex sub layer of architecture views patterns, techniques, policies, behaviours and tools. Never have I seen it called a Project Management Method you follow in process steps.

I am going to throw in a handful of diagrams to prove a point about how DevOps as a Cultural Movement has overcome the Command and Control diesis of ITSM, PPM and Leadership and Management – central to why it exists as a Movement and not as a Method.

Those getting DevOps right are realising its an Invisible Culture that’s grown into a seamlessly integral part of their Organisations DNA as a means to improve overall performance, profitability, revenues, and various other key metrics and is yielding remarkable results over their staged/phased and gated SDLC baselines and benchmarks.

Its like Casper the friendly ghost, present but not there, quietly getting things out of trouble by scaring away the bad spirits.

So, lets set the bar straight, Deep Dive into what DevOps really is, where it started and where its evolving to for beyond the Post Digital Era, explore the capability areas and debunk why DevOps isn’t a PM Method, part of the Software Factory, Rinse and Repeat Cookie Cutter approach, a Team, a Person, a Functional Silo in your Shared Services and how it underpins the Continuous Delivery of Value across Value Streams.

DevOps 101 - What is DevOps?

DevOps is a set of matured, as well as constantly emerging and evolving Lean Agile, ITSM, SRE, Architecture, Security, Quality, Value Stream and Flow Management Technical Practices, Patterns and Behaviours that constitutes a Cultural Movement.

We have well and truly moved on from the early tech confined thinking of the Venn Diagrams that depicted the Dev+Ops or Dev+Ops+QA/Testing as seen below to the DevOps Assembly Line, what we call DevOps 4.0 or DevOps for Everyone.

DevOps continues to evolve out of the frustration with ITIL/COBIT, Siloed Teams and Functions, poor Agile Implementations/Adoptions, the lack of OD and EA, and the constant fall back to bad habits within Traditional Scientific Management and Empiricism – in that only Data, Governance and Bureaucracy can make things better.

The DevOps Cultural Movement borrows heavily from Lean, Lean Thinking and Lean Methods.

It borrows from Value Stream Management – a process to optimise wastes and the Led, Lag and Cycle Times across and end to end supply chain – referred to in Lean as the Muda, Mura and Muri – types of waste in the system.

SCM is a technical practice, explained later, not to be confused with Supply Chain Management, however its related to Value Stream Management and Engineering – a big part of what we do under the banner of DevOps.

Its further complimented by drawing of the strengths, weakness, opportunities and threats from many other Domain Disciplines and Bodies of Knowledge, including BABOK, PMBOK, ITIL, COBIT, TOGAF, Prince2, Product Development, Service Delivery, to UXD, Logistics, Operations and Manufacturing e.g. TQM, TPS…to Management 3.0 and is why its not a defined method, or process to follow, it more akin to a framework if you have the need to put a label on it – but I’d rather you didn’t.

Above all, its a Culture, a Mindset and a Way of Thinking, Being and Doing above Agile, to increase the Agility, Quality, Reliability, Security, Speed and Flow of Value to Market by breaking the downward spiral that like people in the introduction, keep putting us under.

At no point in any of the seminal books, conferences, or events, has DevOps formally been described as a Method, and for good reasons, over its 20-year existence, so why start now!

The Enterprise or Business Architecture for DevOp's Capability

Below is a simplistic architectural view of a cross cutting, integrated Enterprise DevOps capability:

At the highest level, it may look something like this depending on what EA tool you use, the views you’ve designed etc. Notice its neighbours and the grouping it sits in.

For those not familiar with Enterprise Architecture, it’s not just a Tech Discipline, it straddles the Business e.g. the Org and Technology and Enterprise Change Management, however, it usually gets hammed into just being about Tech.

You do not have to have all the above capabilities at the outset; these are a "target state" for a good level of mastery and because change is your friend, you can incrementally or iteratively add to them based on your demands, use cases and needs.

This is the first clue that DevOps is not a prescriptive method or process one can just follow, rather it’s a set of competencies, skills and a mindset the Organisation has embedded in its DNA as way of operating by default.

If I explode this out to an even higher-level EA view as an Enterprise Capability Map, then it would sit in there something like this:

It’s a quick illustration to make the point, and there are multiple ways to organise views around the evolving domains of Enterprise and Business Agility, but the point is, DevOps is a cross cutting capability that supports and increases the Flow of Value across all value streams in the vertical boxes of how typically EA is visualised.

Its worth noting, that Business and Enterprise Agility will force are rework of your TOGAF, Zachman, NIST….Enterprise Architecture Views, Diagrams and Plans, if it doesn’t, your just force fitting it in and not doing it justice and not giving it the proper attention and focus it should have tactically, operationally and strategically.

The two above capability views are probably not what you were expecting – most people’s introduction to DevOps, understanding and perception is based purely on Automation Tools like Jenkins CI.

Introducing The 3 Ways

There are 3 Ways in the DevOps Movement that shape our Culture, Thinking, Doing and Being, set firmly off the Shu Ha Rai mantra.

The collective goals are to Eliminating the Hardships and Pain Points around wavering Quality, Insecure, Unreliable, Cumbersome work flows, to do better than the old ways, Transpiring it from Siloed Team to Organisational Knowledge aka into the Responsive Learning Organisation.

For DevOps, these 3 Ways are akin to the Agile Manifesto – as the foundations of the Cultural Movement.

Flow – The First Way

Making Work Visible, Limiting Work in Process/Progress, setting Capacity Limits, Reducing Batch Sizes, Eliminating Team Hand-offs/overs and Waste across the Value Stream is what this principle is about and as you can see, from your Mastery of Lean and Agile, there is a lot borrowed from Lean Thinking, Value Engineering and Lean SixSigma – a Lean “Business“ Method.

Feedback - The Second Way

Now as we Move things from Right to Left, (yes I’ve got that right) in our Value Stream Workflows, to detect problems earlier, more often and upfront though fast feedback, we learn quicker and can remove vulnerabilities, defects, bugs and do things sooner that would otherwise adversely affect the down/upstream creation, delivery, and realisation of value.

When a problem happens, we take the Andon Cord approach, stop the line, all pile in, swarm, huddle to resolve it, preventing it from becoming an issue later on and a risk for those dopey, time consuming, hugely expensive, poor outcome RAID logs – did I shit can them enough!

Problems are opportunities for learning.

Problems improve knowledge, push quality up and optimise up and downstream, applying systems theory/thinking- incrementing, iterating, improving the whole, not just a part.

This is where we get the Shift Left Mantra from and why we tolerate risk and change better and scale differently to our liner thinking brotherends in traditional PPM, L&M and even Agile.

Continual Learning and Experimentation - The Third Way

Unlike doing lessons learnt after the end of 12,16, 24 month projects, we try to turn fast feedback into new knowledge, better processes, more anti fragile, resilient systems from failing fast to fail forward building high trust, engagement, autonomy from a just do it attitude over asking for permissions, tickets and waiting to be told in institutionalised environments. We go beyond the Demos, Review and Retrospectives.

This is the amplification of Kaizen and Shu Ha Rai as a continually, integrated mindset to grow.

There is no such thing as BAU

So no part of the above refers or even reflect anything like a set method or methodology, its all about a mindset, a way of thinking, being and doing. Not a formula or stepped process, but one of pragmatic and progressive Agility and Innovation based around Flow and Value

What DevOps is NOT then

• A Job
• A Job Title
• A Team
• A Method
• An excuse for a Cost Reduction Business Case
• An excuse for Autonomation or Automation
• No Longer Just Dev+Ops+Test or QA

If its not these, then what...

The Technical Practices for Full Stack, Long Lived Value Aligned Agile Product Teams

I am not going to detail out what each of the core Patterns, Techniques and Controls are, instead I encourage your curiosity to seek out the seminal books for each as opposed to hitting a search engine or social media to give you the best knowledge base for your DevOps Movement and Culture.

I’ll introduce a few new elements here like Full Stack, Long Lived, Value Aligned and Product to the Agile Team here and more later, building a true reference point up for the One Team mantra that DevOps aspires to.

Full Stack – meaning the folks on the team who are software or hardware inclined have atleast T shaped skills, preferably X, balancing front, back end, middleware, and agile delivery skills – yes not everyone on the team is a tech head!

Long Lived – meaning, that the team isn’t pulled together for a project then disbanded part way through or at the end, as they say, team work makes the dream work, so to get to high performing or HiPo status, you need to accelerate the Tuckman Cycle by letting the team, stay together and play together.

Value Aligned - meaning that the focus and priorities for work efforts goes only into things that "add value" to the value stream or chains and are not distracted by other things, HiPPOs, everything is P1...expedited vanity/pet project work outside of the portfolio

Product – yes, before or atleast at the start of your DevOps Transformation/Adoption, you should be pivoting away from stop start, staged, phased and gated projects and towards a product centric organisation which is end customer focused, not under the thumb of the Highest Paid Person who Shouts the Loudest from their position of authority, power and influence e.g. the HIPPO and to reflect the Mobius Loop – the continuous optimisation, improvement, refinement of the value, value stream and not binary ALM.

The Core Patterns

• Agile HR
• Self-Governing, Self-Managing, Self-Organising, Cross Functional, Multi -disciplinary, Full Stack, Long Lived Agile Product Delivery Teams (that new Reference Point for your Team Typology!)
• Customer First
• Security First
• Test First
• Cloud First/Cloud Native Development (the full stack bit)
• Agile Enterprise Architecture
• Value Stream Engineering
• Lean Thinking
• Systems Thinking
• Agile Thinking
• Product/Design Thinking

Notice how I put HR atop. DevOps is a culture change exercise. If you want to fill your org with more people like you’ve already got, then, don’t start the exercise as this wont lead to any changes to the DNA. HR is one of your first Partnerships to build out, to make sure you bring in the right people with the growth mindset, Agile and DevOps Ways of Working, retrain, redeploy or make redundant those that don’t get onboard for future success.

The Core Techniques

• Continuous Agile Business Planning
• Continuous Exploration
• Continuous Agile Strategy
• Continuous Monitoring and Observability
• Continuous Security
• Continuous Integration
• Continuous Development
• Continuous Delivery
• Continuous Testing
• Continuous Value Management
• Continuous Improvement/Learning

So there is a trend here, there is no stop start project based activity, just continuous effort, striving towards perfection, but never getting there.

Observability isn’t monitoring. Monitoring is technical solution or tool to watch and understand the health/state of systems using predefined sets of metrics or logs. On the other hand, Observability is tooling or a technical solution that allows Agile Teams to actively improve a system based on exploring properties and patterns not defined in advance.

Continuous Agile Business Planning and Strategy, I think speak for themselves, think in 30,60, 90, 120 day blocks aligned to Continuous Near Term Road mapping and not 3-5 or 10 year cycles of the old.

The Core Controls

• Humans (yes not the machines!)
• Immutable Policies (created by Humans, applied to machines for scale and quality)
• The 3 Ways (for decision making/any trade-offs as First Principles)
• Agile Organisational Design and Structure
• Lean Portfolio Management
• Agile Delivery Methods and Frameworks
• Agile Health Assessments
• Agile Policies, Standards and Guardrails
• Lean and Flow Metrics
• ADD, TDD, BDD, STDD
• CICD, CDRA Pipelines or Assembly Lines (See DevOps 4.0 later)
• Cloud Consoles, Integration and Consumption Management Tools
• IAM, RBAC, MFA
• AI, ML and Deep Learning Neural Networks and RPA

How to Build an Enterprise DevOps Movement or Culture

The starting point is quite different from Lean or Agile, this is because of the assumed mastery of Lean and Agile first

You don’t have to have mastery, its not compulsory, but it’s a massive lift up and I highly advise it as part of the Shu Ha Rai and Kaizen journey so you are Being, Doing and not just saying DevOps.

The actual place to start is by critically examining your Value Streams.

This is where you need to map and measure the end to end supply chain, development and delivery process and eliminate the wastes with 6Sigma DMIAC/SMVIAC cycles. Again, this is where, how and why Lean Mastery is an essential pre-requisite skill.

Some of the waste reduction solutions will be through the application of DevOps Tooling, Toolchain’s and Automation Pipelines that can monitor, measure, highlight and optimise bottlenecks and impediments in process steps. These are the so-called quick wins via automation, but are far from mastery, done, finished or Being and Doing DevOps.

The tougher wastes to eliminate are bureaucratic, scientific, and so-called empirical processes that need eliminating or reducing, the problem is, there is usually one or many people attached, so some BPO, Capacity and Demand Management Studies with HR are usually required to squash or redeploy.

Even tougher, is the interplay of your wider ecosystem partners, vendors, suppliers, again System Thinking not Siloed Thinking. These areas cause led, lag and overall cycle times to vary and where your SCM folks can help – that’s Supply Chain Management not Source Code Management.

The second place is within your Enterprise Architecture and Strategy silo.

What slows down Lean Agile Product Development and Software Delivery Teams and even Agile Marketing Teams the most, is Legacy Technologies, Applications and Systems, and having to navigate the complexity of them making Innovation, Innovation Management, and Innovation Architecture a woeful nightmare.

This is aside from the bureaucracy built up in the Org Design, Structure and Hierarchical Fixed Mindset Culture that can be navigated, or side stepped, but this seeds an Anti-Pattern for Agility later, so Shift Left, address it earlier than later.

This is an improvement area for EA – they focused too much on Tech and not enough on the Business side as Business Architecture gets overlooked or gets less attention and its where the big gains in OD, Structure and Agile Delivery can be made.

Going hand in hand is the Capabilities you have, in People, in Process, Technology, Information and in the Supporting Tooling.

This is Where, When, How and Why EAS is so important to unpick – if you think you can leave your EA alone, then you got the wrong end of the stick in any Agile or DevOps Transformation

And the final impediment in EAS, IT and HR is the Traditional Change Management Practices, People, and Processes that stifle Innovation and Change by protecting the Structure and Design of the Bureaucracy – something all Agile Methods, Frameworks and Transformation don’t address well enough, as an afterthought – so again Shift Left.

The third place to start is by Internally Disrupting your Organisational Design and Structure

Most Organisations still have some form Delta Pyramid hierarchical structures – the most inefficient bureaucracy you can create for DevOps and Agile not to work and deliver on its business and benefits cases.

Agile and Digital Transformation initiatives/efforts should have taken the Org Design, Org structure and Team Typology towards a Matrix Operating Environment – probably using an adaption of the infamous Spotify Model.

This is the MVP of OD for Agility.

Matrixes however, still create Functional Silos and not the independent Network of Networked Teams in a Socio or Holacracy even despite what Spotify and their Ideal Model was attempting to do through the idea of Squads, Chapters, Tribes, Guilds as HR and Management gets lured back to Line Management concepts instead of Coaching, Mentoring and Leading People for growth and development.

OD is often missed out by IT Lead implementations of Lean, Agile and DevOps.

The fourth place is through Patterns and Practices that create Enterprise Behaviour Change

The No1. Anti - pattern seen or experienced is going in with a Tools First Approach, seeing DevOps as an Automation Only Exercise

Patterns are repeatable Assets, Behaviours and Solutions that address commonly occurring problems by the IT definition.

Practices are the Techniques of being able to apply said Patterns in the right way, at the right time, to solve the right problems to build things Faster, of Higher Quality, Better Reliability, More Securely and More Valued.

Tooling plays a role here, in that tools that rent bespoke under Conways Law, force a new way of working by their inherent design – the worst thing you can do is customise/build tech, its an anti-pattern of transformation as unconscious bias and bad habits always win.

The problem faced here is that poorly implemented Agile and Digital Transformations haven’t set the foundation for successful DevOps transition and adoption due to their poor Outcomes and Objectives not being right, particularly at not getting the underpinning Lean Agile Thinking, Culture and Org Design right.

In Agile, there is the ADAPT/ing model.

Awareness, Desire, Ability, Promote, and Transfer

Like UnDone Stories on a Backlog, the full Definition of Done is rarely achieved, only barely Ready, as Awareness and Desire get sorted, and that’s enough Quick Wins under the belt in a stop start project nature of most CIOs/CTOs/CxOs to claim success.

Lacking is the Ability, Promotion and Transference not only to tech or the IT dept, but outside to other depts/functions – the Ha and Rai bits and Leaders not proactively practicing the Growth/Agile Mindset and Leadership, so we get more of the same same, with new DevOps words chucked in, thats saying your doing DevOps but not Being or Doing it, same happens in Agile and Digital too.

SAFe DevOps offers the CALMR model, based off CAM, CAMs and CALM already out there.

Culture, Automation, Measures/Metrics, Sharing. Lean Flow/Learning Reflection/Recovery depending on which flavour you go with.

In order to apply successfully the advanced agile technical practice and automation, you first must have the Architecture, then Significant Mastery of Traditional Project Management, Lean and Agile Methods.

This is so you can self-actualise/realise that things are wrong, broken and you have the half glass full mindset, in that we can do better. Problems aren’t negative, failure doesn’t mean failed - they are opportunities and challenges to solve, but if you have the fixed mindset, then you won’t think this DevOps Kaizen way.

beforehand, unless you can start from zero with a no baggage,

These Adoption Models are great if you have a Greenfield or clean slate, which is highly unlikely and the closest you’ll get to this utopian state is probably the first weeks of a Lean Start Up if a DevOps Minded CITO/CTO is onboard.

The best case scenario is a sprint based, iterative, emerging and evolving DevOps Adoption Strategy or Roadmap responding to a just in time, demand led skills, knowledge and understanding where you blend in these Adoption Models to the Roadmaps and results of ongoing Health Assessments and feedback from your SCM/STE/RTE and PO/PM folks.

Brownfield scenarios are the common occurrence and I see very few Agile and Digital Transformation that use them over Kotter’s works and its this lack of contextualisation/personalisation/specificity that kills the initiatives because the people leading are those Rogue Traders, Fakes who claim to be, do and know Agility- but there really traditionalists wearing camouflage.

The problem with DevOps is that you can’t go in and buy this cultural approach, movement thing or way of doing and being, its got to be nurtured and put into the DNA of the People and Organisational Culture by Agilists, who live, breath and do it by default.

Culture development is a long burn process and needs to be orchestrated by a skilled Enterprise Agile Coach – a Strategist, Change Agent and Transformation Leader – just like a great DevOps pipeline is continually monitored, observed and optimised, its not set and forget, BAU stuff.

ADAPTing and CALMs go a long way, but other more effectives means are out there in the way of the ESS and ITAF over Kotter’s foundations found in ADAPT and CALMs/CAM/CALMR for large scale, complex Enterprise Change Management using the ELSA, Delta Model and ITAF’s Memes from Amber to Teal.

The second Option is through having a strong, DevOps Leader, Evangelist or Champion who can Push Against the tides of Conformity and Adversity and Navigate the Politics of an Organisation and one that can embrace all these models, methods, frameworks, patterns etc into a seamlessly crafted journey.

Again, its not a Job, its a hat or role someone wears, so don’t get too excited and froth at the mouth, thinking, that’s my next badge.

Don’t suffer the Fakeaways who aren’t the Real McCoy’s, Break Conway’s Laws and Make Shift Real

The Backstory – Accelerating your Understanding for Future Success and Enablement

Lets step back on the failures, so we can fail fast and accelerate you forward on your DevOps Journey.

The first popularised Business Architecture for DevOps (not method) was the Mobius Loop (the image at the top of this article) and the first Ref Architecture was the CICD pipeline outlined in the next section.

Both were easy to digest diagrams that simplified the complexity for some, of DevOps into a view of the better Patterns, Techniques, Practices and Structures across the SDLC or ALM of the late 90’s and early 2000’s, to overcome common command and control ITSM, PPM and L&M problems.

DevOps Business Case

The initial early DevOps Business Case was really in 4-5 layers for Enterprise Agility

1. The Line of Business Model
2. The IT Business Model
3. Multi Speed Development and Delivery
4. The Value Stream Map and to
5. Move away from Water-Scrum-Fall

DevOps Benefits Case

The initial early Benefits Case was:

• World Class Agility
• World Class Security
• World Class Reliability
• Word Class Integrated Delivery Pipelines

Its has since evolved from these positions, but nevertheless, these still are still good enough, rock solid foundations for a successful DevOps Movement inside your Organisation.

Let’s chunk things into 4 digestible buckets in a summary showcase of the DevOps Movement, past to present:

DevOps 1.0: The Late 90s, early 2000s CICD Revolution

Agile Culture and Ways of Working were emerging, including Scrum, however, many issues were still encountered around/with the new methods for software, product, and service development as they were incomplete methods and frameworks, missing much governance, control, discipline, and domain expertise needed to create and deliver value.

In IBM, things weren’t quite working out as intended, so some new nimbler approaches to traditional PPM around the SDLC and ALM were being trialled in RUP, RAD and even later DA – Ambler was an IBMer and has included Disciplined DevOps in DA.

In 2001, The Agile Manifesto as born after a lot of experimentation in how to do things better than the Traditional PPM, SDLC, ALM schools of thought to provide a charter, setting Agile apart from being labelled a method, encapsulating it in a set of core values and principles.

Agile Culture and Ways of Working had not only emerged, but was being widely and rapidly adopted.

Testing remained a siloed and specialist function and problem, as did Source Control, Production Like Environments access and creation, Integration and Release and Deployment practice across the value stream because of siloed structures, designs, and standards like ITIL and COBIT in the ITSM space still forcing this upon people.

What emerged was the CI/CD Revolution and DevOps 1.0

CI Servers like Jenkins, Circle CI, Spinnaker, VSTS emerged in early 2000s, to help get over the Merge Hell of feature and component based branching and forking strategies were each Dev’s all wrote their own lines of code separately and then tried to merge them as a system back to master ,something we don’t do anymore under trunk based development without feature toggles.

Our butler buddy Jenkins, probably still the most popular servant and most people’s first automation tool experience because its free, open soured, has a huge support community, works well as an orchestrator, allows SSH for Automation Scripts or from within its User Console, was widely adopted. It uses webhooks, cron jobs, URLs and queues to trigger integration jobs, merging code. It showed up any problems, by failing builds, stating a build was unstable or passed in a Red Amber Green type of way – detecting vulnerabilities, defects and bugs earlier in the SDLC, rather than after the big bang launch when it was too late, harder to fix and more costly.

This was a huge step forward in the Shift Left Thinking and in Managing Releases/Builds with Greater Agility and when combined with Semantic Version Control and Source Code Management in TFS, GitHub, Bitbucket, cleaner source code resulted (Built in Quality), faster, through automation and this could then be orchestrated across all hardware/infrastructure environments, pushing clean code up and bad code back downstream.

Package Managers like Composer, NPM, NuGet, Nexus, then took all the binaries, middleware, run time, OS and any other files and created a package ready to be deployed/installed on Application or DB servers across defined networks that usually required some downtime outside peak hours/on weekends – not popular and contributed to the ill health of many tech folks – stress, pizza, beers and donuts, if you were wondering.

Circa 2004 -08, Test Driven Development matured out of Extreme Programming, Behaviour and Story Test Driven Development via Cucumber, Gherkin and Agile User Story Frameworks, capturing Functional and Non-Functional, UX and Performance Criteria for Acceptance as well as the Customers.

CI combined with Scrum XP, led to faster and a better way to lead projects, so things ramped up.

By 2010 - 12, Jenkins, our Butler became synonymous with Continuous Integration, making sure any new code/builds were integrated and tested the same day, in the same hour and even in minutes.

Version/Source Control Management evolved, a shared and common taxonomy for major, minor releases, was understood and became the norm across the SDLC and ALM, improving the speed of releases and countering any harm an unstable release done, with automated rollback of any newly deployed feature, component, update or security patch or hotfix – core to the explosion of eCommerce.

The real gains came later in the decade in Continuous Development space as the Cloud Technologies and Models became more sophisticated.

We found ways to treat hardware – networks and infrastructure as Code to overcome the pain points of sizing, ordering, debating for 12 weeks what sized app server DB or Network Routing was required for a new service.

Infrastructure as Code, (IaC) and a Service, (IaaS) was born.

Data, real data even become possible to test with,(DaaS) not some made up, or scrubbed data which was flawed, creating false positive and just plain old negative results that, well, weren’t negative, just bad data made up by another functional silo. DaaS matured on its journey, as provided more reliable test results.

All of a sudden, more automation was possible right across the Dev, Test, Stage/QA and Pre-Prod environments, the SDLC and into ALM – remember the modus operandum was build the business – run the business still.

We got better at releasing, deploying, making it lower risk and more reliable with SRE and Google showing the way , leading the Big Data and eCommerce boom on top of Web 2.0 as a 1min down in Ecommerce space can mean anything from Thousands to Millions lost in sales and revenues.

We got here, because we decided to literally bring Operations and its Sub Teams into the Agile Team. The Dev+Ops+Test bit.

What emerged was a more effective and efficient software or product value delivery and development stream, with less people, less silos, less handoffs, because we now had a new type of team typology, the end to end, cross functional multi-disciplinary team taken from Agile – One Team Culture which later add Full Stack to it.

On these end to end, cross functional multi-disciplinary team, we had the full spectrum of skills to use tools like TFS, Visual Studio, Netbeans (IDEs), we had Unit Testing Tools, like J, N and Q Unit, System Testing Tools like Cucumber who could check that things were oh behaving! as intended or wanted, Austin Powers… and we could trigger/orchestrate all this programmatically through code and the automation tooling, making work highly transparent and visible, through real time dashboards and metrics.

Like all good fads, the FOMO kicked in and everybody jumped on the bandwagon!

Jealousy among the non-believers and resistors of change grew, that better, Security, Operations, Architecture could be evolving and emerging without them and other ITSM, Command and Control PPM, L&M further consolidated their functional silos in IT by adding to complexity, and coining terms like:

DevSecOps, InfraOps, DataOps,SysOps, BizDevSecOps, BizArch,DataDevSecOps

And all kinds of survival acronyms kicked off, fearing that DevOps could, does and can replace them with inner sourced skills from within the now Self-governing, Self-managing, Self -organising, Cross functional, Multi-disciplinary Agile Teams who just added automation skills to their arsenal.

We owe something to these folks, who inadvertently helped push us towards BizArchData,DevSecOps under DevOps 4.0 – the Assembly Line, pushing DevOps out of just the IT silo.

DevOps 2.0 – Mid 2000’s CDRA Evolution

DevOps 2.0 is a huge leap forward, and I mean huge from DevOps 1.0.

DevOps 1.0 got us over the SDLC, ALM, V-Models, Linear and Water-Scrum-Fall PPM approaches, moving us from years and months to weeks, days and minutes to release and deploy value, making Agile Teams, properly fast.

DevOp 2.0 optimised itself into the in the Hours, Minutes and Seconds space, depending on how big the real candidate was for deployment, making Agile Teams, rapid and only really held back by other Functional Silos, Laggards and the Bureaucracy Culture of Strict Rules, Policies of Command and Control.

Netflix was spawning, ready to bring in their anti-establishment No Rules approach, Symbian Army, Chaos Monkey Engineering that would later infinitely change DevOps to NoOps – another story.

As you can see in the 2.0 Tech Arch diagram, we have had a big Shift Left and a whole lot of “As a a Service” integration has been ploughed into the basic CICD Pipeline blueprint from 1.0 as we go further into Everything as a Service thinking, feed up with ticket systems, queues and IT Service Management.

We were now running, (using the pre-crawl, crawl, walk, jog, run and fly metaphor from linear maturity model thinking) with DevOps.

We nailed CI, we nailed Configuration Management via Chef, Ansible and Puppet. We nailed Package Management with Terraform. We could use PagerDuty, Jira Service Desk and Slack for ChatOps and Service Desk type activities combined with Zabbix, Nagios, Splunk, AWS CloudWatch, Prometheus, Grafana for Monitoring and ElasticSearch, Kibana, FluentD, FluentBit, Logstash for Event Logging and Auditing, Docker, AWS Elastic Beanstalk, Kubernetes, AWS EKS for containers, container images, tools were coming thick and fast, as to was their adoption.

Now the Cloud is heavily integrated, we’ve become full stack engineers and architects: we can do way with the dedicated Ops Teams, Cloud Teams, Infrastructure Teams and Service Delivery types, we have genuinely replaced them threefold: within the skillsets of Agile Teams themselves, secondly in Guilds within your within CoP, Self-serving, Self-governing and enabling others, and lastly, through DevOps and Cloud First Strategies, Practice, Thinking AND Culture, realising the benefits case of DevOps fully.

This is the big thing with Lean, Agile and DevOps – they significantly change the Org Design and Structure when implemented right to deliver fully on their business and benefits cases – something hugely missing from most adoptions and transformations because they focus 70% or more on Scrum Method and Scrum Masters.

The Service Mindset, Service Orientation is now properly with us, however, most still encounter roadblocks from CTOs, CIO, Tech and Business Leaders stuck in old ITSM ways of gates and from MBA teachings and entrenched by ITIL and COBIT formed from 1970 computing era and even TBM today.

SoD or segregation of Duties, particularly in heavily regulated sectors become a dogmatic problem caused by Auditors and Compliance Folks, demanding that the same person or thing, should not deploy releases across Pre-Prod and Production environments to assure checks and balances and maintain the controls of Bureaucracy.

No problems, if you want to throw up another needless barrier, we can work around and solve that too.

So we wrote Policy as Code, assuring all the checks and balances of the gated approach align with SoD policy and procedures for Compliance, Auditability and so called Traceability, sent a report to the authorised person, in some cases not, we had trust, and got eSignaures Sign Off/Approvals to trigger a “formal deployment” into Prod. Bang that Amazon button baby!

The Battle of Bureaucracy continues with QA and Testers, even though In DevOps 1.0 we fully automated the entire Test Cycle, Test Plan and built in Test Frameworks and we could run a whole Test Suite in Minutes, Hours and not Days and Weeks.

Exploratory, UAT and eyeballing are still the exceptions, still done by humans with UXD skills, Business Owners, Procut Owners and Friendly but Critical Faces, otherwise the rest is Triggered by Commits to the Source Code Repo Master Trunk/Code Base, not features toggles or forks off branches that create merge hell, bloat production code bases that technical debt and should be refactored, but nobody does as it costs in reality, so it gets overlooked until its too late and breaks new builds and some says a Clean Code Guardrail or Policy would be good or Blame kick in from the Traceability rather than Trust element.

One of the barriers you will come across is that it costs time, money and effort to optimise value streams, reducing roadblocks, barriers and impediments, but this aren’t seen as sexy things to do over Developing new stuff or other empire building activities

Despite these annoyances, we are now properly getting the hang of Agile Architecture, Continuous Security, Monitoring and Development, just fixing it as we go before it’s a problem.

We are really playing at the cutting edge of Anti fragile, Event Driven SOA, Micro Services and Containerisation thanks to tooling like Ansible, Chef, Puppet, Docker and Kubernetes that support these Patterns and Techniques at industrial scale.

We can properly decompose monolithic spaghetti junction legacy applications and build new independent modules that are loosely decoupled, but tightly coupled when playing together under a Plug and Play pattern and also thanks to advances in middleware – specifically APIs, message brokers and buses who can play in real time, meaning components in platforms and system can talk to each other super-fast, ms. fast, not in scheduled cron jobs, batches and queues timeframes of hours and minutes.

Even ERP Systems like SAP, once monsters, are now engineered by SAPs own Agile Teams who’ve adopted SRE and DevOps practices with Loosely Decoupled, Tightly Coupled Agile Architectures, because it makes their life easier too.

DevOps, from the outset, has always spawned new ways of thinking, being and doing across domains and disciplines in order to meet the ideology of faster, more secure, higher quality and more reliably. Methods don’t allow for this continuous innovation.

Security, even today, is seen as a very specialist domain, but in reality, its not, the best hackers and ethical hackers come from places an spaces you wouldn’t dream of and of all ages too.

Security is everyone’s day job, this is how we view it in DevOps.

In DevOps, we properly have the genuine ability to run Operational and Development Security Continuously across DevOps Pipelines to the dismay of CyberSec folks, we’ve kind of had it for a while, but only now have they got onboard and started to Trust us and we are having less of the DevSecOps rubbish, well many still pedal this as its their lifeline, USP, core offering and we need it too, just without the DevSecOps tag.

Static scans for smells, vulnerabilities on code bases for software and hardware -i.e. networks and infrastructure can be done programmatically, from a mobile phone even, as can Dynamic and Interactive scans to protect further Up Stream and Real Time Application Protection, (RASP) covers the Production Zone.

We also Load, Performance, Stress and Pen Test too in Sprints in Pipelines, so nothing is left out.

Speaking of Production, we got even cleverer here too.

We are really taking advantage of Hybrid Clouds and Non -Public Production Networks for Live Testing.

CFO, COO, CIOs and CTOs made production a Black Box fraught with problems.

These CxOs would not allow any Tests per say in Prod, no way, ut argh, definitely not.

Testing Prod safely has always been possible, but it goes back to old skool Environment Management, Creation and Policy’s.

Lean, Agile and DevOps always promote the concept of working from the outset in Production – like Environments, this mean scaled down versions, but factors like the type of DB, App Servers, Firewalls, run time stuff like OS, APIs etc must be the same as in Prod.

CFOs, COOs, CTO, CIOs couldn’t stomach the costs and order their middle managers to make available good enough versions. They didn’t behave like Prod, so whilst tests passed/were all green lit in Pre-Prod, they failed dismally in Production because it was like comparing Apples with Dinosaurs all because of cost – little did they realise the Cost to Fix and the Cost of Delay was far more detrimental on reputation and budgets than just sorting environments out.

QA, Test, Release and Environment Managers all kept up this charade thanks to ITIL, COBIT, ITSM gospel and the lot of them could not see the wood from the trees.

So us Lean Agile DevOps folk took this on as another challenge, and we leveraged Cloud Tech and Models, Integration Tooling and Value Stream Management Platform and Automated Environment Management, along with Test Management, Release Management and banished these antiquated bureaucrats from the agenda, letting CxOs, they can save a whole load of cash, pensions, insurances and overheads associated with occupying and warming a seat.

We pushed Smoke Testing and Canary or Bule Green Deployment Testing out too.

We leverage the Cloud Architecture and the Build and Burn Approach to the Full Cloud Stack, including Networks, Data and Security, and used ring fenced non-publicly accessible Production sub nets in our Clouds to Test in Live , before we go all out, wide and deep with an enterprise wide deployment.

The other beauties about this, is that it also stopped long weekend, night shifts and down time to update systems, we could push to Production is a subnet, hosted in a geographical region, target the upgrades/deployments, test in Live by switching over traffic across the subnets and even Clouds.

Lean, Agile, SRE, DevOps pushing the boundaries once again, making huge leaps forward in getting value to market faster, more reliably, at higher quality and with less pain from the old Guard/Stalwarts.

Netflix, Facebook, Google, Baidu, Tencent, Alibaba, Etsy, Amazon were absolutely flying now and we are copying them.

Thanks to all these annoyances, they just helped get down pat, Super Low Risk, Super Reliable, High Quality Automated Security, Monitoring, Testing, Deployment and Releasing, Environment Managed to Code, saving time, cost and energy for higher value thinking design and marketing activities where we could be more valuable and more integrated withing the business and technology trust and respect equations.

So this is where we properly start to get the “Automate almost Everything” tag from, fairly, or unfairly as without smart bears, the humans, behind creating the tools, behind the optimisation of the value stream, we wouldn’t have got to this stage of the journey.

DevOps 3.0 – 2015 – 18 Continuous Everything

The BoTs have arrived, not the Daleks, well Bots are exterminating low vale, repetitive work, but this is a great use case for them.

Cloud Native is growing strong and Kubernetes, Containers, Containerisation, Container Security, Management and Orchestration is booming and Service Mesh - programmatic communications between containers in registries/libraries is being solved at pace.

Golang, Google language for everything is gain pace, popularity and use in practice.

We have Continuous Everything going now – Integration, Development to Delivery and its time to focus on the Technology Business Relationship – pushing the boundaries here around Continuous Agile Business Planning, Strategy, Value Stream Management – taking what we do at Team and Programme level, into the Dragons Dens at Portfolio, Business and Enterprise Level for Maximum Impact.

Leaving the BoTs to do the brunt of the work with advanced Automation Scripts, (Command, Shell, Python or Bash), triggers and workflows, bringing in and harnessing what we know, understand, and can apply from AI, ML and RPA Technologies, Models and Patterns on top of Elastic Cloud Computing, Event Drive Anti Fragile Agile Architecture.

We now have the Telemetry to visualise problems before they even occur across the value stream or streams, Shifting even further Left.

Self-Detecting and Self-Healing Nodes alert Build and Burn BoTs who tear down, destroy infrastructure within seconds, and build new defect free instances of the hardware, middle wear, runtime and applications and restore networks across multiple availability zones, without anyone knowing, unless you’ve got Eyes on Glass, finding the latest secured containers, with the latest versions of everything.

The Old Break-Fix Panic Button is over, we are know aiming our sights at another siloed function and pain point for us – Disaster Recovery and Business Continuity.

In DevOps 3.0 we have fully embraced other cross domains disciplines and technologies and made the leap from Water-Scrum- Falls/Wagile, One Team, One Product Scrum and now are sparking a renaissance with Value Stream Engineering, Kanban, Lean Start Up and Lean Portfolio Management pushing the Business side along to greater Agility and Better Outcomes.

DevOps 4.0 – The Assembly Line for Everyone

Of course, I am leaving bits out, there’s much more that has gone on from DevOps 1 - 3.0 and now 4.0

Now at the very start of this articles, I introduced you to Value Streams and Enterprise Architecture as two key starting points/enablers of DevOps Adoption success.

Like Agile, in 2020 and Beyond, we are now extending the DevOps Culture, Movement, Ways of Thinking, Being and Doing across other areas, because DevOps is not just a pure Tech thing, it just fallen into this space because that’s were it was driven out from and people had focused on the automation only part, not realising the full business and benefits cases.

All you pure Tech folks, I need to you to step outside your comfort zone a second and put a business hat on.

For the last decade, those of us that straddle Tech and the Business have one point of focus – how do we bring the two closer together, into alignment to exploit tech through sound business and operational models.

Yeah sure, Software is eating the world, but there are still loads of other things we do, need and want, where creating value and optimising that value to make it more pervasive and ubiquitous are needed by upping how the value is created, delivered, realised and flowed.

Bring in the DevOps Assembly Line idea.

In DevOps 3.0 – we followed the Cloud Native, AI, ML and IoT trends, building these in.

DevSecOps is just everyday thinking and application now – we it should be with changes not only to DPA, GDPR, Privacy Shield, eTrust and ePrivacy but the increased threats of hacking, cyber criminals, and terrorism.

We also introduced the idea of Continuous Agile Business Planning and Strategy.

So now we are again looking at the full end to end value stream, not just the CI/CD or CDRA parts for IT

We are now making DevOps interoperable – playing with all other parts of the Organisation to help drive Business or Enterprise Agility. This is DevOps 4.0, sitting alongside Industry 4.0, Enterprise 4.0 and the Post Digital era.

The DevOps Assembly Line goes beyond the CI/CD or CDRA to driving the entire end to end value stream.

We are also seeing this influence in SAFe, were DevOps is a key focus of the Enterprise in terms of Flow and Value Management.

DevOps 4.0 takes all the business and technology, solution delivery, product management, portfolio management, procurement, manufacturing, supply chain, logistics, marketing, sales, the VUCA and the out moded bureaucracy and extends DevOps thinking, practices, tools, patterns and techniques to orchestrating the full end to end lifecycle management by streamlining/optimising the entire value stream as one of many in the Enterprise, as a globally distributed organisation is made up of many portfolios, products, services and business lines, across multiple markets and operating regions and diverse customer bases.

This is tackling the speed and scale problem that pure Scrum, Scaled Scrum, just cannot tackle from its incomplete design and intent.

Take Legal Contracts for example – you can programmatically embed the workflow into the DevOps Pipeline for the value stream – using automation, AI and ML triggered Automation Scripts and tools to scan for key words, phrases and legalise that doesn’t bode well with your organisation, saving countless hours of negotiation.

You can do the same for Track and Trace Supply Chain Systems, updating Dashboards in real time as goods and services are checked in and out, from source as raw materials, to plant, to suppliers, to customers and across their life with IoT.

In the IoT space, you can update all kinds of devices that can check their versioned release against the latest in the SCM Repo – think Mobile Phones or your Smart TV as two examples of this already OTA – over the air tech, then extend this to planes, trains, automobile and other connected stuff, John Deere tractors and drones already are self-driving, self-operating using GPS and automation tech, so why not optimise fields of carrots to grow faster, meeting peak demands or allow the soil to recovery during off peak lows.

This is about getting less puristic about DevOps just being something in the tech industry associated just for software, like with Agile which isn’t a method too, being more pragmatics to push the boundaries of Value Creation, Flow and Realisation.

Just imagine a DevOps Assembly Line custom manufacturing your bespoke/highly personalised medicines.

So those of us who have the skills, knowledge, understating and mastery of Lean, Agile and DevOps 1.0 – 3.0 are now looking to take the Culture, Concepts, Thinking and Mindset beyond just the Tech space i.e. Software and into Product, Production, IoT, Plant and Equipment alongside AR, VR and Mixed Reality.

DevOps, DevSecOps and all that Dev X Ops stuff, is now properly pervasive and ubiquitous if you try to properly implement DevOps and not take CI as a method or stage.

It’s not a trend, hype, BS or a defined and bounded method, its actually just part of Innovation Culture and the value stream sub processes.

That’s really hard to grasp for people just discovering DevOps, who don’t understand it fully or who just want to exploit bits to sell you their hype to make money out of you.

I’ll go as bold to say, that the word DevOps will become less and less used, because it just an expected norm now, in the new normal and new new as its now pervasive and ubiquitous and those using it will be the sales types, not the practitioners, innovators or change leaders.

Crystal Ball Gazing for your Enablement Roadmap

We already have got away from the need for jobs titled DevOps Engineers.

Most Devs, even non-Developers who are Tech Savy, can deal with YAML files, a spawned from JSON and Python, as a human-readable data-serialization language for configuration/config files.

Low Code is the choice of those in the know.

SI’s, bespoke systems engineering and building has created the problems, hassles, and legacy that we no longer want, need or should be considering in any Business or Technology Plans, Roadmaps and Strategy.

Stuff like Azure DevOps is changing the way people think about DevOps tools, toolchains, and pipelines.

Tool sprawl is massive issue in DevOps, so as Cloud Vendors offerings get better and better, will there be a place for open source, inner sourced or proprietary suppliers in the consolidation/simplification game of optimising the enterprise end to end Assembly Line across value streams?

No Code is the future for 90% of Start-Ups, Business and Enterprises. The less time we can spend dealing with Automation Scripts, (Command, Shell, Python or Bash) and work in a script less, minimal click and configure way, the more time we can spend on solving higher value business and software problems, this isn’t just a DevOps trend, this is a Tech, Business, and Industry trend.

We need to spend more time on the business of doing business otherwise business wont survive to the Post Digital Era and it would suck to have just Amazon, Facebook, Apple, Netflix and Google running the world, we’d all be in the ultimate Truman Show.

Better throw in Serverless, Serverless Architecture, Serverless Compute…. its going to be big as it will save on rental costs of reserved instances, save on build and burn/tear down as it will be a more pure PAYG system – for only the workloads you run, so for those that can master this, there is potential in spades, but how good this potential is, is like AI, ML and Big Data, yet to be realised until the ype wagons and bias is trained out and taken away from Sales, Advertising and Marketing Folks you use it to shove stuff down our digital throats.

The 2020 DevOps Enterprise Summit just ran virtually in Vegas, check out here videolibrary.doesvirtual.com to see where we’ve been, where were going and the art of the possible though DevOps Culture and Movement.

Still Banging the Drum - Why DevOps isn’t a Prescriptive Method

The simple answer is sixfold in my mind:

• it doesn’t want to be another Functional Silo
• it’s still an Evolving and Emerging culture and set of cross domain technical patterns and techniques
• it should be implicit, pervasive, and ubiquitous within any Agile team
• it doesn’t want to fall into the empiricism trap of becoming all scientific, commanding and controlling to remain adaptive, responsive, learning, sensing, and feeling
• we believe in better and have moral and ethical compasses that steer us
• we already have a title/name/label/sentiment/intent for it that works – DevOps.

We have moved on already from the initial intention as I have explained in detail, of bringing Development closer to Operations and Testing, depending on which Venn diagram you see as explained in evolution from DevOps 1.0 - 4.0.

If we let people believe its all about pure play automation, then we might as well make the Mobius Loop equivalent to the Scrum Diagram and call this our Method or Framework – no thanks!

We’ve been able to negate these tags largely because DevOps is so embedded, pervasive and ubiquitous, we don’t need to call it out, make a big deal of it, we just know how powerful and advantageous it is in your value stream/s, portfolio and across your businesses or enterprise as a Capability that’s Deeply Seeded in Your Cultures DNA and Thinking.

Succeeding with DevOps - The Benefits of DevOps “Strategy”

What is strategy, its no more than plan and as a military commander once said, all plans are worthless, they change the minute you set foot into the theatre of battle/ the operating environment…something along those lines!

Strategists will have you think its a dark art, only those with an MBA can do, oh so wrong.

There is two approaches to a DevOps Strategy.

The linear one, where you lay it all out upfront, and speed though bits you’ve done already and slow down on bits you haven’t, starting with SCM and Config Management, then CI etc or and then ther eis the more organic, coached style of transformation or adoption, where by you assess and evaluate learning and application on a SWOT style basis, just in time, just enough to get the job done.

Either one, really and truly only forms at best, a Loosely Defined Near Term Continuous Tactical Roadmap more than a set linear strategy based on CPPM thinking of old.

In my Consulting, I have been forced into making it a series of steps like a Capability Maturity Model or Milestones on a Gantt Chart, or under the guide of Proven Repeatable Steps in the vein of Software Factory, Agile Factory or like the SAFe Implementation Roadmap, for Sales to be able to flog it it priced out chunks of work, phased and staged by cost/budget constraints etc.

All fun and games, shits and giggles, however, it just doesn’t work like that in reality, its far more complex, complicated, and organic as it’s about the underlying psyche of people, not tools lined up and automate, automate, automate like a Dr Who Daleks and must take a Lean Agile approach to it.

Its not about exterminating ITIL, SDLC, its about constantly improving and moving on from them and using all that we have learnt, the good the bad, the ugly, and uplifting it with complimentary knowledge from other practice areas/domains/disciplines, constantly evolving and iterating – that’s why its not a method.

Lining the tools up is easy, scripting is relatively easy for all use cases, but changing the Organisational Structures, Designing, Thinking and Process – the bits that create the Value, the Culture and a Following of that Culture are the hardest bits of all.

Suddenly Naming your Team the DevOps Team, The DevOps Department isn’t going to do diddly squat.

Sure it will get some attention and maybe internal Comms might want to hype up the grave train, but the way to approach complexity is with complexity and realise there is a complex, people system to deconstruct/disrupt and rebuild as an always evolving and emerging, complex and adaptive learning organisation through Enterprise Agile Coaching – not Scrum Mastering, very very different.

Take the off the peg DORA X Ray Assessment, SAFe DevOps, AgilityHealth DevOps, Comparative Agility or your own self devised Health Assessment as a bench marker.

Set some OKRs as the CTO, CIO, CISO, CxO leader.

Make an objective assessment with your people and critically look at the results, instead of rushing out, buying Microsoft Azure DevOps, a bunch of best in class/breed tools and tell people to get on and use them.

A good DevOps Adoption Roadmap builds on CALMs, ADAPT and other models by constantly adapting to needs, wants, desires, but remaining focused on the bigger, wait for it, strategic picture, by making tactical and influenceable moves with the jigsaw pieces.

One of the tricks is to build out the capability equally.

Management thinking always goes straight to the Lighthouse Project or phased pilot aka PoC, PoT, Pilot/Trial, Rollout, Wagiling or Water Scrum Falling.

So they build a new dependency hub and call it a DevOps CoE.

If you feel this is right for you, make sure you plan hard to “phase it out”, otherwise you’ve just build a dependency and reliance upon the paid for technical expertise.

Your objective is to build a a secret DevOps Movement or Culture.

This is not just me saying this, this is a key finding of the latest State of DevOps report, it’s a create business model but a poor adaption/transformation model.

If you take a CMM ladder style DevOps Maturity Model approach, people and teams can see it coming a mile off, and it will be the least engaging approach you could take, even creating more resistance to the changes to come and be scaled.

I like to either use triggers or reverse engineer things.

Triggers are caused by problems, blocks and barriers which need a solve/solution. As a Coach, I can leverage these to tackle complex problem fast, and generate lot of learning, ownership and divulge power to the people to solve under my guidance, storytelling, reflection, tutor-lidge etc.

In reverse engineering, I start by building Communities of Practice around the Guilds idea.

A Guild being a bit like a CoE, but one that is owned by the people in the organisation and not the SI or Consultancy as a never-ending contract extension exercise, however you may need folks to jump start or kick start this off, but the goal is for the community to own the community as a place and way of learning.

Taking a the linear CMM Team approach, is the old ways of working and treating things like a factory.

People are not machines and cant be lined up, so to set up for success, to ensure the “handover” or the culture is embedded into the DNA, then you are best served by taking a Coaching approach driven through Agile Conversations, deep diving and sustaining the Patterns, Practices, Techniques of the Culture around the how and why over the what and when.

This builds culture over tools, and you can reaffirm behaviours that you want and clamp down on those you don’t.

Now bringing in HR really early as partner in crime is a smart move

You need to bring new talent in and mix up the talent pool to seed the transition.

Also part of your “strategy” per say, might be to immerse these people into new acquisitions on secondments to acquire the skill and mindsets to cross pollinate and breed in the main organisation or even be given the freedom to set up and be the Chapter Lead, Guild Leader to establish the active CoPs needed.

You see, on paper, in a deck, its easy to say start with CI, the CD, then Testing, Then Security, then, then in blocks, but we don’t acquire skills, knowledge and understanding in this way with Knowledge Workers through Management 3.0 , its through social networks, interaction, inspecting, testing, adapting and adopting that we make real progress.

So, to continuously improve, you need to collect fast qualitative feedback, as well as the hard quantitative performance data from your SCMs, STEs, RTEs, Agile Tech Leads, Agile Architects etc and your Health Assessments and create subconscious interventions and immersions based on opportunity, events, needs and wants…you can lead a horse to water, but you can’t make it drink!

Traditional Change Mangers just don’t get this picture or point of view, so go with an experienced and effective Enterprise Agile Coach, alongside an Agile Coaching Network and Agile Roles and apply a systems thinking approach to sprint in iterations, improvement cycles and increments to balance the whole, instead of having that one single solo team that’s flying and everyone’s else is, well falling back, this is a common anti-pattern and failure rather than a success, as fear, FOMO and competition, doesn’t always breed success.

So as part of your Business Case for DevOps or DevOps Strategy, ensure you have some of these Key Result Areas to:

• Disrupt the Internal Org Design, Structure and Operating Models
• Provide a Disruptive Technology experience
• Build Employee Engagement, Empowerment, Enablement and Retention
• Build Organisational Learning Time In
• Reduce or Eliminate Functional Silos
• Reduce Hand Offs and Bottlenecks
• Speed up Time to Market
• Build Quality In
• Treat Everything as Code
• Automate almost Everything
• Contribute to Efficiencies and Lowered Cost to Serve from Operational Excellence

The Roles you will Need, but beware of the Titles you give them!

Setting some of my own and others rhetoric aside, to be pragmatics and support the adoption, transformation and embedding of a DevOps Cultural Movement, here are some of the roles you will need, but beware of the titles you give them and the employment status as these will have a profound and long lasting impact that you probably never had any intentions of, and their not so hidden subsequent consequences.

The Pi Shaped Transformational Leader and DevOps Evangelist

The Leader is a multi-hatted X or Pi Shaped Role and is a critical Success Factor in inspecting, adopting, embedding, and scaling DevOps.

Its part Evangelist, part Visionary, part Transformation Leader part Change Agent, part Coach.

The person should be tactical, strategic, motivational, emotionally intelligent, speak the language of DevOps and Agility as they will help design, influence, implement, motivate, and sustain the cultural transformation.

More important, this person should be able to communicate these benefits to other people and members of teams.

This communication ensures buy-in and a unified commitment to change. The DevOps evangelist is also responsible for the success of DevOps processes and people.

The evangelist determines which roles are necessary to optimize the process and what training is needed so that everyone is prepared and empowered to make the necessary changes.

They should also have experience in Value Stream Engineering/Management, ITSM, Product, Programme of Portfolio Management, Business Administration and Organisational Development

The CIO, CTO could be this person, you may hire them in as new talent or augment via Agency/Consultancy or Freelance Contractors.

This is the role I perform, Its akin to an Enterprise Agile Coach – because you work above the operational Teams at CxO level on identifying Values Streams, aligning Business Strategy, reshaping Organisational Design, assuring and optimising the Flow of Value.

As you can see, this is more of a role than a job title.

The T or Y Shaped DevOps Platform Manager

The Manager, an optional role and now we fall fowl to title, therefore its commands position, power, authority, and influence – an anti-pattern to the flat structure of the Agile Team Typology.

The role is focused on Sharing Knowledge, Ideas, Concepts, allowing others to better understand DevOps, spark curiosity and innovation

Often this person is the DevOps Platform Owner – more latter on this not so good idea.

The type of person you are seeking is more of a highly skilled trainer, facilitator or consultant who has DevOps Know How, to spot bottlenecks, impediments, barriers in the flow of value, to help set up, configure tooling, support its mastery, coach and transition over to Agile Teams, embedding the skills they need to Self-Service across the value stream, ART, Solution Train etc.

You can find these folks from within the Tech Lead, Solution Architecture, Developer and Site Reliability Engineering communities.

They help the Lead/Evangelist, build the Continuous Delivery Ecosystem.

The DevOps Engineer – The I shaped Specialist

This is an optional role, especially if you take a Low Code or Scriptless No Code solution and/or one that you might have to augment at the start but can absorb completely into the Agile Team Member skillsets.

These folks need a combination of Development/Engineering/Coding skills, be familiar with APIs, Shell Command, Python or Bash Scripts to trigger workflow automation.

They will initially help glue best of breed/class tools into Toolchains or Pipelines, for builds, continuous integration and deployment, sort configuration management of different environments, help with load balancing, auto-scaling, and failover solutions using disaster-free and recovery automated approaches, help sort security audits of networks, environments, and applications and apply real-time proactive software and hardware monitoring.

If you go with scriptless, COTS buy not build approach e.g. Azure DevOps for instance, its pre-glued together by the vendor, Microsoft, so you don’t always need this type of support, just a credit card, and some spare time to click and configure settings, as with Amazon, Oracle and Google, all of whom have inbuilt, free solutions.

Folks that are good at this role tend to come from Solution, Application Architecture, Service Support, Service Delivery, Lean or Agile Teams as they are doers, practitioner focused types.

Roles you Might Need and those you Can Give Up

Might Need:

A temporary DevSecOps specialist

You might initially need a trendy DevSecOps specialist to help with getting security monitoring, security testing, ethical hacking and existing Security Dashboarding integrated to the toolchains.

Cloud Engineer

As DevOps is best done via a Cloud First Policy, it can be done On Prem, On Tin, albeit much harder and without many of the benefits, but a Cloud Engineer can be helpful around the IaC, IaaS, NaaS, DaaS, SaaS, PaaS, IAM and applying the Cloud Native tools eg Azure, AWS, Google, Oracle all have their own free DevOps tools inbuilt, so kill two birds with one stone if that’s your thing and it make sense eg you’re not ging for a Hybrid Multi Cloud Policy were standardising the tools across all the Clouds makes TCO, Mastery much much easier.

Agile Test Lead

Another role that might be initially needed and then subsumed into the Agile Team, CoP, Guilds and Tribes, is the Agile QA or Test Lead.

The Agile bit is super important too. Not just any old tester, they have some awful, time consuming and costly habits that don’t add value! Harsh, maybe, but mostly right in my 20 years’ experience.

They will help integrate Test Management, Test Frameworks and Test Results in your DevOps and Agile Collaboration Tooling based on Technologies, Languages, Libraries used etc.

I strongly suggest you augment this as its short term role and your DevOps Roadmap/Strategy should show transitions for phasing out such roles, otherwise you doing a half way house and not letting old habits go and transforming, instead staying within your failing/burning safety blankets.

Can Give Up!

Now adopting DevOps means major changes and that means you can give up a lot of your functional silos and specialist roles – saving you money or best case, being able to use it somewhere more valuable.

Pure Play IT Operations Managers

These folks who help support/service desk tickets, track SLAs/OLAs, monitoring performance and set polices can go.

We don’t need command and control folks and our tool chain replaces much of this through automation and because we now own things end to end, we don’t hand off, we control SLA, OLA and Metrics, we fix problems before they occur and when they occur, ITSM/ITIL is built into the teams skill sets.

Business Owners/Sponsors can pick up an gaps left, they do anyway and it brings IT and the Busines cloer together, so its more of a win in a word where 99% of companies are tech or software companies, whether they want to admit o it or not.

ITIL Change Managers, Release Managers…

The Agile Team now controls its own destiny for release and deployment strategy/practice, operating a Minimum Viable Bureaucracy, not an ITIL union for jobs for the cronies/boys.

Product Managers, Product Owners, Scrum Masters and Agile Teams now do the Release Plan, Release Planning and Release and Deployment Process, making the roles redundant.

If you’re using SAFe ( nice one, smart move!) as your overall Enterprise Agility Framework, you can uplift, retrain, debrain wash! make old skool folks Agile, then you could reuse/train/redeploy them as Release Train Engineers/Solution Train Engineers – but be warned, 6 weeks in and bad ITIL/COBIT/ITSM habits will kick in, so have a DevOps or Agile Coaching and strong CoP to recognise this and nip it in the bud fast.

Service Delivery Managers

Are another role that can be given up too by breaking free of the ITIL Union and Beauracracy

The Product Owner, Solution Manager replace these roles, so you can simply and rationalise your head count, reducing duplication, overlap and make even more cost efficiencies in your Organisational Design and Structure, something often missed in Agile Adoptions and Transformations, because they only focus on the Scrum Process/Method and because HR is working with Hiring Folks to attract, recruit and retain folks capable of being and collaborating in networks of Self-Governing, Self-Managing, Self-Organising, Cross Functional, Multi -disciplinary Agile Teams.

So there is plenty of coverage of the associated activities in other roles/jobs.

The End Goal is Not a DevOps Team, or Platform, but DevOps as a Self Service

Business's love a Platform Model, whether they understand it as PaaS or the actual Platform Model.

Either way, it’s a great extensible, interoperable and accelerator model used in the right context.

Now the problem you will be faced with if you go for the Platform Model, is that you need to create another functional silo to build, run, maintain, operate improve, each train folks on that special bit of kit and you go down the ticketing route to manage demand, supply and capacity and you never enable self-service and therefore enable better flow either.

That’s the anti-pattern of the DevOps Culture and what were trying to achieve/realise as business and technology outcomes.

DevOps in a Box is plain bulldust, sounds attractive, will entertain you for a while, but in reality, DevOps is far more complex that trying to commoditise/monetise/productise in a kit form to build it yourself like IKEA flat pack furniture.

DevOps as a Self Service is the right frame of mind and guiding North Star to aim for.

Taking a Service Orientation is advantageous in many ways.

First, its Culture First and will change the DNA and RNA to a new cellular nucleus and kreb cycle that emits DevOps Thinking, Patterns, Practices and Techniques.

CoE, Hubs, Shared Service Specialist teams are just siloed dependencies, and we don’t learn if we can fall back to someone to do it for us, it human nature and hallmarks of Delta style hierarchical bureaucracies – no good for Agility nor DevOps as part of Enterprise Agility.

The upshot is music to CIO,CIDO and CTO ears – TCO reductions from tool sprawl.

This is the difference between Enterprise DevOps and DevOps. Discipline and Mastery around 30 tools, or no discipline, no mastery, but all the shiny tools in the best of breed/class reports and analysis for 4 Pipes/Use Case applications.

Consolidation is a good thing, it makes adoption easier, support easier, training easier, enablement easier.

If you have 4 CI tools, 6 repos and 100 Test tools, then migrating away from this to Cloud Vendor offering can also work, but be very cautious for hybrid multi cloud scenarios, probably better of being agnostic to fight any kind/form of vendor lock in!

Tickets suck, everyone hates tickets. So just avoid them.

Making Service Desk people do them instead of the requestor sucks for them too if that’s your customer strategy workaround.

ITSM has ingrained the use of Service Desk, but DevOps and the Agile Team should negate these. Why? How?

Because the issues should be writ as User Stories by the Product Owner who has a ear to the wall for customer feedback, actively uses an open, publicly accessible roadmap and allows suggestions form the suer community to be added.

On top of this, we have such good monitoring and observability tooling and capabilities in our DevOps pipes, that our efforts should be focused on customer sentiment, ratings and reviews, NPS, customer care feedback and other data to be customer responsive, silently but actively listening and learning and solving for the surprise and delight.

It’s a whole attitude change to dealing with things through Product Thinking not ITSM, Management by Numbers and Activity, but by Value and Flow

Enabling and empowering Self Service is the game.

Instead of tickets, let your Users go to a Portal, let them select Tools, APIs, Web Services, Containerised M/S and just get on with stuff instead of watching over and managing – lead them instead!

This Portal is your reusable, repeatable, preapproved asset bank. 

Architecture, the CTO, CFO, COO, Manager if you have them instead of leaders, all approve and therefore we can all spend more time on value creation as opposed to tickets, the hassle, pain points and chokes that ticket systems impose.

This is the pinnacle of empowerment, of trusting your teams, decentralising decision making, bringing agility to the business and improving the flow of value.

I am not dreaming here, this is all very feasibly achievable, doable and possible now, last year and 4 years ago if you just give up old habits, methods, tool, frameworks that lock you in to a fixed mindset.

DevOps vs Enterprise DevOps - Aligning your Organization

As stated, probably the biggest anti pattern to successful DevOps adoption/transformation is just running out and buying a host of tools in a build it and they will come fashion, well hope isn’t any kind of strategy or approach, it’s just guess work but you do need to be ahead, assuring your architectural runway is well ahead of your teams thinking, needs and wants, otherwise flow stops.

CIOs, CIDO, CTOs would argue, where is the business case to support this demand led.

ITSM, ITIL, COBIT and TBM all take this same metric driven approach and this is why we are stuck without the tools we want, need and the terrible architectures and vendor lock of monolithic applications.

This is again a failure point in Agile and Digital Transformation that then DevOps has to re-address because we are looking outside the IT silo to end to end value streams.

The TCO for tools can be high, and every time someone goes to a conference, a meet up, a webinar, they will come back saying this is the best thing, we should have it and do it like Netflix cause it works damn it.

Whilst copying is a form of flattery, its most often not the best or even good way forward, like consultants think this is just another cookie cutter game to build software factories, but how many of these approaches have succeeded, very few.

Stopping the spread of tools is critical, the can cost a lot when you have 20 00 end users consuming them on a 6.99 per person subscription.

Also as an EA, don’t just draw up your capabilities and application views and buy what you want. Add space for Current Solution, Target Solution and Demand Led Solutions.

When I say demand led, I mean by the end users.

Putting a tool in place they actually want to use is more important than the best, mastery is everything, shiny in nothing.

So, what’s great about SAFe and SAFE DevOps, is this principle around Organising around Value, using TBM and blending it up with Solution Management, and stuff to make aligning much more of a participatory or collaborative things than in isolation by EA, its not new, but atleast it gets C – Suite attention.

DevOps Tools: You Need Them But They Are Not The Focus Of Your Efforts

In a convoluted way, I have covered this off in my ramblings.

You can’t avoid “DevOps” tools, they are essential, but more essential is to get the culture right as tools are just a means to an end but it’s the culture of DevOps that’s so game changing from Lean, from Agile that gives it its USP.

DevOps Pipelines: The Functional Building Blocks

Automation enables Agile Teams to promote artifacts through its lifecycle, from testing, development to production, with assurances to achieve Continuous Delivery or to Release on Demand.

Like tooling its part of the culture of DevOps and there is no getting away from it, otherwise its just RPA.

The Value Add in DevOps comes from reducing delay in time to value, increased visibility and governance, early uncovering of vulnerabilities, monitoring, automated infrastructure provisioning, increased agility and resiliency, enhanced quality, reduced outages, scalability and improved innovation.

I’ve seen a lot of assumption that there is only one DevOps pipeline, but there is many in reality, and each one will likely look differnto the CI/CD Blueprint of old as each has its own unique variables by technology, by use case, so is therefore, not a method or cookie cutter exercise of one pipe fits them all.

Ensure that if your still a project focused organisation, in your alignment of people, you atleast acknowledge that for success, its not a matter of creating one pipe and where done.

When is DevOps a Success?

DevOps is a Success when it’s like the Secret Service or Spec Ops, Never Heard or Seen, just Felt, providing Overwatch

The best outcome for any DevOps Adoption, Transformation, Initiatives is when it becomes part of the Organisational DNA, when you don’t hear people saying we do DevOps, it’s not in their job titles and definitely not a Shared Service team or silo.

DevOps works best when Lean and Agile Teams leverage it to increase the deployment rate of value, value added product, services, or experiences and that’s enabled through a strong active community of practice.

It is able to do this through networks of small Agile Teams, fast feedback loops, MVB, small batch sizes, and smaller but much more frequent releases of higher quality, more reliable and secure products, services and experiences.

Enabling this is a Pivot to Product, Cloud Models and Technologies and most importantly, people who think, live breathe and do DevOps unconsciously, as part of their normal day to day activities – that’s when it deeply embedded into the DNA as an unconscious competence.

Judging this is a Go See exercise, measured by seeing the rings on the radar nice an even and most importantly, is when the organisational brand recognition is uplifted, your fending off talent, your perceived to be a disrupter or disruptive in your markets, demand is meet with surprise and delight and you don’t say we are done, it’s not a project, a programme, it’s a continuous journey.

Summary: It’s a Culture Thang!

Once you’ve passed the initial J- curve, you’re a long way of success still, you must sustain and keep scaling your DevOps Movement/Culture within your Teams, Brands, Divisions, Business Units or Lines of Business, across the Business and the Enterprise as part of you overall journey to achieve Business or Enterprise Agility.

Its takes a while, I am a Skateboarder, Surfer and Snowboarder and as part of these movements, have been called a layabout, anti this, anti that as part of the cults, but these are so mainstream, they are Olympic Sports.

DevOps is mainstream, its not hype, nit a fad, and isn’t going away either.

Avoid Agile and Digital Transformation pitfalls, focus on Organisational Design and Structures and move from the Delta Pyramid to atleast a Well Matured Matrix, even if this means Spotifying it, as this is when the Cross Functional, Multi-Disciplinary, Full Stack, Long Lived, Self-Governing, Self-Managing, Self-Organising, Product Focused, Value Optimising Agile One Team Culture is able to Continuously Respond to Change and Deliver a product/service/platform or experience to market On Demand, with high quality, better security and more reliability that endlessly surprises and delights your customers as there is no such thing as BAU.

Good luck, happy to help and remember, DevOps isn’t a Method, a Team, a Person, or a Job, it’s Cultural Movement, A Way of Thinking, Being and Doing Deeply Embedded into your Responsive Learning Organisations DNA.