Technical Challenges In Offshore Software Development
-
Upload
jonathan-bardin -
Category
Software
-
view
84 -
download
0
Transcript of Technical Challenges In Offshore Software Development
10
Per feature delivery
Daily feedback
Continuous Integration
Chat/ Video / Email
Short Feedback Loop
13
Definition of done
Create definition of done with Client/Partner
Quality check list
Security check list
Conduct detail review
Automate quality report
~40% times of Senior member
Technical Challenges
The TTV Case Study
Jonathan M. Bardin
In Offshore Software Development
Good Afternoon!
My name is Jonathan Bardin. I have been working in TTV for two years as the CTO.
Today I will talk about three of the challenges we faced and face in TTV, and how AGILE practiced help us to overcome them.
2
Challenges we face
Let's start with Challenges.
First: The communication gap. Between our team in Vietnam and our client and partner in Japan, as well as the one within our company.
Second: The Agile culture change. Moving from plan driven practice to Agile ones.
And Finally: The lack of Trust. Building trust in both our team skills and in the Agile practice.
3
Communication Gap
In all of our project we have to deal with communication issue. While some our staff speak Japanese, most of us don't (as you can see).
Our partner and client does not always speak English or are feeling conformable to use English to discuss requirements and the project. The documentation, the requirements are often needed to be translated.
4
2/10
In which language the meeting should be held.How can we test application that we don't fully understand.
( out of the 10 last project we work on, in only 2 of them the product owner was feeling comfortable communicating in English)
5
Change To Agile
Our partner and client have often a long history of following 'Command control model' practices.
They almost always ask us to integrate our work in within a waterfall lifecyle.
They are use to work with plan driven requirements, and don't feel comfortable moving from it.
Not only our client and partner, but some of our employee where also use to work with plan driven requirements in their previous company.
We often have to deal with `I have always done it this way`
6
Lack Of Trust
Finally, the lack of trust.
This is probably the biggest issue we have faced so far.
As Mr. Minh outline it in is presentation, 60% of our employee are bellow 28 year old (which correspond to Vietnam median age), while the Japan median age is 46.1.
Japanese quality standards are very high and strict, as well as security standards. While most of our developers came from the top 2 university in Vietnam, they never have been trained on Japanese quality and security practice.There is a lack of trust in our skills and thus our ability to conduct successfully the project.
There is also a lack of trust in Agile practice. Our client and partner doesn't feel comfortable to give more decision and autonomy to the developers.
7
AddressingChallenges
So here are our three challenges:
Communication Gap, The Agile Culture Change and The Lack of Trust.
I will know talk about some of the methods that helped us to address these challenges, and the one that we are planning to put in practice in a near future.
8
TTV Holy Trinity
Short feedback loop
Going the distance
Definition of Done
The TTV holy trinity, or the set of practices that help us to overcome our problems.
1/ Having a short feedback loop2/ Going the distance3/ The definition of done (+ conducting review)
9
Short Feedback Loop
1 week Iteration
Kanban Board
Keeping a short feed-back loop helped us to avoid miscommunication. It also comfort our client/partner.-We keep the iteration short one or two weeks at most. -We use a real Kanban board, so that everybody can have a quick feedback of the project status just by looking at it. We also maintain on online version that is available for our partner. It help us work in a transparent way.
10
Per feature delivery
Daily feedback
Continuous Integration
Chat/ Video / Email
Short Feedback Loop
Even when given a waterfall plan, we convince our partner to review the story as soon as it as been define as done. We use continuous integration practice to always have the last staging version available for the client to test.
We communicate daily, over chat, and with a video conference if possible. I cannot emphasis enough the important of having multiple mean of communication.
Without a doubt having a short feedback loop with the client helped us to reduce communication gap, build trust and show the benefits of Agile practice.
11
Going the distance
Visiting Contact
Face to face
Kick off meeting!
Going the distance!
It's very important to meet face to face during a project.
Frequent visit contact helped us to build trust with our partner and client. It is always easier to kickoff a project having all the person involved in a same room.
12
Going the distance
Ambassadors
1->3 months
build trust
both way
Sending ambassador for long term period in each site help a lot. It helps with communication but also to assure that we share the same expectations (quality standards, security ...)
We sent a team in TCI office for 3 months, it gave us precious information of what are expected from our team. We learn so much that we clearly regret not having done it sooner.
After this experience we learn that going the distance was mandatory to build trust and reduce the communication gap.
13
Definition of done
Create definition of done with Client/Partner
Quality check list
Security check list
Conduct detail review
Automate quality report
~40% times of Senior member
Last but not least, the definition of done and review process.
We should always be clear on the `definition of done` with our partner and client. It's really valuable to take time and create detail checklist of what it means for a story to be done. It helps to be sure that we share the same expectation for the quality of the project but also help the developer of what they need to check before defining a story as done.
One problem we face, is the lack of experience of our young developers. Unfortunately some of them need more control. Putting in place `continuous review` help our developer to grow, and reduce the risk of not meeting the definition of done.
Because review is time consuming, it is important to be able to automate part of it (code coverage, code conventions..). Iteration review report can also help to motivate the team as well as to reassure the client.
14
Short Feedback Loop
Going the distance
Definition of done
While the journey is not easy, we are confident that AGILE practice helped us to grow as individuals and as a company. It lay down the foundation of better communication and better trust between us and our client.
Short feed back loop, going the distance and a clear definition of done; Those are we believe essential in the success of offshore software development
15
Make it your own
While those are our answers, they are not the only ones. AGILE is born from the need to adapt to change. It is a set of practices and methods that may or not fit your needs. We believe that is up to everyone of us to tailored those practice for each of our project. To discover new AGILE way and to share them with the community.
We are looking forward to know about your AGILE way.