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 policies (r…

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 the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…