Interview: Ludwi Samoen, Midtrans On Different Roles And Agile Mindset

The following is an interview between Ludwi Samoen and myself.

Hi Ludwi, thanks for taking the time to run this interview. We have spoken a couple of times before about agility at Midtrans. You have a wide background in IT project management, working for companies like Icehouse, Samsung’s R&D labs and Telkom. My curiosity is piqued by that experience!

Let’s start with a short introduction about yourself (your role, how long you’ve been working with agile and the current company, etc)?

Ludwi: Hi Hugo. I am currently Head Scrum Master at Midtrans (don’t worry too much about the title). I am a Scrum Master on multiple products. I’ve been using Agile for about 6 years, with the last couple years being at Midtrans. Midtrans itself has been using Agile for over 3 years, but we continuously evolve our methodology, hopefully in the right direction.

The first thing that came to mind when I first saw your profile in linkedin is: your title says ‘scrum master AND project manager’. Now in the agile world, many people think ‘manager’ is a bad word. What is your view on this?

Ludwi: Both Scrum Master and Project Manager are trying to achieve the same things. They are both tasked to take whatever resource they are given in order to orchestrate the development team to produce an output that will hopefully bring value. The title project manager is a more general while a scrum master would use Scrum as an approach to meet targets.

I would understand why some would think negatively of the title manager. A manager’s task is to help stakeholders control the use of resources to provide the highest possible output. Team members don’t like the feeling of being controlled.

Ok there’s two interesting things in that for me. Firstly you say ‘team members don’t like the feeling of being controlled’. At the same time, many people like to be told what to do so they don’t need to pick their own work and take ownership. To me, waiting for someone to ‘give you work’ is equal to allowing to be controlled by another human being. How do you see this?

Ludwi: I believe there are a couple reasons why a team member would rather “not pick their own work and be assigned by someone else”. 1) They just don’t care very much about the value. 2) They don’t understand enough about the value of their selections, such as new members that are new to the industry.

I too agree that some people can’t work without being told what to do. Sadly, I see and hear about each of these all the time. If you find a team member who doesn’t care enough about the value the product might bring, you need to keep a very close eye, because they can be poisonous to other members. Being only half committed won’t result in total quality. That’s not the type of service or product that you want to deliver. We need teams to own their work from inception to maturity and beyond. I always want team members to treat their products like their baby.

Second thing is that many people are ‘agile purists’ or ‘scrum purists’. They believe that it’s either 100% agile or not at all. I see a lot of discussion worldwide about ‘being agile’ versus ‘not being agile’. From your answer am I correctly interpreting that you’re not a ‘purist’? And how do you see being an agile purist versus doing whatever is right to generate the right output?

Ludwi: Well, I think that you are free to be whatever you’d like. I actually don’t want to limit myself in any way, and I always try to be open to trying new things. For the most part, that’s how people get into Agile in the first place. Don’t get me wrong, I truly believe in Agile and I try to implement it in everything I do. But sometimes situations conflict with the Agile mindset. I’ve managed projects using all kinds of development models such as USDP (branded as Rational by IBM), V-Model, Waterfall, Spiral, and the Agile methods of Kanban, Scrum, and Scrumban. Each has their strengths and weaknesses.

My goal is actually to bring the biggest value. Sometimes, if a person asks me what method we are using, I would say, “You know what, I don’t have a name for it. We are going to do this and that. If scenario A happens, we are going to be doing [this]… if scenario B creeps in, we are going to do [that]…”. Wouldn’t it be great if we can bring the best of all worlds.

Yes, I completely agree with you. I believe in the end, the only thing that matters is getting the outcomes you aim for. How you deliver doesn’t matter.

What are some of the biggest differences between the role of ‘project manager’ and ‘scrum master’ in your experience?

Ludwi: This biggest difference is what they do when the original commitment will be broken. A project manager would initiate the planning and re-baseline, develop a new commitment. Normally, the conversation would start with how the stakeholder or user wants to change something in the spec. Then the team would be brought in to assess the effort and the impact to the original target.

Now the difference is that the scrum master would use the scrum framework to do so. The framework tells the team to wait for the next sprint to begin a new commitment. The target is whatever was planned for the end of sprint. And the sprint’s value would begin to surface.

Yes and what often adds to the confusion about scrum versus traditional project management is ‘the deadline’. The ‘old’ way of working is to analyze a big project, estimate and plan and give a deadline. So a team commits to everything that was specified. The goal of the team is to finish that commitment. In scrum, we’d say that the estimate is the budget or project scope. Then we iterate and we try and create as much value as possible within this project scope. Especially in fixed price projects, the problem that occurs is that a customer expects ‘all that was agreed’ to be delivered ‘on time’. But it might be that we estimated 6 months work or 12 sprints but in sprint 12 we’ve only completed 75% of the initial requirements (but we did add 50%). How do you see this difference at play in your current company? And in a service provider?

Ludwi: The scenario is very true for a lot of companies and for the most part it is the mindset that this is the only correct way to do so. Sometimes it goes so far as teams don’t care about the success of the product in the market but to just meet the deadlines. And in the beginning of the product, that is the only way to achieve success.

It is great to have a master plan or a product roadmap, but it is also great to always be aware that the market changes. Agile believes that along the way of reaching the pot of gold at the end of the rainbow, we can collect coins. Agile also believes that bullseye is a moving target. Meaning that the ultimate highest value achievable changes with time.

The hope is that we can be a tangible part of that and goal with the customer and that bringing more business to the customer leads to more business (or sponsorship) for our team.

Now, imagine if that is not the case. That no matter how successful the product is, or how successful our customer becomes, it will only be a one-time thing and nothing after. Would it still be worth running Agile?

Yes, that’s a good point. I believe great software is built by people who are truly committed to the product they build. If collaborations are structured as a one off thing, that commitment will never be as big as a team that sees it as a product (as opposed to a temporary project) of their own. Agile has this product commitment as the goal.

You have also worked at Icehouse. I’ve heard a lot about the company and they are one of the pioneers in scrum based collaborations as a software service company. What do you see as some specific challenges for a service firm (as opposed to building a product in-house)?

Ludwi: The first challenge is the commitment to use the framework. At Ice House, most of our customers understood enough to want to use it and trusted us to be the experts in the field. Our customers, for the most part, played the role of the Product Owner in its own right, so they were given a part of the responsibility to co-own the process. We were fortunate to have such great customers work well with the team so everybody felt as if the product were our own.

As one of my mentors once said: You want your customers to say ‘yes Mr Messer if that’s what you think is best, we’ll do it that way’. I think that comes from the right experience, authority and credibility.

It really doesn’t matter whether or not what we worked on was in-house or was actually owned by another company. As long as the feeling of ownership was there. I’ve also had experiences where the product was in-house, but the ownership was not present. The level of quality put in the product was not as good as one would hope. Dealing with that is key. Deal with it early so we only need to maintain.

So what you’re actually saying is: it doesn’t matter what you do, what counts is having the right people working in the right company culture?

Ludwi: The mindset is the key. I’m not a psychologist, but I think that the culture could help shape the mindset. Creating that culture takes a lot of dedication, commitment, and effort. I believe that support from top management can make things easier in creating that.

Same thoughts here, I’m not a psychologist either, but I do believe that shaping a culture helps attract the people who can support the culture. I’ve always made a big effort in my company to do just that. When I opened my office in India, I spent a lot of time defining our values with the initial people we hired. Two core values that have helped us are ‘openness’ and ‘entrepreneurship’. By making those values the core of our culture, we are able to attract people who are more comfortable communicating openly about everything (to our customers). And to ‘fight’ the hierarchical culture in India, we hired people who understand that entrepreneurship is about taking responsibility, fully owning the products you work on. Based on those two values, agile becomes easier to instill.  

A related topic; I always get questions from service companies on how to combine scrum with the demand of customers who want a fixed price contract. How in your experience do we best tackle that ‘tension’?

Ludwi: I always say that a fixed price needs fixed specs and a fixed deadline. Unfortunately, that never sells. The only other way I would advise to take a fixed price deal is if the margin is big enough to endure extra costs due to changes. Basically, we want to convey the message that with a fixed price, you get a fixed budget to use on resources. If you still want to do Scrum, then each story would have a fixed cost converted through Story Points.

I would hire you as a sales person :). The last point you made is interesting. I often get the question how to work with story points if you deliver services (usually priced at man hour or day) to customers. How would you go about pricing story points or stories? And if you manage to put a price tag on stories, how would the billing (ideally) look?

Ludwi: It takes time to find the exact formula for your company. But if you can find the right formula, you also need to keep in mind that it changes over time. A couple of models you can use, such as price per estimated man hour/day (effort) with a more flexible margin. Or price per actual effort spent on each story. Either way, you put a price on each story point.

It’s like when you buy a house for a fixed price, the developer would probably ask about some details you might want to choose from, such as wallpaper or if you need to choose the ceramic tiles. But when you request some infrastructural changes during development, the developers would answer in two parts, “Please wait until we complete everything as we have planned.” and “That’s going to cost extra.”

Yes, and the ‘that’s going to cost extra’ is where many of the problems in software development come :). What I always have in mind as the main issue in fixed price contracts is the incentive. If I as a customer or project manager keep the development team to a deadline (and/or a fixed price), they have 0 incentive to create the best version of the software I have in mind. A fixed price makes teams focused on delivering as specified because they want to avoid the ‘extra work’ discussion’. Whereas in agile, we welcome change. Now the incentive becomes ‘creating the most value for the buck’. The problem I often times see is: how do you define ‘value’? As a project manager, my main reference is ‘building what I have in mind’. If a team doesn’t build that but does add extra stuff, I might still be upset by their delivery. I think this notion of ‘value’ is a highly underserved topic in the agile community. Have you been able to make ‘value’ clear in this context and if yes, how?

Ludwi: No, I/we haven’t been able to define value clearly and consistently. It’s ambiguous at best. But sometimes it’s consistently ambiguous to the point that it doesn’t need to be defined in a single sentence. I have found that in any environment, you give context to what each story means to the end customer and to the company. When the stakeholders and the team understand that, they are brought into the same world and the same mindset.

Going back to the example of buying a house, a typical buyer wouldn’t say “I need the house to be x meters by y meters, with room 1 z meters by w meters”. They would typically say, “Look, I have 2 kids and I might have a house helper. I like big cars, but I know that we don’t have a lot of space to work with…” With this sort of conversation, teams can help shape the highest value possible.

You are part of our Agile Indonesia community. I haven’t seen you at our meetups yet, probably because you are very busy. For most people in the global agile space, communities are where they find support from like minded people. What are some of the things, groups or people that have helped you grow in your (agile) role?

Ludwi: Ok, this is by far the hardest question you have asked me :). Yes, I am so busy with work and life, I guess. We have a couple of wonderful kids that need help with their homework and studies. Stay in school kids.

I really like the fact that there are communities now in Indonesia. Believe it or not, when I first started out, we were probably a bunch of individuals searching for forums to find answers to everyday problems. Looks like we now have ways to face these problems together, which makes things a lot easier.

I’ve had mentors teach me the mechanics of agile and for the most part, understanding the principles and values are the keys to success in bringing the methods forwards. Without it, agile would just crumble. Some other things that have helped was that I was taught to keep an open mind and keep discussions live. This way I have found new things that have taken me beyond agile.

Yes, I think an open mind is what I take from this talk with you. I share that view: things are not absolutes, are not either black or white; this can be yes AND no. Thanks for the talk and hope to meet you soon on one of our meetups or agile circles if your kids allow you to join!

March 17, 2017 Hugo Tags: agile coach, agile trainer, scrum interview Categories: Interview

Read the full story here

Post Published By: Hugo

Sign In or Register to comment.