Technical Challenges

The TTV Case Study

Jonathan M. Bardin

In Offshore Software Development

2

Challenges we face

3

Communication Gap

4

2/10

5

Change To Agile

6

Lack Of Trust

7

AddressingChallenges

8

TTV Holy Trinity

Short feedback loop

Going the distance

Definition of Done

9

Short Feedback Loop

1 week Iteration

Kanban Board

10

Per feature delivery

Daily feedback

Continuous Integration

Chat/ Video / Email

Short Feedback Loop

11

Going the distance

Visiting Contact

Face to face

Kick off meeting!

12

Going the distance

Ambassadors

1->3 months

build trust

both way

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

Short Feedback Loop

Going the distance

Definition of done

15

Make it your own

16

Thank You!

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.

16

Thank You!