Scrum

In May, my girlfriend and I start preparing to move to the UK. Moving out is challenging, especially when moving to another side of the world. It involves numerous tasks. One day, my girlfriend complained about my working style. It lacked transparency – she could not understand my progress or our plan. “You have been a project manager / Scrum Master for a long time,” said my friend during our video chat, “It’s time for you to apply your PM skills in this life project.” Indeed, I tried many skills and techniques while I was working at the office. Life is also one of the “products”. Those techniques might work in managing my life. ...

Last time, I wrote about how I started the Scrum Team without stressing the Scrum terms. After the preparation before everything begins, it’s time to start our development cycle. Daily Scrum Our Daily Scrum is similar to the standard one. Apart from developers, our manager also attends the Daily Scrum. Some might argue against the existence of the managers in the Daily Scrum. The Scrum Guide states that Daily Scrum is an event for Developers, but it isn’t meant to disallow managers’ existence. ...

Returning to the time I was told by my team manager I was going to form a new team to work on a new product, I’ve never thought that in almost 4 years, my team has grown and sustained in a way different than other teams in the company. When I was in my previous team, many people struggled using Scrum. People are obsessed with Story Pointing. Some team members refused to attend the Sprint Review and Retrospective. Everyone works without a clear goal but only emptying the backlog and fighting the deadlines. Arguments like Code Refactoring versus meeting the deadlines and estimation versus actual were everywhere. There were times that I doubted if Scrum brought us a tough time. There were times that I almost wanted to quit the job due to the burnout. ...

“Have you ever read the Scrum Guide?”

Adopting Story Points as a measurement tool is now one of the anti-patterns in the Scrum world nowadays. However, many product teams are still using this. The majority of them, even worse, emphasise the accuracy of their plan by comparing the estimated story points with the actual completed story points. They’re afraid of carrying over the unfinished Product Backlog Items and upsetting the stakeholders. The more time the team spends in planning, the less time they can work on the actual items. Their overplanning creates an illusion that they know everything about the upcoming Sprint. When it deviates, they feel nervous and only think of fulfilling the estimated story points. In the next Sprint, they put even more effort into planning. ...

In traditional software development, a business analyst is responsible for gathering the users’ requirements, translating them into other formats like requirement specifications or user stories, and requesting the developers to commence the development work. When a team adopts Scrum, they often feel unsure of where to start. In most cases, the business analyst will assume the role of the Product Owner. This decision is based on the intuitive similarity between the responsibilities of a business analyst and those of a Product Owner. ...

Several years ago, I participated as an observer in a Sprint Retrospective of a team. The Scrum Master facilitated the event with beautiful drawings to encourage active participation from the attendees. The Sprint Retrospective ran smoothly. They gathered the data, generated insights and decided what to do. In the subsequent Sprint Retrospective, the Scrum Master introduced a Mario Kart theme as part of the facilitation process. The event, again, ran smoothly. The Scrum Master reviewed that facilitation was successful and decided to keep applying the fun elements during the Sprint Retrospective. However, when I revisited the team several months later, the team barely kept the “fun” style, and the attendees were not energetic anymore. ...

As a Scrum Master, I often have new ideas about the tune-up of a team. I further develop the ideas by reading books, listening to podcast channels, and working with the developers on actionable practices. As an Agile coach in a company with over 20 Scrum Masters, I occasionally present and discuss new ideas. If my idea is too controversial or niche to the Scrum Masters, half of them will feel uncomfortable and refuse to listen to my ideas. ...

In 2020, the Scrum Guide changed “Scrum Roles” to “Scrum Accountabilities”. This implies that a member of a Scrum Team is not tied to a role. A Scrum Team member takes accountability to work towards the same Product Goal. It also implies that a single member may take multiple Scrum Accountabilities. But is it recommended? Despite the influential people at Scrum.org not recommending us to take multiple Scrum Accountabilities, I had no choice but to take all three accountabilities since my team’s establishment. The team works quite smoothly most of the time, but there are unnoticed risks. ...

Last year, whilst preparing for the Scrum.org certification series, I often encountered questions regarding the unavailability of the Product Owner. The effectiveness of the Scrum Team can indeed be affected when the Product Owner is absent. What if the Product Owner is always available? Would it have an impact on the team’s effectiveness? What should the Scrum Team do when the Product Owner is unavailable? As a team member with multiple accountabilities, I take on the accountabilities of both Scrum Master and Product Owner simultaneously (and occasionally even a Developer when urgently required). Influenced by and misunderstanding the implications of the questions regarding the Product Owner’s unavailability, I initially made myself as available as possible during the early stages. Whenever the developers needed clarification, I would always be there to ensure that all Product Backlog Items were transparent and well understood. ...