The document discusses the technical challenges faced by TTV in offshore software development projects, specifically communication gaps, changing to an agile culture, and lack of trust. It describes how TTV addressed these challenges through their "holy trinity" of practices - short feedback loops with 1-2 week iterations and daily communication, going the distance through face-to-face meetings and sending ambassadors long-term, and establishing a clear definition of done with quality and security checklists and automated reviews. These practices helped reduce miscommunication, build trust with clients, and improve software quality and development processes at TTV.

1. Technical Challenges
The TTV Case Study
Jonathan M. Bardin
In Offshore Software Development

2. 2
Challenges we face

3. 3
Communication Gap

4. 4
2/10

5. 5
Change To Agile

6. 6
Lack Of Trust

7. 7
Addressing
Challenges

8. 8
TTV Holy
Trinity
Short feedback loop
Going the distance
Definition of Done

9. 9
Short Feedback Loop
1 week Iteration
Kanban Board

10. 10
Per feature delivery
Daily feedback
Continuous Integration
Chat/ Video / Email
Short Feedback Loop

11. 11
Going the distance
Visiting Contact
Face to face
Kick off meeting!

12. 12
Going the distance
Ambassadors
1->3 months
build trust
both way

13. 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

14. 14
Short Feedback Loop
Going the distance
Definition of done

15. 15
Make it your own

16. 16
Thank You!

17. 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.

18. 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.

19. 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.

20. 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)

21. 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`

22. 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.

23. 7
Addressing
Challenges
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.

24. 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 loop
2/ Going the distance
3/ The definition of done (+ conducting review)

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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

31. 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.

32. 16
Thank You!