Scrum is Fum

So, I was an intern at one of the growing finance company and learnt so much about scrum there, and as expected, the software engineering project that we were working on this semester also uses this method. I’m really glad to be the first scrum master as I really am inspired by one of my team leader, who lead us through sprints back in my internship several months ago.

Here, I learnt more about scrum and being a scrum master 🙏. Okay, enough flex. Because flexing too much can cause your friends to be ill with you! hehe. Instead, let’s talk about scrum and how to gain the scrap out of it.

W.. W…. What are THOSEE!!!

There are several terminologies in scrum that you must know, some of them are

• Product owner, this is the one guy who knows what product the team is going to deliver. In my project, the product owner is the client partner who assigned this project to us.
• Scrum master, the one who leads the team and guide them to ensure the agile and scrum practices and principles are being followed.
• User Story, user story are just basically tasks, this is what we call a certain feature. Sometimes features can be separated in implementation, but sometimes tasks are monolithic, if the user story is too big, it can be separated into several Issues that can later be assigned to people.
• Epic User Story this is just the bigger picture of the user story, this sometimes can be included into a milestone.
• Initiative, a certain features can be grouped into releases after several sprints.
• Release, Deployable software package
• Sprint, is an iteration usually conducted from one to four weeks long, depending on how large the team is and how big is the plan.

So, in my software engineering project, the product owner is Mr. Tirmidzi. He is nice and good at delivering things.

The scrum master is me! For the first week, I think I can do it.

This is one of the epic user story which consists of several user story. This is the examples of initiatives made in our PRD.

I Know Agility in DOTA 2, But What About This Kind of Agile

Agile is an approach in software development, while scrum itself a technique and like the framework for agile itself. So you doesn’t have to use scrum to work in agile approach. So, agile is needed because requirements are changing. Sometimes features are being removed and being added, because our planning was not that good. But yes, there will still be a planning reference document 📑.

In the same time, that document can change in a certain period of developing the app. Then, the developers should adapt and the changes should be done while developing. It’s possible that the feature that being changed is the one who is developed by the team. Yet, they have to adjust so the codes should go under the changes of the requirements 🙏.

This feels OK, because in a world like this, we never know about new technologies and requirements, the old sequential planning and coding patterns are too old and it just doesn’t work anymore.

Beside scrum, there are kanban, feture driven development, extreme programming, and many more.

This approach has several advantages. Those are:

• It’s easier to track the progress and there is a real standard for the product owner to judge whether the requirements are satisfied or not.
• Each sprint will have a proof of work and is a part of the final product.

The scrum framework chart, acquired from scrum.org.

Well, we have already planned the features of our releases in our PRD, there are somethings called product backlog who is filled by the product owner and/or the stakeholders 🦄, then me as a scrum master picked some of those story from the backlog, that will be inserted into our sprint backlog 🎶. I separate the issue into two milestones, the transaction part of our app, and the initialization part. We separate it into labels and tags. In the sprint planning session we discussed and voted on how many sprint points so we assign a task with 🙏.

Then, we also discuss who should take each tasks. Well, in this case I take some of the easier part which is handling the registration UI, setting up more on CI/CD and linter, also setting up the QR page for the transaction🍃.

In the mean time, we also held some standup meetings to report our progresses with each other 🐭.

After several days of implementing, we did a sprint review. Thank god, all the issues are finished. Even though the burndown chart is not really good too see. HAHHAHA 😂.

Next, we demoed the release APK, and the product owner is quite happy with it. We also did a sprint retrospective, which is to review the stuffs that we’ve done in several days back (in the sprint). We uses the sticky note app to note 4 things, that is the Good, Bad, Start, and Stop 🤚.

Next, we noted some good points, that maybe you can take a look at:

• Fix more tasks, the assignee for each issue is imbalanced, Eko worked too much.
• Story points are too biased and wrong
• Stop taking other people’s works/stuffs
• Current MR review sucks
• No review is done because of deadline
• Strict code review should be done
• Wanna consider TDD more? Because currently our TDD is fake too comply with the grading requirements. All of us are not fluent with the testing framework
• Consider functional practice, design pattern, architerctural design
• Comments should be resolved ASAP, not to postpone.
• Functional integration of cryptocurrency are quite difficult, not all member understand
• Sprint 1 is kinda monolithic and depends on Eko, making the crypto connector, setting up the Async storage, the tests are hideous.
• Code and knowledge sharing session should be held to introduce idea to each other.
• should we held meeting? Explaining the past codes? We are too busy as a student!

Evaluating Scrum, Adultness, Le Maturity!

Now, there is another metrics that’s should be consiered in the end part of the sprint. That is scrum maturity and sprint velocity. Velocity is the “speed” of work a team can do during a single sprint and truly a key metric in Scrum, you can check this out in the burndown chart 🔥.

It is being used to monitor the speed of a team, and with that we can find the problems that makes the team slow?. There are a lot of templates, indicators sheet used to review your scrum, for example: https://www.smartsheet.com/content/agile-maturity-templates 🧓

There are several aspects on how we approach this thing:

• What kind of a enviromental improvement we can bring into the development team? What things should you change between each member of the developing team 💘
• What kind of outcomes we are making and generating because of our scrum 🙊
• How predictable our delivery is 🚚, is everything on point? Is everything according to plan? By the end of the sprints, are the Product backlog items being done implemented? Are there any stuffs your team are carrying into the next sprint?

Take a look at this:

Here are the example sheet of the indicator we’re measuring during our sprint assessment. These metrics should be assessed properly, you should check which are not “TRUE” yet, and you should discuss with your team, on what should you improve!

How do you measure maturity of an adult?

Well me, sometimes I see them based on their behavior and how they react to certain things. In my opinion, an adult should have:

• Self control
• Environment attention, meaning they should know how to act properly with others under different circumstances
• Sure, this process takes not one day, one week, but can take a whole period to know how mature they are based on their behavior.

Now, in a scrum team if there are a lot of problems in your scrum team, sometimes it should show clearly. For example, in my old scrum period:

• It’s a course project based, so deadline pressure are higher than usual sprints. We’re chasing our deadline more angrier than ever 😡.

In the end, you don’t really measure a scrum maturity, you should determine the metrics, indicators, and based on that, we should know what should we improve. But yes, it will revolve around the team’s ability to deliver, inovate, understand the value they’re delivering and to really understand how they improve and be productive working together 👪.

Maturity is very judgemental and subjective, it’s often interchange with effectiveness, but yes, it’s more internal and each scrum team has different opinions on maturity. It has no standard, but one of the main metrics to see how mature a team professionaly is indeed by evaluating some of the works being done, and stuffs being done ✅.

That’s it!