(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

ITIL advocates that IT services are aligned to the needs of the business and support its core processes. It provides guidance to organizations and individuals on how to use IT Service Management (ITSM) ­­­as a tool to facilitate business change, transformation and growth. Some are believing that ITIL has run its course.  In truth I believe the opposite is true.   In the past, and still today, many organizations believe that Best Practice and ITSM processes are focused on the Service Operation Lifecycle.   Implementation, process design, and ITSM tools have had a very heavy focus on processes like Incident, Problem, Change and Configuration Management. Few have yet to recognize or have not seen the value in the guidance for Service Strategy and Service Design processes and roles.   How did these get overlooked? In the last three or so years I have seen a bit more buzz about “Business Relationship Management”.   Less so for “Demand” and “Strategy Management” for IT Services. Few are

 Success in modern technical endeavors absolutely requires multiple perspectives and expertise to collaborate. (1)  When I ask managers attending my classes if their organizations practice ‘agile’ they hesitate and say something like we kind of do but not in all areas of the organization. Further questioning usually uncovers that most of this agility starts and ends with the software development teams. When asked if these practices have been introduced to the business units there is a long uncomfortable pause, and then I hear 'we don’t usually talk to those groups'. Over the last couple of decades, a new set of major management philosophies have been developed and are now being adopted to ITSM. These new ways of thinking enabled manufacturing, software development and others to analytically realize both disciplined execution and continuous innovation, something that was thought to be mutually exclusive and impossible to accomplish with traditional management methods. Over

I always hear people say ‘Don’t like the weather, wait an hour it will change’.  The one constant in our lives is change. In business today, customers, users and stakeholders all have the expectation that as IT service providers we can and should be able to handle change requests at an ever-increasing pace.  Yet they still have the expectation that an appropriate response to all requests for change entails a considered approach to assessment of risk and business continuity, change impact, resource requirements, change authorization and especially to the realizable business benefit. For us to be able to do change management in an Agile environment, does that mean we must give up those requirements for speed and agility? The purpose of Change Management is to control the life cycle of all changes enabling beneficial changes to be made.  I was once told by a very wise thought leader ‘Being agile is a state of mind.  It’s more perspective than prescription.’  Why can’t we have a

ITIL is not in conflict with DevOps, ITIL supports DevOps with a solid foundation by providing an up to date an accurate configuration of our IT infrastructure. This, in turn, supports the ability to accurately carry out the detection of issues and underlying problems and deliver collaborative, permanent solutions to operational deviations. Further, it engages the Second Way by “shortening and amplifying the feedback loop” to development.  Historically most IT organizations structure their incident, problem and change processes within a very confined view, typically utilizing these processes from an operational perspective and only marginally engaging them at the design stage of the lifecycle.   ITIL should and can be adapted to DevOps practices to proactively define when incidents and problems arise while still in the design phase of the lifecycle.  This means engaging both software development and infrastructure design in a way that allows us to capture these deviations proactivel

What is an Agile Service Manager? The following is a definition from the University of California Santa Cruz for an IT Service Manager. “The Service Manager has overall accountability for defining the service, ensuring services meet the business need and are delivered in accordance with agreed business requirements and managing the  service lifecycle  – often in conjunction with a  Service Team ” . I also looked up some jobs offerings from around the globe that were described as Agile Service Management and took some pieces from them.  Here are a couple of examples: Has responsibility for defining and creating the global service, developing the reliability and performance of the services in line with the business requirements, and managing the overall service lifecycle within an agile environment. This includes stability, performance, capability, risk acceptance and analysis of the services. Developing a deep understanding of what is important to the service, you will be pri

Behavior-Driven Development ( BDD) is a process or best practice for the development (and testing) of code. Behavior-driven development is a design and testing practice that is utilized to ensure that the outcomes and the behaviors of products and services are articulated in terms of business value.  It means that we should step aside from the technical aspects of coding, development and testing and consider, in real everyday terms, what the behavior and usage aspects are of the application or product.   We will still require technical skills, insights, automation and more, but when thinking about the defining and development of a product, business and service providers can articulate in PLAIN ENGLISH exactly what they are attempting to achieve. BDD helps design and development practitioners scope appropriate testing for a variety of test types including: Unit tests : A single piece of code (usually an object or a function) is tested, isolated from other pieces Integration

Network Neutrality preserves your right to communicate freely online. The term Network Neutrality was coined in 2003 by a Columbia University media law professor named Tim Wu.  Back in the day it was referred to as “Open”.   Network Neutrality is a principle where internet service providers and government regulators must treat all data  on the Internet the same.  This means that you cannot discriminate or have differential charging and costs based on user, based on content, website, platform, application, equipment type, or mode of communication. It’s because of Net Neutrality that small businesses and entrepreneurs have been able to thrive online.  Our fair and level playing field is at risk.  Big phone and cable companies and their lobbyists filed suit against the FCC guiding principles for Network Neutrality.  Internet Service Providers (ISP’s) have much to gain financially if they can discriminately charge for varied services that are currently free.  Free Press jumped in an

We saw in a recent blog from “The Professor” how cybercriminals could create a network of controlled computers to propagate a “BotNet”.   One of the malicious reasons for these powerful networks of control is so that the hacker can perform “Distributed Network Attacks” (DDA’s). We all have experienced this at some level and the outcome is not good for enterprise, corporations, or businesses of any size.  DDA’s create disruption even to our own home operations.   A DDA is sometimes referred to as a Distributed Denial of Service or DDOS attack.  This virus or network of virus’s attacks behind the scenes to take over system resources.  A DDOS could attack switches, hubs, routers. It sometimes will flood the network backbone with nuisance transactions with the intention of sucking up all the bandwidth that might otherwise be necessary for day to day operations. DDOS can bring to a screeching halt the web sites for processing claims, or even shopping cart interfaces for the purchasing o

Today every business is an internet business.  The performance of any business is directly related to the capability and performance of IT.  Therefore, we must all take cyber security seriously.   Let’s start with a botnet by breaking down the word itself.  The first syllable, “bot” is short for robot. The second syllable “net” is from the word network.  A botnet is formed when a hacker writes a computer program that will breach security on a single computer.  It does not stop there.  This computer program called a virus has the capability to take over that computer that it just hacked into. It does not stop there either because this is not good enough for the cybercriminal.  With a botnet, the virus will move from one computer to another, take control of each and then connect all of the disparate computers into a powerful system or network of control.  This is known as a botnet. Cyber criminals are control freaks.  They will sometimes create a virus that controls thousands or

In a previous blog from the ITSM Professor we focused on the relevance of ITIL and ITSM Best Practices to contemporary IT service providers.  We learned how a successful DevOps initiative must embrace ITSM, Lean, Agile and other frameworks and practices to ensure success.  The solution to value is like a diamond and has many facets!  In 1992 I read an article that talked about the key to delivering value and the topic was all about People, Process and Technology. Twenty-five years later I must agree this is still the winning formula.  What might be different is how we view and utilize these for success. What will Change? People – Integrated teams with ownership and accountability. Visualized workflow and clear direction.  Communication, Education and Collaboration required.  Inspire and Educate! Process – NO MORE overburdened bureaucratic d ifficult processes to follow.  We want just enough process, just enough governance and the process activities will no longer be

With the onset of practices such as DevOps, Continuous Delivery, Rugged Code, and Value stream mapping, is ITIL / ITSM Best Practice still relevant? The short and emphatic answer is YES! Let’s look at how ITSM Best Practices are relevant and enable some of the initiatives that are in the foreground of Service Management for many contemporary IT organizations today. DevOps – DevOps is a cultural and professional movement that focuses on communication and collaboration to ensure a balance between responsiveness to dynamic business requirements and stability.   Therefore, things like Lean and Value Stream Mapping, practices like Continuous Delivery and Continuous Deployment, all become a subset or a building block to a successful DevOps initiative.  DevOps is frequently an organic approach toward automating workflow and getting products to market more efficiently. Ok, if we can accept that then the next question is … What are you going to automate?    ITSM Best Practice

Every business has become a technology business.  Let that one sink in for a moment.  With the internet of things ever increasing it has become ever more imperative for us to make wise decisions about how to move forward on which IT services we should be delivering into the future (pipeline), how long we should continue to deliver our current (catalog) and when should we retire them (retire).  We literally could be an app away from becoming irrelevant. It is no longer enough to satisfy our customers, we must now delight and excite them.  They have to be able to enjoy the experience of how they receive these services along with the knowledge and comfort that the service provider of choice can continue without interruption to deliver this level of performance and functionality and even deliver new capabilities swiftly and often. By engaging in DevOps principles & practices (Scrum and Agile) at the strategic level we can begin to prioritize new and changing customer require

Agile Service Management ensures that ITSM processes reflect Agile values and are designed with “just enough “control and structure in order to effectively and efficiently deliver services that facilitate customer outcomes when and how they are needed.  We accomplish this by adapting Agile practices to ITSM process design.  Implement service management in small, integrated increments and ensure that ITSM processes reflect Agile values from initial design through CSI. By being able to incorporate a variety of tools from many practices, the Certified Agile Service Manager (CASM) can engage both the operations and development sides of the organization when defining and documenting processes, engaging in a major project or just move through these steps as part of an improvement project.   By incorporating these DevOps principles along with the CASM role, we can begin to incorporate the idea of process and functional integration much earlier in the development lifecycle.  It allows

To survive in today’s competitive business climate organization’s must respond quickly  to their customers’ evolving needs and desires.   How many times have you heard that? We know from experience that an agile culture where agility is gained through people, process and tools can enable organizations to gain market share and competitive advantage.   And still, more organizations than not silo agile principles to software and product development. Ever wonder why, as an industry, we are not getting the types of returns that are expected from our efforts? Agile software development alone will not get us there!  Other factors include: Ability to quickly respond to customer feedback and needs – Customer engagement. An understanding that the customer and business requirements are dynamic and that we must have agile processes in place to respond to them. (Not only agile development) Sustained innovation and speed from idea to end of life for the service and processes. Incre

It’s that time of year where the kids are heading back to school, the seasons are about to change and YESSS it’s time for FOOTBALL!!!! The other night I was watching the HBO series NFL Hard Knocks about the Los Angeles Rams training camp and it dawned on me how much a football organization is like an ITSM organization and how they can incorporate the 12 Agile principles into their game plans.  I know your saying, what?? But hear me out and let me explain: Our highest priority is to satisfy the customer. Ultimately this means to win the Super Bowl, but we have to win each week against a different opponent, with different circumstances at each game. Weather, crowds, injuries all have to be adapted to. We have to welcome changes, even late in the game.   Some changes might not be so welcome but we have to be agile and adapt to whatever circumstances arise during game day. This may mean dealing with something bad or some opportunity presented to you during the game.   (Respond to

The “Best of the Professor” blogs will focus on one unique individual topic and will be followed by links to papers with more in depth information.  DevOps initiatives are supported by three basic principles. In his book “ The Phoenix Project “, Gene Kim  leverages the Theory of Constraints and the knowledge learned in production environments to describe the underlying principles of the DevOps movement in three ways. These principals are referred to as The First Way, The Second Way and The Third Way.    This segment of “Best of the Professor ” will focus on “The Second Way”.   The Second Way                In an earlier “Best of the Professor” paper we discussed “The First Way” and how this DevOps principle was all about the flow of work from left to right.  “The Second Way in contrast is all about the flow of work from right to left.  It is reciprocal. How do we take all of the knowledge and learnings acquired and create feedback loops to the previous s