Agile

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. ...

Values provide direction for a team’s work. Scrum consists of five values essential for a Scrum Team to succeed. As a Scrum Master, I often consider how practices support Scrum values, allowing us to align new initiatives with Scrum. Our mobbing experiment is still ongoing, which leads me to think about how mobbing supports Scrum Values. The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems. ...

In my passage about the myth of lengthy Scrum meetings two weeks ago, I mentioned that people often misinterpret the Scrum events and leave all the pre-Scrum meetings to exist. Code review is a common practice in many software development teams nowadays. There are various styles of code review, each serving different purposes. In traditional development teams, the developer submits their code to the source control, and a more experienced developer checks the code quality and logic before approving it for deployment. However, this process has been largely replaced by continuous integration tools like SonarQube. ...

More teams within my company have been adopting the Scrum framework to enhance their product development process. Occasionally, I have the opportunity to engage in conversations with the developers and Scrum Masters from these teams. Among the various comments and discussions about Scrum, the most common issue raised is the abundance of lengthy meetings. Their managers complain that their teams are spending more time in meetings since implementing Scrum. However, is this issue truly caused by Scrum? When I presented my team’s weekly calendar to them, they were astonished by its brevity and simplicity. ...

As a Scrum Master of the team, I often raise questions to stimulate the team’s discussion and improve their understanding of Scrum and other frameworks or practices we use. “It’s Thursday and the fourth day of our 5-day Sprint,” I said, “If I pull a Product Backlog Item from the Backlog, I have to finish it by tomorrow, or else the Work Item Age will be increased by 2. Should I pull it or slice it to guarantee I can finish it by tomorrow?” ...

Several weeks ago, there was a meetup at my company, targeting Scrum Masters to share their experience with their teams. A Scrum Master shared how several Scrum teams within his area work. “Let me give you some advice,” said one of the attendees, “You should do blah blah blah…” After the attendee’s advice, the presenting Scrum Master immediately denied the advice and explained a lot. Tension built up. The debate, filled with “No, I mean…”, lasted several minutes until the facilitator stepped in to end it. ...

Every system operates under specific conditions, including Kanban with Flow Metrics. Of the 4 Flow Metrics, it is important to understand that Kanban with Flow Metrics is supported by Little’s Law. Little’s Law states that the average number of customers in a stable system is equal to the average arrival rate multiplied by the average time a customer spends in the system. To uphold Little’s Law, the system must be in a steady-state condition. ...

Last time, I described how my team applies Flow Metrics with Scrum. Although we don’t often estimate the short-term delivery, we are sometimes asked when a big feature will be completed. In the Story Points era, we used Story Points and calculated the average velocity of the previous 3 to 5 sprints for forecasting. In theory, averaging is the easiest way to forecast. However, in reality, unexpected situations may arise. For example, someone may call in sick, there may be a public holiday in the middle of the Sprint, or a PBI may be blocked by external parties. It is easy to fall into the trap of relying solely on averages, resulting in an unrealistic forecast. Moreover, communicating Story Points to stakeholders can be challenging due to their inherent ambiguity. In such situations, Monte Carlo Simulation comes into play. ...