Interview: Tri Nugraha, Tokopedia On Squads, Scaling And Scrum



By
Hugo
13 February 17
0
comment

Interview: Tri Nugraha, Tokopedia On Squads, Scaling And Scrum

The following is an interview between Tri Nugraha and myself.

Hi Tri, thanks for taking the time to run this interview. I’ve heard a lot about the agile efforts of Tokopedia. I believe you guys are one of the Agile front runners in Indonesia. Let’s start with a short introduction about yourself (your role, how long you’ve been working with agile and the current company, etc)?

I joined Tokopedia in May 2010. My first role was Web Designer, employee number 7 at that time (now 1000++). I then formed a design team and became the Product Designer Lead.

And what’s your current role?

I am now the Product Tribe Lead, handling 2 out of the 12 tribes in Tokopedia.

In late 2014 we adopted Scrum. There are two reasons, one is because we hired a new product guy from BlackBerry US who had adopted Scrum. The second is because we read Joshua Partogi’s article about why Scrum will not work in Indonesia.

So because he wrote that it will NOT work, you decided to make it work? Why did he claim it will not work?

I think it’s his style. He often creates some controversial content, then makes us curious, haha. So after we read his article, we called him to explain what Scrum is, and why he wrote that piece. All management, me, and all early leaders joined the meeting.

So then we called Joshua and he trained us for 2 days. After that, I always replicated his training to each new Tokopedia employee, every month.

So you are doing the training yourself in-house? Do you train them only on Scrum or also other frameworks?

Yes, in-house. I trained the first couple of batches, after that I passed the knowledge and let others conduct the training. We only teach Scrum and a little Kanban knowledge.

Then I started the role as Product Owner, and now Product Tribe Lead.

We started with 3 squads (copying Spotify’s term for the team name) at first, now we have almost 30 squads. Each squad is responsible for 1 module, for example, logistics, transaction, messaging, gold merchant, and so on.

I have heard a lot about the Spotify model and I assume not everyone in Indonesia knows it. Could you explain in your own words how the model works? And maybe you have some interesting links or books for people to read more about the model?

So basically teams (squads) that have proximity, gather under a tribe to make the alignment in big company work. Communication is the key, so we think that we have to try the tribe system, chapter, and also guild concept.

Please access their explanation here:

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

Why did you start squads?

It makes the process transparent. It increases the quality of communication and collaboration. Squads exist to keep the focus. We give our squads cartoon character names to make it easy to recognize them. Stitch for transaction, Kerokeroppi for logistic, Mr. Krabs for gold merchant, and so on.

Each squad focuses only on one module, that’s the mindset we want to apply. When a team is focused on a module, they will own it more. They will devote themselves to it, give all their ideas and critiques to it.

This year, we applied the Tribe system (again, Spotify). Squads that have similarity or proximity, gather together under 1 tribe. Let’s say cart, order, resolution center squad, are now all under Transaction Tribe. There are 12 tribes now.

There are currently many frameworks in the market to scale scrum. Have you looked at LeSS, Safe and Nexus? If no, why not? If yes, what’s the reason you chose the spotify model?

We haven’t look at that framework. We just want to laser-focus on one working model, Spotify. There’s no time to explore others, haha.

I have also heard from many people that so far not many companies have succeeded in ‘cloning’ the Spotify model. Did you copy literally what Spotify did? What were some of the challenges you encountered in this adoption?

We use their squad, tribe, chapter, and guild concept. The challenges arise when we use the tribe system. It’s quite difficult to socialize it at first. But now, there’s no problem in adopting it.

I studied Tokopedia’s vacancy page and came across this image:

What does it mean for you personally to ‘be agile’?

Agile means being responsive in every condition. We have a DNA, “focus on consumer”. Our consumers are: merchant, buyer, partners, and internal team. So for any pains, needs, jobs that they try to reduce or accomplish, we have to try our best to serve them.

Of course, we have our quarterly roadmap. But in practice, there will be some pivot/changes to keep us responsive.

Also, agile means iteration, continuous improvement and collaborative work. Previously we were separated: design teams had their own island, same goes for engineers, QA, business and so on. But now we sit down together as a team. Everyday syncing-up together towards the same goal.

I recently stumbled upon a post about agile on ycombinator. To me it is refreshing to hear some ‘counter-sounds’, being surrounded by agile practitioners every day. What are your thoughts on what he writes?

Very interesting. I think there must be something wrong there, here’s a couple of hypotheses:

  1. No REAL support from management (CEO, CTO). So not everyone understands how agile works and not everybody ‘breathes’ it. I think in Tokopedia we’re lucky to have a management team that supports the agile framework. They understand about squad, sprints, planning, team happiness and so on.
  2. There is no strong PO (or SM). In my opinion, a strong PO should exist in every squad. He both needs to support the team and take the role as a servant leader. A PO or SM must take a role as a bridge between stakeholders and development team. His/her leadership and communication skill must be good. In Tokopedia, we devoted to shape the right culture and have a mission to influence people and maintain the culture.
  3. There is no one maintaining the culture. Like a said, we have monthly Scrum training for every new Tokopedia member. All roles, all functions, all levels, MUST attend the training. We call it Nakama Academy, Scrum is one of the training materials and is always the most favorite based on our surveys, and I’m proud of that (haha!)

Scrum is the most popular framework nowadays and that’s where most companies start. Once teams gain maturity, they move to or add other practices and frameworks. What methods, frameworks and practices are you using?

We only use Scrum and Kanban. Scrum is for the feature/product teams. Kanban is usually for the Site Reliability teams. They usually focus on scaling and R&D.

On the engineering level, do you also use DevOps or related practices?

Yes, the teams actually use DevOps. They consist of infra team, DBA, and rock-star engineers.

What do you mean by scaling in this context?

Scaling means to do research and implementation to keep us growing, such as converting programming language, databases, technical architecture and so on.

What are some of the challenges you have faced in your role and how did you tackle them?

To keep the culture and make the team happy. You need to have a great communication skill. The way you talk with engineers and designers and business guys are different.

You need time to make a team happy. Each team has their own definition of happy. The challenges are to keep them solid, responsible with a sense of ownership, while they stay organized.

You mention happiness a lot. Does each team really define their own ‘happiness’? And do you have metrics for this?

A happy team will (this is my personal opinion):

  • Do the everyday work happily without complaining or any bad attitude
  • Be solid inside and outside office hours
  • Communicate and laugh a lot, in the same time deliver the value needed in every sprint

For the metrics, we are trying to conduct some survey per month (Spotify also did this). We basically ask our team to evaluate the team happiness.

One thing I often notice is that it is hard to develop a ‘sense of ownership’. What things do you believe contribute to that sense in Tokopedia?

  • Solid team, inside and outside work
  • Give the team some exciting and high-responsibility work
  • Include the team in important decisions
  • Include the squads in Design Sprints
  • Trust them
  • Share the current situation about the market, so that the team feels that there are no secrets between you, and they feel trusted & involved

Related to this is the notion of responsibility, which we could call ‘self organization’. Now I noticed that in Indonesia, many people are not automatically pro-active, they’d rather sit and wait and be told what to do. What’s your experience on stimulating self organization and responsibility?

I usually ask the team “What do you want to do this sprint?” on our sprint planning session. If they feel like there’s nothing to do, we will brainstorm and discuss pending backlogs or future roadmap.

So the key is to never let them feel some “empty days”. I will always remind them to speak-up when they have something in mind. So again, good communication is the key. When you listen to them, they will trust you, and become more open to you.

Also on their first day, we always say that “we won’t always be there watching for you, so you have to be proactive and start the conversation”.

I love the “become friends” approach. I will laugh and play with them, to understand their world. That way they will not look at me as a boss or manager. I want to look like a supporter, servant leader. I will offer help as much as I can to them. Simple things like proposing to replace outdated or low-performance devices, will boost happiness and productivity at the same time.

I noticed that compared to some other countries, Indonesia doesn’t have that many scrum masters, product owners and agile coaches yet. What do you think we as an industry can do to develop those skills?

In Tokopedia I saw that the PO role is in the blood, but SM and AC are not. We tried to apply SM role, but not as a full-time SM. It also maybe because one of our early PO’s also had SM skills and took the SM role, so it’s not in urgency level to have a dedicated full-time SM.

So from this, I understand, that you don’t have scrum masters? Why didn’t it work?

Yes, we don’t have the official role. But in some tribes, we have one guy in every squad to take care of the team, to take the SM role. But the problem is they are QA guys, so they cannot be a full-time SM.

What do you believe makes for a good scrum master?

The one that can make the team happy and in the same time deliver the expectations. The one that has “the power” and the ability to approach things bottom-up in the company.

Sounds a lot like you 🙂

🙂

If a company wants to start adopting agile, what are some of your recommendations on how to start?

Do basic simulation training like we did. Introduce some theory and the events, then actually do it in a simulation. That works for us.

Sounds simple! So you would recommend companies to go it 100%, adopt everything the scrum framework describes right from the start? Or go step by step?

Learn the scrum guide, do the 2-days training, then jump into real life scenarios. Daily standups, progress board, sprint planning, retrospectives, transparency, collaboration, good communication, responsibility, self-organized. Do that all I think is a must 🙂

Thanks for the interview! Tokopedia is well known, but if you want to know more about them, please visit their website. You can also find Tri’s LinkedIn profile here. If you want to learn more about people like Tri, join our meetups or for peer to peer learning, join our Agile Circles.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>