Have you been thorough the process of outsourcing your Agile project to an offshore service provider? If yes - you must have wondered how you should be measuring the progress & success of the work that is getting carried out by your service provider. But what could be the measuring criteria? How do you know if you are heading the right direction or not?

In this session we look in to the aspects of identifying how one may successfully measure the state of an ongoing delivery model & based on it, how we refine/improve the outcome.

Backdrop:

Over the last 10 years while working in onsite-offshore model, what I have personally come across is the fact - whenever we work on Agile, we do come across one magic phrase every now & then - "I have also worked on Agile". Yes, we all have! :) Agile is simple & there is no rocket science in doing so while delivering across onsite & offshore. We all know the drill i.e. set up some time zone overlaps, establish virtual communication channels, identify some Proxy POs, have some kind of "all hands" infrequently & we should be good. Isn't it?

We all know these (at least we all claim so)! But then why is it that some of the projects do better than the rest & some even fail? Why is this that we don't realize that if you offshore your work in Kolkata, you deal with a different cultural barrier than if you offshore the work at Bangalore (or vice versa)? Did we ever consider that it is upon us - the so called Agilists - to bring up the Agile knowhow to our clients (& many a times - learn from clients as well)? These are the simple - yet mostly unnoticed elements - which play a crucial role in deciding how a project succeeds in Agile offshoring & we should be able to take them in to consideration.

More often we jump in to the Agile bandwagon - bit prematurely. And mostly as we try to do so, we fall flat (well, there are exceptions of course) & jump to an off-shoring organization. The good news is, by doing so - we may have just taken the second (i.e. after deciding to go Agile) right step i.e. if we don't have the expertise in house, bringing in the talent from outside makes most sense. But we need to keep in mind; unless we ourselves are not having an open mind to embrace the changes, we are most likely to fail despite all our good intentions.

Basis of this talk:

I am working on Agile onsite-offshore model for last 10+ years (with total 15+ years in the service industry). Over these years, have dealt with numerous small (2-3 teams - all co-located) to large scale (75+ teams, spread across multiple geographical boundaries) Agile engagements & have worked as consultant to several projects. Offshoring is a big challenge - not only to our clients, but also to ourselves - as we often fight the situation, where customer is either too rigid on Agile expectations or too much bent towards traditional PM style. Bringing the right mix is always the tough ask - that is where the success of the project depends.

Agile has always challenged people with the question on how much to design upfront! It doesn't end there, it even flows in the day-to-day work of the developers & the associated Engineering Practises. We do understand the need to have a scalable design, rigid code quality checks - but who is eventually driving these? How are the architects coping with the changing dynamics of development methodolgoy? Are we really driving those practises in reality or are they finding place in management slides only?

This session is an attempt to project how the practise of architecture is getting mis quoted/mis understood in most of the ongoign Agile projects & what has been the root cause behind them.

We also try to come to an agreement as what should be the ideal approach towards setting up an Agile Architecture.