#3 - Agile Essence and Challenging Status Quo - Stanly Lau

Episode Introduction [00:00:49]

Henry Suryawirawan: Hello, everyone. Welcome back to a new episode of the Tech Lead Journal with me your host Henry Suryawirawan. Before we start today’s episode, if you have been enjoying this podcast so far, it will mean a lot for me if you subscribe and leave a review of your favorite episodes wherever you listen your podcast from. Tech Lead Journal is also available for you to follow on multiple social media, such as LinkedIn, Twitter, and Instagram.

Every few days, I post inspiring quotes from the amazing guests in the available episodes. And in the future, you can also get new updates about the podcast from there. You can also leave your feedback directly on Tech Lead Journal website at techleadjournal.dev/feedback.

Feedback is a gift. And I appreciate if you can leave me any comments or any suggestions, including any potential guests that you would like to have here in this podcast.

So in this episode, I had the opportunity to discuss with Stanly Lau, one of the early leaders of the Agile Singapore community. I met Stanly from the Agile meetups and subsequently at various workshops that he organized, inviting various world class thought leaders to come to Singapore to share their knowledge and wisdom.

Ultimately Stanley was also able to pull off multiple successful Agile conferences. And I still remember from all these conferences, I had a chance to see several of these thought leaders on stage, people like Martin Fowler, Kent Beck, Michael Feathers, and many others. I even had few opportunities to take some pictures with them, which I forever cherish in my memory. So I fully appreciate of what Stanly has done to the growth of Agile community in Singapore, and also around this region.

In this episode, we discussed about Stanly’s career journey and the unique culture of Odd-e, the company where he’s currently working at. Stanly also shared his view on the current Agile state and some misconceptions that are arising in the industry nowadays, and even suggested on how we can bring Agile adoption back to its essence. So I hope all of you enjoy this episode with Stanly Lau.

Introduction [00:03:06]

Henry Suryawirawan: Hey Stanly, thanks for spending your time on Tech Lead Journal. I know Stanly since few years back when we all have Agile Conferences going on in Singapore, and also I met Stanly a few times in training with the thought leaders from around the world. So Stanly also helped to bring those kinds of thought leaders to Singapore to help conduct workshops. And I attended some of them, get to know Stanly a little bit more. And today I’m really happy to have Stanly to be part of this episode. And I hope we can learn from Stanly a lot.

Stanly Lau: [00:03:40] Thank you, Henry.

Career Journey and Odd-e [00:03:41]

Henry Suryawirawan: [00:03:41] So Stanly, one thing that I read about your career, right, is that you have a very interesting journey. I read one in Odd-e page where it mentioned that you used to think that your career as a developer will be stuck and then you have to go to become a manager in order to progress. But you decided that you want to try something else, in which what you are doing at Odd-e. Could you tell me a little bit of the thought process behind that and what have you learned based on that decision?

Stanly Lau: [00:04:11] Sure. So this I’ll need to go back into history, that is about, I think in 2004, I was out from the army in Singapore military. And I got a diploma in Information Technology, and I’m also beginning my part time studies in Computer Science, because I didn’t want to take a full time. Otherwise I would not have enough practical experience. So I decided to work directly at that time. As a software developer after I worked through about three companies, like Motorola and small company and a larger company, of various domains, I saw some common patterns, that people around me and my peers who graduated with me on Computer Science or in IT, eventually they went out of this field. And for those that remain in this field, they try to get into manager role positions. They would tell me that you cannot be a programmer forever. You eventually need to become a manager or at a time the popularity is project manager. And otherwise most of my friends went out to outside IT field, they went to real estate, financial domains. They become more business oriented, and part of the reasons is also because it is very hard working as a software developer. Often you need to work long hours firefighting endlessly. So I didn’t really accept that this is how software development should be . I think there are other ways that the other companies that approach software development differently. And, in a more growth manner, there’s a lot of learning and then making things better. Early in my career, I tried to look for mentors, people who I can learn better practices from. And after three companies, I stopped finding because I realized that there isn’t one in Singapore. So therefore I needed to take this responsibility myself to learn what are the better practices on the internet. So at the time there is theserverside.com, very early days, Java is popular, you also have .NET platform that’s also very popular and gradually serverside also posts articles about practices like clean code, unit testing, test driven development, which I don’t really understand at that point in time what those things means. So then later on there is also this website called infoq.com. They post a lot more variety of practices and also technologies.

I pick up Clean Code book and I learn and I enjoy it. The more I read then the next book I went up to is Domain Driven Design. It opened up my eyes. There is so much more to software development than just code and fix, and then pray that it works in production. So since then I’ve been learning myself some of the technical practices, like refactoring, like a unit testing . Eventually I know myself I hit the limit, this is the most that I can learn myself, self-learned from the articles and the internet. That was in 2008, I think. So I thought, maybe there is some courses in Singapore that teach TDD, test driven development or refactoring. So I searched and there’s none. The closest I can get is how to be architect, all the documentation and processes. Wasn’t really interested into that, but I thought, maybe this is how software development is, eventually need to go there.

There’s a forum in Yahoo groups, there’s this guy named Bas Vodde, and he is doing a course in Singapore called Scrum. I thought it’s scam. What’s interesting is his profile is interesting. He’s the co-author of Cpputest, which is a unit testing framework for C++. And he’s giving this Scrum Master course, like a master of scam. So I don’t really care about what this course is about. I want to meet this person and see what I can learn from. When I attend this course, it open up my perspective, it broaden, it’s like a whole new horizon just emerged. There is so much about company dynamics and also practices that I tried to encourage my peers at that time, my colleagues. Like I still remember over the cubicle, I told my colleague “Look, Clean Code book, this is very very interesting you know. You need to read it.” Then he was saying that “Read books? I only, only read newspapers in toilet. I don’t read books.” So you know, I mean that is the first form of what I learned as resistance. I don’t know what to make out of that. Is this sarcastic or what? It didn’t really bother. So I try to encourage my, my peers at the time and about what I read. So Bas Vodde, through his Scrum Master course I learned that he is not only good at technical practices or understanding product development at a technical level, but also how he relates the code base, the shape of a code base relates to the problems in organization. So if you want to make any changes in organization, you need to learn about all the dynamics that is weaved together that relates with each other. He has a lot of Amazon reviews on books. So I went to search all his reviews that are four or five stars. I will buy all of them. And very soon my cubicle is full of books. And then my colleague was saying, “Oh, Stanly, what happened to you? Suddenly you have a lot of books on your shelf.” These are books that I like to read. In Chinese, you call it kungfu manual that is a secret manual. These have the answers .

So going back to your question, my quest of finding a mentor led me to discover the ins and outs of product development and led me to the interests of helping others to be better problem solvers. Thus in the past decade, I decided to mostly focus on coaching, mentoring, and training.

Odd-e Culture [00:09:38]

Henry Suryawirawan: [00:09:38] I found also Odd-e is one of the unique companies, in which you have different set of working process, different set of culture. Maybe you can share with the listeners here about what’s so unique about Odd-e that you think worth to share with everybody?

Stanly Lau: [00:09:54] I will share a story first before I explain the concept. When I joined Odd-e, I asked Bas, how many days of annual leave I have. He asked back, “How many days do you usually have?”. I replied the same number as my ex-company at that time. And he said, “Okay!”. I regretted it immediately.

He also told me a bunch of things, which I didn’t really understand at that time, but I thought it was cool, like you decide your own title, there is no hierarchy and manager. It was later then I realized there is no HR in Odd-e, and no one keeping track of your annual leave. You decide how you want to work and be responsible for the organization and working with each other.

So Bas founded Odd-e as an experiment to see what will happen if the organization is based on principles of self managing teams. We have no hierarchy, management structure or centralized control. Though he’s the founder, he’s not the boss of the, the company. There is no manager. Within each team, there is also no structure, but together they do have a responsibility for their profit and loss. They will make their own decisions about basically everything like which clients to work, how to deal with finances, and how we set our own salary. So you can imagine each team is like a company and it is, also usually it’s own legal entity. Instead of having company values, we have the opposites, what we never do. For example, Odd-e never does performance appraisals, never optimize only for profit and growth, never hire people because we have work, and never gives up writing code. So it has been a decade, and we have now more than 10 teams located in different parts of the world. Every half yearly, we have a gathering at some location and spend a week exchange learnings and write code. Although now times have changed. I’m not sure when we will be able to do that again, but, we will see.

So there are challenges with the corporate and accounting practices on Odd-e because it assumes a ownership model where someone is in control. So if you think of ACRA, which is a Singapore’s authority for accounting and corporate practices, you must have a director and shareholders, and so and so forth. That is what we thought of as a ownership model. We actively not let that influence how we want to work. And if you think about it, it is easy for any organizations to be influenced by how corporate practices want them to work. One of the reasons people join Odd-e is because we dislike how most organizations are run, I guess this makes Odd-e quite unique.

Henry Suryawirawan: [00:12:29] Thanks for sharing that. It’s pretty unique. In your point of view , having seen the corporate world and having worked now with this kind of culture, like set your own salary, no appraisal, you do what you want to do and you own your profit and loss, right? What are the key big difference that you think are beneficial for people to at least know and acknowledge that this kind of working model might work?

Stanly Lau: [00:12:50] Right at the core, Odd-e is designed with the acknowledgement that people wants to learn and be better. So, what we say and do are congruent. It is different from most companies where they expect you to be better, but have structures and policies that backfire. I believe people have good intentions, but because of the organization rules that accumulates over time, influences people’s behavior and de-humanize the workplace. Over time you come in terms with how the organization play games and you work within the box. Until you join one of Bas Vodde’s courses, you may either become aware of yourself being in the box that wants to get up and improve, or defend yourself to keep yourself in a box. For those that want to improve, the enthusiasm usually last for a couple of weeks before the force field molds you back to the shape of the box. If the organization doesn’t improve, your accumulating frustration will lead you to leave the company. It is not uncommon to hear this stories from our students when they know what can be better.

I don’t suggest all organizations should follow Odd-e model. If I start a cafe shop or like HR software product company, I would manage it differently because the context is different. However concepts like self-managing can be useful, especially in product development. And it doesn’t mean you cannot have managers.

On the other hand, there is nothing new to this concepts that I mentioned. There are many evidence based studies done on this area. There is a book called " Abolishing Performance Appraisals" which shows how and why traditional processes backfire and what to do differently. There is the principle of beyond budgeting, the idea of abolishing traditional budgeting processes because of its inherent flaws. Numerous studies on the importance of growing real teams and team coaching to create a learning organization. And more recently, actually five years ago, Yves Mourieux gave an insightful TED talk on how too many rules at work keep you from getting things done, which highlights how overload of rules, processes and metrics keeps us from doing our best work altogether.

So why would a software developer care about these? There is a high chance that performance appraisals, traditional budgeting, traditional processes, department silos, managed by control, thinking of people as resource to be utilized, these form the box that will influence your behavior and thinking subconsciously. Understanding this can reduce the influence and gain back control of your own growth.

Yeah, it is easier said than done, I know. Since the time I became aware of these, 10 years ago, I noticed more organizations are challenging the box. Usually not the whole company, but pockets of it and I’m aware that it is not easy.

Agile and Its Misconception [00:15:50]

Henry Suryawirawan: [00:15:50] Hearing what you’re saying, it seems like this is kinda related to how Agile should work in a way and switching the topic a little bit now to Agile, right? I mean, Agile is your bread and butter. You’ve been Agile coach, you have Scrum certifications and all that. You also work with Bas who invented LeSS. Obviously Scrum has been around for like many years now. And in fact, the popularity is pretty, pretty huge. But I see personally in my opinion, that there are people who are now being skeptical about Agile and Scrum thinking of it, maybe it’s a scam, you know? When people come with the title Scrum Master, oh is he a scam master, you know, that kind of thing. So, can you maybe clarify a bit about Agile state at the moment in the industry and what do you think are some of the misconceptions that people see in Agile?

Stanly Lau: [00:16:38] I’m going to clarify briefly what Agile and Scrum are first before share my thoughts about the misconception. Agile is a manifesto containing 4 values and 12 principles written by a group of programmers in 2001 who are frustrated by the traditional development processes at that time. So founders of Extreme Programming and Scrum were there, and they had been challenging the traditional development for many years before. The authors of Agile manifesto had only thought it was a good meetup, and didn’t expect anything after that. But people found out and it became a movement. What this means is there were people who resonated with the authors in improving software development. Extreme Programming and Scrum became the most popular and often used in combination.

Extreme programming has very useful technical practices like refactoring, pair programming and Continuous Integration that helps to reduce the feedback loop in development. Some of these practices were stolen from the good parts of traditional development like code review. And when you turn the frequency up, it becomes pair programming, thus called extreme.

For Scrum, there are three keys. First is cross functional and self managing team. As you can imagine, this is a bigger change in your organization compared to adopting a technical practice, like refactoring. It will challenge the box and you need different types of skills for that. Second is acknowledging that we are in a complex domain and therefore we need to inspect and adapt on how and what we work. Third is acknowledging we are developing products and not projects. So it is common to have teams use Scrum along with a few technical practices from Extreme Programming.

Let’s talk about misconception. Most of the misconceptions I came across are the lack of understanding. I met a person in Agile meetup and he told me that they were using daily standup, therefore they were doing Scrum. I have seen more than 10 times a developer created a task that says refactoring, but when I paired with him, he was rewriting and adding more functionalities. Knowing and understanding are very different things. When I come across a new term in an article or book, in most cases, I only know and not yet understand. Unless I practice it along with good guidance, I may not increase my understanding.

Another common misconception is led from the people being forced to do Agile or Scrum. It could be the headquarters wanted various development sites to have Agile/Scrum in their contract, or a company’s management roll out an Agile wide adoption initiative. These are breeding ground for just show the motion without real change.

On certifications, if you’re the organization, how can you easily know that people are qualified for something? Certifications. Though this thinking is flawed, most companies still do it because it is easier to manage by numbers. So they send people for certifications, which creates the demand. Suppliers use this dynamic to create certifications to fuel the demand. I want to highlight that Certified Scrum Master doesn’t mean you understand and skilled at it. The reason Odd-e we still have certifications is because this dynamic in the industry is too strong, that if we don’t, it is hard to show up our experience with people in public trainings. And we are always upfront about the truth in certifications to our participants.

Henry Suryawirawan: [00:20:06] Yeah I find that also this is quite dangerous, right. Because as we all know, people tend to, like, over-hype sometimes about a certain practices, like Agile, DevOps, SRE, CI/CD, there are so many things, right?

So, what do you think can be done in order to put back Agile to what it was originally intended for, to rule out all this misconception, or even if you want to advise people who really want to go dive deep into this Scrum or Agile, right? What should they be focusing on?

Stanly Lau: [00:20:36] Focus on the essence. One approach that I tend to like to think is that , ignore this terms Scrum Agile stuff, but think about how do you improve your work. What are the challenges you are meeting today? What have you tried to improve it? And then what have you not tried? Who can you seek out for to get guidance, whether you’re you’re on the right direction or not. And if you have this thinking of trying to improve your work everyday, and also trying to understand the broad perspective. The things that you do, who is going to use it, who to get the benefits of it, who is this valuable for? How is this relate to the end customer? So, the thinking of this, and also, how do I know this is what they want? Am I actually on the right direction? How do I know? Who I can ask for whether is this the right direction?

Maybe you need to ask the customers, you need to ask someone else. Who am I depending on? What is the assumption I’m making? Is this assumption still valid? Or am I trying to mindread what other people are thinking? I need to check, so therefore I need to ping someone as early as possible. This is the kind of feedback, getting very tight feedback. I think this is one of the essence.

Henry Suryawirawan: [00:21:46] Hearing from what you’re saying it doesn’t work just for like a group of small teams , right. Being certified Scrum, and then they should be able to incorporate that to the whole companies, right. I mean, in essence, Agile is about culture, ways of working, the ways of thinking as well. So I think it’s more than just getting certifications. And probably, I don’t know what’s the best way for people or companies in general to actually adopt Agile other than bringing a bunch of people like you, who has experienced a lot in doing this, and trying to inculcate that practices, that ways of thinking, that ways of working in order to be able to finally adopt these whole Agile practices. I mean, that’s my take of it.

Learning from Thought Leaders [00:22:29]

Henry Suryawirawan: Switching a little bit about, you know, you mentioned so many times about mentors, learning from people who have experienced before. I noticed that all the contributions that you have made to the community, especially in Singapore, right. I still remember that few years back, we had this Agile conferences. We have so many great speakers and thought leaders, Martin Fowler, Kent Beck, and so many others, right. I think there’s one thing that I see from you, is that you’re seeking this kind of a thought leaders to actually learn from them.

What do you say about learning from all these people, and going to a workshop and some of them are actually paid workshops, right? So do you think it’s something that we as practitioners need to do, continuously and frequently from time to time?

Stanly Lau: [00:23:10] I think so. I think the reason I bring these people to here is because of, the, the ease of access. The reason I do conferences here and bring people here is, I was inspired when I went to the North America Agile Conference in 2010. And then there were thousands of people there. You can just walk along the corridor and you’d see Martin Fowler. You’ll see Uncle Bob, and then you say hi to them. Then you have some discussions with them.

So I realized Singapore is so far away from where these ideas are being originated. So I want to make it easier for people to access, by bringing them here. So I provide opportunities. And I believe people who turned up, most of them, in fact, I overtime I got to know, quite a few of them who often turned up to some of the workshops that I organized, including you as well.

So these are the people that are seeking for learning, for guidance, and looking for different perspectives. Because these workshops are not frequent, they are once in a blue moon and either you get it now or never, so there are people even want to pay themselves for these workshops.

Right off there, I got the right people who have this thirst for learning. And I’m not sure if this is something that’s, I would say everybody should do it. Because there are multiple factors. The prices that I set in the workshops is at the cost price, to make it possible for people to attend, but there are also people who couldn’t attend because they will have to fork out or they would have to self-sponsor themselves, company wouldn’t sponsor. And I think there are financial matters that even people who want it, they may not be able to attend it. And there are some people who don’t find a relationship to that. So if I were to say that, no, you should go for this, this workshop, but if they can’t find a relationship, there is a disconnection. It may not be the content is bad, but it may not be at the right time. Or maybe really that this content is not relevant to this person at this point in time. And I fully accept that. So what I would rather encourage is that people to think for themself, it can be very short term, how they want to improve their work right now. And usually that would lead them to find more answers to the questions that they have. And probably, one of these workshops could connect.

Experiment of Going Back To Being Employed [00:25:21]

Henry Suryawirawan: [00:25:21] Stanly, I realized also looking back at your career in the last few years, you moved out of Odd-e for a while for like one year, joining GovTech. And before that, you told me that you had a thinking process behind it. So can you share a little bit, what made you make that decision and also what have you learned going back to the industry for like one year or so, before you joined back Odd-e now?

Stanly Lau: [00:25:44] So , in Odd-e I’m often being an external person and that is I’m not the internal staff. So I don’t get the internal bureaucracies and processes that is required aspect of an employee, a typical employee. Being in this external position for a long time, I see things of course on the outside of box perspective. I also acknowledged that I’m missing or maybe I forgot how it was like 10 years ago when I was still employee of a corporation. This is about empathy as well. The people that I coach software developers that I paired with them, what are they actually struggling with in the company?

A question popped up. I do not know this question. I know that knowing this question or this answer can help me improve my work in the future in coaching them. So therefore my action is to join a company. I did this deliberately for a one year experiment. One experiment, join a large corporation. And at the time I have two choices. In the end, I decided to join a GovTech, with the help of Steven Koh. It’s also interesting to join him at that time. He’s under Government Digital Service. I got to see what kind of leadership he is in the company.

So eventually I joined that and I’m a subcon to Ministry of Manpower as a software developer. I think I enjoyed that a lot. Although I struggled a lot as well. Like the first thing that I struggled is that I have to reach the office, follow the office hours, 9 o’clock or 9:30 to reach there and then leave by 6 or 7 o’clock. Back in Odd-e, I , there’s no timing, there’s no work hours kind of concept. So I struggled that for quite quite a bit. And then I also get to have performance appraisals. 10 years, I need to do performance appraisals for myself again. I have a supervisor, I have a tech lead, and this hierarchy of things, and there is managers and so on .

When I joined, I didn’t expect what I would learn. I’m just open minded and, and being a obedient staff, try myself to be in that position and what would happen. What comes in the first three months is that , as I pair program or work on the functionalities, working on programming. I somehow have a imagination that I have this soul spirit that goes behind me, seeing myself at this position, and comparing myself more than 10 years ago before I joined Odd-e as a software developer. And then this two person, how Stanly was like back then, and then how is he now? The things that he would think, the things that he would say, the things he would communicate and do, are very, very, very different. So, I didn’t know that I could get that kind of reflection on myself. So I’m, I’m very surprised on that.

So that first is self awareness. I learned more about myself, the difference that I have that is probably more than 10 years apart, when I was still a software developer. The other part of learning is also, in the past, you know, I may not actually ask the customers or the users, I may not validate my assumptions with them that much. I would keep on coding. But now, I would find ways to validate my assumptions much, much early on. Like there’s one, one case, which is typical is that you have a backlog item, product backlog item, user story for example, to do some functionality in this screen. So then a typical developer would just, I see as myself in the past would just look into that, or what are the statements or in the JIRA ticket, what it says, and then I will try to code according to that.

So, what I did differently this time is that I come out with specifications, executable specifications in Cucumber. So coming up with a scenario, if this happens and then, if this is some of the input and then based on a user action, what is the expected output. I come up with one scenario with my pair first. My pair was quite eager to get onto the code. I was like, hold on, wait wait, I don’t quite understand and also because I am new to the domain. So I come with one scenario first, and then I, I try within, is this what you understand? And then he says, I’m not sure. I think so. And maybe let us ask the product owner. Then we ask, pull the product owner in, and then she, she sees and then, no, I think there is something, something different. Immediately we validate our understanding on the business level. Can you imagine we went into code and we think that this is how it is. We trust the documentation.

So, I never worked at this level that deeply as much as, when I was as an Agile coach back in Odd-e. But I can also see how this challenges my peers around me as well. I often bring out perspectives that he hasn’t thought about.

There is another conversation with my pair. I think there was an integration work and he wanted to create this classes because that’s what the task said. I asked him, why do you need these classes? He couldn’t answer. During our reflections, he said he should perhaps first think about why he needs those before jumping to code.

Henry Suryawirawan: [00:30:51] That’s very good learning. Yeah.

Stanly Lau: [00:30:53] So interestingly, I’m supposed to be a software developer, coding. At the end, after the close to end of one year, my colleagues told me that, you know, thanks for your coaching. I don’t deliberately want to coach, but it happens to be.

Henry Suryawirawan: [00:31:08] So having experienced all these, first of course, you improve yourself internally, your self awareness and things like that. You also have seen all these working practices could be done better. So now coming back to Odd-e , putting your head back as an Agile coach. What can you probably now share with all your customers about what you have experienced from that one year, and things that they should be, either like focusing on, or maybe thinking of improving, instead of just hire a coach and, you know, everything will be okay?

Stanly Lau: [00:31:40] I think that it is less of that parts where I could tell them that what they should do. There is more about my empathy on the teams that I work with now that I’m engaged, that in the past, I used to have this expectation that we pair program for some time, or maybe I give some workshops. I think you should know these topics.

But when I see that you don’t, then I have this feeling that, no, you’re not really learning or no, that’s, is there some, some problem with how I teach. I begin to be more empathized that, they have their struggles because of the other kind of policies, expectation of them from the company. They may not be able to pick up these skills as much as I hope. And that is okay. I begin to accept this fact and with this information, it also helps me to revise my expectations of a coaching engagement with my sponsors. Or maybe they expect that, oh, you’re here for one month and then I would expect them to, the developers will be level up immediately. So I would be able to bring out some examples of, what they’re struggling with and that deters them from learning as quickly as you would wish that they have.

3 Tech Lead Wisdom [00:32:51]

Henry Suryawirawan: [00:32:51] Right. So Stanly, towards the end of every episode, I will ask my guests about their three technical leadership wisdom that they would like to share for the listeners. So would you be able to share, what do you think are your three tech lead wisdom?

Stanly Lau: [00:33:06] First I would consider the, the, the word tech lead as a leadership is an ability, is ability that anyone in software development could have. It’s not necessarily that you must be in the tech lead position. So as a new joiner or even you are experienced a software developer or product developer. One of the things that I find very valuable and yet lacking is having a broad perspective. Broad perspective can comes in different ways. It can be knowing your domain, the business domain, in a broader scope. It can be, instead of just focusing on one component of the, of your application, you could understand how it all links up together, right from code til building packaging, testing, to production. And it can also be a broad perspective in the sense that understanding the dynamics in your company or how you guys work, for example, maybe in your team right now, you do have a business analyst and you have a tester and you are developer, and broad perspective it also means that you understand you do not just focusing on programming, but you also understand, what is required of getting a good test results. How to come up with test cases. You’re also open to understand how to analyze requirements. How do you actually talk to users or customers. Without this perspective of your peers, maybe in your specialized role, it is very hard for you to collaborate with them. Collaboration is not keeping my specialty as my specialty, and then working with them in this manner. You can’t get collaboration from that. You get collaboration from understanding the other disciplinary skills. And then you can anticipate and you can empathize what they need, so that you can work with them better by providing them, being more sharper in providing information to them, being sharper in asking for specific information. So that is a broad perspective.

The other skill is listening. It is very common if you are just starting out as a junior programmer developer. Through a few years, I often found, depending on the culture as well, there is more about winning your argument than listening, what your peer, where he comes from, what brought his or her argument. If you have that perspective, then you would ask more questions, and you will be able to listen better. There are different levels of listening. A typical level one listening means that I listen to form an opinion so that I can win my argument. The second level of listening and a third level is more towards really understanding what is the behind this person says. Does this person have certain fears or worries or concerns? Then instead of sticking to what they say literally, we ask questions to elicit what they are feeling about it. With this, it helps yourself to understand other people more. People will open up and you would have a better conversation with them.

The third thing is mentorship. It is hard. I’ve been in this journey and took me eight years to find ideal mentor that I would learn from. I think I gave up at one point in time , but then I found it. So my assumption is that eventually you’ll find a mentor. Look for Michael Cheng, his community developer community is great. He connects people together. You have that opportunity that I don’t have before. Back in the time where communities are still more rare, people don’t come out and talk about things that, that much. Join the communities and see who you can meet and learn from . Within your company, if you find there are people who is interested in improving, those are potentially good mentors that you can learn from. Yeah.

Henry Suryawirawan: [00:36:48] Thank you so much, Stanly, for sharing all your knowledge, your experience, and especially your unique point of view. I personally myself have learned a lot and I hope all the listeners here could also use this knowledge and level up your understanding about Agile, and also what you should do in order to improve yourself.

So, one final question, Stanly, how do people find and connect with you online?

Stanly Lau: [00:37:10] They can join the Agile Singapore meetup group. Facebook as well, you can Facebook message me. I could provide my email address after this, so you can reach out to me as well.

– End –