Agile

It has been over three months since I introduced Flow Metrics to my team. My team has changed their mindset when it comes to work. Today, I am going to discuss how I apply Flow Metrics to the team. Before implementing Flow Metrics, I created a spreadsheet and recorded all the Product Backlog Items (PBIs) created in 2023. Following Daniel Vacanti’s Flow Metrics for Scrum Team, the spreadsheet includes an Aging Work in Progress Chart, Cycle Time Scatterplot, and two Monte Carlo Simulations: “How Many” and “How Long.” I obtained the Service Level Expectation (SLE) for the Cycle Time. ...

Management loves measurements, especially those who work in traditional companies. When management wants to assess how much the team has improved after adopting Agile development, things like the Agile maturity model are usually presented to them. Everyone celebrates the results as the scores have improved from negative to positive after three months of hard work and dedication. Several years later, we revisited that team. Unfortunately, the team continues to practise the same things since we celebrated the improvement in Agile maturity. They continue practising what they learned, even if the industry has already abandoned some of the practices for years. They believe they are mature and that everything is going well. They refuse to change their current way of working. ...

Recently (and finally), I watched the film “Oppenheimer”. They won’t fear it until they understand it. And they won’t understand it until they’ve used it. — “Oppenheimer” (film) I don’t know whether it’s a quote from the real Oppenheimer or a creation from the movie, but this impressed me the most. Typically, we can’t change people’s minds directly. Often, they change because they realise that the change improves their lives. People often fail to realize the dangers of constantly staring at their phones on the street until they experience a vehicle collision. In the Agile world, people won’t understand the concepts we teach until they’ve tried them. ...

The Agile coach training programme at my company has reached its second half. One of the training objectives was to teach the Agile coaches about unit testing and code refactoring. Naturally, the coaching programme expects the trainees to subsequently coach their teams on the same topics. As a mentor to two new Agile coach trainees working in different teams, I often allow them to choose their approach and evaluate it later on. Both teams had no prior knowledge of unit testing and code refactoring. After learning the basic techniques, Trainee A decided to ask everyone to try writing unit tests themselves simultaneously. They would then share and discuss their work during Code Review. On the other hand, Trainee B dedicated all his time to working with a single developer, allowing others to continue working as they had been. Once that developer had grasped everything Trainee B knew, they would split up and work in pairs with the other two developers. ...

Last month, I wrote a blog post about why I have refrained from using Story Points and capacity estimation in my team since day one. I have been delving deeper into Kanban and immersing myself in the materials, and I have started implementing it. After introducing Kanban and Flow Metrics to my team, I received a lot of questions and feedback from them. Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system. There may be various ways to define value, including consideration of the needs of the customer, the end-user, the organization, and the environment, for example. ...

When I first practised Agile on my old team, one of the things I learned from the consultants was Story Points. Since then, it has been used in many product teams in my company. As all the teams use Scrum as the main framework, many colleagues even misunderstand Stories and Story Points as Scrum ideas. They’re actually from Extreme Programming. Stories Points were invented by Ron Jeffries, one of the three founders of Extreme Programming. They were invented to abstract from hours to complete an item. With the Fibonacci series, developers can easily say the bigger the Story Point is, the more complex the Product Backlog Item is, and the more uncertainty in developing the Product Backlog Item could be. Developers can use empiricism to vote for the size of a Product Backlog Item. With the aid of the velocity trend, they can select the Product Backlog Items into their Sprint Backlog. ...

I wrote a blog post in April on studying for Professional Scrum Master (PSM) II. Last week, I took the exam and scored 100%. PSM II was called Professional Scrum Practitioner (PSP) before 2016. After that, it was renamed PSM II to bridge the gap between PSM I and PSM III. This exam focuses on applying Scrum in the workplace, as evidenced by its old name. Without extensive experience working as a Scrum Master, this exam would be challenging. Luckily, I have over five years of experience working in all the Scrum accountabilities. ...

As a mentor of two new Scrum Masters working in teams with little to no knowledge of Scrum, I often face challenging questions. My usual reaction is not to give them a direct answer at first. During one of the lectures, an Agile coach emphasised having a 2-week Sprint. Perhaps his speech was very effective. Perhaps there are some misunderstandings. A mentee who had been working in a team that runs a 4-week Sprint asked me whether he should ask the team to change to a 2-week Sprint. I asked him why he wanted to change to a 2-week Sprint. ...

Recently, my company launched a training programme for new Agile coaches. As one of the members of the company’s Agile coaches, I’m responsible for teaching the candidates basic knowledge and assisting them in on-job training. It’s been 4 months since I passed PSM I and PSPO I. It’s time to refresh the knowledge I acquired during the exam preparation. I also wanted to test how much memory I left. Therefore, I took the initiative in presenting the introduction to Agile and Scrum. ...

Last month, I wrote a blog post about taking professional exams. My goal was to pass 2 certifications, Professional Scrum Master (PSM) I and Professional Scrum Product Owner (PSPO) I, at the end of the year. 18 days later, I completed the challenge. PSM and PSPO are the certificates offered by Scrum.org to validate the knowledge of the Scrum framework. The names are self-explanatory. PSM focuses on Scrum Masters who understand how to apply Scrum, and PSPO focuses on Product Owners who enable value creation and delivery. Both certifications consist of 3 levels. Level 1 covers the fundamental understanding. ...