Translate

Sunday 9 March 2008

Agile for Services (for want of a name!:)) - Draft I

About the Germans in 1940, US Airforce Colonel, John Boyd had observed how the Germans had fought and won against a superior force, during the world war, without any superiority in arms power. In the same vein, he had observed the communication happening between two fighter pilots, locked in a dog fight, who had to make fast adjustments to rapidly changing scenarios and decide, with their lives at stake.

The vision of two fighter aircrafts engaged in war is a sufficient definition of agility.


The nimbleness, the dextrous manipulations, the speed of thought and near lightning reactions of the pilots - all are best fit for a definition of agility.

Agility, hitherto, in the software development communities, has been defined by the Agile manifesto. But, "Alistair Cockburn cautions that simply using iterations, user stories and velocity doesn't mean your project is agile - or on the way to success", Steve Adolph. But, Agile for Services, is meant for the Service Industry and therefore, by its very nature, demands a different definition. The lifecycle of a software development process is different to that of a Service process.

The service industry, having come into shape fairly late, is yet to have a proper structure defined for itself. Although, CMMI-SVC is taking shape and there is an ISO implementation, both are yet to actually happen. It is a natural conclusion that because the service industry is highly demanding, in terms of requirements that constantly take new shape, there is only one way to handle the swift changes in the requirements scenarios - imbibe agility into the process as well as the people within.

Having said that, being agile in a physically demanding secenario is different to a non-physical scenario where physical effort may not be necessary at all; so, where does the agility come from? Agility, as we all know, is not just about the physical reactions but also about mental preparedness. Therefore, the intangible elements that demand immediate attention and solution require mental dexterity. Having said that, it is not that a skilled chess player can be a great Agile player.

Unlike in a game of chess, where a Second is well capable of giving out permutations and combinations of a given move and the associated variations using analysis, the same cannot be done in a service industry, where the current scenario is always unique due to the influence of individuals and, therefore, reaction time is far lesser. It requires a highly tuned individual with experienced knowledge of the domain to actually instill the required agility into the process to maintain, increase the velocity of the process' reaction time.

The Service industry
What is the first thing that comes to your mind when the term "Services" comes to your mind? "Competition" would be the most likely answer. Therefore, the ability to provide service to the customer and, at the same time, keep an eye on the competition demands almost as much dexterity as the fighter pilots in a dog fight!

So, how does the service provider tune himself up to the likes of a fighter pilot when all the data and elements that he can work with are intangible? The answer is simple: agility.

Agility, to define with the help of Boyd's principles on OODA (we shall expand it in a little while), is the ability of a process or a team to rapidly respond to the needs with constant change as an implied parameter!

Implicit guidance is a key to agility in a service scenario. The process is robust and therefore, the implicit guidance, in the form of constant and frequent feedback, is healthy and effective, as the feedback obtained is used to orient the existing process; the outputs from such orientation lead to decision making culminating in the ability to act ! This is what Boyd's principles on OODA (Observe-Orient-Decide-Act) is all about.


Services=Unfolding events
The chief factors in a service arena are


  1. Response Time to customer queries/requirements

  2. Constant monitoring of the status of queries/requirements

  3. Delivery

Each query/requirement of a customer may be unique. Therefore, no pre-conceived guidelines can have any significant impact on delivery.

"Agility, in this context, depends on keeping one’s orientation better matched to the real world and actual requirements during times of ambiguity, confusion, and rapid change, when one’s natural tendency is to become disoriented", Steve Adolph. This cannot be attained through on the spot decisions because, analysis cannot be performed on all the changing scenarios at all times, successfully. Here is where the implicit guidance comes in; implicit guidance, not in terms of individual skills or knowledge as in the case of Agile for software development, but, in terms of the process paving the way for quick decision making.

That there is constant change in the requirements of the current scenario in a service leads us to a foregone conclusion that agility is the only solution in the reckoning . For example, in a recent conference held at the NCR, each speaker had about 30 minutes to make his presentation. Some opted for QA session at the end of their presentation and others, took questions on the fly. With the latter case, it led to overflowing the time limit. In the presentation in which I was a reviewer, I oriented myself based upon the observations of the previous sessions. The previous speakers found that the passing of the mic from one questioner to another was consuming time and so I decided to take two actions - one, to pre-empt the direction of the questioners and two, to move faster between them! This ensured that the presentation took exactly the time that it was allotted with. Of course, not to take any credit away from the speaker's agility in tackling questions.

So, with this example in mind, it is fairly easy to conclude that the process areas of the service domain only serves as the guiding block while the people within the process are the real driving force.

It may be questioned as how to implement a process with agility in the perspective. Again, the solution is rather simple. Observation, which is the paramount activity of the service loop, described in the below image, can be directly mapped to the quality control activity of any work area. With strict quality control measures, where the observation points are, useful inputs can be obtained for the next activity in the loop - orientation. Existing service models may have incorporated this but, where Agile for Services, makes an impact is in introducing the agility into the process.




Implicit Guidance

The implicit feedback in the above figure, part of the delivery loop, is the constant observation that goes into the execution of the lifecyle of a service. This observation serves as the source for orientation of the response leading to actual data on which to decide and act.

"While agility is about using time for competitive advantage, it is not speeding up the loop by doing things faster because doing the wrong things faster is not a strategy for success", Boyd.

The agility, in this loop, is the faster response time between the various activities thereby, increasing the velocity, as well as the momentum of the loop. The volatility of the service environment requires a greater response time within the process and the agility with which the stakeholders of the process react!

Decision making, in any context, depends upon free flow of information and its correctness. Therefore, misinformation, compartmentalization, non-adaptability, alienation/isolation and fixed techniques can only lead to slowing down of the loop. Information has to be easily obtainable at all levels in the loop and visible at all levels to reduce friction in the loop and consequently, increase velocity and momentum of the process of delivery.


Observation Posts


Let us cast our mind back to the allegory of the two fighter pilots at dog fight and the parallel drawn with Service Providers. A good Service Provider always has an eye on the market and his competition and tunes and revs up his service accordingly. Quality not only gets noticed but is also appreciated.

Those who have travelled domestic, in India, would be able to associate with the following example.

Kingfisher Airlines (KA) is one of the new airlines in the Indian Aviation industry but has made such a telling impact, in such a short span of time, that competitors have begun to think out of the box in a great hurry. KA introduced the concept of ushers at the airport terminals, who would also double up as porters. For the uninitiated, this form of service is only showman stuff but the keener eye points to you the incredible effort in identifying a key factor in customer service - when the customer "thinks" of you, you are there with the service ready!

What does a passenger face with as soon as he reaches the airport? In most cases, it is "how do I get to the security counter?" and this is the moment that KA has so well identified and implemented in the form of the Ushers! The moment you reach the airport terminal and in your mind crosses the thought, "Hey, how do i find the KA counter?", there are these polite, well-clad ushers waiting for you anxiously and from that moment on you realise, "Yes, this is probably the best service that can be offered and has been offered in an Indian's flying experience!"

Let us relate this to OODA. The process makers of KA had clearly identified the point in the process workflow "when the customer first thinks of you as the service provider" and oriented its delivery process to include the Ushers! So, Observation and Orientation has happened here.

Orientation Points

How to apply orientation points in a process?

Orientation could be in the form of any tweaks that could lead to an improvement of the delivery loop. Feasibility study, effort estimation, offer making, requirements mapping to skills etc can all be direct recipients of orientation inputs.

One important point to note here is - "change". The evolution of technology and customer requirements have brought about the plethora of development methodologies that exist today and therefore, it should be a natural conclusion that old techniques existing within the lifecycle of these methodologies should also be revamped and renewed. For example, if time changes, time management techniques must as well change. What was applicable a decade back in time cannot be applicable to a decade later in time! Similarly, older techniques being used in newer and evolved methodologies must also be renewed and refined.

Let me now deviate from the OODA pattern and introduce the proposed delivery loop.



[More to be added...]


(c) Copyright Ravichandran J.V., 2008.



Reference:
What Lessons Can the Agile Community Learn from A Maverick Fighter Pilot?Steve Adolph, University of British Columbia, Vancouver, B.C. Canada
steve@wsaconsulting.com