Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« November 2012 | Main | January 2013 »

December 12, 2012

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!

December 6, 2012

Create, Assemble and Deploy - The Future of Application Development

Created by Prashant Pawar, Delivery Manager, CORPADM

Discussions over a cup of coffee can really provide food for thought. I was talking to a few office colleagues about a deal we had recently won. The topic of discussion was what actually got us to win that deal. Everyone agreed that our solution was well matched to those of our competitors, then what was different...

The debate finally ended when we came to a common understanding amongst ourselves. We had actually embraced the existing assets (client's as well as ours) before we started working on forming a completely new system from ground up. That is what had won it for us.

This episode provoked our thoughts. We looked at avenues to leverage assets to reduce development costs and improve cycle time. We felt the need of an ecosystem that will embrace existing assets and harvest value to the fullest. This ecosystem will comprise of - CREATE, ASSEMBLE and DEPLOY. CREATE focuses on standardization to build reusable assets (components), ASSEMBLE focuses on standard assembly approach to assemble applications from various assets and DEPLOY focuses on infrastructure.

CREATE is nothing but component based development (CBD). It is a methodology used to build industry standard components. CBD is about understanding client business in best possible way and converting it into world class reusable components that can be extended to deliver the solutions. These components are designed in a manner where they can be leveraged across clients and technologies with valid IP checks in place. If we are able to pick opportunities for which we have available components we will have a definite price and time to market advantage.
The mantra is to create opportunity and generate more with less.

ASSEMBLE is smart assembly of the components. This approach is common in manufacturing or auto industry. In IT, once standardization is achieved while creating components and defining interfaces then it is only a matter of adding customization on top of it. Customization plays an important role as it creates business differentiation to our clients. At the end, stitching of assets (client, Infosys and third party) is to be done through defined mechanism to create desired functionality.

The third aspect is DEPLOY. Once an application is ready then it has multiple choices for deployment. Deployment depends upon the agreed arrangement between our clients and partners.

This ecosystem has a lot to offer to various stakeholders. For client community, it will offer AD solutions with lower cost, faster time to market with great agility.  For Infosys it will generate IP, create accelerators to deliver solutions and win more business.

Create a WIN - WIN situation for all the stakeholders......That's the ultimate objective.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter