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 policies (r…

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 the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…