How We Utilized Scrum Framework to Build Tryhards - A Web3 Project

We launched the MVP of TryHards in October and have been working on developing it further ever since. The development process was full of new challenges and experiences. That's why we decided to share some details on how we built the Tryhards web3 project using Scrum Framework.

Before we dive into the project execution, we should outline the context:

First of all, when we started engaging with the Tryhards blockchain project, the client had already had an established idea about the concept of the product and had created Figma designs for the MVP of a decentralized application.

Secondly, unlike the traditional software development process, our team didn't have just one technical lead orchestrating all the tasks. Instead, we had a multifaceted team with different competencies that created the needed synergy to execute the individual aspects of this project and integrate them.

Finally, the extraordinary thing about this project is that Tryhards is three-sided. While all classical Softwares are two-sided with backend and front-end parts, Tryhards has a third side - Blockchain technology which has its distinctive technical stack and requires a specific approach to the development process.

Okay, now we are ready to dive into it. This article will further discuss the main challenges during the product development process, including how we managed to organize sprints, facilitate collaboration within the development team, and manage the project.

 

Organizing Sprints And Dividing Responsibilities Between The Team Members

It was very comfortable for us to start the Tryhards project development process using the Scrum framework. We decided to have one-week sprints because there was a high frequency of requirements changes, and we needed to be highly flexible.

Here is what the Sprint ceremonies looked like:

• We had 15-30 min team stand-up meetings every day.
• Every Tuesday, we had backlog grooming with PO, senior backend dev, front-end dev & blockchain dev lead with our project manager. In these meetings, the team went over the list that everyone had contributed to during the previous week, discussed the issues gathered there, assessed each task according to the impact & effort principle, and distilled the prioritized list of jobs for the upcoming sprint.
• Every Wednesday, the team met for the review session. The review included showing the completed work to the client and getting actionable feedback.
• After the review session, we were planning a new sprint.

We prioritized backlog so that the low-effort & high-impact tasks were selected for the sprint over the high-effort & low-impact tasks.

We also used Scrum Poker during the sprint planning process. Scrum Poker is a consensus framework for estimating the complexity of tasks in a sprint with story points. With that technique, each development team member assesses task complexity independently, and then the team discusses differences between estimates of different members. As a result, Scrum Poker helped us measure team velocity and plan future sprints better. Also, Scrum Poker helped identify which story/task should be assigned to whom during the sprint.

The Main Challenges During The Product Development Process

Like in every other blockchain project, the main challenge was that there was not a single person in the team with a high level of experience in every aspect of the project. In traditional software projects, there is always a team leader responsible for monitoring every part of the team's work.

Blockchain is a new technology that requires a different approach to the development process. Therefore, it is rare to find one person who will have the ability to manage the whole web3 project development process. Luckily, our team members had complementary backgrounds. In addition, they were super proactive in trying to fill in those gaps.
The other challenge we faced during the Tryhards Blockchain project was its architecture. Two projects were active simultaneously, which included

1. Developing smart contracts
2. Creating a web app for the product and integrating it with blockchain (Polygon network).

Given the nature of smart contracts, we couldn't use Scrum on that side. Once the smart contract is deployed on the blockchain, you cannot push further updates to it. That's why developing smart contracts resembles more a waterfall process than agile. Managing two projects simultaneously made the communication between the two teams a bit challenging. Luckily, we had a very competent crew and efficiently worked around this challenge in the Tryhards project. However, that's a critical point to consider while developing a Blockchain technology project.

 

Collaborating With The Development Team

While discussing collaboration with the development team, it's noteworthy that creating the Tryhards project was a fully remote process. The team members were working from home (mainly in Georgia) while the product owner attended the meeting from the Netherlands.

Slack was the primary workplace for the project team members, and the whole team used it exceptionally proactively. This type of communication mindset has various advantages:

• Information is centralized in one space (ironically)
• Information is available for everyone
• Everyone is aware of the current challenges and solutions
• Team members know all about the development process
• It creates a bond between team members

Even though the Tryhards project development process was entirely remote, the team was tight. Facilitating effective communication was our key focus, and it proved critical for boosting team motivation, effectiveness, and efficiency.

On top of that, daily meetings throughout the week made it easier for team members to exchange ideas and information and solve existing problems successfully.

 

Things We Would Have Done Differently

Even though we overcame many challenges during the Tryhards web3 application development process, there still were several things that we wished we had done differently.

First of all, since we were running waterfall and Scrum projects simultaneously, we might have been better off with more frequent integrations between the two teams' deliverables. So, as they say, if we had to fail, we would do it faster. However, the challenge was that developing one smart contract spanned over a few sprints, which often overlapped with mid-sprint, so we had to make room for integration tasks in the sprint.

Lastly, it would have been better to have a more streamlined communication with the marketing team. So many of the backlog topics come from the feedback a product gets from the community; it could have created a nice loop for us to discuss the feedback with the stakeholders and prioritize the backlog accordingly.

Overall, working on Tryhards was an excellent experience, and even though we had some challenges here and there, it was definitely worth the time and effort!

 

Written by Keti Getiashvili

Based on an interview with Paata Kikilashvili