Tag Archives: agile coaching

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?

Envy

Not this Sane

Scrum Master is the most sane people in the organization

I forgot where i got above quotes but it quite makes me envy and touch me a lil bit.

There will be a lot of uncertainty things happen during the day of sprint. There will be a lot of problem arise caused by the uncertainty things that coming. Some of you sometimes would be anxious, (fr)agile, un-stable, etc. And you don’t know how to retain your mentality, rise up when a big things hit you, etc. Not only about works, it’s also about your personal issue.

Please don’t worry, you still have your Scrum Master.

Hey, not all problem are appropriate to share to your co-workers

I know, but Scrum Master will treat you as their friends or even their family member. Scrum Master will put their problem aside, park it, and re-thinking about it later, then put your problem as their top priority. When you think it’s appropriate, don’t shy, just share it to them. Scrum Master will tell you the truth, the honest side one, even it gonna hurts you, a lot. Sometimes what we need isn’t what we want, it is?.

The envy part is:
When Scrum Master is arrived to become a servant leader, then serve you, help to solve your problem, who will help them to solve their problem?. Scrum Master is also a human, isn’t it?. Sometimes they also have a problem to solve, even their personal issue.

But that’s not your problem, don’t worry, we can take the rest of it. :)

So, please love your Scrum Master. For us, there won’t be any happier thing other than that.

Fasilkom UI Agile Coaching Session

With the lecturer

A great news comes from my college (Faculty of Computer Science, Universitas Indonesia): one of their courses, software project developent (PPL), will using agile rather than old methodology (Waterfall).

Wohoo!

It’s such a great news, since i realized, when join in industry, especially in startup ecosystem, we mostly using agile process. Why? because we usually work with uncertainty problem that sometimes easier to be handled using empirical approach rather than planned upfront approach. And agile process usually missed or didn’t get enough attention inside the courses. I remember it only contained in software engineering course, mostly theory, without any practical lesson. So, me (during that time) should learn from external resources :(. But that’s okay, as a student, there’s no boundaries to learn since there’s an internet isn’t it?.

So, a week ago, Rizky (also a founder of Agile Campus) tell me that Pak Ade Azurat (PPL lecturer) needs help to coach his students. This coaching session has a purpose to make sure all students have basic understanding of agile before they jump into the practical development. Of course it will be YES for me for the invitation!.

Then, here it is:

Let’s do it!
Let’s breakdown our product backlog
Let’s breakdown our product backlog (2)
Let’s breakdown our product backlog (3)

This coaching session basically only covered basic Scrum, included all inside Scrum guide and a little bit best practices (see some my experiment in Scrum and agile process here). Below are some best practice we share:

How to define a MVP:

How to make an estimation in agile development process using planning poker:

How to do a task planning

Thank you so much Pak Ade, Kak Maya, Pak Adin, & Rizky for the opportunity. It’s an honor to share and also learn from you guys and all Fasilkom students.

Thank you for making one of my bucket list checked: become a guest lecturer.

It’s a wrap!

Improvement Visibility

In HappyFresh tech-product team, another sprint means another experiment.

One of requirement from agile organization is improvement. Your organization should improving every hour, every day, every time. Improving means increasing positive things or removing negative things. How to be able discover that? usually some of agile organization do kinda sharing session between the employee and decide some improvement. But unfortunately the improvement sometimes comes with “top-down” approach, from top organization managerial, not comes from employees.

I’m grateful to have colleague & manager who value an improvement as a shared responsibility.

In Scrum framework there’s a session to accommodate that necessity, it’s called sprint retrospective. For those who don’t know retrospective session please read guides from Scrum.org here: Scrum guides. This is the example how we hold a retrospective session: Retrospective: Apresiasi dan Mesin Waktu.

Let’s jump into the problem and experiment.

Problem: Sometimes the improvement/action items from retrospective session still not “checked” by PIC (person in charge) of the action items by the end of the sprint.

Pre-condition: I usually use Confluence to documenting all action items, improvement, anything from retrospective session.

Question:

  1. Are they forgot to did the task/action items?
  2. Are they just forgot to check the items on Confluence?
  3. Are they just haven’t read the Confluence?
  4. Are they??

Hypothesis/Expected Result: If i make it more visible, it will raise the possibility of the items will be “checked” by them. “Checked” means they did the action items to avoid previous sprint mistakes.

So, what i did in previous sprint:

  1. I still used post-it in the retrospective session.
  2. But, rather than using Confluence to documented the problem and the action items, i used offline materials.
  3. I used A2 paper to put all post-it (contain with issue and problem).

    Avengers Retrospective

  4. I put that offline retrospective documentation close to team’s table, to make sure it’s visible by the team.

    Put it close to your team’s table

  5. The other advantage of this approach is, team also able to reviewed it in/after/before every daily scrum session.
  6. It’s kinda give them indirect pressure to avoid similar issue/mistake by did the action items.
  7. Additional tips: we also able to use offline retrospective documentation from previous sprint as a benchmark for the next sprint retrospective session, just to make sure the mistakes isn’t repeated.

And here’s the Result:

It’s all CHECKED.

Seems like make it visible will increase the awareness of the issue that lead to improvement. It’s not about something that should be pushed, it’s all about shared responsibility. Showing a commitment to improve shouldn’t because of reward and punishment from the organization.

What i want to also highlight: result isn’t the most important one from this approach, instead of learning process itself. So, i think it’s okay to not got all the action items checked by the end of the sprint as long the team has realized that they shouldn’t repeat any mistake in the future. Not repeating 1 or 2 mistake from 5 mistake is still improvement isn’t it?.

So, let’s help them to improve!