Category Archives: Scrum

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

TWIL – Ep.1

I’m starting to write This Week I Learn (TWIL) in the spirit of continuous improvement. I hope it helps me remember how far I go and get feedback on my thought; even better, it allows you not to be trapped on similar mistakes.

As a #coach, I just realized we often face the unideal situation. Some of our co-workers left the company, and I need to keep the team engaged and continue to run the business.

This week I learn that just supporting the team in this condition with just literally saying “come on guys,” “what can I help,” etc., sounds/feels useless. We need to change our uniform from a coach to an enabler: “so, what should I do?” “how to make this happen?” etc.

It’s a different spirit.

I know there will be a judgment: “No, as a coach, you have to make your team able to do the task by themself (self-organized).”

Yes, I know it. But I think the most important thing, in the beginning, is to fulfill the team’s needs first. Along the way, then we can start to delegate the task one by one.

Just my thought, do you have any other better idea?

Scrum Day Bandung 2018 – Session’s Material

Dear Scrum enthusiast,

Here’s my session’s slide on Scrum Day Bandung 2018:

  1. Busting The Myth: Scrum Has Too Many Meetings
  2. How Tools Helps Your Scrum Team

PS: I don’t guarantee you’ll understand the context. But don’t worry, I’ll share the recap on the different articles, so don’t miss it! i’ll let you know once it get published.

Thank you and see you around!

Design Sprint Meet Scrum – Scrum Jakarta (CiKemPon) 3rd Meetup

Group photo after the meetup

Hello Scrum enthusiast in Cilandak – Kemang – Pondok Indah – (and around) area!
Thank you for those who came to our last meetup. (Thursday, November 23rd 2017)
Thank you also to PT Asuransi Astra Buana (Pak Iwan) for a great venue.

There wasn’t a usual meetup that we had some speakers to shared a talk, we only did an open space. Open space is a session when we discussed everything based on what we want to discussed within the timebox. So, this is how we hold the session:
1. We are divided into 3 different group (each group will be facilitated by someone: Mas Aditya Suryomurtjito from Sepulsa, Mas Tommy Fadillah from Aleph Labs, and me)
2. Every member of the group got opportunity to share the topic that they wanna discussed, used a post it
3. Then we prioritized the topic to being discussed based on vote from member of the group, means the topic that we pick is the topic that still confusing by most of the people
4. Let’s discussed! (don’t forget to keep the timebox!)

Goal of the session: no more confusing on the most topic, and can you guest what is that? it’s basic Scrum. :”)

Yeah, we discussed everything related basic Scrum, it’s okay, there’s always a session to build the mindset first.

Then we discussed about Design Sprint – Scrum.

Myth that usually came up:

1. Design Sprint is sprint that held by product people (designer and PO) and should be held exactly before (Scrum) development sprint

Design Sprint involve everyone whose in charge or interact with the solution, it can be people outside tech and product team, it can be inside (developer). So it’s not only for designer and PO even though PO and designer might take a major role in the session.

Exactly before Scrum sprint? of course no, it’s not a mini waterfall for designer and PO. So, what is the goal of having a Design Sprint? please check next answer..

2. Design sprint is REQUIRED before we start a Scrum sprint, means no Design Sprint == no Scrum sprint

Goal of Design Sprint is to produce high quality backlog. High quality means validated and tested considered human desirability, business viability, and technical feasibility. So, it can help PO in terms of produce the backlog, but is it always required? the answer is: it can help but not always needed. For pretty straight forward solution and more technical feature, having a Design Sprint might overkill.

Then what is required to start a Scrum sprint? of course not always having a Design Sprint before it.
It is Product Backlog and Sprint Goal.

3. Design sprint is held in sprint planning

Remember, how many hours maximum for sprint planning? 4 hours. Then 4 hours for having a design sprint? of course not enough.

4. Additional time needed in design sprint means less time for all member of the team to developed and delivered the feature

Not all member of the team required in Design Sprint. It can be adjusted based on possibility scope of the solution. If it’s probably impacting front end then we can only invite one of front end guy (not all fronties from that team). It’s also applied to stakeholder, if it’s only touch operation issue, no need to involved marketing guy isn’t it?. Be effective!

Then, don’t forget to consider %capacity of the team that probably involved on Design Sprint so we can include it into capacity calculation during a sprint planning.

5. There’s no any other methodology other than design sprint to produce a great product backlog

There’s no silver bullet. :))

Sharing session after open space

Sharing session after open space

Sharing session after open space

So, what is the best way to accommodate Design Sprint into Scrum?

Design Sprint is one of great way in order to produce high quality backlog, which is something that Scrum framework not really told deeper. So, it’s complementary. Just do Design Sprint separately with Scrum sprint so our product backlog pipeline will always filled with a great one. And just do Scrum sprint as usual as long we have list of product backlog and Sprint goal.

Hope those can help. If it’s still confusing? let’s meetup in our next meetup!

Scrum Jakarta (CiKemPon) 3rd Meetup