Skip to main content

Posts

DevOps Metrics – Time vs. Cost

There are three main principles that will help to optimize your DevOps initiative.  You may have heard them referred to as The Three Ways . All three of the principles will have a role to play but for the purpose of Time vs. Cost, I would like to focus on the first way which is “The Flow of Work from Left to Right”.  When considering this flow of work think of the value stream from left to right as being from the time the request is made until the time that value is realized. Using LEAN methods and applying techniques like the Theory of Constraints we can increase velocity to apply just the right cadence to meet the evolving business demand.  These practices along with our DevOps integration, Continuous Delivery Pipelines and automation will radically increase the time to value for products and services.  Time is a key metric.  DevOps organizations use “time” as the primary measurement tool.   Why time is a better metric than cost: Time is used to set goals beyon

Flow of Work

Agile Software Development is very well known and practiced in most organizations today in order to respond quickly to the ever increase in demand for IT Services.  Many of these organizations, while making some improvement, are not seeing the outcomes they had expected.  Why is this?   We are applying Lean methods, cycle time is increasing and yet, unplanned work, delays in deployment and unstable production environments remain. Consider the time from idea to delivery as the “ Value Stream ”.  Through this Value Stream, we want to increase the “Flow of Work”.   We will never see the type of optimization that is required unless we look at this Value Stream as a whole.  Applying Agile, Lean, and even tools in development without integrating Change, Security and Operations will break down and decrease the Flow of Work. DevOps helps with this idea.  Many companies, both large and small, are attempting to integrate the development and operations teams.  We have cloud services an

CPDE - Process Design Considerations

S o who should consider becoming a Certified Process Design Engineer (CPDE)?  Well anyone can consider it.  Is your organization engaged in some type of certification, working to reach some optimized level of maturity, trying to improve the processes you already have or create a process to meet some new customer requirement? All of these scenarios would employ the skills of a CPDE. To start with, no matter which framework or standard you are utilizing processes must be: Defined Documented Managed via performance metrics Continually improved  Undertaking this effort is not as simple as it may appear and having a staff member with the necessary skills and capabilities (a CPDE) ensures that clear and measurable improvement targets, along with a process design approach, can and will be carried out.   You first must understand the factors that are triggering a process improvement initiative.  These are just a few factors, but understanding why an initiative is needed is an ex

Xtreme Velocity - Accelerating Change Management

Although Agile, DevOps and automation for Continuous Delivery (CD) techniques are on the rise, service providers are still at risk for not having the necessary velocity to meet demand.  In the same way that we recognize that we can NOT silo our IT teams, we must also recognize that as providers of services we must not silo our processes. ITSM processes, including Event Monitoring, Problem Management, Release and Deployment Management, Test and more, are not going away. The integration of ITSM process must be considered throughout the entire value stream and CD pipeline.  None more so than “Change Management”.  Certainly the need for Change Management is increasing not decreasing. What must go away are over engineered, bureaucratic and outdated process activities.  We must begin to radically rethink the way we incorporate change into the CD pipeline.  Our mission overall is to deliver a “Quality” product or service. Ok then, what is “Quality”?  Quality not only infers that the

DevOps - The Basics

“Change sticks when it becomes the way we do things around here.” ~  John P. Kotter DevOps benefits the business by improving communication, collaboration and the integration of people, processes and technologies across the IT value stream. Ultimately, DevOps enables companies to deliver better software faster and more reliably by… Improving communication, collaboration and the integration of processes and tools across the IT value stream Automating the process of software delivery and infrastructure changes Leveraging Agile, Lean, ITSM and evolving DevOps practices DevOps – The Basics Get Involved! DevOps practices will continue to evolve through communities of practice. Seek out opportunities to collaborate with others and to share what you’ve learned. Change related to DevOps initiatives will affect organizational culture. Effective communication plans, training, and clear policies and procedures are all needed to achieve the desired performance outcome

Process Design

I looked up “Process Design” and found: “The activity of determining the workflow , equipment needs and implementation requirements for a particular process . Process design typically uses a number of tools including flowcharting, process simulation software and scale models.”  Hmm… that is good but “So What”?  Why should a service provider care about process?  I have heard some say that process is secondary to automation.  Okay, sounds good, but then we have to consider, “What are we going to automate?” Every Certified Process Design Engineer knows that when it comes to process we are talking about activity.  The key is that we need just enough process and just enough governance to meet requirements.  Process design contributes to our ability to balance speed and agility with stability.   Having good process design allows for a smooth service belt that delivers value to customers and also gives a service provider the ability to meet business and customer demand at a

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