Skip to main content

Posts

Continuous Delivery

Continuous Delivery is a software development practice where software is always in a releasable state.   Teams produce software in short cycles, ensuring that the software can be reliably released at any time.  By relying on automated testing and deployment, as well as ensuring collaboration and communication between development and operational teams (DevOps), the goal of building, testing, and releasing software faster and more frequently can be achieved. This approach can help to reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications and configuration items (CIs) into production.  A straightforward and repeatable deployment process is important for continuous delivery and will be critical for operational processes such as Change Management and Release and Deployment Management to be agile and robust in the DevOps environments where continuous delivery will be part of best practices.   Continuous Delivery is sometimes co

Desktop as a Service

In today’s world of DevOps, development, deployment, operations and support are being done at lightning speed compared to methodologies employed just several years ago. With the implementation of “Infrastructure as Code” (IAC), a type of IT infrastructure, development and operations teams can automatically manage and provision through code rather than using a manual process.  A part of this movement includes, “Desktop as a Service” (DaaS) which is a cloud service where the back-end of a virtual desktop infrastructure (VDI) is hosted by a cloud service provider. The service is purchased on a subscription basis. In the DaaS delivery model, the service provider manages the back-end responsibilities of data security storage,   backup, and upgrades. DaaS has a   multi-tenancy   architecture which means a single instance of a software application can serve multiple customers at one time. Each customer is called a tenant. Tenants may be given the ability to customize some parts of t

Business and IT Strategy – 2016

As the New Year begins, most IT service providers already have their IT strategy in place.   A few decades ago we heard loud and clear… “You must align IT with the business”.  Then we heard in the next decade…  IT...”You must align with the business”.  Notice the focus was on what “IT” must do.  I believe that most IT organizations get that.  The real question when considering a strategy is how this can be achieved.  Or is it?   I hope that moving forward the new mantra will be “Hello business”… “You must engage IT in order to ensure success.”  If the strategy does not include how the business is going to consistently engage, plan and strategize with the IT organization it is possible that the business strategy will not ensure the type of success that is hoped for and could continue to miss the mark. A recent BizReport article by Kristina Knight states; "During 2016, the perception that developers are basement-dwelling, socially-awkward techies with no grasp on business

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

DevOps Patterns

In his recent blog ‘ Devops Areas - Codifying devops practices ’ Patrick Debois explains that DevOps activities typically fall into four patterns or areas.   DevOps activities typically fall into four patterns or areas. In each of these areas best practice dictates that there will be a bi-directional interaction between Dev and Ops, which will result in a fluid knowledge exchange and feedback from each of the major stakeholders, including Development, Test, Product Management and IT Operations.   In the 1st area we extend delivery to production. This is where Dev and Ops will collaborate to improve anything on delivering a project to production by creating or extending the continuous integration, deployment and release processes from Dev into Ops. Activities here include making sure environments are available to Dev as early as possible. That Dev & Ops build the code and environments at the same time. Create a common Dev and production environment process while ensuri

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

The Customer Experience

We are all customers of someone right?  What was your last customer experience like?  Was it so good that it completely changed how you thought about the product or the organization you were receiving services from? On the other hand was the service you received so poor that you vowed never to use their products or services ever again.  We have all been in those situations. You may not have realized it, but how that interaction was designed can have a huge impact on the perception you, the customer, walk away with.  I recently read a series of articles in the September issue of Harvard Business Review magazine.  The entire series was titled “The Evolution of Design Thinking” - It’s no longer just for products. It speaks to how executives are using this approach to devise strategy and manage change.  I can’t tell you what an absolute must read this is for all.  It will make you take a second look at how you design, deliver and support the services to your customers. For me personally t

Designing a Service Design Package

I was recently asked what the compliance requirements, architectural constraints and interface requirements are in designing the service design package for a new app. The short answer is that the Service Design Package (SDP) would have ALL of the documents and information related to how the app was designed and developed including any policies or known compliance or other constraints.  The purpose of the SDP is to provide a living set of knowledge assets that can be passed around the lifecycle for use in each stage (e.g. deployment, operations, support, updating, etc.). For more information the the SDP please use this link:  http://www.itsmacademy.com/itil-sd/

Resilia - Cyber Resilience Best Practices

Operating under a constant threat of cyber attacks is the new normal for many organizations in today’s virtual business environment.  These attacks can come from anywhere, from anybody and at any time.  It is no longer a question of reacting to and then fixing the problem.  Today the question is “How do we prepare the entire organization to be prepared and vigilant to deal with cyber security threats each and every day. A defensive approach is no longer adequate.  A proactive strategy by cyber security teams with the appropriate expertise, capabilities and best practice processes and policies is an absolute must have in order to meet the challenge of recurring engagement with those whose intent is to harm the organization in some way. There must be well defined and documented processes to prevent, where possible, detect and respond with control and countermeasures as quickly as possible while predicting what will happen next.   The introduction of effective cyber resilience requir

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

Change Proposals

When an organization is planning on a major change that will incur significant cost, risk, time and engagement of resources along with organizational impact, it is best practice to initiate this activity through the Service Portfolio process.  Before this new or significantly changed service is chartered, it is important that it be reviewed for how it may impact the short, medium and long term support of other services currently being delivered, the pool of limited resources that will be utilized for this undertaking and on the change schedule itself. The Change Proposal is used to communicate a high level description of the change and is normally submitted to Change Management for authorization.  Authorization, however, is not an approval for implementation, but is a measure to allow the service to be chartered so design activity on the service can begin. In some cases the proposal may be created by someone other than Portfolio Management, such as the PMO or SMO. This high le

DevOps - Cadence vs Velocity

A developer recently asked me “What is the real difference between Cadence and Velocity?   Aren’t they both just talking about speed?”   Hmmm…  Good Questions. Cadence Generally thinking cadence can be tied to rhythm.  One thing to remember is that the DevOps value stream is much broader in scope than just Dev and Ops.  So what are we looking at here?  The rhythm of code integration, and how we align with that things like integrated testing?  Yes, but also consider that the code development integration and deployment has to be in rhythm with the demand that is coming from your Customer and Business side.  If we are not in sync or have the same cadence as the business demand all other measurements may not be beneficial.     Alright, now let’s consider that your design and development teams work diligently to implement Agile Software Development principles to align and sync with the business.  If the cadence in test and deployment is not in sync then you have a potential bottlen

Process Maturity

So unlike the Billy Joel lyric “Love you just the way you are”, we can never be satisfied with our processes being just the way they are.  As the organizations that we are engaged by continually change and mature to meet customers dynamic requirements, our processes must be continually assessed, measured and matured to ensure that they stay relevant and deliver value long into the future.  This takes real time, effort and resources.  Organizations cannot possibly move from being informal or ad-hoc to having a fully integrated ITSM program in a short period of time.  Just being able to gather the correct components (people, process, technology and information) can be a lengthy process and, of course, there is the decision of which processes do I begin with. The saying “Rome was not built in a day” really applies in this situation.  We must begin from the perspective that each level of maturity forms the foundation for the next level of maturity. Trying to jump over levels will almo

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

Creating and Supporting Services – Plan, Protect and Optimize!

Would you buy a product or service that did not include some type of warranty?  If the manufacturer or reseller does not explicitly set the expectations, then you will form them for yourself.  It is the same with the customers of your IT services.  Either IT clearly sets the expectations, or end-users will develop them on their own. Best practice tells us that during the negotiation and acceptance of Service Level Agreements, IT commits that services not only meet business and customer outcomes but also that they will meet requirements for availability, capacity, continuity and security.  Ok… that is good.  Best practice tells us to include these so called “non-functional” requirements early in the lifecycle of a service.  In reality these warranty requirements are often considered somewhat in the Strategy/Design stage but more often than we would like to admit the majority of the work and effort for security and availability are performed reactively in the Service Operation lifec

User Stories / Story Points

User stories are one of the primary development artifacts for Scrum teams.  They are a short description of the feature as told from the perspective of the person (stakeholder) who desired some new capability from a current service, system or application.  Many Scrum teams have adopted the user story template developed by Mike Cohn, which identified who the end user is, what the end user wants and why in a single sentence.  This template is most often written like this:  "As a (type of user), I want (some goal) so that (some reason)."  Example: As an Incident Process Owner, I want to see a release of known errors in order to do appropriate service desk staff training. In this way team members are encouraged to think of their work from the perspective of who will use it, ensuring requirements get met and value is delivered.  User stories are narrative texts that describe an interaction of the user and the service.  It focuses on the value that a user gains from utilizin

Service Offerings and Agreements - Service Catalogs

What is the difference between a Business Service Catalog and a Request Fulfillment Catalog?  One clear way to distinguish the type of service catalog that is required is to ask yourself, who is your audience?  I have found that when a lot of IT organizations say that they have a Service Catalog many are talking about a service catalog for end users.  Another very important service catalog is one that is mapped to your business customer needs.  In this blog I will briefly discuss some characteristics of service catalogs for these very distinct audiences and for the purpose of clarity I will refer to them as Request Fulfillment and Business Service Catalog. Request Fulfillment Service Catalog Service providers today are striving to automate the first line support for user request fulfillment by providing self-help and also more importantly self-serve end user request fulfillment catalogs.  This self-serve catalog is the most common and allows users to fulfill requests directly fro

Assessing and Evaluating the Change

All changes need to be assessed and evaluated.  Changes that are considered significant should be subject to a normal change evaluation in which we have well defined criteria for making this determination.  In this blog we will focus on the assessment side of the equation. A logical place to begin assessing the impact of changes on services and configuration assets would be the use of the "Seven Rs of Change Management".  Without these questions being answered a proper impact assessment could not be completed.  When leading an impact and resource assessment several items should be considered.  At the top of the chart we need to determine if there will be an impact to the customer's business operations.  Next we might want to know what the effect will be on infrastructure, individual customer services and their performance, reliability, security, continuity and ability to handle various levels of demand.  Additionally we will need to understand what the current change sc

Release, Control and Validation (RCV) – Service Management Secret Ingredients

In today's dynamic business climate, service outages cause real bottom line impact to the business. There are documented best practice processes and known critical success factors and yet outages that throw support organizations into reactive firefighting turmoil are far too common. Mature processes with just enough control are needed to smoothly transition new and changed services into production, helping to ensure stability for IT and the business.  Most organizations will confirm that they do have Change and Release Management processes in place.  Service Providers will usually have some level of Service Asset and Configuration Management control.  There is generally a lot of buzz and focus on three core processes for Service Transition and the success and integration of these three are critical to business success.  Three Core Processes for Service Transition are: Change Management Service Asset and Configuration Management Release Management Most IT organizations