Skip to main content

Posts

Showing posts with the label CASM

Filling the Process and Framework Skills Gap

By Donna Knapp For many organizations, the COVID-19 pandemic exposed one of two ends of a spectrum: poorly defined processes, or overly-rigorous processes. At either end of the spectrum, these organizations likely struggled to adapt as the pandemic impacted our lives. For those with poorly defined processes, things were probably pretty chaotic. For those with overly-rigorous processes, things were most certainly taking way too long. Even organizations with well-defined processes felt, and continue to feel, pressure to speed up the flow of work, minimize toil, and automate processes where possible. To do this, they must develop a culture of continuous improvement and learning. Continuous improvement is an ongoing effort to improve all aspects of an organization; its people, processes, tools, products, services, and experiences… all of which are tightly integrated. Whether improvements are large or small, what matters most is that they are constant. The highest performing organizations a

Optimizing Value Streams and Processes

Value streams are getting a lot of attention these days for a couple of reasons. One is that value streams allow us to identify opportunities to minimize waste or bottlenecks across organizations, processes and functional silos, and to improve the flow of value. Organizations adopting DevOps , for example, are using value stream mapping as a way to improve the flow of activities during the software development lifecycle, and to improve cross-functional collaboration. Another reason is that value streams direct our attention to what customers value. For example, organizations can use value stream mapping to streamline new product development activities, improve time-based measures such as lead time and time to market, and identify ways to improve product quality. They can also use it to streamline the activities involved in integrating a new employee into the company and its culture. What these both have in common is that the focus is on optimizing the value-adding activities; with the

Golden Keys to Unlock Agile Success

Communication and Education before Collaboration  An engineer attending a recent DevOps FND class for certification said “OMGosh! I have been trying to do DevOps and I really did not understand what it really was!” He knew that a self-organizing team was defined as a group of motivated individuals who work together toward a goal, have the authority to take decisions and readily adapt to changing demands. Solutions are derived from inter team collaboration. Innovation is the name of the game for digital transformations. All true but … “authority” without ability is dangerous.  Let’s not forget that before these teams are able to recommend innovative ideas for improvement that we must communicate the strategy and outcomes that deliver value. Also true is the fact that we must educate teams to continuously enhance their skills.  Challenge: During your next virtual or face to face meeting with staff, ask a few questions to validate that all are on the same page. You could as

What is a Microservice?

Business requirements are not static.  The rate of dynamic change for new evolving business needs is increasing as you are reading this blog.  The traditional software development practice for building one big honking monolithic program to provision services is not applicable to the explosion of need. This old way of thinking and deploying is not conducive to Agile.   To understand a microservice let’s first start with our traditional view point.  For this purpose, let’s say that you want to build a “Self Service Catalog”.   To make this seemingly complex service less complex let’s break it up into many microservices.   For example; one microservice might be for “Creation of Online Account” another for making a selection from the “Service Catalog”.  One might be to “Select Payment Method” and yet another microservice for “Invoicing” and so on.  These are many microservices or sub-services that will eventually be connected via Application Programming Interfaces. These microservices

Agile / DevOps: Value Stream Mapping for IT Services – Some Thoughts

Value stream mapping  originated a s a   lean -management method.  Today this method along with Agile, ITSM and other LEAN practices is utilized to understand and improve the delivery of products or services for all industries.  Being able to analyze the current state for the series of events that take a product or service from concept all the way through to value realization by the customer is a powerful tool. A tool necessary for designing an efficient future state and for strategizing continual service improvement.  Below are some thoughts on how the approach to value stream mapping can be applied to service management. Getting Started: Beginning with the formal proposal or request from the customer and then documenting what takes place throughout the lifecycle is always a good starting point.  Value Stream Mapping requires a gradient approach including the following elements: ·          Define physical flow of events – If you are just starting out, it might prove helpfu

CASM and the 3 Ways

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

Agile Process … What?! Is That an Oxymoron?

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

The Year of Shattering Silos

This is the year to shatter the silos.  Consider any best practice, method or standard that you have or are thinking of implementing.   In any DevOps, ITSM, ISO or Lean initiative the biggest challenge that any CIO or organization as a whole will have to address is how to meet the rate of demand and the dynamic business requirements.  Dynamic business requirements are a norm not an exception and the service provider will need to ensure fluidity throughout the value stream.  Shattering Silo’s will be a prerequisite to achieving end-to-end workflow and agility.  Functional Silos When talking about silos most practitioners immediately think of integrating departments or functional teams.  One of the more obvious silos to address here is the division between development and operational teams (DevOps).  While there is a lot of buzz in the industry on how to bridge that great divide, the real chasm that hinders efficiency and optimization is that between the business and IT.  Bus

Your Process Is Either Improving or Deteriorating

Do you ever notice you can hear things over and over and then there is that one moment where a comment or phrase all of a sudden shouts at you with real meaning and significance? I’d like to share one of those aha moments with you. I recently took a class called Certified Agile Process Owner (CAPO). During that class the instructor, Donna Knapp responded to a learner and said …  “Remember that your process is either improving or it is deteriorating”.  For some reason while thinking about that from an Agile Service Management perspective I thought REALLY?! That is so very true. If we think about it, by the time we define, deploy and utilize any set of process activities the objectives could change, the technology used certainly has changed and the overall requirements for any one of those process activities or procedures could have changed. Today we all know that business requirements are dynamic. All the more reason for taking an iterative approach to process design. For

The Goals and Objectives of Agile Service Management

Part of the role of the Certified Agile Service Manager (CASM) is to ensure that ITSM processes engage and reflect agile values and that they are appropriately 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. The goals and objectives of Agile Service Management include: Ensuring that agile values and principles are embedded into every service management process from design through implementation and continual improvement. Improving IT’s ability to meet customer requirements faster.  This includes process and process integration, capabilities, knowledge transfer and the use of appropriate technologies for automation. Being effective and efficient (lean).  It also means ensuring that we don’t bias too far in one direction.  I can be very effective but not efficient. On the other hand I can become too efficient but impact my effectiveness.  Either of these s

Agile / DevOps: (_____) as CODE #DevOps

Infrastructure as Code – is a common term among developers, architects, and operational staff and the practice has evolved in response to demand for quality and efficiency in the industry.  Over the last decade many organizations have come to realize that the essence of Infrastructure as Code is to treat the configuration of systems the same way that software source code is treated.  Frequent code integration, automated builds, and integrated testing have resulted in stronger IT performance and therefore business value. Security as Code – An increase in security breaches across all industries has brought forward a similar concept, and that is to look at “Security as Code”.  This concept would include the usage of repeatable algorithms to integrate security checks with each code check.  This expands the scope of traditional “Continuous Integration” and automation.  Organizations realize that security is no longer a second thought and must be addressed at the front of the value s

Product Backlog + Process Backlog = Success!

Flexibility and agility are key to success and business performance.  Many Service providers have adopted Agile methods to ensure that they can meet demand for increasing changes in business requirements.  Product Backlogs are common and are generally understood; but what about Process Backlogs? Product Backlog – In the “Scrum Guide” Ken Schwaber and Jeff Sutherland describe the Product Backlog as an ordered list of everything that might be needed in the product.  It is the single source of requirements for changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.  A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be app

Agile – My Product Backlog is Out of Control!

If a product backlog is growing faster than you deploy, if it cannot be prioritized properly, and business outcomes suffer, are your “Agile” efforts really working?   Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams . It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. A broken product backlog is only one of many symptoms that something is broken. If there are bottlenecks in change, delivery and deployment than what real value can evolutionary and faster development bring to the business?  It is time to consider “Agile Service Management”. Agile Service Management ensures that agile principles and methods go beyond software development t o ensure the product backlog is in control and that we, as service providers, can meet the s

The Agile Process Owner

Let’s face it, IT service management (ITSM) processes get a bad rap. Sometimes deservedly so. Bureaucratic and overly risk-adverse processes can be a real constraint in the IT value stream; particularly in organizations that are adopting agile, lean and DevOps practices. To keep pace, today’s IT organizations must be built on ITSM policies and processes that facilitate speed and change. So who ensures that ITSM processes are designed with ‘just enough’ control to meet an organization’s needs? Here’s where the role of Certified Agile Process Owner comes into play. A Certified Agile Process Owner (CAPO) SM adapts agile and Scrum values and practices to ITSM processes and process design and improvement activities. Much like a Scrum Product Owner, a Certified Agile Process Owner manages stakeholder requirements and strives to translate those requirements into process activities and features that deliver value. What’s different is that CAPOs and Process Improvement Teams use Sprints

The Agile Service Manager

A core principle of popular Agile methodologies is to limit “Work in Progress”. Self-organizing Scrum teams, will only take on a small piece of work from the overall backlog that can be completed within a timeboxed period, normally between 2 and 4 weeks. By limiting their focus and attention to what is most important (priorities are set and agreed to) you enable the team to complete the agreed to work and by limiting work in progress we train teams to finish work, rather than begin added work. With this focus to customer requirements, a higher level of quality and more satisfied customers is the result.  Additionally, because the work is done in smaller increments, there is much less risk to our environment. In order for our ITSM teams to move from the methodologies currently being used to Agile methodologies such as Scrum and Kanban to name a couple, we must have an advocate for our teams to be able to engage in this new way of developing and maturing our ITSM/ITIL processes. T