 There are still some seats at the front that could take the VIP seats here. Okay, let's start a very good evening everyone. I'm Stanley. Welcome to the tonight's Agile Meetup. So this is the first time I'm starting a new series called Agile Journey Series. The point of this series is to invite people in the organization who have started their journey of Agile and to invite them to share with us their experience. So I'm very happy to be able to get Winston from S.P. Digital. And I would also like to thank S.P. Digital for sponsoring their venue and also Pizzas for us. So without further ado, I think I'm going to kick start this. This session is going to be pretty casual. We are going to imagine there is a fire site. No, fire camp, campfire, whatever, over here. Talk over that campfire. So maybe to get some starts, maybe Winston, can you tell us more about yourself and what you're doing at S.P.? Okay, hello everyone. My name is Winston. So yeah, like what Stanley said, I think let's keep it casual. If at any time you have questions, feel free to ask. If not, it could be until we are done to the Q&A section. I also have a lot of colleagues with me today. So in any case, if I start to bullshit, please call me out for that. Because I do hope that this session would be very open, transparent, very truthful on our agile journey so far. So to answer Stanley's question, who am I? So my name is Winston. I joined S.P. Digital almost when it just started. So it's like two months after S.P. Digital started. So Michael and I joined together to sort of like help put in agile practices for this place. Of course, it evolved along the way. And right now, if you ask me what am I doing now, specifically leading a team called Engineering Excellence. And Engineering Excellence covers three important pillars. The first pillar would be on culture, developer practices. So agility falls into this pillar quite nicely. And then I have another pillar called Engineering Effectiveness, where we look at building internal tools or getting external tools in to help make our developers 10 times more effective in how they are working. And the last pillar is Technical Excellence, where we also have a team of quality engineers who are doing a lot of test automation, a little bit of manual testing and stuff like that, to keep the quality of products that we roll out to clients at a tip top shape. So that's basically what it has evolved till to this stage so far. Could you also share with us about your background like people, S.P., where were you and what do you do? Okay, so without going all the way in time, I think I just mentioned the important parts of how my agile journey began. So I would attribute that to my base at Pivotal Labs. How many of you have heard of Pivotal as a company? Alright, a lot of you have heard of Pivotal, right? So before they were called Pivotal, they were called Pivotal Labs. And it was just a consultancy specializing in Ruby on Rails. So that was like how many years, nine years ago already, when they decided to come to Singapore to set up shop in Singapore. And they sort of asked if I wanted to join them as a developer, as a local hire, because they'd be setting up shop in Singapore. At that time actually it was very funny because I was already like transiting out from being a developer. I was going to become a product manager. That was like the aspiration for all software engineers in Singapore at that time. So it was like, hey, do you want to come back to be a software engineer again? And at that time I was really skeptical. Hey, do I really want to do that? Or am I just going to be my product manager? But I started to read up about what Pivotal Labs does in terms of engineering. I found it very interesting because they were doing peer programming. And it's not just occasionally. They do peer programming every single day from 9 a.m. to 6 p.m. Every single day. And then they do test-driven development so on and so forth. Basically all of the XP practices that you read, they do it every single day. So at that time I was like, oh, are you sure? I'm going to sit beside someone staring at the same monitor for 8 hours now, hours a day. Why go mad because of that? And what if I don't like my pair? So I was very skeptical. But I went in for the interviews, et cetera. And I found that, oh, actually it's not that scary and seems quite interesting. So it felt like it was an opportunity. I get to enjoy or get to learn without having to go to San Francisco. So I decided, okay, let's give it a try. If not, then I'll go back to being a product manager. So I went and luckily I passed the interviews. And that began my agile journey. So for 3 years I was with Pivotal Labs Singapore. And of course to them, they're not explicitly calling it agile anymore, et cetera. It just became their way of life in Pivotal Labs. Doing pet programming, doing test-driven development, so on and so forth. So that was the culture I was immersed in. After 3 years, I sort of decided to leave and start my own consulting agency, which I call Jolly Good Code. Why did I do that? Because I find that it was interesting. I got to learn a lot from Pivotal Labs. But at the same time, I wanted to have access or have control or be able to reach out to more fellow startups in Singapore and try to help them on this journey in understanding what agile was about and how they can do better with... I would feel software engineering management in general. Because like I said, before that, a lot of engineers are just thinking of becoming a project person after a while because software engineering management, I feel, is still a very nascent kind of discipline over here in Singapore. And a lot of engineers are living because they don't get that. And so I wanted to do more with startups so that to make sure that people feel like they are valued as a software engineer. So I went out to do my own. So it's Jolly Good Code. I would always say it's like an extension of Pivotal Labs. I do roughly the same thing. I do consultancy. I help build startups. I write code. I also do some pure agile training. I also do some pure Ruby on Rails training at that time. So these are the things I did for the three years before I actually joined SP Digital. I'm curious. Why do you call it Jolly Good Code? Why do I call it Jolly Good Code? Because I feel that I hope that I would be happy doing good work and writing code at the same time. So I decided to call it Jolly Good Code. Did you achieve that? I do feel that I achieved that within those three years that I was running Jolly Good Code. And so it was a consulting as a business nature. And after a while, I felt that consulting has its pros and cons. One of the cons is that if you scale it very big, then you get into a lot of consultancy challenges where sometimes you have to take in work just to be able to feed the people. And that might compromise the quality of work that you are doing or your principles in terms of what kind of projects you take on or not take on. So those are the challenges. And then when SP came along, I found that this is probably another stage for me to do agility, for me to do software engineering management at a bigger scale to see how I could further expand the horizon of building a software engineering unit that would potentially be well known through its strong practices and strong culture. So that's why I decided to join SP Digital and take a pause on Jolly Good Code. Could you share with us who are the few people or mentors that influence who you are today? So I would again largely attribute a lot of that back to my pivotal labs days when I interacted with a lot of my peers who came from San Francisco. And I felt that they brought along the culture that was missing here and that I wasn't a part of. A lot of it includes open communication, includes collaboration, includes empathy, etc. For example, on the first day, I still remember on the first day in my work when I was doing pair programming with my pair and he had to send out an email to a client to explain on certain things. So he typed whatever the message was, I can't remember, and then he signed off. He signed off not as himself, he signed off as him and me. I'm like, I didn't even do anything here. But that left a lasting impression to me because he's like, oh wow, he really treated me as a pair and that we are really doing the work together. So even though he's just replying to the email himself, he put in my name as well. Maybe he wanted the responsibility to follow me to know I'm kidding. No, but that felt good because it felt like, wow, you really empathize with me as a person and you want me to be involved. Of course, it's just one of the examples. And then a lot more examples are then my boss back in Pivotal Labs who I learned a lot in terms of how to be a nice person in general. What does that nice means? I don't know, it's really true, you know, daily interaction of how he empathize with us, how he empathize with clients. So it's very non-judgmental and it's always operating on, let's understand the data first before we come to a conclusion and let's always try to work this through together as a team. So getting the teams to do retrospectives very often. So back in Pivotal Labs, we had breakfast, right? So we even do retrospectives for breakfast to retrospect on how good the breakfast is and stuff like that. So a lot of these things, I think that sort of form a lot of my philosophies and a lot of my opinions that I carry on even to today. Nice. So in your own words, what is agile? So when I was, so remember I said when I was running Jolly Good code, I would sometimes go and do like a two hour session to talk about what agile is. So I would talk, talk, talk, talk, talk. At the end of the day, you know, at the end of all my slides, I would have one slide. I would just say, okay, if you all forget whatever I say, you can just remember that to me, agile is about constant feedback, right? Because I feel that it is about a lot of practices that we do is about the feedback. We can go as low as, you know, the developer practices, test driven development, it's feedback between you and the code, right? You write a test, the test fails, and then you write a code to make it pass, it's feedback. And then if you talk about daily stand-ups, it's feedback. It's feedback within the team, right, between individuals. Then you go up one level, you talk about your sprint planning meetings, iteration planning meetings. Then again, it's feedback, collecting feedback. Then if you talk about on a larger scale, now we put in a lot of like hypothesis testing, you know, validation, you know, we want to be fast in terms of proving our ideas, et cetera. That's also feedback. So, I mean, to me, that sort of captures the essence of what agile is really about. But with my time here in SP Digital, right, I've also formed a new talk. So, yeah, the video is flaming, but so what I told my guys is that now I feel that agile to me is just fucking talk. Because I find that a lot of people are just doing talk. And that actually creates a lot of the miscommunication or miscollaboration. And, you know, people think that, you know, putting in more tools, more processes would actually help. But I think it only helps to a certain extent. It's just, it only solves the symptoms. It doesn't solve the root cause, which is that we should just talk. Like this one, individuals and interactions over processes and tools. Exactly, exactly, right? Yeah, so the funny thing is, yeah, we were in a workshop and then the first leader asked us what is the 12 principles of agile, right? Nobody can remember it. But I just read it up. I just read the second one, you know, which is like, we should always favor change, right? Or something like that. Interestingly, you know, developers always tell us, I know we don't like change at the last minute or things like that. But actually, that's one of the principles in agile. You should favor the change even if it comes at the last minute, right? Because your process or rather the workflow that we do should actually allow us to react to that very easily and very quickly. That challenge comes, it's also people are naturally or most people, not some people, changes are something could be unfamiliar. The familiarity zone, comfort zone and unfamiliar zone. So how people deal with the unfamiliarity could affect how they respond to it when something unfamiliar comes. Okay, we are going to shift more into SP Digital in your time over here right at the beginning. Share with us your journey challenges and also what you tried, what doesn't work. So when it started, it was really Michael and I, right? So Michael also came from Pivotal Labs, but we were of a different era. But whatever I know, he knows as well, right? So when we started, we sort of have that pure intuition of, you know, we want to make software engineering awesome here. Of course, we have to, I mean, in essence, it's agile, right? We have to call it agile. But if you ask us, right, you know, what flavor of agile do we do here? Then I think that all of us can answer it because to us, it will just be agile. And then people will give us a weird stare, you know, what do you mean? Do you mean scrum? Do you mean Kanban? And I know we do agile, right? Because to us, that's our philosophy. That's our belief that, you know, agile is just agile. Yes, sure. You can use scrum. You can use Kanban. You can use XP. Actually, we use a mix of them here. So it's also very hard for me to say we use one thing. So I'm not a purist in terms of that. So when we started, right, what we really tried to do is do a lot more pair programming with the teams. We get embedded in the teams, you know, we try to work with them. We try to, you know, help them do planning, try to introduce the technical processes, everything. But over time, you know, the team suddenly exploded. It started hiring more as in hiring growth, right? And because there was only the two of us, it became a bit unskillable, right? So I think that's our biggest challenge. You know, how do we scale that process to a lot more people? And even to today, I think we're trying to figure that out. So what we started to do after that is to write more documentation. In fact, then I got in Sylvia to help me. So Sylvia is the agile specialist in our team right now. So she's purely focusing on agile specifically. Unlike us, you know, we were sort of like, we don't call ourselves agile specialists. We identify ourselves as software engineers, but we had that knowledge. Even if you ask me now, I'm not scrum certified. I'm not whatever certified. So you might say I'm an imposter. So we got in Sylvia to sort of focus on agile specifically because we find that over time as the team grows, then inevitably we need to put in the guidelines, the processes to help reach the communication between people and to make sure that people still talk with each other and with different teams, et cetera, to move the project along. So I would say we have tried to put in things that we are familiar with and things that we believe should be there in an agile organization. So starting with technical processes, right? I mean, we try to encourage people to do test-driven development. Of course, if you ask me, is everyone doing it now? No, the answer is no, right? I'm not going to lie to you. It's very hard for us to make sure everyone can do that very nicely. Even now, the challenge is do people even write tests? I think that was one of the evolving challenges. Because new people come in, they bring a lot of different knowledge. They bring a lot of baggage. The baggage can exist in the form of they had a lot of agile training, but maybe specifically the scrum, let's say. So they think that agile is scrum. It could exist in the form of they had no training at all. So then they don't know what to expect. Or it could exist in the form that they had the wrong training. So they come here and kept talking about the wrong training as well. So there's a lot of things that we need to sort of unbundle and fix and educate along the way. Even till today, I would say we are still trying to tackle all of these problems, getting everyone aligned, et cetera. And that would be our main challenge. So like I said, we bring the technical practices. We then also put in all of the stand-ups, the planning meetings, so on and so forth, but we try and let the teams iterate and figure out whether this makes sense for them and tweak it along the way. I think one of the challenges is also that when Michael and I started, our belief is that we do need a scrum master. Because back when we were with Pivotal Labs, we worked as a software engineer and then it's like a self-managing team. Everyone contributes. The life is good, right? But when we come here, then I think that was one of the things that we experimented and it didn't work very well. It turns out that somehow in a large organization like this, with many teams running, maybe we do need someone dedicated to agile and to be specific to that. Right now, I mean, we are still talking about the idea. Do we really need a scrum master per team? Do we really need to train one per team? I think we are still trying to evaluate and see if that is the right answer or not to running agile teams. But of course, my hope is that all the teams will be just self-managing. You don't need one specific role for that. And I'm sure a lot of agile coaches here, some of agile coaches will also feel that even as agile coaches, your role will be to come in, help educate the team, pack the team nicely, hopefully they can self-manage, then you will exit to go to other teams. So that's our belief. So we are still trying to talk about the idea and see whether it will work or not. When you talk about the growth, hiring, what are the numbers like? So, I mean, three years ago, I mean, we started with one, Sao Xiong, right? Then today we have around 150 people. I think maybe 80% are engineers, if I can remember the numbers correctly. And still growing? Yeah, still growing. What contributes to the... Is it a need for growth? What influences the growth part? I mean, definitely, there's jobs coming in, so there's a requirement for growth. I mean, if you talk about SB Digital, maybe I explain what SB Digital does, right? So SB Digital is like a team that was formed three years ago for SB Group. So SB Group is the one that sends you the utilities bill every month. But that's not the main line of business. The main line of business is in the transmission and distribution of electricity, right? We own the grid. So SB Digital was formed to do, like, digitalization for SB Group and also to identify new products in the energy space that we could potentially build. So we have two main interests. One is in consumer and one is in commercial and industrial. So if you talk about consumer, it's the mobile app that you might be using on your phone right now that allows you to check your bills, pay your bills, and also any other things that might potentially be more consumer-facing in nature. When we talk about CNI, it's more of the B2B businesses. So things that I can publicly talk about are things like, you know, we put solar panels in community centers, in SAMCorp, and then we build software solutions to help look at the load profile, to look at, you know, how we are drawing electricity from the solar, from the grid, and how we can optimize their load, so on and so forth, together with AI and stuff like that. And so, like, a mix between commercial and consumer is that recently we also put in electric charging vehicle, electric vehicle charging capabilities in the app itself. So you can now use the app to charge your electric vehicles if you see charging stations around the island that is owned by SP, right? So these are the things that we are building. Could you share a bit about what kind of roles or skills are there in the team to serve, to work on the product? So it really depends from the consumer piece. Usually it's more of the regular software engineers, you know, with front-end capability, back-end capability. Of course, because there's a mobile app, then we build our apps natively, so there'll be folks who are focusing on iOS, folks focusing on Android. For the CNI space then, we also have these, without the mobile developers, but we also have sort of like what we call IoT engineers because when we talk about the solar panels, you know, hardware, we actually build small boxes for us to collect data and bring it back to us. And these data are like on the IoT boxes that we build. So we have IoT engineers who are actually handling that. But otherwise, yeah, it's the same mix of software engineers in general. What is, how big is the team size here? Is there any guidelines? So it's a mix. There are some that's like two people, some that's like seven or eight or even more. And we are sort of going through a revaluation of how we're structuring the teams right now. And increasingly, you know, so we have two different parts, right? So one part might be more functional in nature, splitting people in terms of their abilities. And then another part could be experimenting with being more feature squad type right now with a full set of capabilities within the teams. So as you can see here, I mean, we try a lot of different things to see what might work, what might not work. I think it depends a lot on context and a lot on the people skills, etc. and how we shape that. I think we have been talking about almost half an hour and I thought to open up the questions from the floor if you have any questions for Winston. Now is the time. Questions. Do you work with SP Group IT? And are they agile? We do work with them. Good question. Because for example, when we talk about security, when we talk about hardware, on-prem hardware, actually they will be helping us with that and security and stuff like that. They will be helping us with that because we do not have all of the functions here. And no, they would not identify themselves as agile, right? So the challenges also come in the form of how to sometimes work with the mothership. I think it makes back our feelings. Sometimes you just have to default back to the processes that work for them because otherwise it's very hard for them to collaborate as well. That would be my answer. You shared a lot. There's a strong focus on software engineering and practices. Can you share a little bit about the product and maybe the user experience parts? What would be the mixes? My hit of UX is actually here, Chris. So share a little bit about that. What would you like to know more? Ah, okay, okay, okay. Ah, good, good, good. So more context of that is that in the past product engineers would actually sit within SP Digital formally. So they were part of the HQ and stuff like that and they were working with them in that kind of relationship. Recently, we sort of brought them in to the mix so that it's all under one organization. So in the past, it felt a little bit like vendor-client relationship to a certain extent. So it could be very agile here but a little bit more of deliverables and gated process there. But I think increasingly we are trying to bridge everyone together to make sure that we're all concerted and aligned on what we're trying to do, how we're approaching this at a product angle and things like that. UX has been with us since day one. So a lot of, I mean, we do UX research. For them, they do a lot of hypothesis testing. They do a lot of user validation to make sure that whatever we are building is what users want and then they keep on improving the UX in that manner as well. So UX and developers are very tightly integrated. But, okay, so for example, like my team, right, and UX, so my team is engineering excellence, we act like the support teams, a shared services team. We are not specific to one product. So we have a lot of product teams that are specific to that but UX team and our team and a few other teams would be more of like, okay, you have requirements and we will come in and help you. Because, yeah, so certain things, we are not like fully cross-functional where we have one dedicated person in that team. We do try to say, okay, this product has a lot of requirements now, then we will dedicate that person for this period of time, but it's not like, you know, we won't shift the person around for shared services in that sense. More for economies of scale. Okay, so from a product management perspective, how is it managed? Is there like a central group to define what's gonna be built or each team has the ability to define what they're gonna build next? How does it work? Because the domain is quite different from, you know, regular domains that maybe a regular person like us would know about. A lot of times, product requirements do come from like a centralized group of product people who have done a lot more in-depth research or domain knowledge within that area of focus, right? But of course, then they would come back to the developers and, you know, we would see what is visible, what is not visible, and whether it can be done or not. So there will still be that kind of collaboration that we would see, you know, between the product and the developers. Of course, I think as what I've mentioned, right, all of these communication and collaboration can definitely all be improved even further. There's definitely still gonna be some gaps in terms of how communication, how the information we just asked, you know, is it too early, too late, and things like that. I'm not gonna sugar coat it, right? So it does still happen. But it's more about making sure that we are explicit in telling the product people, hey, you know, we definitely need to work this out. We do it in a different way. One more question. So being a consultant yourself, have you ever thought about engaging consultants or is everyone internal? So lately, I've been toying with that idea, but more with the sense of from a training perspective. Because for example, I said, like, as the team scales, right, we start to notice that everyone comes in with a different set of baseline in terms of what agility is about. So if you ask, you know, different people will have different opinions. Some could be right, some could be wrong. Some could be extreme. Some could be non-extreme. So I feel that that's what I'm thinking about in terms of, you know, tailoring a customized training program that could be more contextual to what we feel is, you know, our type of agile and to at least spread that across the whole team and maybe specific to the roles that people are playing. So maybe product owners could have something a little bit more specific to them, developers would have something more specific to them. If they want to play that scrum master role, they can have something that's more specific to them. But I mean, yeah, my challenge is that if we look at training in general, across the board in Singapore, there's a lot of scrum training, right? But like I said, then if you ask me what's my type of agile, it's not scrum, it's not combined, it's not XP, it's just agile. That is a challenge for me in terms of finding the right training. Because sometimes, I mean, not to bash scrum, right? When people go for scrum training, they come back, then they'll be like, oh, we need to do this, this, this, this, this. You know, very dogmatic. Yeah, then like, to me it's always, actually I want you to go and understand the principles of what agile is about. Even though you cannot, you know, memorize the 12 principles, it's okay. You know, the core behind it on what actually is agile. I wonder after hearing this from Winston, someone is going to create an agile training. Okay, raise your hand. One, two, three, okay, let's start. Yeah, sorry, I have a lot of colleagues here. If I push it, please call me out on it. It's okay. Hi, based on your expertise at SP here, on SP agile journey, and also at your own venture as a coaching guide for new companies, do you have any list of common agile traps which companies may fall for while implementing agile, like common mistakes that they may end up making during agile implementations? Can there be something called as too much communication? Yeah. I've never seen too much communication yet. So usually there's too little. I would say a lot of times, I would say one trap is that. Like I said, you know, people would want to say, okay, let's have this process here. You know, let's put in this tool here. They would think that, okay, so firstly maybe, they would think that the tool can solve all of the problems. But sometimes only solve the symptoms. And they would think that, oh, we need to put incident process in place. But if you really start to map it out, you put in a lot of process, right? Then everything just becomes very gated. Then it just actually looks like waterfall instead of being agile. Which is why we were almost going to fall into that trap. You know, I was talking to Sylvia with like, okay, let's map this out. You know, okay, maybe we should have, you know, this gate here to check on certain things just before it moves there because developers are complaining about this and that. But you know, as we map it out, then we're like, this feels like waterfall. Then why are we not doing waterfall? Then we're like, no, no, no, this should be... Then we started to cancel, right? No, no, no, this is not right, this is not right. Because you just talk. So maybe we should be thinking about processes that will help people talk. So I think then one of the challenges is that then people will start thinking that there's a lot of meetings to talk. So the challenge is to identify then who are the relevant people that should be part of the meeting. How can we make the meeting more effective? How can we make the meeting more productive? So that people will find that there's always value in going to these meetings. Unfortunately, I think as the number of people increase in the team, right? Communication has to increase as well. You cannot say you minimize it because if you minimize it, then there's going to be more miscommunication. Some people would feel like they are being left out of the decision-making process as well. And that's not what agile is about, I feel. So I think it's a double-edged sword. So maybe the correct answer is to then find the right level of team size so that that can stay in. Correct, correct, correct. Since you mentioned about now you have 150 plus people here. I guess probably you have more than 10, 20 agile teams, independent teams. So how do you manage the collaborations and knowledge sharing, license sharing across the agile teams? And probably you can share more about how you build the culture here at SP Digital. Ah, okay. So every Thursday we have tech talks over here. So if you look at the board over there at the door, it's our tech talk schedule. I mean we are missing two weeks because this week there's a lot of people who was out for goal fundamentals training and then next week it's like holiday. It's one day after holiday. But if not, we will always have tech talks scheduled on Thursday. And it started very early since we joined and mainly so that we wanted to make sure there's a forum for people to learn. It could be technical things that's related to work or actually it could be non-technical things. I think one of the first few talks was about how to solve the rubric cube. But there are also talks that are very relevant to the domain that we're in now. Nowadays, you know, some people give a talk on energy industry and things like that. That's one. And then we also have cross-sharing between teams that is domain-specific, technical-specific. So this is a little bit like a Spotify model. So for example, we have a lot of developers who are doing goal in different projects. So every two weeks at a certain point in time we will bring everyone together to share about, you know, their experience in using goal on the projects, what they want to talk about and things like that. So with regards to different programming languages we will have the different sharing tracks. Those are two of sort of the, you know, specific learning activities that we put in to make sure that people cross-learn from each other. General culture, yes. Yeah, actually it's not easy. It's very difficult. I would say I don't have a good answer. Even I'm trying to figure that right now. I mean, our hiring process, okay. I mean, through our hiring process, that hiring process is definitely one of the first gates that we have, right. So that we will definitely screen for culture fit. So our hiring process is we will first send a take-home test, you know, check on technical ability. Then we will bring the person in, you know, we will have a chat. We will also do two rounds of pair programming with our developers to make sure that, you know, everyone is comfortable. Although we don't do pair programming here, you know, on the daily basis, but so for us, pair programming here is like, we use it as a tool for us when we require, for example, knowledge sharing. There's a very difficult problem that we need to work on, et cetera. So we actually have pairing stations set up at the end of the room. So we have a few pairing stations set up. So if you want to pair, then you can go over there to do pairing, right. So we make sure that there's conducive environment for them to do these kind of activities. Thank you. My question is about how you manage the potential chaos. Because you mentioned about you're allowed to have a change of request at the last minute. So if it happened too frequently, then would it affect a team to achieve the goal of a spring? Secondly, you mentioned about you basically share a resource across different teams. So if it happened too frequently, would it have a case that people are fighting over resources because they have different goals to achieve? So let me answer the second question first. So product teams will definitely have their own dedicated developers who are working on the product itself. The shared services is more of like we know we would have this challenge. So we are sort of built to try and handle that or to give relevant expectation to the teams that okay, we are focusing on one now. I cannot focus on another. So for example, to give example of Sylvia, she's our agile specialist, but she can only work with one or two teams at one single point in time. She can't work with all of the teams that we have here. You know, it's that communication. So of course other teams will be screaming out, oh, we don't need that, we don't need that. Then we'll be like, yeah, okay, okay. So the picture is we are hiring for agile specialists. But the second thing is that then we will communicate that we don't have the right person to do this now. Actually, we want people to be self-managing with someone to step up and do some of these roles that you believe was supposed to be a role of the agile specialist. So we ask people to try and step up in certain things. So what was the first question again? How to manage the chaos? Frequent change request? Yeah, actually that one have to... I think developers... I have to ask the developers actually, right? Because I'm not on the day-to-day coding. I mean what we do is I think we do try and make sure that changes in the last minute would be reasonable. If they are really drastic changes, then maybe it should be a new story instead. Right? But of course, you are right. You know, actually when we do team retrospective such things do come up. And then when we dig into it, then maybe it's like oh, it's because the user requirement wasn't clear enough in the first place and that is why it resulted in all of these changes. So for us then what we try and do is to fix that root cause which is then to check with PO, hey, can we do a much more deeper dive into the story before even we start? So we start to do like pre-IPMs to dive into the story to see how we can understand the story even better from a UX perspective, from a developer perspective, from a product perspective before the developer actually start. So then we spend invest time in the pre-building activities instead to minimize debt. I'm not sure if that helps, maybe Kenneth will be able to answer that. Yeah, does pre-IPM help in reducing chaos? Hello? Yeah, so probably the correct word to use is refinement backlog. So before we come to spring planning, the PO tells us hey, we want to work on this story. So it's sometimes our record pre-IPMs where we our product planning period can be longer than one day. Sometimes we have multiple features running so how, for example, my team what we do is that for a sub feature, I would try to get an owner for the topic Equipment Engineer who will actually ask the PO what do you want to do and before the meeting, because we don't want to come to the meeting and then let's waste one hour brainstorming about ideas or trying to solve the problem. What we try to do, we try to ask somebody to propose a solution and then when we come to the meeting we will just tweak the solution based off what was proposed so that meetings become more effective. So when our meetings are now more structured, we don't waste so much time and in fact what is currently done is that for we have two-hour sessions two days of two-hour sessions and then I'll tell people this at the pre-IPM these are the items that you're going to talk about. If you are interested, you come in and sit in and we found out that a lot of people are enthusiastic about it and at this point we have a lot of engineers trying to own the topic and trying to drive the stories. So this whole thing, I would say credits to Kenneth for stepping up into doing this for the team because if you ask him, he will identify himself as a software engineer as well, not as a agile person and that's what I'm very concerned in seeing people stepping up to take on this responsibility and that's really what I believe we build the culture, we build the support environment to allow this to happen hopefully with more people. Yes. Sorry, we have one question for you first and then Samantha, Daniel. Alright, so you say that you follow the different practices in agile but you just do not want to say to anyone that you do not, you are following or you are following XP or something like that but you just want to say that you follow agile, simple. It means that you just do not want to restrict any practice to be followed in any particular application development or something like that. So in your journey you might have tricked it a little bit less or more according to the requirement or the team size etc. So what is the outcome till now? What kind of practices do you think which work best for you which you had to pick up to some up to some extent or something like that or the pure agile, Scrum or XP practices which work best for you? Okay, good question. So I would say definitely over time I think we picked up a lot more Scrum right because I think I don't know I feel the answer maybe is because it's much more universally understood and it's quite specific in nature on what it means what it does so it might be easier to communicate that as a start. So maybe if you ask me to think back on all of these maybe what should have been and this is what the feedback I got a lot from developers as well right because we say it's agile it doesn't give people a right framing there's nothing to catch on so sometimes people feel a bit lost so maybe we should have done this in the first place and also just say we do Scrum so it's like training wheels right so you are on the training wheel you just do root practices only until one day when you really don't need it anymore then you can remove that maybe that's another methodology we should have adopted because then over time we do find that we take more Scrum because that's more easily explained but at the same time then some people are trying more Kanban style as well like the TV here they plan their stuff in Kanban so again then that's why I don't want to restrict sometimes when you say specific things like or we do Scrum what if the team really want to try Kanban then you know they feel like oh I cannot do that or things like that so in which scenario seeing the Kanban can be more effective so in which scenario you didn't assume or you just tell that the Kanban can be more effective no the team sort of wants to try that you know because they are familiar with that Kanban so then they decided to try themselves I try not to dictate and say we should do it something something something the audit world will want me to dictate so that it's all documented and people don't follow the documentation then something wrong but to me that's not agile agile is allowing people to figure out what works best for the team with the relevant knowledge with the relevant skills with the relevant context thank you we have time for the last two questions Samantha and the gentleman behind hi are you able to share what kind of metrics you look at in achieving engineering excellence so when we talk about engineering excellence I think there are a lot of facets to it right which is why I said the engineering excellence as a team we have three main pillars that we look at we look at culture, level practices we look at engineering effectiveness, we look at technical excellence so there are metrics that we would probably be looking at each I would say we are not absolutely the best at looking at this but when we did try to build dashboards to visualize how teams are doing so one part of new idea that we want to try with regards to agile is to use data as well to guide us in our planning guide us in how we are working which is why I started to toy with the idea of taking okay so we use pivotal tracker taking numbers out from pivotal tracker and trying to visualize them in a way that will help us see whether teams are doing well or not so for example I started to formulate a very naive algorithm around whether the team is on track or in danger so I take numbers like how many stories is each developer working on at this point in time if one developer holds on to 8 stories then that's a danger sign to me and then I also look at how many stories have been rejected at this point in time I look at how many stories are open and stuff like that so I start to formulate and then I have a naive algorithm that is 100 points score that start to deduct points of whatever is showing and then it will show up as green, amber or red so that's one thing I've tried and to me at least I feel it's quite accurate sometimes when I see that I know the team needs some prompting in terms of maybe story acceptance or things like that if it dig deeper then there are also numbers that we might look at from a developer perspective so we actually start to look into github and I think one of the main things in github is about pull requests so we start to look at how many open pull requests are there are we able to nudge developers to try and close the pull request faster in fact recently we also did a trial on one of this product called git prime eventually we didn't go with it but this git prime looks into even more details about how people are working using just pure git data alone so we do look at some of these numbers but I must say we are not operating on them like a year KPI or things like that we just use it as more of data to help us in our daily work yes how do you measure the what I don't have a base the baseline is 100 points and then based on whatever is showing it will minus so I put a weightage to it so I might maybe think that having a lot of stories that PO haven't accept is disastrous so I will put a weight to a number of stories times 20 it's very arbitrary as I said it's a very naive algorithm but it just gives me a sense of what is happening on other levels then we also have CIs failing build etc stuff like that we have one last question behind you our first question mentally related to that one asking for a friend my CTO wants to use our agile board to track work delivered as a measure of performance evaluation he thinks this is a quantitative way to determine work done how does this work and will your naive algorithm track work done then again back to agile what is work done what is working software that provides value to customers I would rather they look at that rather than looking at work done because they could get a lot of work done if they could use this they could see there is a lot of commutes there is a lot of stories being built etc but it might not translate to users it might not translate to ROI but maybe if you focus on just one important feature it could bring you a lot of money already so then you will see all the hits shake hit already so I would say that your friend probably needs to understand more about what agile is about that's why I say very scary because maybe the person learn about one particular variant of agile and then started to think that that can be translated to performance numbers and things like that that's not the main point of agile it's not to evaluate people to get people to work together so that's the scary part and a lot of maybe it's part of industry fault as well because somehow the narrative became that agile will make you faster will make you cheaper will make you better I don't know why it doesn't work that way to add on top of that you can search up on research on how extrinsic motivation or extrinsic rewards not motivation sorry extrinsic rewards tends to derail people from doing the tasks more effectively in fact it actually narrows people's vision and if you are working on a creative work type of work like software development you often have quite a lot of side effects from there so the CTO it probably did not want that side effects he knows it it's a good question which is why back to Cementous question sometimes I very scared about matrix because if I put it out there and then people will think ok I can use that to measure developer because people have actually came back to me and tried to use that but I would say no we don't use it that way we don't look at the matrix and try to say this is what developer has done etc it might not be correlation yes capability growth your capability would be about product about the end software engineering I guess is more of individual and team growth right I mean how do we measure that even but output doesn't mean you are growing you can produce a lot of output so that's why I wouldn't you know correlate that together which is why it's scary because sometimes when you put out matrix then people will hold you to that and people will say that oh this is how the team is doing so when we talk about velocity then people will say oh how come the team is 40 points velocity this is only 20 points but if you need to explain actually you cannot do that you cannot compare some people have tried to come back to me now I can compare right how come this team is slow or this team is faster this doesn't work that way every team got different people right and different products that they are working on some are more difficult some are easier I'm not using the boards to compare right but when people come from very traditional view they'll be like no no no at some point in time people will compare and then I'm like no this is not as a this really not what I'm doing and what this is all about yeah it's for self evaluation what I hear from you right I think your belief of agile is more on your mindset kind of changing changing people but I think the challenging part I think what they have been trying to understand is more about how even as of today you are sitting here how you measure your success so I think we can look at the culture looks very good but how you yourself measure your success in a way because it's very intangible I think that is a problem because I know that agile is about mindset is very intangible but how do we how do you really get it as a success factor or even talk about metrics is there anything that you can share one one gauge I would use to see whether it's success or not is when I start to see developers talking and trying to own it right and not just be at the receiving end of are you just tell me what to do then I'll build whatever you want because when they start to have their maturity they can be part of the process they can own the process they can have a say in it then I feel they will start to be engaged and they will start to make sure this team works in a very collaborative manner what I've seen with low agile maturity is that developers then will always be taking the backseat to be like you need to give me in exact specifications then I will just build according to that then that is low agile maturity to me I feel high agile maturity is they are getting involved as well to help to co-create that specification that is one I would say another thing is how people start to use all of these practices and iterate with them iterate these practices within their team or even in their personal life when we started doing this we started to do retrospectives with teams so this is a story I have people playing Fortnite there is this game called Fortnite they all play games so then they started they did a retrospective how they can better play that game I don't know whether the paper is still somewhere they did a retrospective then that to me is I feel they are trying to apply some of these concepts into their daily life as well which means they find something valuable out of it so I know I agree it is intangible at the end of the day luckily or fortunately my boss is not measuring me on certain metrics because otherwise it is a bit hard because I don't know but I guess what this would translate into would hopefully be better products faster very hard to quantify whether it is faster or not but at least you would feel that you would be able to feel it the drag how the team is moving maybe others with experience I think we are going to do a closure we could probably still spend another hour here but probably let's get some closure before we leave what would be the parting words for people who are beginning or on their agile journey for them your parting words to them don't give up I think it's not easy especially with changing mindsets it's going to be very tough very tiring at times but if you believe in it then don't give up hopefully you see the light at the end of the tunnel I mean you might not be able to change everyone's perception but I feel that even if you have one impact on one person I think that's a start and that's good enough the one person will help you spread the knowledge one of the reasons why I joined SP Digital and why we did this as well at least in my belief is that we are going to work with the people here and hopefully impart whatever we know to the people here at the end of the day people would leave the organization but hopefully they will have learn something from this experience they will sit within the industry that will help grow the plan that we see in 10 years time people working with me one of the one day they will become a leader in one organization hopefully something that they learn about here would help them do the right thing in the future that's my belief thank you so much for your generosity thank you and showing us your determination in creating a productive environment for developers and for other people in the product development let's give a round of applause for Winston thank you I believe we will still be hanging around for about 10-20 minutes feel free to chat with us thank you