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.
Outline/structure of the Session
The flow is like this:
- How work tends to flow at offshore - the backdrop [10 mins]
- 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?
- Challenegs faced - focusing on the following: [10 mins]
- What offshoring provider tend to offer (e.g. what are the selling USPs)
- What client expects (i.e. what motivates one to outsource work to offshore?)
- What are the do's/dont's & bridging the expectations
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)?
Management, Project Managers, Business Development Managers, Corporates
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Quality in Code not in Management SlidesArijit Sarbagna
schedule 3 years agoSold Out!
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.
Reading the pulse of an offshore Project - what to look for?Arijit Sarbagna
schedule 3 years agoSold Out!
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.
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.
Trust and Committment, a two point mantra for a successful agile projects in offshore
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.
Thinking Environment - Do you have one?
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
- Incisive Questions and
Each Component is powerful individually, but the presence of all ten working together gives this process its transformative impact.
Offshoring Agile Projects - Myth, lies and Facts
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.