KINTO Tech Blog
Agile

How an iOS Engineer Became a Certified Scrum Master

Cover Image for How an iOS Engineer Became a Certified Scrum Master

Hello.

My name is Koyama from KINTO Technologies. I work on mobile app development and maintenance. I am an iOS engineer.

Last time, I wrote an article focusing on iOS development, titled(Using Combine to Achieve MVVM). This time, I’ll be focusing on the Agile development practices we use at our development site.

In the team I’ve been part of for a while, we follow Agile development with the Scrum framework. I was asked whether I wish to try being a Scrum Master, so I would like to share my experience.

*This post is part of an ongoing series exploring Agile.
We have faced various challenges and difficulties in our quest to become Agile as an organization.

Although there have been failures at times, we have continued to grow steadily.
In this series of articles, I would like to introduce some of our actual efforts.

Why Did I Take the Scrum Master Training?

I had worked with Scrum in previous projects as well, but always in a developer role. I had never acted as a Scrum Master before, so I felt anxious about taking on the role. Then, I learned that there was a Scrum Master training course available, so I decided to take it. This time, I took the Certified Scrum Master training course hosted by Attractor Inc.

My Development Team

Let me introduce the development team I belong to.

Structure and Roles

  • Product Owner
  • Team Leader
  • Backend Development Team
  • Frontend Development Team
    • iOS Development Team ← I am here now
    • Android Development Team
  • QA
  • Designer

In mobile app development, it is not uncommon for the frontend development team to split into two teams like this. This time I was going to be a Scrum Master, and the structure was expected to be as follows:

  • Product Owner
  • Backend Development Team
    • Scrum Master (Team Leader)
  • Frontend Development Team
    • Scrum Master ← I was supposed to be 50% responsible
    • iOS Development Team ← I was supposed to be 50% responsible
    • Android Development Team
  • QA
  • Designer

Since the team leader had a background in backend development, the plan was for him to act as the Scrum Master for the backend, while I would handle the frontend. In hindsight, it was a rather unusual arrangement. But at the time, I didn’t recognize that—and even if I had, I wasn’t in a position to voice it confidently.

Challenges in the Existing Team Development

Of course, since we had been proceeding with Agile development up until then, we had many questions and challenges when using Scrum.

  • What should we do if our development team exceeds 10 people?
  • We are carrying out various sprint events by separating them into backend and frontend, but is it OK?
  • The level of understanding of Scrum varies among the team members.

And so on…

I attended the training hoping to resolve these issues.

Taking on the Training!

Training Overview

The Scrum Master training consisted of a three-day curriculum and was held online every day from 1:00 pm to 6:00 pm. After that, you can take the exam at any time. Upon passing, you can obtain the Certified Scrum Master qualification issued by the Scrum Alliance.

The breakdown of the three-day training was as follows:

  • Day 1: Lectures on Agile and Scrum
  • Day 2: Hands-on Scrum practice
  • Day 3: Lecture and hands-on practice on the Scrum Master

You can read about Agile and Scrum in books or online, but the lectures explained the concepts in a much clearer and more understandable way. I was able to relearn the principles and mindsets that I had almost forgotten, and I was able to ask the instructors any questions I had, allowing me to solidify my knowledge in a practical format. It was a very meaningful experience.

What Changed after the Training

Anyway,

I gained confidence

That’s what it all comes down to.

One absolute requirement for a Scrum Master is to provide guidance on Scrum. With what I had learned up to that point, I couldn’t completely clear up my doubts and often found myself thinking, “This is what the book says, but it doesn’t quite match reality.” Even though I understood the principles, I didn’t feel confident enough to share or promote them within my team.

Taking the training cleared up all the questions I had, and the reassurance of being taught by a renowned instructor, who has even published books on Scrum, gave me confidence. I was also able to obtain the Certified Scrum Master qualification, which further reinforced my confidence.

What I Tried after the Training

Gaining the Product Owner’s Understanding

During the training, I discovered that my team was using a number of techniques known as anti-patterns. So I began by explaining to the Product Owner what anti-patterns are and why certain practices we were following fit into that category.

Since changing everything at once would be difficult, we decided to start with the more straightforward areas. The team agreed to begin by reevaluating how we manage the backlog.

Sharing the Training with Team Members

Agile development requires the entire team to be on the same page. I think this is a very important aspect of moving forward with Agile. Even if we were to start by changing the way we manage the backlog, we first needed to unify our understanding.

To achieve this, I created new documents for internal sharing and held group training sessions the week after the training. I was able to do this just because I gained confidence from the training. Materials for internal sharing From the team members, I received feedback such as "I realized we had been unknowingly doing anti-patterns" and "I'm glad you shared this immediately after the training!" To be honest, creating the documents and conducting the group training was quite a challenge, but I'm glad I did it.

Implementing Improvements

To improve our approach to backlog management, I outlined the current issues and the desired state, then began applying those changes starting with the next backlog refinement session. All of this was accomplished in just one week after completing the training. The reason we were able to get this far, even though I was still fresh from the training, was thanks to the product owner’s and development team’s understanding. Materials explaining the improvements we wanted to make

What Happened to Our System?

Sharing the training content with the team went smoothly, but that’s when a new issue came up.

It turned out that our team leader had to go on parental leave suddenly.

Our company has a parental leave system (for men as well, of course), and the whole team wanted to support child-rearing, so we were happy to send him off. However, it seems that I need to support this big project (in terms of number of members) as the Scrum Master. Oh no! So, the restructured system is as follows:

  • Product Owner
  • Scrum Master ← I was supposed to be 50% responsible
  • Backend Development Team
  • Frontend Development Team
    • iOS Development Team ← I was supposed to be 50% responsible
    • Android Development Team
  • QA
  • Designer

The reason for the earlier statement, "Looking back now, I feel that we had come up with a strange structure," is that a single Scrum Master is generally sufficient for a team in the first place.

Having separate Scrum Masters—one focused on the backend and the other on the frontend—doesn’t seem to align with the original purpose of the Scrum Master role. There’s a concern that this kind of division could result in Scrum Masters being Scrum Masters in name only, functioning more like team leads.

Additionally, the initial team split between backend and frontend naturally required cross-team communication, leading to the challenge of needing someone to serve as a bridge. Furthermore, there was a likelihood that the burden on the bridge member may become very heavy, so I believe that consolidating them into one team at this time was actually a good move, considering future developments (see below).

What We Want to Do in the Future

Our immediate goal is to continue updating our development team, starting with the improvements mentioned above. Once we are able to run Scrum smoothly, we would like to try splitting our team into feature teams. This will solve all the team challenges we originally faced.

In the long term, I would also like to work with other Scrum Masters within the company to spread Agile development using Scrum. Once we've helped them reach a point where they can operate smoothly, we can shift our support to other teams. As Scrum adoption grows, we’ll be able to contribute more effectively to building better products.

Conclusion

This concludes my experience with the Scrum Master training. Anyway, there are many benefits, so if you are reading this and struggling to make Scrum work well, I encourage you to consider taking the training. The training fee is relatively high, which makes it hard for individuals to take it on their own. However, I believe it includes enough value to justify asking your company or manager to cover the cost.

Personally, I think the biggest point of Agile development using Scrum is that each team has different practices. Other companies' practices may not necessarily be applicable to your company. Exploring different ways of doing things can be difficult, but it may actually be the most fun part.

Facebook

関連記事 | Related Posts

We are hiring!

【QAエンジニア】QAG/東京・大阪・福岡

QAグループについて QAグループでは、自社サービスである『KINTO』サービスサイトをはじめ、提供する各種サービスにおいて、リリース前の品質保証、およびサービス品質の向上に向けたQA業務を行なっております。QAグループはまだ成⾧途中の組織ですが、テスト管理ツールの導入や自動化の一部導入など、QAプロセスの最適化に向けて、積極的な取り組みを行っています。

【ITビジネスアナリスト】/業務システム開発部/名古屋

業務システム開発部について業務システム開発部は、KINTOの事業運営に必要なシステムを開発し、その運用を統合的に管理することで、効率的な体制を構築している組織です。部門のミッションは、複数のプロダクト間での業務プロセスの整合性を担保しつつ、KINTO全体の業務プロセスの最適化、高度化を担うことです。

イベント情報