Transforming Development Methodologies: Our Journey from Waterfall to Agile in Crafting the Prism Japan App

I am Gojo, a software engineer at KINTO Technologies.

I am doing backend development for a mobile app called Prism Japan that uses AI to suggest nice places to go around Japan.

I co-authored this article with Saito, the Product Owner of Prism Japan. I will talk about how our relatively large agile team improved its overall development and teamwork.

About Prism Japan

First of all, let me briefly talk about Prism Japan, the service we are developing.

In a nutshell, Prism Japan is a user-friendly app that leverages AI to provide personalized travel recommendations, helping users discover exciting places to explore.

Have you ever wanted to make the most of your holiday in Japan, but found yourself unsure of where to go?

Prism Japan can be your perfect companion, offering personalized travel suggestions to help you plan a memorable getaway.

With the "Search by Mood" feature for example, users can simply select a photo, and the app will suggest places to visit based on the chosen mood.

Users can look at photos and search for a travel spot that suits their mood.

We released the app for iOS in August 2022 and the Android version in April 2023. As of the end of October 2023, the total number of registered members has exceeded 30,000.

Prism Japan's Development System

Prism Japan can be used on iOS and Android. The team developing the mobile app is divided into:

• iOS development team and
• Android development team.

The backend is divided into the:

• API development team and
• AI development team.

Development is led by team members who specialize in their respective fields.

In addition to the development team, there are teams in charge of planning, analysis, and design.

The Product Owner decides the direction of the entire project and thinks about the functions that the user will need.

There are 15 members who are mainly in charge of Prism and 20 members who are involved in development sub-tasks.

It might be considered a relatively large family for an agile team.

How We Switched to Agile Development

The Prism Japan development team now works as a single team, but the frontend team and backend team used to work separately.

When we needed to coordinate work between the teams, we sent requests through a Slack channel. After we sent a request, it was left completely to the other team.

The jobs were divided because the departments were divided, and we had the following issues managing each team.

• Since the development process was not shared between the frontend and backend, there was no consensus between teams
• There was no improvement in the entire team across frontend and backend.
• Project Managers and remote members were less likely to have ownership because development proceeded on a request-to-work basis

When the initial development of Prism Japan was over, we discussed switching to a development method suitable for the improvement phase of the app.

When we considered development methods that could address the aforementioned issues, we quickly decided to switch to agile development, which allows users to flexibly change specifications while monitoring user reactions and is compatible with mobile apps.

There were experts in the teams, and we decided to adopt the Scrum method, which was very advantageous in terms of communication, which was one of the issues.

How We Set Up Scrum from Scratch

Not all of our team members had experience with Scrum. We needed to convey what Scrum was to our team members.

We started off by having our Scrum Master Koyama teach our teams about Scrum.

For more details, you can read Koyama's article below.

How an iOS Engineer Took Certified Scrum Master Training and Become a Scrum Master

Starting with a Study Session

When we decided that we wanted to develop using Scrum, we started by having a study session on Scrum. I think it was very useful.

All of the members were determined to start using Scrum, and they all learned the basics.

Setting Up Scrum Events

The week after the study session, we set up Scrum events. We were fumbling at first, so the Scrum Master and Product Owner took the lead in discussing what to do at each event.

First we did tasks like the following.

• We set up a two-week Sprint
• The Product Owner created a story
• Start a daily Scrum of 15 minutes every day
• Set up Sprint planning
• Set up Sprint reviews
• Set up Sprint retrospectives

The Scrum Master took the lead in setting up the above events and moderating them.

This article will not go into the details of the Scrum events, but we felt like we were actively taking a Scrum approach when we took concrete actions such as:

• the Scrum Master taking the lead in setting up events, and
• the Scrum Master and Product Owner working closely together to hold events

I found it important in the process to have a passionate Scrum Master pushing the team, along with a team willing to improve; especially during the initial stages when we were still finding our footing.

Team Building

Through Scrum development, I observed our team's gradual growth overtime.

Especially in the following areas:

• It became easier to discuss specifications
• Team members actively exchanged opinions regarding the functionalities of the app
• We can now practice Scrum without solely depending on the Scrum Master

I think this is a common experience for many organizations, but Scrum did not initially function effectively for us at the beginning.

The first month we formed a Scrum team, our Product Owner Saito and the Scrum Master Koyama played a central role in searching for ways to improve the team. It took about two months to use Scrum smoothly.

The Product Owner's Role and Concerns

In general, the role of the Product Owner in Scrum development is to manage the development requirements through a product backlog and maximize the value of the product by defining the development direction.

It’s a crucial role in Prism Japan as it is in many organizations, and a not an easy one to make tangible decisions to reach this vague concept that is to maximize the value of a product. At first, there were endless concerns over whether their decision was the correct one, or if the user really needed a certain functionality.

They took two decisive actions to address their issues, and as a result, they can now make decisions based on an established criteria.

Step ①: Redefine user issues that Prism Japan should solve

All Scrum team members took part in a workshop based on the Jobs Theory framework.

I won't go into the details of the theory, but this allowed us to define the essence of the value that Prism Japan should deliver to its users.

Step ②: Implementing data-driven decision making

Since our Product Owner has experience as a data engineer and data analyst, he designs user logs, visualizes application usage, and makes analyses based on problem hypotheses.

This made it possible for us to incorporate app-related issues into our development policies, while assessing the acceptance of released features by users.

The Story of An Issue with Scrum and How We Solved It

Finally, I will talk about an issue we had with developing with Scrum and how we solved it.

The Issue: the Product Owner and the engineers did not agree on what they wanted to do

When we first started developing with Scrum, we struggled to communicate requirements and specifications to each other accurately and at the right time. Various factors contributed to the challenges, including the delay in finalizing specific specifications until development started, or the fact that we relied on verbal coordination, leading to discrepancies in how each team member interpreted the information.

The Solution: Use sprint refinement and sprint planning

Courtesy is necessary for a good relationship, even with Scrum. Changing the timing and manner of the requests and properly incorporating them into the Scrum events was very effective.

Sprint Refinement

We also conducted Refinement sessions the week before each Sprint.

The Product Owner explains the User Story, agrees to the requirements, and makes a quick quote. The Product Owner has to decide on the User Story they want to address in the next sprint in advance.

Sprint Planning

Beginning by establishing the priority of User Stories and tasks, we then reach a consensus on the goals of each Sprint.

That ensures that the work is feasible in light of past performance, giving engineers accountability and confidence in what they are doing during the Sprint.

The Impact of Implementing Scrum

Although there were some minor issues using Scrum in the beginning, overall, it brought positive changes to the team. I will look back on what issues we had before we started using Scrum and what benefits it brought.

Since the development process was not shared between the frontend and backend teams, there was no cross-team consensus.

Now, we are able to understand what both parties are working on at the Daily Scrum.

In addition, during refinement, planning and other events, we had many discussions on backend implementation policy based on the requests from the frontend side, and we started development smoothly and avoided a lot of detailed rework.

There was a lack improvements that considered both frontend and backend aspects.

I think discussions have improved a lot since engineers participate in them with a sense of autonomy, responsibility, and desire to improve the app.

We now have discussions at the architecture level considering performance and future scalability, and we can organize things that we would not even discuss if the teams were divided.

Members who don’t work with Project Managers closely were less likely to have ownership because they developed on a per-request basis

Instead of working only on specific requests, as they work on User Stories, engineers now engage in consideration, discussions, and even proposals to devise the best approach for accomplishing tasks in the most effective manner. Not only did we improve the development, but I felt that many team members grew with each Sprint.

Conclusion

The development team and the planning/ operation team share a common purpose and work together to make improvements. I hope this article could serve as a reference for those who are developing with Agile Scrum development and those who are just starting!

Prism Japan was just released a little over a year ago, and since then, the app has experience growth and attracted an increasing number of members. Feel free to try the app and witness firsthand how it has evolved through our development system!

For those who want to try Prism Japan

You can install Prism Japan through the link below.

• iOS: App Store
• Android: Google Play