Skip to main content

WARNING! The Titanic is Sinking! Service Providers… Stay CALM & Share!

(DevOps VALUES revisited)
We used to talk about the rate of demand for change and how that was forcing service providers to change course.  Service Providers are the current Titanic.  Many believe that they are invincible.  The iceberg today is multifaceted. It is not only speed and quality but the challenge of dynamic business requirements, complexity of new services and rigid silo’s. These all add to the depth and potential threat of this new iceberg.  To avoid sinking, Service Providers must consider the DevOps values and stay C A L M and Share!  There are five DevOps values that will help us avoid the iceberg.  These values include:

C - Culture
A rigid, “We have always done it this way” culture will break your capability to steer the ship in the direction that you must go to avoid the iceberg.  A Cultural shift will steer your ship in the right direction.  Those shifts include
Shift Left Culture– Getting representation for change, compliance, security and operations engaged early in the requirements gathering.  The challenge here is how we integrate these into our Agile/Scrum teams or traditional project management activities.  Service providers will need to integrate and engage these stakeholders throughout the design, delivery and support from idea to end of life for the service.  Life preservers and Lifeboats must be fit for purpose.
Proactive vs. Reactive - Continuous Integration should not be confined to code and developers. Integrated Security and Integrated Testing for true Continuous Integration will be required to get the type of results we hear about from Continuous Delivery.  This cultural shift will require that we shift our entire thought process out of the silo and collaborate across all functional teams.  These teams include:  Business Partners, Customers, Architects, Developers, Operations, Engineers, Security, Legal, Change Managers, Partners and more.  Being truly proactive keeps us on the right course and away from the iceberg.

A - Automation
Automation alone will not keep us from hitting the iceberg.   You can not automate chaos. Just enough process, (not a 40-page document with hundreds of checklists and useless KPI’s) and just enough governance will be required.  Communication and Collaboration will allow for an understanding of toolchains and the ecosystems involved.  Easy to say but what tools are you using to allow for collaboration?  What teams are using Kanban, Chatbots and others?  Do you have policies in place?   Do you know what your “Eco-Systems" are?  Transparency is required here.  Be very careful.  Remember that open source is not always the most efficient and there is no one vendor solution to provision.  Continuous Delivery is not the goal but is merely one of the tools utilized to meet the business goals. Be careful and don’t automate your ship directly into the iceberg.

L – Lean
Consider the flow of work from idea to the delivery of a service into an antifragile, secure production environment. Service providers will need to consistently search out where there are constraints, roadblocks and waste.  Visualizing the flow of work using lean tools like Value Stream Mapping will prove to be a good first step.  Plot the correct course at the right speed and avoid the iceberg.

M – Metrics and Measurements
If metrics and measurements are looked at subjectively from your individual functional teams or departments (silo’s) then they are likely to look good.  As a matter of fact, individual teams are out celebrating their numbers and customer satisfaction could very likely be taking a dive in the wrong direction.  WARNING!  New metrics and measurements such as lead time (not just cycle time) will need to be considered.  Also, what is your velocity?  Does it meet the rhythm of demand or cadence required from your business customers?  Are developers using Agile, Scrum and other techniques to speed up only to hit a brick wall when it comes to change, security or other risk mitigating activities in the delivery cycle?  If so then Danger, Danger, you may be headed towards the iceberg.  Measure to business goals and results.

S - Sharing
Share what? People, Process, and Technology.  Experimentation and learning is key.  Across the board collaboration, communication and education will be an ongoing endeavor.

Learn more,  Inspire and Educate so that we don’t hit the iceberg!


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): ·          Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” ·          Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services-that is people. Because the people element adds variability, the service is variable. This holds true especially for th

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service". I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize: SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle. ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with