Being Agile in a Cross Cultural Environment - XP Day 2015 @ Vietnam - Nguyen Vu Hung

A Case Study at Septeni
Technology:
Being Agile in a Cross-
Cultural Environment
XP Day 2015 @ Da Nang, Vietnam
2015/04/18
Nguyen Vu Hung, CTO, Septeni Technology

AGENDA
1. Introduction
2. Highlighted Case Studies in Random Order
a. Tools
b. Processes
c. Best practices
3. Q&A
2014/04/18, XP Day Vietnam 2015 @Da Nang, Vietnam - Nguyen Vu Hung

About Septeni (Technology)
epteni Group: 1990/10
Tech: 2013/03
affs
service developement

Self Introduction
1. Nguyễn Vũ Hưng, 1978
2. CTO, Septeni Technology
3. POS:
a. Agile
b. Open Source
c. Project Management
d. Bridge SE (!)
"Nguyen Vu Hung is the CTO of Septeni Technology, a development center of Tokyo based Septeni Group that
focuses on developing and operating, mostly, web-based online advertisement systems. He has numerous years of
IT and software development, project/product management in both Japan and Vietnam. Considering himself as a
FOSS and Agile evangelist and being a Agile lover and an CTO, he is also interested in not-so-related domains
such as human resource management and (organization) (re)structuring."
www.facebook.com/nguyenvuhung
vuhung16plus@gmail.com
+84-904-28-7878

Disclaimer
What is talked and discussed here is my
personal opinion and is NOT the opinion of
my employer(s), associations and/or
groups I join.

Disclaimer (2)
I am too young to understand XP.
And I am here to talk what I think
when looking back to XP. And not
about XP itself.

What (NOT) to Cover?
1. In this session, we share our experiences,
tools, practices,
2. We don’t cover basic information, defintion
such as “what is Agile?”, “Is this really Agile
or scrum-butt?” here,
3. XP and Scrum. We follow Agile principles
but not only XP and Scrum practices.
“At Septeni Technology, we've been trying to apply Agile practices and and its principles for over two
years for IT projects as well as web-based services since the beginning of the company. In this session,
as a case study, with the purpose of sharing our knowledge, I would like to share our best practices for
applying Agile, the tools we are using, the mindset we must have for applying Agile successfully.”

Who Should Join This Session
1. Basically, everyone can enjoy this session,
2. However, a little experience with software
development, Agile/Scrum practices will
make you feel more comfortable with this
session,
3. You are in a (offshore/outsourcing)
development center in Vietnam.

OK, Let’s Start

Which came first?
1. Agile,
2. Scrum,
3. XP?

Which is Most Important?
1. People,
2. Process (quy trình),
3. Tools?

People
Tool
Process
Japanese
Vietnamese
Agile
Scrum
XP
JIRA
Wiki
Skype

The Organizations
1. Septeni Group
a. Based in Tokyo
b. (Internet) Marketing
2. Two development centers
a. Japan/Tokyo (~50 staffs)
b. Vietnam/Hanoi (~50 staffs)
3. Operation centers
a. (Mainly in) Japan
b. U.S.
c. EU, Korea, APAC

Project::Communication Gap
Operator
ProductOwner
BridgeSE
DevelopmentTeam
Sysadmin

Gaps in Definition of Done
1. Be proactive
2. We define our DoD and defense it
3. Clear DoD is a good thing
4. Ambiguity for rooms of improvement
5. Have an RACI table
6. Done when reviewing is finished.

Problems of Language Gap
1. 80% understandable
2. English, Japanese and Vietnamese
3. We are not English native speakers
4. Speakings & Writing
a. Criticial cases: Native languages
b. English is OK
5. When to speak and when to write?
6. TV Conferences
7. Translators/Bridge SE

The Importance of Business Analyst
1. We don’t BA officially
2. Bridge SE, PM, PO have to act as BA
3. Fill the business gaps between business and
technical

Getting Things Done is not Enough
1. Japan
a. More process oriented than,
b. Result oriented
2. Vietnam
a. Which one is more importance? Process or Result?
3. Scrum (as a process) is a (Agile) toolkit or
the goal?
4. Balacing the two
5. Short-term and long-term goals

Seeking for a Standard
1. Does it exist: “Standard” Scrum?
2. The Scrum way in Japan,
3. The Scrum way that make Vietnamese
happy?
4. Customized Septeni Scrum way.

Meetings and Reports
1. Do we need 2 daily meetings?
a. Morning meetings,
b. Afternoon meetings
c. Why?
2. Issues/Progress tracking for all stakeholders
3. Managers/PO in Japan and Vietnam can
track easier,
4. Prepare for Overtime if needed

Test Automation
1. Not directly improve quality
2. Types of AT
a. Unit level
b. Function level
c. Integration Test (IT), UAT
3. Tools
a. Selenium/Web Drive
b. Cucumber
c. Shouldbee (?)
4. The goals
a. +80% coverage for unit test
b. +50% coverage for IT, UAT (webapps), by number
of test cases

Test Automation (Developers)
1. PHP Unit
2. Ruby: Rspec
3. Scala: Scalatest
4. The goals
of test cases

Test Automation (Manual Testers)
1. Selection criteria
a. No or little programming skills required
b. Quick learn, low cost to start
2. What to apply
a. TDD, BDD
3. Shared goals among testers/developers
of test cases

Cultural Transition
Note: Thanks Kakeya-san for the slide
Most of the audiences agree that Vietnamese must/should and is more Amerian-like that Japanese.

Culture Comparation (2)

Note: Thanks Kakeya-san for the slide2014/04/18, XP Day Vietnam 2015 @Da Nang, Vietnam - Nguyen Vu Hung

(Task/Collective) Ownerships
1. Main responsiblity for each
process is defined in RACI table
2. Each task/process has ONE
person to take ownership on it
3. Team members help each
other, but main ownership
belongs to only ONE
4. “Trách nhiệm liên đới"/連帯責任
5. "Cha chung không ai khóc"/"
bóng ở giữa sân"
Project organizational chart

Rhythms of Agile (Scrum)
1. Asa-kai (朝会=morning meeting)
a. All company staffs join
2. Product P
a. Daily meeting
i. Morning: Task for Yesterday and
today, issues
ii. Evening: Do we need to work
overtime today?
b. Teirei meeting (JP/PO/VN)
3. Release weekly on Tuesday
4. Bug statistics at the end of every
months
5. zabbix alert statistics at the end of
every weeks
Regular meeting calendar of a month.
Type of reports
Type of meetings

Platform Team - The Next Target
1. DOs
a. Build technical common foundation through our
company
b. Adopt it to application development with
communicating with application development team
2. DONTs
a. Develop applications

DDD: Domain-Driven Design
1. Ubiquitous language to fill the cutural
gaps
2. Business and technical friendly
3. New and still immature
4. Why not try it?
5. Full cycle: from requirements to operation

Scala: New Development Stack
1. (Ubuntu)
2. Scala 2
3. JDK/JRE 8
4. Play Framework
a. backend, application server
5. IntelliJ IDEA
6. Amazon AIM Linux (server)
7. Frontend: AngularJS
8. Amazon MySQL RDS
9. Specs2
10. Vagrant, VirtualBox

Kanban
1. Big Backlog
2. 4 lanes: Todo, Doing, Resolved,
Done
3. “Release” with Jira Kanban
4. One-week iteration
5. Limit WIP (TBD)
6. Mainly for operation and research
tasks

Planning Poker
1. 1, 2, 4 8... vs. 1, 2, 3, 5, 8…
2. Qualitative Measure
3. Planning poker cards
4. 10 months from ideas to
implementation

Typical Vietnamese :)
1. Resistance to change
2. Always start with a “NO” statement
3. Don’t speak
4. Don’t open
DRIVE THEM!

(Some) XP Rules We Follows
1. We follow most of XP Rules
2. Test first (TDD)
3. Automation Test
4. Small Iteration
5. Unit test

Let’s Vote for the Next Topics

Topics in Detail
A. Organizational:
1. Organzation structure
2. Technology overview
3. KPIs (Key Performance
Indicator)
4. Roles and Responsibilities
5. Report Lines
6. Bridge SE
7. (TBD) Scaled Agile
B. Management:
1. Knowledge
Management/Transferin
g
2. Result-Oriented
Management
3. Planning
4. Estimation
5. Review Process
F. About the Project:
1. Project P. Overview
2. Agility in project P.
D. Important quality practices:
1. TBD: Software Metrics to
Measure
2. Quality = Measurement
C. Best practices:
1. Jenkins - Continuous
Integration
2. Integrated Test Automation
3. Source Code Quality
4. Code Coverage
5. Unit Test - PHPUnit
6. Test Code
7. Test Driven Development
8. Source Code Refactoring
9. Source Code Quality
10. (git) branching model
E. Tools:
1. Jira - Ticket Management
2. JQL: Powerful Ticket Queries
3. Collaboration with Confluence
4. Stash - a git Repository
5. Chatwork - Realtime Instant
Messenger
6. Google Drive - Realtime
Collaboration Tool
G. Other
1. Book we read
2. What are the gaps?

WE ARE HIRING

APPENDIX

Organzation Structure
1. Infrastructure
2. Human Resource/Back Office
3. Developement
a. Project P. We will talk about this project

Technology Overview
1. Infra: Amazon EC,
2. Framework: CakePHP,
3. Database: MySQL RDS,
4. External interface: Facebook API

Project P Overview
1. Japan side
a. 01 Product owner
b. 02 facilitators
2. Non-technical
a. 01 Project manager
b. 03 Project lead
c. 01 Quality assurance lead
d. 01 Bridge SE
3. Technical
a. 10 developers
b. 08 testers
c. 120 KLOC

Agility in Project P.
1. Customized scrum practices
2. Big team to run scrum? (~30 persons)
3. 01 PMs, 01 Bridege SE
4. 3 teams
a. One project leader in each team
b. One scrum master in each time
5. A half is QA
6. A half is developers
Note: We are going to make this structure more flat and cross-functional

Knowledge Management/Transfering
1. Confluence (wiki)
2. Blog labs.septeni-technology.jp
3. Training (external, internal)
4. Pair programming
5. Review processes

Planning
1. Long-term
a. 3-month after the FB API update
plan
b. (For development) We don’t plan
longer than 3 months (the market
changes too fast)
c. New requirements are queued on
the backlog
2. Mid-terms
a. Per projects
3. Short-terms
a. Weekly, per-sprints
b. Daily
Product backlog for a quater

Estimation
1. We have not yet using
planning poker
2. Consensus-based
estimation
3. Quite buffered by
individuals
4. Must follow FB’s
deadlines
Topic: What is the accuracy of the estimation
Estimation by team member, at man-day level, using GDrive
Estimation, Gantt chart wth Jira

Test Code
1. 1534 + 1115 tests / 116
KLOC
2. Using PHPUnit
3. Integrated with Jenkins
4. A part of test automation

Test Driven Development
1. This is a technical debt we are
paying
2. We applied it late, not in the
first place
3. We keep updating test
cases/test code during
development
4. Code coverage is an KPI we
measure how good is
TDD/test code
Failed test cases
Stack trace for a failed test case
Test result trend: failed test cases over builds

Source Code Refactoring
1. This is a technical debt we
are paying
2. The sooner the better
3. What we (will) do?
a. Remove dead code
b. Optimization
c. Simplify the source
code (logic, function)
d. Keep all test cases
“green” (don’t break TC)
4. Jenkins’ pmd code size
rules are the KPI for
refactoring
PMD evaluation result
Duplicated code warning using DRY plugin
Notes: Image taken from jenkins-ci.org

Source Code Quality
1. Source code quality metrics
a. Degree of code duplication
b. Degree of code complexity
c. Number of warnings by code static analysis tools
d. Coding conventions (naming rules)
2. Tools
a. Jenkins’ plugins (such as pmd, dry…)
b. Sonar’s plugins
c. <Your tools?>
Bonus: Cyclomatic Complexity (CC)

(git) Branching Model
1. Based on Vincent Driessen’s git
branching model,
2. Defined use of earch branches,
3. Mapping betweens (servers’)
environments and branches,
4. Defined input/output, definition of
done, RACI on each phases,
processes,
5. Sample flow for hotfix and
single/multiple projects
developments
Original git flowSepTech’s custimized process
Branching for hotfix Branching for multiple projects

TBD: Software Metrics to Measure
(Some) software metrics used for measuring source code
quality:
Duplicated code
Coding standards
Unit tests
Complex code
Potential bugs
Comments
Design and architecture
Lines
Lines of code
Comment lines
Classes
Functions
Statements
Public API
Cyclomatic Complexity
Note: We are planning to do it with Sonar

Review Process
1. Basically,we review all output
2. “Cusomters”/PO involves reviewing
3. Review group
a. Source code
b. Release note
4. Design document reviewed by
a. Cross-review
b. Project lead
c. Japan side

Roles and Responsibilities
1. As clear as possible.
2. But not so clear to encourage
cross-functionality.
3. RaR (RACI) based on output.
4. RaR (RACI) based on steps in
software/system development
process.
RACI matrix for all roles in projects

Report Lines
1.

Bridge SE
1. Fill the communication/language gap
between Vietnam and Japan,
2. A must-have position when working with
Japanese,
3. Communication skill is important,
4. We require BrSE to be good at Vietnamese,
Japanese and English.

TBD: Scaled Agility
1. Scaled Agile Framework
("SAFe") by Dean Leffingwell,
2. Disciplined Agile Development
(DAD), by Scott Ambler,
3. Large Scale Scrum (LeSS), by
Craig Larman and Bas Vodde.
Being agile at team-level is not enough. We should be agile at organizational level.

Result-Oriented Management
1. Đánh giá bằng kết quả?
2. Hay đánh giá bằng quá trình?
3. Hay đánh giá bằng mục tiêu?
4. Với phần mềm, có thể đánh giá bằng KPI
cứng không?
Note: This slide is in Vietnamese

Quality = Measurement
1. Common KPIs to
measure
a. Product KPIs
b. Project KPIs
c. Operation KPIs
d. Customers’ satisfaction
2. Specific KPIs in our
product
a. Number of operation
bugs after release
b. Number of alert emails
after release Number of system monthly alert
Number of system monthly bugs

Jenkins - Continuous Integration
We are learning about Jenkins, a powerful CI
tool. Here is the list of major plugins in we are
using
1. PHP messy detector: pmd
2. Code duplication: dry
3. Code coverage: clover
4. Automation test WebDriver
5. Unit test: PHPUnit

Integrated Test Automation
1. (headless) browsers
a. htmlunit, phamtomjs,
b. Firefox (runs on a slave machine)
2. 97 test cases (simple and complicated)
4. Run with cronjob
5. Coding in Java is a little pain

Source Code Quality
We (aim to) measure source code quality
1. Without human being involved
2. Automatically generated by Jenkins’ plugins by
● Degree of code duplication
● PMD (PHP mess detector)

Code Coverage
1. Source code static analysis
2. Visualized trending
3. Code coverage
a. Targeted:
i. Minimum: 80%,
ii. Better 90%
b. Actual: 80% and 61% (for C0 -
statement coverage)
4. PHP_CodeCoverage,
integrated with Jenkins
5. Clover PHP
6. TODO: Build triggers on
commits
7. Run by cronjob
Coverage tree map
Coverage report
Images taken from: jenkins-ci.org

Unit Test - PHPUnit
1. Training/seminar
3. Number of test cases
a. Batch: 1115 cases
b. Web: 1543 cases
c. Failure rate: < 1%
4. TODO: Build triggers on commits
5. Run by cronjob

Jira - Ticket Management
1. Jira is the heart of our team
a. Ticket (task) management
b. Project management
2. Master tasks
3. Gantt chart
4. Text
a. Richtext formatting
b. Table
c. Quoting
d. Collaboration: Tagging
5. Watching: update notification
by email
6. Dashboard
7. JQL: JIRA query language
8. Scrum board, Kanban,
Master ticket
Gantt chart
Dashboard
Note: Images taken from atlassian.com

JQL: Powerful Ticket Queries
Issues in last 24 hours
project = PPP and createdDate > -24h AND parent IN (pyx-669) ORDER BY
createdDate ASC
Tasks to remind customers
project = PPP and createdDate <= -2w AND parent IN (ppp-142,ppp-669,
ppp-124) AND status not in (closed, reject) AND assignee in(po1, custumer1,
customer2) ORDER BY createdDate ASC
Remind us important issues
project = PPP and createdDate <= -2w AND parent IN (ppp-142,ppp-669,
ppp-124) AND status not in (closed, reject) AND assignee in(po1, custumer1,
customer2) and priority in (critical, blocker)
My tasks:
project = PPP and assignee = currentUser() AND status not in (Closed,
Reject)

Collaboration with Confluence
1. Collaboration wiki
2. Tracking changes/history
3. WYSIWYG richtext editor
4. Integrated with JIRA
5. Lots of plugins
a. Source code beatifulizer
b. Table
c. Diagram
d. Table of content
6. Process document
7. Detail design
8. Rules & guidelines

Stash - a git Repository
1. Following git-flow branching model
2. Commit (pull request)/source code
review
3. Source code browsing
4. Merging permission
5. Fork, clone, download
6. All in one place
a. Everyone
b. Everything
7. Integrated with JIRA, Confluence
Code Review in Action
Branching “network”
Note: Images taken from atlassian.com

Chatwork - Realtime Instant Messenger
1. Realtime
2. Tagging
3. TODO/Scheduling/reminder
4. Text/message quoting
5. Cloud-based webapp
6. TV conference (sucks on Linux)
7. 20+ chat groups for project P
8. RESTful API
9. Suports mobile (iOS, Android) 1. Group chat
2. Mobile support
Picture take from http://www.kddi.com/business/cloud/cloud-app/chatwork/

Google Drive - Realtime Collaboration
1. (One of) the best real-time collaboration tool
2. Cloud based, only requires a browser
3. Real-time editing my multiple people
4. Review-and-resolve feature
5. Tracking document changes/history
6. Good for Q&A
7. Sharing with permission
8. We mostly use
a. Google Sheets
b. (and sometimes) Google Docs

KPIs
1. KPI for an online service
a. Number of bugs reported by users
b. Numbers of zabbix alerts
2. KPI for (development) projects
a. Customer satisfaction survey
b. Number of bugs
i. On production server
ii. Operation/Integration test phase
c. Deadline
Zabbix: An open-source (network/OS/service) monitoring system

Books We Read
Ngũ Luân Thư (五輪の書) Continuous Delivery
Management 3.0
Agile Product Management
with Scrum
Programming in Scala
Domain-Driven Design:
Tackling Complexity in the
Heart of Software

What are the Gaps?
1. Technical
2. Languagues
3. Culture
4. Knowledge
5. Background

A case study at Septeni
Technology:
Being Agile in a Cross-
Cultural Environment
XP Day 2015 @ Da Nang
2015/04/18
Nguyen Vu Hung, CTO, Septeni Technology

References
http://c2.com/cgi/wiki?ExtremeProgramming
http://www.extremeprogramming.org/rules.html
http://xpday.vn/
https://www.facebook.
com/groups/agilevietnam/

Being Agile in a Cross Cultural Environment - XP Day 2015 @ Vietnam - Nguyen Vu Hung

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (17)

Más de Vu Hung Nguyen

Más de Vu Hung Nguyen (20)

Último

Último (20)

Being Agile in a Cross Cultural Environment - XP Day 2015 @ Vietnam - Nguyen Vu Hung