Trinity – Product Development
Blueship Vietnam was established in 2016 with the primary purpose to become an exclusive development team for Trinity, applying the best practices of Agile methodology and utilizing leading technologies more effectively.
For more than a decade now Blueship Vietnam continues to maintain and develop Trinity. During these years Trinity needed to adapt to the ever-changing ecosystem, realize new features, migrate to the latest technologies and improve scale-ability.
Trinity is an integrated solution for IT Service Management, encompassing source code, change, build, release and deployment management. Trinity was developed in 2008 for the finance sector and primarily the banks in Japan.
Technologies: Struts, Spring, Ant, Thymleaf, Wildfly, Bootstrap, Hibernate, Apache, Gradle, Ngnix, WebDav
Database: Shunsaku Data Manager, PostgreSQL
Testing: Selenium, Junit
Code review: Sonar
Project management tool: Backlog, TestLink (Test management tool)
New UI design
Upgrade product to new UI/UX design
Migrate 3 independent applications into 1 web application.
Guarantee browser compatibility, as well as a user-friendly and ergonomic UI.
Migrate the database from Shunsaku data manager to PostgreSQL
Guarantee data integrity and continuous business for existing Customers.
Guarantee backup and rollback.
Upgrade to the newest technologies: Java8, Apache web server, Gradle, Bootstrap, Ngnix, etc.
Implement new features to keep up with market demands.
Continue maintenance and enhancement based on customer requests.
Our journey toward success
- CCB discusses and defines the objectives, prepares a high-level scope of each phase, plans for release dates and expenses for each release.
- The Product Owner (PO) introduces the release roadmap and business purpose of eache release to the developer team and other stakeholders. There shall be no detailed specification at this point.
- The Product Owner decides the priority of user stories. Designer and Business Analysts compose user stories with the help of the PO.
Sprint 0 is an introduction sprint, sometimes it takes place before the first sprint, other times, it is held together with it.
In sprint 0, the developer team becomes familiar with the project objective and roadmap. Furthermore, we overview the release requirements and determine the release date as well.
Sprint 1..n – product development in 2 weeks periods
- Sprint planning. On the first morning of every sprint, the PO introduces one or more user story with the highest priority. The scrum team and the PO discuss the details of business requirements and technical conditions, create an estimation and define sprint backlog.
- Daily work
- Stand up meeting: A daily scrum is held every morning, where the team members share what progress they made, whether they encountered any problems, and what work they plan to accomplish on that particular day.
- Pair programming: Depending on the type of task; every team member can work either independently or in pair with another developer.
- Design a test case for each user story based on the Definition of Done (DoD) principle. Our team will analyze the impact based on their experience in testing and on their knowledge about the system.
- If present, the PO (and the BrSE) can join the daily meeting to answer arising questions, or can be available via chat or call.
- Parallel with the work of the scrum team, the PO creates new user stories and builds product backlog for the upcoming sprint.
- The team takes care of testing and bug-fixing during the sprint
- Sprint review and retrospective
- At the end of every sprint, we demonstrate what we achieved during the two weeks, and receive valuable feedback from the PO.
- Collect the opinion of the team members regarding the work accomplished, and things learned to improve our work in future sprints.
This is the last sprint before the release, when our team focuses on the regression test, while the PO and other stakeholders take care of acceptance testing.
Each critical bug must be fixed, while low priority issues need to be assigned to the product backlog, to be handled in a future release.
Usually, a package will be created one week before release, by this time the release team finalizes the release note, the user guide and other documents essential to the delivery.
Challenges and solutions
Miscommunication due to language and cultural barriers
In the beginning, our offshore development team had difficulties with accurately understanding requirements due to miscommunication. As a Result, we had to rework some of the requests.
Speaking different languages also makes it harder to explain problems that arise during development.
Due to cultural differences and varying communication styles, we faced many challenges interpreting the specifications and requirements.
- At first, we relied on the help of interpreters, but soon we realized that without IT background their mediation could cause even more confusion.
- English communication: English is an international language, it is commonly used in the field of Information Technology and Computer Science. Almost every developer at BSV speaks at least basic English. Our Product Owner and other Japanese colleagues are also confident to have a conversation in English with us.
- Programming languages and business domain languages: IT has its own terminology; understanding business domain, technical specifications or source code written on different programming languages is easy for us and helps to overcome difficulties.
- BrSE: The Bridge Software Engineer is responsible for connecting Japanese clients and offshore project teams in Vietnam. He works closely with the PO and scrum team to help information transfer and communication
Established goals are not always achievable
Unexpected work during Sprint
Case 1: In the middle of the sprint, customer support raises a flaw in the recent release. Product Owner instructs the developer team to fix the bug as soon as possible.
Case 2: Occasionally we complete a User Story earlier and demonstrate it to the Product Owner to get their feedback. When seeing live product execution, our PO decides to change the original requirement or add new functionalities. He instructs the team to implement the extra features before the User Story is closed.
Freezing the sprint backlog is extremely important in order to maintain velocity and keep up with the planned sprint delivery. On the other hand, uncertainty is a common issue in the software development process. Therefore, it always depends on the situation which solution we find most suitable.
• The scrum master reminds the team and the PO of the time-box and the necessity of a settled sprint backlog.
• The PO and the team assess the importance of the added request, may it be a bug-fix or a new feature.
◦ In case of smaller flaws, with little or no impact on the scope, the team includes the issue into the current sprint.
◦ If the request is critical, the PO and the team decide together to replace a similar size user story with it.
◦ For urgent matters, we implement the new request and accept that it affects the aimed sprint delivery.
The Scope of a sprint is inadequate
Our Product Owner is a software engineer who met the Scrum process for the first time. He is very precise and always creates a detailed design when writing a user story. Such thoroughness takes time, therefore occasionally he cannot prepare a sufficient scope for the upcoming sprint.
Having a proper size of the sprint backlog is crucial for the team to preserve commitment and improve velocity. It also helps the team to make accurate KPI for the project.
- The Scrum Master guides the Product Owner in writing adequate user stories.
- The Product Owner is responsible for backlog refinement. During the sprint, he keeps the backlog up to date by re-prioritizing, adding new user stories or removing obsolete ones.
- A Backlog refinement meeting it is held in the second week of the sprint (usually on Tuesday or on Wednesday). The purpose of this meeting is to provide the developer team an overview and clarification of backlog.
Unclear goals, roadmap or expectations
For some releases we had no clear product roadmap, The team had to develop product features following customer needs and the requests of the management, rather than a well defined strategic plan or vision for the product.
Listening and being responsive to customer needs are extremely important, but it is quite hazardous to customize a product without long term goals and established requirements. A product roadmap serves as a technology roadmap too and is essential for building products with long-lasting value.
- Before a release, our scrum master reminds the Product Owner to develop a sufficient product roadmap.
- A Product roadmap shall be based on market research, industry standards, and best practices. IT must be revised frequently, and both external and internal stakeholders have to be aware of it.
- A clear roadmap helps the team to plan on technologies, to mitigate risks originating from the gap between product and technology plans. It allows the understanding of needs and helps to adapt accordingly.