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.

« September 2013 | Main | November 2013 »

October 22, 2013

Ensure success with agile - Three critical precepts

Posted on behalf of Surya Prakash K., SVP - Business IT Services Head - Retail, CPG, Logistics & Life Sciences

The Northern Sea Route helps ships from China reach Germany 2 weeks faster than the traditional Suez Canal route. However, speed (timely delivery) and quality (no loss of original scope) is only guaranteed if the weather's great and the timing is good, which is only for 3 months a year. Agile projects are sometimes this way - they succeed only in fair weather (i.e. business and IT collaborate very well on a consistent basis) and the timing is good (i.e. if the project size is small, one gets great programmers and program leaders).

Today, Agile is a way of life adopted in many new development projects. So doing it only when everything's all right, is not an option. Get a lot out, faster is required at all times.  As companies embark on large agile projects, here are a few things to keep in mind.

Scale is not possible without systemically integrating business & IT throught collaborative platforms, and without leveraging distributed delivery

The larger projects/programs inevitably have a lot of things to keep track of. Issues pop up in ongoing work, new features are unclearly defined causing more iterations, things in production give rise to new changes - the number of things to keep track of, on a daily basis is high.  Business has to work closely with IT, and track and close impediments. Architects have to regularly remove bottlenecks, programmers have to be moving forward constantly.
A lack of systemic integrated models that facilitate smooth collaboration between Business - IT - Engineering, will clog the supply chain.

Supply chains can also get clogged by the ability (or lack of it) to get scale in people. Distributed delivery brings in scale, but increases complexity and collaboration needs. Offshore locations bring in scale, but how many projects do distributed development properly. But if one can do it well, the cost benefits are quite handy.
Success in large agile projects requires seamless virtual collaboration that enables scale and distributed development. Success also means usage of tools and ready to use custom components that improve productivity. Cost benefits without forsaking the very principles of agile, is useful.

Don't slow down for quality control, but align quality control to the agile way to ensure quality

"Let's go agile" - this does not mean that one gets to roll out crappy stuff. Quality control and testing is as important in agile programs as in waterfall programs. Traditional testing though, often means meticulous planning, and uses a prolonged pit-stop phase.  Ask anyone who runs an agile program; they don't want anything to stop. Multiply the complexities of parallel development that happens in agile and you have a quality disaster waiting - Features often need other features to be ready & ready data before they can even pass basic quality checks.

Agile quality way - this requires process map driven test planning, test case generation, and service virtualization to test features while using stubs for dependencies. These are new ideas being tried for quality control in agile programs.
Providers though need to bring in the quality control maturity. They need to bring in tool sets to enable application process map to test case generation, service virtualization kits and the like to enable client IT organizations and businesses breathe easy on quality control

Agile development ain't agile delivery

Huff and puff, get your features built, but wait at the last mile - infrastructure not ready! Not unnatural in agile projects. Environment changes - setup/dismantle/setup - are still traditionally managed. Releases into production are strictly controlled by change control boards. Infrastructure management is at times outsourced to external service providers and SLAs and operating procedures were set up years ago.

In Agile, value realization is important. Value realization is not possible until the "value developed" hits production. This requires one to incorporate frequent releases, speedy test environments and fast releases to production. It is not that agile projects reduce overall time, it's just that the features with higher value get deployed first and feedback from production is used to modulate future sprints. Agile programs often use a term "Demand to Deploy" to mean - choose right (better value) demand upfront and Deploy it fast.

Without the infrastructure teams playing ball, Demand 2 Deploy is often a pipedream.

Saying all these is easy. Bringing in a "show and tell" to complement the "say and tell" is important when one writes blogs like these :)

At Infosys, we have developed a collaborative platform and set of processes and toolkits that address these critical issues I have talked about. There is also additional ready to use domain and technology components for scenarios like ecommerce, digital marketing, talent management - that help add necessary acceleration at high quality - to these time-strapped programs.

Several of our clients have gained-

  • A leading US fashion retailer grew their revenue while their release cycle reduced from 3 months to 3 weeks. More features went out and helped them cash in a new promotion trend.
  • A leading UK retailer got out 40 new features in 45 days for their e-commerce platform that helped created a marketplace for various sellers.
  • A leading telecom and information service provider in Australia reduced Infrastructure provisioning from 10 weeks to 20 minutes and became more responsive to changing business demands.

How did we manage all of these? Keep watching this space for more...


October 16, 2013

The Excitement or The Fear of Agile

At Infosys, I have recently interacted with many senior executives from multiple organizations which had just started some projects in agile or were eager to start it. Agile is more than a decade old now and is mainstream but there are organizations yet to embark on the agile journey. Why some organizations did not adopt agile in past? Why are they now keen on adopting agile?  Let's take a look at some of the interesting insights that can uncover the origination of the skepticism while adopting agile though technology/environment might be favorable for it.

  • Organizations, having their own detailed processes, successful execution models and well defined organization structure feel that everything is going well from the IT teams' perspective . For them, with current delivery processes and teams, project deliveries seem to be working fine for years. When things are going well then it's a natural tendency to resist the change as it leads to fear of uncertainty. 
  • "Agile is chaos" - a misconception is another reason why organizations shy away from agile. Agile has been misconstrued for uncontrolled teams, not having management plans, not following rules and many more. Further many enterprises need to follow regulations and meet compliance requirements. Misconceptions about agile make them worried that the rumored unplanned and chaotic nature of agile may result in defaulting on compliance. Thus, it's better to stay away. 
  • Next is the fear of the unknown - Agile teams talk like aliens. They talk of self-organizations, trust, freedom and heavy business involvement. They talk of team focused goals and not of individual performances. They talk of servant leadership and not project management.  Can it work in a medium or a large enterprise? Isn't it a fancy of small organizations where close knit groups can successfully do agile?
  • Additionally, agile seems like a lot of investment. Agile teams are excited about different Application Life cycle management tools and won't use organization's age old project management tools. More often, they need continuous integration tools and test automation tools. Further, some teams need continuous deployment tools. Are we really ready for all of these?
  • Lastly, distributed execution has been working fine for these organizations. Agile needs co-location. They question "How will a large organization with multiple locations across continents be able to use co-located agile methodology?"

 With all these fears, many organizations have shied away from adopting agile rapidly. However, some of these organizations are now excited about adopting agile ...What is the reason for these organizations to be excited when a many still have their reservations?

  • For many organizations, one of the key reasons for embarking on agile journey is market dynamics. With tough competition and rapidly changing consumer patterns, it is important to quickly launch the latest products and services in the market. Any delay in addressing the market need would mean either the consumer base will shift to competition or the need for such offering will become obsolete. This kind of volatile market conditions are observed more often post 2008 phenomenon of economic situations in the world. Obviously business is demanding early value delivery which can benefit it to either increase or retain the business.  With changing business demands such as improved time to market or early realization of business value, it's time for IT to adopt newer ways to cater to these demands and agile definitely looks promising in such cases.
  • Another reason is that with the ever increasing cost-control measures in organizations; business wants low upfront investment, tight control on budgets, flexibility to modify the funding for projects during the course of execution. Further, business wishes to know what value is delivered against the funding they are providing. With traditional models, it is difficult for IT to adopt such flexibility and control on funding. Also, IT needs to adopt the way of execution which can help measuring the delivered value rather than just meeting IT goals such as productivity, quality etc. Agile looks like a help in this matter.
  • Last but not the least, the reason is 'if others are doing then why not me?'. IT teams are rethinking that when competing organizations have adopted agile, when IT teams around us are talking about their agile experiences, when our new CXO has positive views on adopting agile from previous experiences then why aren't we thinking about adopting agile?

During the discussions of  embarking on the journey of agile, we talk a lot about clearing misconceptions about agile and how a low risk , low investment agile journey can be started while still keeping the big picture in mind. One of such point of views, which breaks the co-location myth of agile "Staying agile in distributed environment successfully", can be read here.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter