Skip to main content

Posts

Showing posts with the label Certified Agile Process Owner

Shifting Sands - Minimum Viable – What is it Really?

For high performing IT providers, the sands are shifting. If you are getting certified in ITIL 4 , DevOps , or Agile Service Management you hear that we have to “Think BIG and ACT small!”. Minimum Viable Products and Minimum Viable Processes (MVP) are on the move. Historically, IT organizations delivered products and processes into production with huge batch runs or the big bang approach. This method is fraught with issues, escalations, and constant firefighting. These large releases are tightly managed, governed from the highest levels, and require participation from all parts of the organization. The days of large batch runs that take months to create and war rooms staffed 24×7 for weeks before and after the release, have given way to small incremental deployments. In comes Minimum Viable Products/Processes:  High performing organizations know that deployments that deliver value to the consumer fast are required. The idea is not to stage, stage, stage until you have a huge batch

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 dem

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

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 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 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