Tag Archives: agile coach

How To Unleash The Benefit From Daily Scrum (Part 2)

THE TEAM DIDN’T COMMIT TO THE SCHEDULE

Note: please visit the Part 1 article here to get the context.

First thing first, let’s double-check are all team members aware of the schedule? And are all team members have agreed to the schedule?.

If the answer is no, you know what you should do, right?

  1. Make a consensus
  2. Make the consensus explicit (i borrow Kanban practices here, make policies explicit)

If the answer is yes, it’s time to make a regular reflection.

  1. What makes it difficult to follow the agreement/schedule

Please note that you have to put your empathy above everything when conducting the session. Do not put any judgment on your team member. Make the session safe for them to emphasize their difficulties.

I believe the way you solve it must be custom based on the case shared by the team. Meanwhile, I hope these myths of daily scrum didn’t arrive at the answer:

The schedule is too early (morning), so I can’t catch up with the schedule.

Answer: No one said that our daily scrum must be done in the morning. Even the Scrum guide doesn’t say so. Even though there’s some benefit if we do it in the early morning, that doesn’t mean we have to. Daily scrum will only benefit if everyone can contribute to the problem resolution and be aware of the adjusted delivery strategy.

I hate to stand up only for the meeting.

Answer: No one said that our daily scrum must be done in a stand-up position. Even the Scrum guide doesn’t say so. You can do it in sit-down, while having a push-up, sit-up, or in any body position that makes you comfortable.

The event doesn’t make any sense because we always sync every time.

Answer: Wow, it would be even better! We believe some of us don’t have that luxury. It could be because some team members are not working at the same location as the others, the type of work has a considerable risk from context switching, etc. The daily scrum is just how the Scrum framework helps us establish the habit. Once it’s established, we will feel it as the way of working, not a meeting. It becomes the need instead of the ceremonies.

I have so many meetings already, only 15 minutes, and I have to join offline? It doesn’t make any sense.

Answer: Daily scrum doesn’t need offline participation instead of active participation. It means we can do asynchronous communication (such as chat or e-mail) or synchronous communication (such as call) to share the problem, discuss the problem-solving, and do action items generation.

Please refer to my Part 1 article to find out the essential things to be shared during the daily scrum.

This is the end of Part 2. Feel free to put any comments or feedback regarding this article. See you in Part 3!

How To Unleash The Benefit From Daily Scrum (Part 1)

How often have you found a useless daily huddle, daily stand up, sync up whatsoever you can call it?

How do you feel about it?

If you expect to find what is the best way to do daily scrum in this article, sorry, it won’t be explained here because there are no such things as best practices!. Let me re-highlight again: THERE’S NO BEST WAY TO DO IT.

But let me help you to find some areas of improvement.

Here are some usual symptoms that are causing your feeling above:

  1. Timing issue
    1. It took so much of our time
    2. The team didn’t commit to the schedule
  2. Facilitating issue
    1. No clear output and outcome from the conversation

IT TOOK SO MUCH OF OUR TIME

I don’t mean to be a preacher of Scrum guide, but in reality, we can do it in less than 15 minutes, seriously, for real. If you find your last daily scrum took more than that, the first thing you can do is learn about the historical event by (1) recording your daily scrum session & (2) re-hearing/re-watching the session.

Then counting the duration of:

  1. Problem explanation
  2. Problem-solving discussion
  3. Action items generation
  4. Others

The first element that we definitely can remove is (4) Others.

The only thing we should keep is (3) Action items generation.

What if (1) Problem explanation took so much time? Here are some ideas that you can play around with:

  1. Be prepared by summarizing your explanation
  2. Only highlighting information that is relevant to others
  3. Postponed the explanation as an action items

What if (2) Problem-solving discussion took so much time? See below other ideas:

  1. First thing first, be brave to cut off the discussion
  2. Postponed the problem solving as an action item

Focusing only on action item generation could save each other time. We only involve relevant people in discussion while still keeping the overall essential issues during the day.

And the most important thing is to put in our mindset that it is okay not to solve everything in 15 minutes. We only have to keep our attitude to adapt your delivery strategy as soon as the problem comes.

Here’s the end of Part 1. Feel free to put any comments or feedback regarding this article.

I’ll see you again in the next part.

TWIL – Ep.2

Another episode of This Week I Learn (TWIL).

This is an “aha” moment with Ashish Kumar during Agile Product Ownership class by ICAgile & Agile Visa (Training, Coaching & Consulting)

Product ownership must be focusing on 3 elements:

1. Business: customer, market, competition, etc

2. Organisation: ROI, cost per employee, growth, etc

3. Knowledge/people

I assume points 1 & 2 are already straightforward, aren’t they?. Then why there’s a point 3??

Maximizing the value of the product will lead to the increasing value of the company or organization, agree?. Then, is the product having the ability to doing self-improvement? of course no. Who can do it? the people behind it. The more knowledge they have, the more chance they can win the competition.

People tend to forget that improving people’s knowledge = increasing the asset of the organization. Increasing the asset of the organization can lead to the increasing value of the company and organization.

So, is your team still afraid to doing a re-write? or moving into the latest technology stack?, of course, we shouldn’t forget to calculate the “investment” (need to explore more about this).

Multiple Team and Multiple Project/Product in JIRA

Yesterday, i read a beautiful article from : Healthy Team Backlogs.

It’s all about how to make, organize, and manage our product backlog in a beautiful way. Honestly, it’s really helpful. You can implement some practices there. Let’s read that article then experiment it to your team.

But there’s a question from  in his article that quite makes me interested:

Scrum most commonly uses the term product backlog. However, many product owners who are new to Scrum are confused by this term. Reasonable questions arise: Does this suggest that a team working on multiple products would have multiple backlogs? If so, how do we prioritize between them? Where do bugs get recorded? What happens if work needs to be done, but it isn’t associated with a product; do we create a placeholder?

In this article i’m trying to answer that question in a summary. And my answer is: by using JIRA, how?

  • First, let me explain 2 most important entity in JIRA: Project and Board.
    1. Project is group of several backlog that is grouped based on similarity (based on the author purpose).
    – Similarity is subjective. It can be based on team, theme, mission, KPI, etc.
    – Due to support this article purpose, i put project as a group of several backlog that has similarity: contribute to one product.

    Project not associated with board

    2. Board is place to visualize our project.

    Project that visualized by the board (DEMO board)

    – Relation between Project and Board is many to many (m-n), so: one project is able to connect with several boards, several project are able to connect with one board, etc. (i’ll explain about this later, let’s continue!).

  • Second, let’s create 2 different project that represent 2 different product.
    – In this example, i created DEMO-1 and DEMO-2, let’s assume DEMO-1 & DEMO-2 are different product that our (full) tech-product team working on.

    Example of project

  • Third, create several backlog for each project.
    – To make it more likely a real backlog, we can put an epic to represent every each product (represent by project) has prioritized epic.

    Project DEMO-1, please do the same to DEMO-2

Then, let’s answer ‘s question one by one..

  • Does this suggest that a team working on multiple products would have multiple backlogs?
    Yes, multiple product can be represented by multiple project in JIRA. In this example: DEMO-1 and DEMO-2.
  • How do we prioritize between them?
    By using filter on the board:
    – Let’s create 1 board that visualized our team board. In this example, i named the team as “DEMO”. So, i create “DEMO Team”.

    Create a board

    – Choose what’s project source of the board that we want to visualized. In this example, we choose “based on an existing project” since we already have the project (DEMO-1 & DEMO-2).

    Choose the source of the board

    – Put board name as DEMO Team (our team name) then put DEMO-1 & DEMO-2 as our combination of 2 project (product) that we want to visualized.

    Let’s name the board!

    Ta da! we’ll see board that contain both product backlog (from 2 different product) that we will be working on!

    Let’s prioritized!

    So, currently we’re able to prioritized between this combination of product backlog.

    Then, how to differentiate between which one is backlog from DEMO-1 and DEMO-2?
    – Actually each project has a key that you can setup when you created a new project. In this example, i put “DEMO1” as a key for backlog from DEMO-1 and “DEMO2” as a key for backlog from DEMO-2.

    Setup a key for every project

    DEMO1 & DEMO2

  • Where do bugs get recorded?
    Before answer this question, i assume when the bugs is coming we easily to define the bug is coming from which product. So, for example the bug is coming from product DEMO-1. Then, yeah we just create a new bug that tight to DEMO-1 project.

    Create [BUG] DEMO G

    Board will also showing combination of each product (project) bug on the backlog, similar with the other backlog. Then, we are also able to set the bug priority and prioritize it along with the other backlog.

    Let’s prioritize the bug!

Finished!

Hope this article will help you to setup your JIRA for your team. I’ll share how HappyFresh tech-product team process in bug handling in the different article.

Here’s Atlassian documentation if you want to learn more.

See you!