Agile development ≠ Agility
Posted by Suman Sasmal, VP and Service Delivery Head - ADM
I was visiting a friend in London recently when he was talking about a health emergency he ran into. As one would expect, the ambulance services (999 in UK) was very prompt and efficient. They arrived within about 5 minutes and transported him to the nearest hospital in another 5. Admirable, for sure and a benchmark for others to follow! It was late night, rather early morning and not much of help was in sight inside the emergency room. He was complaining of pain, but had to wait for an hour before he was seen by a physician! Although everything was fine subsequently and he recovered quickly, in some sense it defeated the purpose of the high performing ambulance services...Are you already nodding your head in agreement? Do we come across such situation in our business too? An on-time high-speed software development meets with an out-of-synch Ops and gets into production only after months. IT shops are full of such examples, where agile is worshipped and considered a nirvana. Where roles, artifacts and ceremonies, the daily stand-up meetings and burn-down charts become the end goal. And, we forget asking the question what outcome we are seeking.
So much for agile bashing! Not really. As they say, either you love agile or you hate agile. You can't be someone in between. Let me say this, you don't have a choice any more. And I will tell you why. So, might as well like it and have fun, so that it becomes more enjoyable!
Let's start with the question why. Why do we need agility? If we look around, we will see how the business cycle is getting shortened. It is in days and weeks, no longer in months or years. A new product that gets launched in the morning , gets to know of its performance by the end of day. The companies are compelled to respond to such triggers on a real-time basis. Scott Cook, co-founder of Intuit says "A brand is no longer what we tell the consumer it is - it is what consumers tell each other it is." Therefore, speed of response becomes a necessary hygiene, without compromising the quality of product or services. Second, business innovation is the success mantra today and logically, such programs have fuzzy knowledge of the end state. For business, explore and evolve become the fundamental approach, and they look for an ability to do mid-course changes to maintain their leadership position. Agility of business and associated processes (like IT) does not only mean providing a rapid response, but it is also about how predictability can be embraced in uncertain situations
How can IT support agility needs of business? That's where the debate starts. Agile enthusiasts has traditionally seen agile, in the context of software development and programming practices. It was seldom viewed in the context of agility of business and associated value delivery. Therefore, It was not a means to an end, but an end in itself. The principles of agile and agility were somewhere getting lost. And the naysayers, believed in pre-planned outcome and measurements more than the business needs. The ideal situation is, as usual, somewhere in between.
But if one carefully examines the agile manifesto, one would see that it is actually a powerful balance of individual contributions and established processes. All that it says a) individuals and interactions, over processes and tools b) working software, over comprehensive documentation c) customer collaboration, over contract negotiation d) responding to change, over following a plan. This means, agile values the processes, plans and documentations, but attaches more value to individual acts and collaborations. Agile is therefore not a prescriptive policy or system and adoption is in the hands of the beholder. A good adoption is one, which looks beyond the fad, looks at the business goals and tries to adopt agility across the entire life cycle.
Yet another myth.....agile isn't disciplined. Yes, it doesn't follow an assembly line process. Also, the iterative approach appears chaotic, as it demands flexibility and responsiveness of team members. In fact, this team needs more discipline than a traditional waterfall team, where everything is defined. In a situation, where one is fitting tires to a moving car - wont you need more team cohesion and discipline? Business never told IT that it would love to get a software that is developed fast but can break for lack of quality! So, Quality is a pre-requisite. In fact, Quality from agile projects is considered better, because teams detect defects much early in the cycle and have time for course correction. Predictability is improved because team will work on smaller goals with shorter cycles which can be assured to be complete in a given time.
Simply speaking, agile is a philosophy. This is neither a methodology nor a silver bullet, that can be or must be applied to all types of software development. The approach fits in well in the context of a new product development, or applications development where requirements are evolving, or tiered budget approval process based on success in earlier phases and so on. We should embrace it, only when it can facilitate the end outcome and then adopt it across the entire life cycle and not just during the coding stage. Agile delivery (the final delivery of working software in production) as opposed to agile development is a much broader scope and needs holistic consideration and a proper evangelization. Not just the ambulance reaching the hospital, but the physician actually treating the patient and making him feel better!