Can Agile Service Management give you the flexibility your organisation needs?

What is Agile

Often, we hear that we work in an Agile way, we do Agile. Often that is an excuse not to do things, documentation, meeting the checkpoints that are in place with Operations. Agile is used as an excuse. It is assumed it means you don’t need to do things.

There is indeed a clash between waterfall-based implementations that traditional operational setup may have in place. But the increased tension between an agile approach and a waterfall approach is the perceived non-delivery or artifacts or, the delivery in short timelines by Operations on Agile projects.

Agile development is a phrase used to describe methodologies for incremental software development. It is an alternative to traditional project management where emphasis is placed on empowering people to collaborate and make team decisions in addition to continuous planning, continuous testing and continuous integration.

Agile development uses 12 guiding principles that are designed to satisfy the customer through early and continuous delivery of valuable software. Principles include:

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Working software is the primary measure of progress.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

Agile doesn’t say you don’t do things, what it stresses is the appropriateness, so for example what level of documentation is proper? The philosophy of Agile is to do the least amount of something and no more for a given situation. A regulated industry will require much more documentation and trace matrices than an unregulated one. Agile process can accommodate this whole spectrum of needs.

The appropriateness of delivery is key. Sensibly this would be agreed between different parts of the organization in a change Delivery Method, or, and Operational model rather than forcing a solution by non-engagement.

o  Here it’s the appropriateness of Service management that is key

DevOps

Moving on from Agile we are now faced with DevOps. DevOps is a software engineering culture and practice that aims at unifying software development and software operation. The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.

DEVSecOPS

With the introduction of Lambda functions and Azure functions we have moved on again.

DevSecOps is a practice that aims at integrating security into every aspect of an application lifecycle from design to development, testing, production, and ongoing operations^. It is sometimes referred to as SecDevOps and many argue that they are two distinct concepts. DevSecOps is increasingly being used in the context of cloud deployments where organizations already have DevOps teams and tools in place to integrate, automate and monitoring every aspect of the development lifecycle from development to production.

Organizations use DevSecOps techniques and practices to reduce security risks, lower costs of compliance, speed software delivery, and improve reaction and recovery times.

DevSecOps is a response to the tension between stringent security requirements that slow down cloud deployments and the agility of DevOps delivery models. DevSecOps practitioners employ cross-functional teams, security automation, and process optimization to integrate security into the development process and to rapidly remediate vulnerabilities and security incidents in production.

o Here it’s the appropriateness of security, building it in as we develop and in the same way we can build in Service Management

Service Management

So, where does that leave Service Management, with the changing landscape of Agile, DevOps, DevSecOps?

Agile Service Management doesn’t mean not doing things (as per the often-put Agile Excuse), it means we move to a stance in which the requirements are met in different ways.

So, ServiceOps has been proposed as a of bridging gaps. The principles here are to deliver speed and agility, the following principles apply to ServiceOps:

• Operations is part of the design phase in which it provides input on the serviceability from the very start

• The support model is designed for a continuous and infinitive loop of improvements in short cycles

• Services are aimed at 100% automation (manual intervention only causes delay and errors)

• Every service enables self-service (services are designed with minimal IT intervention)

• Support levels default to "good is good enough" (no disproportional effort on support processes and activities that do not add value)

There are learns that can be taken from this and applied to the handshake that takes place been operational and development activities. The basis of ITIL was that it’s a framework you use what you need. Regulated organisations need more than a small office. Although for example the principle around change would still be true – who, what, when, how. Any organisation can grind to a halt given poorly implemented changes. From AWS to a small office.

As we start to look at Service management and its implementation, we have more tools that we can call on 6-sigma, the Deming cycle. The simplicity of PDCA (plan–do–check–act or plan–do– check–adjust) is an iterative four-step management method used in business for the control and continual improvement of processes and products. It is also known as the Deming circle/cycle/wheel. Another version of this PDCA cycle is OPDCA. The added "O" stands for observation or as some versions say: "Observe the current condition."

So, what is Agile Service Management.

Agility or nimbleness is the ability to change the body's position efficiently and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, and endurance. Agility is the ability to change the direction of the body in an efficient and effective manner. Agile service management is therefore the ability to change, to build and be efficient.

Taking the example of change we may have in the past had a change proposed that went through CAB (Change Advisory Board), had approval from members of operations that had a two-week cycle or more. In the world of Lambda functions that just won’t work. So, we move the need which is to know, who what when, how to be within an automated toolset. Providing the auditability. The way in which the code is livened by being able to immediately fall back to a previous version. The initial release still going through a phase to ensure supportability for the change or release is there. The agility is being able to adapt to the tools that are available introducing automation and not by clinging on to a legacy tomb of words. It’s by making service management live. Understand that it can evolve and integrating it with solution delivery.

There are tools, for example service now, which you can run your SDLC (software delivery Lifecycle) in. By making this your system of record you can join the project stages, to your delivery and support, monitoring and alerting, change, incident and problem flow within the tool. By using the tool, you reduce time to market, you capture the needed service management points and know the state of a service at any one time.

The agility is by changing using the information around you changing words to data and exposing that data in a service lifecycle. The agility of service management is by embedding it as part of the lifecycle the processes becoming efficient by introduction of automation.

There is a need to ensure that required elements are inserted at stages so like a CMDB (Configuration Management Data Base), the configuration items are in place. Like SecDevOps, security is embedded in the construction of the code. The amount that the cycle is touched, and the processes included is going to depend on the needs of the organization. Key to this is the planning of our Deming cycle. The doing performed as much as possible by the tool, the checking by the designated service management function who then act of the finding and input to the planning stage of the cycle.