Agile Offshoring: Touching the right chord

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.

 
2 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

 

The flow is like this:

  1. How work tends to flow at offshore - the backdrop [10 mins]
    1. How does a project life cycle go for an offshoring work? How does it flow across shores? Who all are generally the decision makers & what are their influencing factors?
  2. Challenegs faced - focusing on the following: [10 mins]
    1. What offshoring provider tend to offer (e.g. what are the selling USPs)
    2. What client expects (i.e. what motivates one to outsource work to offshore?)
    3. What are the do's/dont's & bridging the expectations

Learning Outcome

You will learn

  • Agile is not new, neither is the practise of offshoring - but why do we see varying results across projects?
  • What are the differentiators?
  • How can we avoid the "silly mistakes" (i.e. the practises - which appear very relevant & obvious to us - but actually work the other way)?

Target Audience

Management, Project Managers, Business Development Managers, Corporates

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Pavel Dabrytski
    By Pavel Dabrytski  ~  3 years ago
    reply Reply

    Hi Arijit,

    my feedback: it is hard for me to see unique selling point in your submission. Think of the way to make your proposal to standup out of all other Agile Offshoring submissions. What is your main idea and main message you want to convey.

    Also we need more details in Process section. we need a 1-2 sentances for each of the points. (i.e. give us examples of do and donts you will speak about).

    tip: it is better to edit the proposal itself instead of putting info into comment replies. This way we can save reviwers time.

    Thank you very much for submitting you proposal to Agile India!

    Regards. Pavel.

    • Arijit Sarbagna
      By Arijit Sarbagna  ~  3 years ago
      reply Reply

      Hi Pavel,

      Thanks for sharing your feedback. I understand your point. :) The point that I am trying to make is - end of day, when we work on Agile, it is Agile all across - nothing new per se. But how we tend to implement Agile in an onsite-offshore paradigm, that changes the game. And this is precisely what my objective is - to help people understand how to touch the right chords to be successful.

      Does that clarify?

      Thanks & regards

      Arijit

  • Raja Bavani
    By Raja Bavani  ~  3 years ago
    reply Reply

    Dear Arijit,

    I went through the abstract, process and the slidedeck.  My suggestion is to highlight the differentiators. These can be two or three issues or challenges or factors you want to highlight and deal with in your talk.  Without this it looks open ended because it carries broad scope.  Also, it is recommended that you highlight the basis of your talk. It can be based on n years of experience in working with m project teams Or it can be based on a survey, etc.   These things will help the reviewers and conference program committee.  Could you please update your proposal ?

    Regards,

    Raja

     

    • Arijit Sarbagna
      By Arijit Sarbagna  ~  3 years ago
      reply Reply

      Hi Raja,

      Thanks for the valuable comments. I have updated the proposal, even changed the title. :) I made the following changes:

      1. Changed the title
      2. Added a small section under the abstract as "Basis of this talk"
      3. Updated the flow - made it more concise

      Please review & advise if this makes sense.

       

      Thanks & regards

  • Sudipta Lahiri
    By Sudipta Lahiri  ~  3 years ago
    reply Reply

    Hi Arijit,

     

    Thanks for your submission... I have 2 comments:

    1. You have a lot of content for 20min 

    2. As you have correctly said, it is for beginners. I should qualify that and say "rank beginners". I don't know if we will have a audience like that.

     

    Regards

    Sudipta.

    • Arijit Sarbagna
      By Arijit Sarbagna  ~  3 years ago
      reply Reply

      Hi Sudipta,

      The topic demands more time, but intentionally it has been kept to a shorter duration - as intention is to touch upon the salient points. Time is precise - as I have presented this over multiple sessions. :)

      Coming to target audience: This is an area which has affected us all (& still does) - whoever has been in this onsite-offshore Agile delivery industry. I will ideally mark it as an "open forum". But marked it as "beginners" - so that general population don't shy away. Per my experience, even the most experienced people will love to hear the story.

      Hope it makes sense.

       


  • Liked Arijit Sarbagna
    keyboard_arrow_down

    Arijit Sarbagna - Quality in Code not in Management Slides

    45 mins
    Talk
    Advanced

    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.

  • Liked Arijit Sarbagna
    keyboard_arrow_down

    Arijit Sarbagna - Reading the pulse of an offshore Project - what to look for?

    20 mins
    Talk
    Intermediate

    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.

  • Liked Dinesh Sharma
    keyboard_arrow_down

    Dinesh Sharma - Trust and Committment, a two point mantra for a successful agile projects in offshore

    45 mins
    Talk
    Intermediate

    Agile projects success (or failure) depends on two key points in an offshore setuo i.e. Trust and Commitment. Lack of either can cause serious trouble in agile projects as they say "You can't solve people problems with policies". So a lack of Trust on each other (Customer and Supplier) leads to rigid, complicated, lengthy SLA driven contracts and both side fight over it by taking oath of 'the contract'. Trust comes from knowing each other well and it takes some serious commitment to build trust. Committment from Customer should be is to treat its supplier more as partner or equal stakeholder in the project and invest in making a strong, trustworthy relationship early in the project to build a long lasting bond. Also, equally from a supplier committment is to understand its Customer challenge and help them to achieve their business goals. A committed supplier will invest in its people to produce a best quality product for its Customer and be transparent with their (and customer) organisation culture and its challenges and openly discuss how to overcome those. A bond based on Trust and Commitment goes a long way and bring a very healthy environment for people working in that environment.

  • Liked Dinesh Sharma
    keyboard_arrow_down

    Dinesh Sharma - Thinking Environment - Do you have one?

    90 mins
    Talk
    Advanced

    Everything we do depends for its quality on thinking we do first. Our thinking depends on the quality of our attention for each other.

    A Thinking environment is the set of ten conditions under which human being can 'think' for themselves - with rigour, imaginaton, courage and grace. A Thinking Environment is natural, but rare. It has been squeezed out of our lives and organisations by inferior ways of treating each other.

    Thinking environment is based on ten behaviours that generate the finest thinking, and have become known as The Ten Components of a Thinking Environment. These components are

    • Attention,
    • Equality,
    • Ease,
    • Appreciation,
    • Encouragement,
    • Feelings,
    • Information,
    • Diversity,
    • Incisive Questions and
    • Place.

    Each Component is powerful individually, but the presence of all ten working together gives this process its transformative impact.

     

  • Liked Dinesh Sharma
    keyboard_arrow_down

    Dinesh Sharma - Offshoring Agile Projects - Myth, lies and Facts

    45 mins
    Talk
    Advanced

    Offshoring in an agile environment (especially with Indian IT organisation) is always a hot topic within agile communities. You will often find people talk about challenges rather than opportunities with offshoring agile projects e.g.

    • communication challenge,
    • lack of focus on quality,
    • rigid offshore organisation environment,
    • lack of agile practice knowledge,
    • lack of trust etc.

    Although these constraint-cum-challenges often directly linked to offshoring but it can exists in a non-offshore environment as well. For example, to see how you can work effectively with distributed teams you don't need run a project in offshore environment, just split your teams and ask them to sit on a different floor without seeing each other face to face and all these so called offshore challenges will appear in an onsite environment as well.

    So lets understand various Myths, lies and facts about offshoring agile project and understand key ingredients to make it successful.