Skip to main content

Changing Culture to Become Agile Based

 Success in modern technical endeavors absolutely requires multiple perspectives and expertise to collaborate. (1)  When I ask managers attending my classes if their organizations practice ‘agile’ they hesitate and say something like we kind of do but not in all areas of the organization. Further questioning usually uncovers that most of this agility starts and ends with the software development teams. When asked if these practices have been introduced to the business units there is a long uncomfortable pause, and then I hear 'we don’t usually talk to those groups'.

Over the last couple of decades, a new set of major management philosophies have been developed and are now being adopted to ITSM. These new ways of thinking enabled manufacturing, software development and others to analytically realize both disciplined execution and continuous innovation, something that was thought to be mutually exclusive and impossible to accomplish with traditional management methods. Over the last decade these new practices, such as Agile, Scrum, Lean, Kanban and DevSecOps, have been proven to improve performance in thousands of organizations around the world.

As organizations begin to shift towards continuous integration, delivery and deployment through the adoption of the DevOps principles, Flow, Feedback, Experimentation and Learning, we can also create a new type of conversation with the business – a continuous one. We now have the resources and capabilities to deploy products in hours, not months. To support this rapid level of change the business units that define and fund the creation of these services must also display that same level of agility. ‘The way we’ve always done things’ with little to no communication creates constraints on the development and support teams ability to quickly respond to the rapidly changing competitive landscape.

Every business decision creates an IT opportunity.  Agility in the entire organization requires decision-making to be done as close to the customer feedback as possible (The Three Ways). The teams working on the products need to be able to quickly decide what to work on next based on continuous feedback from the end-user/customer.  Through experimentation and learning making mistakes is not a failure, it is the elimination of an unusable alternative.   These opportunities should be quickly analyzed and any new information incorporated into the next set of sprints (The Three Ways).

Some organizations like Apple, Google and Zara do things differently. These firms constitute what has been called the Creative Economy. They have shifted the goal of the entire organization from maximizing shareholder value to delighting the customer. These are organizations in which all the management layers adopt the philosophy of ‘customer-value first.’ They are Agile-friendly environments. In such firms management practices at the team level, like Agile, become self-evident. Making money becomes the result, not the goal of the organization. Paradoxically, as the examples of Apple and Google show, this approach can be hugely profitable. (2)

Making the transition to Agile includes five major shifts:
  • Instead of a goal of making money for the organization, the goal of the organization is to delight the customer.
  • Instead of those doing the work reporting as individuals to bosses, the work is done in self-organizing team: the role of management is not to check whether those doing the work have done what they were meant to do, but rather to enable those doing the work to contribute all that they can and remove any impediment that might be getting in the way.
  • Instead of work being coordinated by a bureaucracy with rules, plans and reports, work is coordinated by Agile methods with iterative work cycles and direct feedback from customers or their proxy.
  • Instead of a preoccupation with efficiency and predictability, the predominant values are transparency and continuous improvement.
  • Instead of one-way top-down commands, communications tend to be in horizontal conversations.

The principles are not a random collection of improvements. Together they form a mutually reinforcing sequence. (3)

(1) John Allspaw - The DevOps Handbook by Gene Kim 


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): ·          Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” ·          Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services-that is people. Because the people element adds variability, the service is variable. This holds true especially for th

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service". I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize: SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle. ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with