Skip to main content

Posts

Showing posts with the label Scrum

Digital Transformation – Pro ITIL?

Some IT executives and practitioners still believe that Agile is the way to success for transformation. Some IT executives and practitioners will argue that ITIL is the way to go. Some will say LEAN should be the approach to ensure success. Oh, you say, “they are all wrong?”  Perhaps you think DevOps and Continuous Delivery is the silver bullet? Well guess what?    You are all right.  The truth of the matter is that no one best practice or method stands alone.  There are far too many examples of how this trinity of LEAN, Agile, and ITSM enable DevOps for digital transformation.  ITIL’s Continual Service Improvement (CSI) Approach - Iterative ongoing continual service improvement is at the core of every Service Management Principle. The concept of ‘adopt and adapt’ involves adapting best practices to an organization's circumstances, needs, goals and objectives . Using Agile and Scrum will help increase your velocity. LEAN will help to remove waste to help w

WARNING! The Titanic is Sinking! Service Providers… Stay CALM & Share!

(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

Every Business Has Become a Technology Business

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

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

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

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

Agile Service Management – Roles and Responsibilities

Agile Development is an umbrella term for several iterative and incremental de velopment   methodologies.  In order to achieve Agile Development, organizations will adopt frameworks and methodologies such as SCRUM and LEAN. Being Agile and using SCRUM, LEAN and other methodologies in development is good!  What happens when development starts adopting this culture and becomes more agile and begins to move faster and leaner than ever before, only to come up against laborious and bureaucratic change management and Service Operation processes?  One example that I heard lately is that it is like pushing more and more paper into a printer and expecting it to print faster!   It doesn’t work! The Agile Principles and the  Agile Manifesto  are applicable beyond software development. Therefore, service providers not only need Agile Development we also need to adopt Agile principles throughout the entire Design, Transition, and Operation lifecycles.  Agile Service Management (Agile SM)

Agile_ITSM – Ingredients for Success! Part 2

In part one of this topic we discussed the “dynamic” needs of business and also discussed how we the service provider must be “agile” to meet those dynamic needs.  Understanding of course that none of that can be done without the support of “processes and technology” and the best practices that enable them.  In part two of “Agile_ITSM – Ingredients for Success” I would like to discuss the most important ingredient for the success of all service providers: people.   People People with their skills, their diversity, their productivity and innovation are at the heart of agility and speed to deliver quality in a world where business needs and demand are dynamic. Empowerment! Trust the intentions of your people.  We have to be careful not to hobble the productivity with micro management of staff members and their effort.  When considering trust, it is not just a matter of whether a single member of the team or workgroup is trustworthy but do you trust that the team will

Agile_ITSM - Ingredients for Success! - Part 1 of 2

Dynamic We the service provider must meet the “dynamic needs of the business”! Someone recently asked me “What does that mean exactly?”   If that is what we are all chasing after and that is what we as service providers must understand and meet, then what is it?! The business demand for speed and productivity is not decreasing in any way.  The dictionary definition of “dynamic” is: Always active or changing Having or showing a lot of energy of or relating to energy, motion, or physical force This would mean that the needs of the business are constantly changing.   We can attest to that in our own experience.   So the question really becomes  "  How do we quickly adapt to that need?" Agile Being agile would mean that we are flexible so that we can adapt to change. We have to start looking at the provisioning of a service as a consumption cycle. Products are produced but a service is consumed.   Once consumed the demand for that service will incre