 Hello to everyone there in person. It's Sunny SJSU, it looks like it's Sunny today. My name's Darra Hoffman. I'm an assistant professor in the School of Information, as well as the program coordinator for the Master of Archives and Records Administration. I always joke that I teach at SJSU way, way north. I live in northern British Columbia, Canada. My co-PIs here with me today are Dr. Michelle Vieira, also in the School of Information. She is in LA. Of course, there in person, you have our wonderful in-person hostess, as well as our co-PI from the Computer Science Department, Dr. Nada Atar. Not able to join us today are Dr. Shuvik Ghosh, also from the School of Information, and Dr. Sohair Nojen from the Department of Sociology and Asian-American Studies. This is our very first ever Circle Speaker event, and we are thrilled to have Dr. Fatima Albar to talk to us about Agile as a mindset. First and foremost, we're thrilled. This is like the first ever ever. It's our inaugural event, and we are delighted to be able to have you with us, and we're also so excited that we can finally publicly share for the first time with the world, that Circle is a Mozilla Responsible Computing Challenge awardee. I saw Ziad is here in the audience. Yes, Ziad says exciting, and we can't tell you how excited we are to be part of the Mozilla family, to have had the shell and I just came back from Boston, where we had a wonderful kickoff, and to bring all of those exciting, responsible computing perspectives and opportunities to y'all, our students and faculty at SJSU, regardless of your discipline, your background, even if you're like me and you're always terrified, you're going to break something if you do anything other than work. We want to first off say thank you. In the very first project I trained in under my doctorate, we always use this proverb that we got from our team in Africa, which is if you want to go fast, go alone. But if you want to go far, go together. This wouldn't be possible without the generous support of our many funders who fund the Mozilla Responsible Computing Challenge, and of course our partners at SJSU. In addition to our respective departments and the College of Professional and Global Education, we've gotten wonderful support from the Center for Faculty Development and Ecampus. If you're faculty, you're going to see some of our work products rolling out through CFD and Ecampus in the days to come. We're also really lucky that at SJSU, this is not new ground to be broken. Digital Humanities Center has been doing wonderful work in tech ethics and digital humanities for a long time, including pedagogical materials, open source digital humanities, pedagogical materials, and they provide their support as well. We want to thank them for being the newest part of the Circle family. If you need some resources, we suggest you also check out theirs. What you can expect from the Circle project in the year to come, and we are just so thrilled to be able to do all this for all of y'all. We're going to have more speaker series events. This is the first one. I see that all y'all in person are going to have to eat a whole lot of pasta today. But we're hoping to have this grow, and we would love your feedback after the event on what topics you would like to learn more about. Some of the ones we're thinking about are having someone come to talk about indigenous data sovereignty, for example, or cultural computing, all kinds of interesting topics, and especially for the students, we really want to hear what you guys would like to learn more about. Then it's also important to know that this is not just a speaker series. Part of the reason that there's lunch and all that is we'd love for you to stay and chat about what you've learned, your perspectives. Y'all are very important in responsible computing. Your voices matter, your experiences matter, and so we want to be creating those spaces for you and welcoming you into that space, especially into the tech space. In a way, you might not have always felt welcomed. For our faculty, we're going to have training modules through CFD on responsible computing pedagogies for both tech folks and non-tech folks. If you find yourself going, I'd really like to know more about data privacy and how to incorporate that into my courses. We got you. We'll also have teaching materials full on Canvas modules that you can drop right into a course. We're going to offer a new course on human computer interaction that will be offered for both the iSchool and the Department of Computer Science at the undergraduate level, and course revisions and courses every from sociology methods and introduction to Asian-American studies to computer vision and thinking with data. Finally, of interest to y'all students, we're developing our responsible computing student action guide, and this is ways that you can start to make your voice heard in our tech ecosystem, and to be a broader part of it, to find your power, find your voice, and make the world maybe a little bit less terrible and a little bit more just and inclusive. Thank you all so much for being here, and it is my great pleasure to turn it over to our wonderful in-person host, Nada and to Dr. Fatima Albar. My name is Fatima Albar. I work at Cripple and here's my LinkedIn and my website. Besides that, before I start, I would like just to give some sense about who you are and where you are. Any other data? Okay, great. That's good. And online, I don't know how we can get the pulse from online, but we'll figure that out. Grad, one? That's cool. Nice. Which majors? Computer science? Software. Software? Software. Software. Computer science. Computer science. Great. Computer science. Just to let you know, you are only 6% of American and go to computer science, so a great addition. You are only 6% of not just of American, of people who go to school in America. There is about, the percentage has been increasing, but there's about 60% of America, 50 to 60% of American go to school. And out of that, only 6% go to computer science. I think internationally, it's 7%, 7 to 8%. So still, you are among those few people who could get to this major globally among people who are quite lucky enough to get to the screen too. Working? Perfect. Okay. Who I am? I'll start with that. I was born and grow up in Saudi Arabia, in the Middle East, until I get my undergrad studies there, and then I moved to the States. Moved between three to four States, but I have been in Oregon for 20 years. So, Portland, Oregon is known by, beside hiking and waterfalls, and nine months of playing, it's mostly known for two things, two industries or two big companies. And you guess what? Nike is number one. We have the Nike headquarters there, so you will find a majority, lots of people in Portland, they work at Nike. The other option is Intel, which Intel, we have the biggest campus of Intel in Oregon. Lots of people, they think Intel, the headquarters is in California, but Intel is mostly Oregon-based. These are the two things that we are friends with, besides being weird and all other stuff. Okay. Through my career, I was in academia for a very long time. I was teaching, I was doing research. I did research with Project Management Institute. I was a joint professor for a while. I did some consulting with startups and with different companies, but those are the other names of companies that I work with. In addition to that, I started a startup and I decided not to continue with that. It took me three, four years and then I stopped, and I started a business also on the side, and I decided that business needs different plans, so I'm still on hold. I'm not going to go through these, but you can read more about them in my LinkedIn if you're interested. The idea is I went from academia to big corporates, to startups with different sizes, and that's where I'm going to try to cover part of, and this mixture of what is the difference between all of these industries. Being from Oregon, I like hiking, I go hiking, I go, I did paragliding once, I did the planning, I like to discover new things and try new things, and last, every year or two, I try to do something different, so last winter I started horseback riding lessons, still doing it. This is my kitten, his name is Chico, and I have two children who cares about them and add their pictures. They're called your students, they're not here, but I love summertime, and I always, I know we are in the fold that I live in the summer still, last summer, last year, summer of last year, I did the level five water rafting, and to do level five water rafting, it's one of the fastest and most, it's kind of the highest that you can go with commercial group. Higher than that, you have to be either expert or go a small group that they don't take groups to it. So I will share the video, and then I will tell you why I'm sharing this video. Stops. This was the last rattle, which is the harder one. Meanwhile, if we go fast enough, we will pass the rattle and then we will land, and what happened is we were fast, but not fast enough to kind of fly through it, so we fell and we dropped and we were in the water. The team were really agile, really effective, they were expecting some risks to happen, so in less than 90 seconds, all of us would be flipping the water, we're out of the water, because otherwise it will be, either we'll go with the stream and it will be more risk and more dangerous, or the water was 52 degree, so we didn't want to risk anyone, but the efficiency, the agility, the fast moving of the crews, they really were organized to get everybody out of the water very quickly and get that to be in the safe place. So now you know what is agile, it's about being fast, being grounded, anticipate risk and do it. So we can conclude this section. And I'm feeling, we're gonna say it's a good one. Anyone knows anything about agile? What is it? Yeah. It's like a fast dynamic program, or like programming in a way that gets on the ship, nice suits with the team. Yeah, great. Anyone else? That's mainly the idea, the agile mean being fast, being dynamic, anticipate risk, don't spend too much time to plan for what you're gonna go through, plan enough to go fail or sense what's going on and adapt fast. And this is why I put that I think because that was mainly what we were doing. So agile as a mindset, bigger than what we do in software industry, it's about all of this. It's about sitting goals, customer focus, self-organized, about being collaborating together, having the growth mindset, being flexible, and we're gonna go through some of these. So agile really started in 2001 for software, and then from there in the past 20 years, it's become cross all industries, that even you would fast some sales, some customer success, some finance, they adapt to agile methodology. So it started for software, but hardware companies and other companies are also adapted to it. The idea is we can build the minimum valuable product and you will hear a lot about MVP, that what is the smallest thing that you can deliver and give it to the customer so they can work with it or they can try it. So for example, if we're planning to rebuild the whole vehicle thing, we're not gonna go to do it, kind of go with one wheel to two wheels and then have the body and then have the car ready to be shipped because that's gonna take way too long and nobody can use any of this until it's a whole vehicle. The way that we do it is, what is the purpose of building this? The purpose is to move from point H, we always focus on what's the problem we're trying to solve, what's the purpose of what we're building? So the purpose is to get from point H to point B with less effort and quicker or faster or less time. Then how can I reach that by having a skateboard, scooter, then a bike and from bike to motorcycle and then we need a body or whatever for rain or for cold or to be faster and we build the car. So there's still the customer can try the product in all different phases. We don't have to wait until the final product we have it for the customer to try out. And that's a way that we are doing business today, especially lots of business that adapt to this style that they don't work. If you think about the business 20 years ago, it was kind of have a fancy office, get everything ready, get the team ready and then start building the business. Today we don't do the business in that way. Even for business, we start by trying the product, get it to the market and from there expand. One example of that, that is nothing software, nothing industry is sold and store. So in the store, they started with three flavors, just on a cart for festivals. The concept was good. They had a truck, ice cream truck. The concept was good. So in every phase of what they have, they had a whole kind of business model. They have marketing sales, product, customers advertising in the small scale and just on a cart on the festivals, then an ice cream truck. Then they had the first store. I don't know how many stores they have now, but they are there across almost all states or most of the states. And you continue with this model and everything. If you wanna do something, especially if you're trying innovation, if you're trying a new product, if you're trying a new recipe, if you're trying anything that's new to the world, we will not wait until we have the final product with the final, with all the features to the end. Try it kind of in a small way and keep the kind of the valuable product all the time, that we have a minimum value of product that the customer can try it. Feel free to interrupt me anytime and ask any question. And online, you can do the same thing on Zoom. I don't know how to see them, but I don't see the chat, but you can unmute your mic and ask questions. If people want to ask questions, I'll be happy to read them out to you, Fatiba. Perfect, thank you. You're welcome. So the old style of doing software and especially not just software, for the most of the innovation, for most of the business we used to kind of get the requirement, what do we wanna do? And after we get, it's kind of an assignment, the style of the academia that you get the assignment, you get all the requirements, and then you start by designing it and from design you go to implementation, and we call this waterfall because it's, every step is really a lie on the dependency on the step before it and you take it and go with it. What's the problem with this? Really, there is no problem, except we do, every one of these steps rely on the step behind the view before it, but also many times you need the feedback. So after you do the analysis, you go to the design, but many times you get some feedback from design and you need to go back to analysis. It's not really straightforward that you go from, you have all the requirement upfront and you can go from there. You have some of the requirements, you do the design, you wanna validate the design because you don't wanna, if you keep going until you have the implementation and you put it in the market and you get feedback, it's too late, it's too expensive. It's mostly your competitors already are there. So if you wanna do it fast, you will do the first one, get some feedback, get to the loop back, and this loop is going back and forth in all the phases. Like any phase, you can go back to the phase before it and you continue. And that was happening in waterfalls, but they didn't deliver it to the market until they finished all of these phases, which sometimes take two to three, four, five years, depends on the product, especially if it's hardware, which means that you start working on something, you sell it years down the stream and then you get the feedback if it's good product or not, it's the customer who adapted or not, which means you have visited all of this money for all of these number of years and then you get surprised that it's working or not working. And what you're trying to do is to avoid this and move faster, get the feedback faster and make the loop moving. These are some of the roles that we have. You hear it a lot in the industry that there is the product owner, there is a project manager, there is a business analyst, the chief technology officers, and when you go, you will have this, but with Agile, some of these roles being kind of either mesh to different roles or disappeared. For example, product owner, we still have product owners, it depends on the size of the company, but most of the time you will have a product manager. Project manager mostly will have program manager. Business analyst, sometimes that's, that role is distributed between multiple people. System architect, sometimes many times we have the architect working with the design, design and development. Many times they work one team. It depends on the size of the company and where are you with that. Do we have people to test at the end? Sometimes most of the time we have people to test in brief phase. So how do we do software is mostly, not just software, but lots of business that we do it in this way. We do design, documentation, we go in the loop, development, testing, and then releasing. So if, for example, if you think about, I don't know if there is a system like that or not, but if you wanna make it easier for patients who move from state to state or from a hospital to hospital, without getting a record, they can go to any hospital. The hospital can access the record anywhere. Let's say we have an unified system for health, where that unified system allow you to go to any hospital and then you don't have to go to your doctor and they still will have your health record. If you start, if you wanna start this startup or start the idea and say, okay, I'm gonna build this health database where everyone can get their health records from anywhere. If you start by, I don't know what's the big hospitals here in Oregon, we have Providence and Tizer, what do you have here? It's such a good health and the standard. Okay, let's say any of these two, you're gonna start with, if you wanna start with all hospitals across all of California, that's a lot. And this is what we say when we do this agile methodology, we're not gonna start with every hospital in the state. We're not gonna start with every hospital in US. We're gonna start with two. Say, let's say hospital X and hospital Y. We're gonna say, okay, how's the database structured here? How's structured here? What can we do? What is the first feature that we can build to connect these two together? You know that there is payment you have to put, there's insurance you have to put, there is unified user interface, there is one password access you want, but you're not gonna care about all of this in the beginning because you wanna focus on one feature, which is combine these together so you can when anyone log in can be able to navigate these two, at least big hospitals. And that will be maybe this and this, that. Go to these two hospitals, go to some number of patients, do you like it? Are you okay with it? Yes, this single feature is working well. And then you're gonna go to say, okay, what's the most important second feature? Should I unify the interface? Should I have one access user, one password? Or should I do unify the format of those files? Whatever it is. Then you're gonna decide on the next feature and you're gonna build that feature. And then you're gonna go to the third feature. And maybe after that you say, okay, I'm gonna have a third hospital. I'm gonna have a fourth hospital. I'm gonna include these. I'm gonna figure out how I'm gonna make them pay me to do this because now I have a proof of concept. I have three, four features and I can start making them pay. Are they gonna pay per patient? Are they gonna pay per size of the record? Is it big or small? Are they gonna pay per membership? Number of, you will think, so as you go, you're not just figuring the software. You're figuring the software and the business model that goes with that software. Because you're building features and with building features, you're building business. And you need to think about the business, how the business is gonna grow. And to figure all of this out in the beginning, it's too expensive. You will spend two, three years, just recession to see how the whole industry and health industry is working. And by the time you start coding, by the time you start developing, it's too late. It might be other software competitors out there or it's too late because you're not getting any income through these years when you're doing the research. So building it in this way, allowing lots of people, and this is why you see lots of startups starting, because if you wanna only build this feature, while you have your full-time job, you still can do that. Building this feature might take you a few months or time, but still you can do it when you are doing your full-time job or when you're studying. But if you try to build the whole system, while you're doing something else, it's impossible. If you try to build the whole system without income, it's also hard. So building it one by one, testing the market, getting the feedback, getting who's willing to pay for this, even $1 doesn't have to be a price and we grow with this. Any question? Too much? Too fast? Good? Okay. So how do we do this? The way that we do this is not by having no plan, because that's kind of ridiculous if you go to start your business or to go, or if you have any software company that wanna develop software and they have no plan, we're not gonna go anywhere. And the other extreme is, as you say, to have all the plan is also extreme and it's hard to find it. So the rough plan mostly focus on, I know where I'm going. I know what's the final product should look like or what's in my mind? Or what's the problem I wanna solve? And engineers, we always focus on the problem. This is the problem, I wanna solve this problem. And from there, I will just put, okay, what is the rough plan for that problem? How I'm gonna solve it? What's the architecture? What do I need? Like a skill set, what do I need? And what do I need to build? Because once I know what I need to build, I will know the skill set and I can't find these people either to hire them or to be a partner with or to develop the team that's gonna develop this. This is how we do it. When you have kind of teams, the structure of the teams is you, the team plan that work every two weeks. Some of them do every four weeks, depends on the software usually one to two weeks, hardware usually go longer, but you can, what do you wanna develop in this period of time? In two weeks, I wanna have this interface clean. In this two weeks, I wanna have one method of payment. Let's say credit card. I'm not gonna care about bin wall or any other, or PayPal, I just gonna have one payment. Whatever it is, you have a period of time, you have a goal for that period of time. And that's what we do in that period that we're gonna develop, we're gonna design, develop and test until we have that feature complete and then we release it. But in the backlog, I have a list of everything. Like if I'm gonna do payment, I have a list of all the payments that I wanna include. Bin wall, PayPal, credit card, I have all of these lists. I'm not gonna start with everything in the vision. I'm gonna just take one of them, go put it in the backlog for those two weeks, implement them, test them, release them. So in period of one month, sometimes this, the customer can't see this. If today, on my website, I don't have any payment method, in two weeks, my customer should be able to see the payment method. And this is why it's fast. Customers feel that you're giving them something all the time. So this is not bad, this is not terrible. I have a bad, like it's kind of what you do. You have a long to-do list. You pick a homework project, you take one of them, you say, I'm gonna finish this, you finish it and then you take the task after that. That's kind of makes sense because we, in our life, mostly we do this. This puts makes it more complicated. When I joined Intel, was my first job after each day of the afternoon. I was in academia after I finished my PhD, I was a professor for a number of years, and then I joined Intel. So they give me a title of Vertical Program Manager. And I was kind of with the Vertical Program Manager. And they realized that they have horizontal and vertical. Horizontal are mostly scrums or team, engineering teams. And verticals is the business sector. So everything client, which is kind of PCs, anything, computer, game computers, anything like that on the client. And then servers is for mainframes and servers, and then internet of things, that's kind of the term. And each processor is different and each thing is different. So I was responsible for one of these, the vertical ones, which means working with nine development teams. And those nine development teams were almost all over the world from India, China, Malaysia, Seattle, Portland, East Coast, California, Arizona, many different places, just to organize their work, to see what we're gonna test and what we're gonna develop. Because we receive the design from the design team, where they design the circuits. And then we have to test it virtually or by code. We don't send it to the app yet. And once it's tested, we go back to the design, don't, they'll change this, this is not working, they'll lock it back. And we do that creation back and forth for a while until we prove it. And then for hardware, it's harder because you don't send it to the app until you're kind of 100% sure it's gonna work. Because printing the motherboard, printing the ships is too expensive. And if it comes back with defects, that will cost the company millions. And this is why we have to make sure about this. So what are these? These are kind of digital, analog, whatever, memory, all everything that you have in the ship that is a team responsible for. And with that, there is this project timeline and all of this. So now the Scrum team is not just one Scrum team. Now there is this company, this company, this company and this company, and there's businesses between them. Because if you are doing the interface and I'm doing the backend, you're waiting for me and I'm waiting for you. So we need to decide which piece is gonna come first. And if you're gonna do this piece, which date, which date, you're gonna finish it. So I can take it from there. If you're gonna work from Monday to Wednesday of this feature, I can start on Tuesday or Thursday. If you're gonna take this week, I'm gonna start next week. So one big part of my job is organizing it between these teams. Because this engineering team, they really don't look beyond what they're doing. And that engineering team is doing the same thing. So to go and make sure that all the dependencies are there and the timeline is there, so we will chip on time. That's part of what makes the kind of the job is interesting. It's kind of you, if everything is going smooth, I just go and watch them. If anything is going wrong and let's say this is not gonna be shipped, then there's dependencies everywhere. And that's between just developing team in one org. If that is, then when you think about cross function, you do the same thing. Here is your scum teams, here's your engineering organization. The guy's doing a good job, but there is product that's talking to the customers and they want something different. And then there is customer success that they need some training and they need some documentation. And then there is marketing that they're already putting that advertising outside and there is this event that they're gonna announce this feature on. And sales that already promised the customer that the product gonna be out in July and near October and the product is not still there. So all of this need to be organized together. And that's also part of my job as a program manager is when you're responsible for the whole program. And the program is that sometimes it's just a product line like for this product, everything related to that product we take responsibility for. Sometimes it's just R&D. So it doesn't really have marketing or sales, but it's deeper communication between the engineers. It really depends on the program that you're on with. But the idea is being agile is not just for the developers. The developers and the impact of that is in cross functions and all the whole company. And if there is legal department, the legal departments will be part of this. If there is, it can go as a snowball everywhere to the whole company. So if you plan it, if you do your agile, once the software engineers are agile, then everybody else needs to be agile. They need also to learn how to adapt fast and move fast. They can kind of put things in concrete if we don't know when we're gonna deliver this feature. Good, so far? Sure, okay. Now we're gonna go, what if it's cross company? What do we do in that case? And I did that for a while. I did that for almost a year and a half and then they said I can't do this anymore. It was between Intel and Microsoft. For the ship to work, Windows operating system needs to adapt with the new feature of the ship. And then, so all the whatever you build on the ship, you wanna make sure that the software is compatible. So there was, we were doing all this craziness with Intel and then we wanna make sure that we will send the board to Microsoft. We will get the binaries for the Windows early on, so they will test the ship. We will test the binaries and then they have their own adult and we have our own thing. And anything goes wrong in one company when we make the other companies going down. First the cost of this is billions. And you don't want escalation to go to the CR because once it's the relationship between companies, it's escalation goes to the level of CR, right? So it's really interesting, that means meetings, it's five meetings at 11 p.m. It's fun, but it's different. If you're up to it, it's really fun to work with cross companies, but it's a lot. For smaller companies, we still have integration. Like we, Puppet has integration with ServiceNow. We have integration with XV, for example. Those integration always happen, but it depends on the size of the companies, the size of the integration, you see the impact. Until they, like within Intel, you would find Intel Amazon, Intel Apple, Intel Siemens, Intel Windows, I was just with Intel Windows and it was a nightmare and they cannot imagine. Intel Dell, Intel, those are departments with 500, 600, it's like a company running by itself, just to organize this work between two different companies and make sure that deliveries from here can get to this on time and rise versa. Questions? Very good. Okay. Is this complicated enough? Why? Why are we doing all of this? And why are we going through Agile? And why were, especially if it's complicated to that level, wouldn't it be easier if at the beginning of the year we say, hey, Microsoft, we're gonna build all of these and this year, give us this, end of the year we receive it. Yeah, it will be easier. Definitely, waterfalls easier. But in reality, in those 12 months, things change all. Custom money change, economy change, wars happen. What is the relation between the owner and companies? Everything related to stock market. Stocks market related to shareholder. Shareholder, they have their voices say, hey, we're not anticipating next year people will be able to buy a laptop with this amount of money or not anticipating that the demand for servers gonna grow in this much as we expected. So if that demand change, why don't you provide us with something less expensive or more expensive or the demand gonna be bigger or the demand gonna be smaller? So it's really more complicated than being just, I see the goals and they go on and implement it. I hope it is, but it's not it. And this is why being a giant is kind of moving and moving faster. And one of the important things is, before we move to that, one of the things about being, I wouldn't say being rigid, but being not able to adapt fast is what happened with iPhones or with smartphones when it came out. I think it was in 2006 when Steve Jobs went to Intel and they have the agreement and they talked about, they want SIM card, they want a processor for the phone. And that processor has to be fast enough, doesn't have to be as fast as BC, has to be fast enough, doesn't consume the battery, doesn't heat, so it can be used in a smartphone. Until in the beginning, say, yes, we're gonna do it and then we're not, but the idea is Intel was the lead of making microprocessors. And for them, they made the most complicated one, the fastest one. Now to come and tell them, give me something not as fast, not as expensive, not as complicated. So it's supposed to be easier. Like if you think about it, if you are a student and I'm telling you, solve this problem at sea level, not in a student level, it's supposed to be easier, but it wasn't. Intel started with that for a little bit, Apple went and tried different, they developed, they started a different company with ARM with different players, but Intel started from 2006 and think until 2016 or 17 with the smartphone, they could not develop like enough, a processor that's cheap enough, fast enough and doesn't take the battery and doesn't heat much because their mindset was we developed the best and it was hard for them enough to develop the best. So part of being agile is you might go to harder level to compete in the market and it might be the opposite. You might just need to deliver something very simple that another market needs it. And with this, I don't remember the number, but of course, the smartphone industry is huge and until today Intel is not part of it because they missed that window. So they always say in theory that we have the triangle of cost time and scope and do not compromise with quality. Quality is the thing that you don't want to compromise with. You can add more time, reduce more time, add more costs, reduce more costs, add more scope or reduce it, but do not compromise with quality. And in real life, you're juggling these things, but you're not juggling the cost. Most of the time goes with the time because it's rarely, and I'm saying rarely because it's really happens that you go and say, I have a team of five and the deadline is next month and we cannot deliver, give us two more engineers. It's really happened that they would give you two more engineers. So what happens usually is you have the time, time means cost, like if I delay it for another two weeks or another three weeks, that's salary that I'm paying. So time and cost becomes almost one thing. And what are we playing around is time, quality and scope that I either have to deliver on time, but reduce scope. I cannot give you all of this. I cannot give you five different methods of payment for next month. I can give you one or two and we can negotiate that. Or I'm gonna sacrifice the time and you want five different methods of payment. It will be in December, it will be next year in January or give me more engineers, which mostly doesn't happen. So what we do want to sacrifice, we don't want to sacrifice the quality, but what happens in most cases, because engineers, because managers, they don't change scope. They didn't change time. So what happens if we sacrifice them? Okay, what can we do not to keep these things without sacrificing anything is priorities. And with priorities, I will tell you there's some sticking out, that's not showing. Interesting. With priorities, I would say, always think about the priorities. What is the most important thing that I need to sacrifice? And that most important things can vary and can be different because it goes both ways. There is feature that has a high impact, which means I know if I put this feature, most of my customers can use it. If not all of my customers can use it. So this feature has high impact. Are they willing to pay more for this feature? No. So it's high impact, but what should I put in priority? Because the high impact is not gonna bring me much revenue. And there is this feature that one customer want, but that customer is willing to pay two million product feature. Which one should go first? And then I have those things, like this customer is blocked because this thing is not working. There is a bug, go and fix it. And always we struggle with these things. And that where we go, it's a product manager, TPM, engineering manager, sometimes CEO, sometimes CTO. It depends on the level of escalation. It depends on the work that we are doing is to put the priorities right. And we change priorities. So you put the priorities, we change the priorities because if the customer say I'm blocked and the Black Friday is coming soon, if all of these payments is not working, I'm gonna lose this amount of money. That's urgent. That we have to work on it today. So by the Black Friday, this is up and running. And if we enable that enough, can we go back to the most impactful feature? Can we go back to that feature that most of the customers will want it? I was in one of the meetings and that's part of kind of where the whole company, even as a developer, first you need to understand the culture of the company, the priorities of the company. Because I was in a meeting with the engineering manager, tech lead and the CEO was in that meeting. This is a small company. So the CEO was involved in that meeting. And we were talking about one of the customers come from one of the requests come from a customer. The CEO asked this question, how big is this customer? We all of us, we didn't know how big is this customer, but what's the size of the contract? And he pulled it up in a second and he said, okay, this contract is less than a hundred K. If it's more than a hundred K, still this conversation shouldn't happen on engineering like on engineering TPM level. This conversation should happen in between the sales and PMs, but if it's less than a hundred K, don't bring it to the table. If it's a half a million to more, then you prioritize it in your bubble, then you bring it to engineers. So sometimes engineers, an engineering manager needs to ask this, you interrupt my work with this feature, who wants this? Like, and how big is this contract? Sometimes it's not the big of contract, it's the big of a name. Like, Tesla asked for this feature. We know that if we add feature Tesla, even if the contract is the only 30,000, that's a big name that will encourage other companies to come and buy. So even as a software developers, your head will be down to writing the code, but understanding that dynamic of where are we going with this, you will, when you get into that and say, hey, stop working on what you're working on, take this and work on it. You understand what? Why I'm dropping this in particulars? Why this happened? Why they keep changing their mind? It's not they keep changing their minds, it's what happens is there is demand coming. And when you are like a small company, or a startup, or just when I feel, it depends really on the goal of that company and how they want to put the priorities. I, through my experience, some companies, their priorities at certain phase is just to learn bubbles. They really don't care if it's a $5,000, $10,000, 20, but they want more people to buy from them because if you land logos, that means other companies will come. And then you can increase prices, build new features, whatever it is. Other pieces of the companies where they say, no, I don't really care about anything below 100K. Some of them, they say, I don't really care about anything less than a million. And for Intel kind of size or AMD or one of those, I don't know what's the size where they cut it to say, I don't really care about these small customers. If the customer is big enough that we can, then we can sit together and talk about the deal and the future that comes through. So understanding this helps a lot for, even when you build your own code. Okay, Sony, when they build, when they adapt to Agile and just bringing one example, they reduce it the pending time almost by 30% by 28%. They reduce their, they save about 30 million a year and the downtime has been kind of almost reduced to zero because it's always planning, always execution, always delivery. Okay, Agile has all of this. Like with Agile mythology, it goes that you have extreme programming, you have scrums, you have camp on and have safe. I'm not gonna go through it, but I'm just dropping it here for you. So if you kind of wanna know more about this, each one of these, they have their own certificates. Some of the certificates are two months, some of the certificates are online, some of them you need to attend. But it's different ways of doing development, whether it's software or hardware or building your business. Okay, how are you doing on time? Okay, are we good? You're going? Okay, what does Agile mean to you, either individual? What does it mean to me as an individual? And as I said, Agile is a mindset. It's not just about software development or business development, it's about, it can be social Agile, it can be ability to change in your life, ability to look at your professional career can be Agile. So it's a whole concept of the whole mindset. Where do I wanna go? What's my goal? And then how can I be flexible enough to reach that goal? So the first thing, the first thing you take it to the Agile is what's your goal? Where do you wanna go with this? I don't know if you know the story for Coca-Cola or not anyone. Okay, Coca-Cola when they started it, it started in I think 18, 80 something. So about 130 years ago or something. The person who started it was Pharmaceutical and he started Coca-Cola as pain relief medicine. He added coke to it and he added lots of sugar. And he did the syrup as something that helped people with chronic disease or with continuous pain to kind of help their mood and smooth their pain. So they will, at least for the rest of their life, they can live without severe pain. And that was the purpose in that person's scientist mind that this is what Coca-Cola is. I think four years later, another pharmaceutical guy bought that recipe. And the vision of the new one, forgot the names, but the vision of the one who bought it is to have it as a drink, everyone. It's just a change of the vision, change the market space. Because one is you're taking it as a medicine and for specific cases that will be, you have certain market size. When the other one has the vision that this is gonna be drink for anyone, he kind of widened his market space. But in 10 years, and I think in eight years, the sales of it grow from 10,000 to 100 and something thousand liters of the syrup. And then it went growing and growing because the vision, and I think after 1900 with few years, they remove the coke and they make it as a drink so anyone can drink it. Coca-Cola is one of the companies that it's, now it's whatever, 120, 100 and something, and it's involved in many different industries, bottling, cans, and their sales is across the world. And all of this started by just a vision that, what is your vision is? Your vision is to have it as this or as this. And this is why I'm saying, anyone who starts from all these, you're gonna start with MVP, you still need to know where is your vision? What's your eyes are on? And open for possibilities. Being a gentleman means being flexible. And one of the things that we do as engineers, we get attached to our work. And that's one of the things that we do, we not get attached to your work. You will work in the most fantastic code. And before you finish it, they will take your priorities change. Drop this, pick something else. And drop it, I don't know for how long I'm gonna drop it. I'm gonna stop working on it, I'm gonna pick something else and priorities keep changing. Do not get attached to your work. And do not get attached to your idea, because sometimes we go and we are so enthusiastic, we want this idea, and you go and you propose the idea, and the answer is no, we're not gonna implement it. In those cases, I would say, do not take no as an answer, but doesn't mean go and make trouble to make it. It means understand why the no. Because sometimes the no is, I really don't have a patient and I'm busy, and this is why I'm telling you no, because I don't have energy or I don't have time to listen to you. That's completely different between no, we tried this before and it didn't work. Also, you shouldn't stop by that. You need to understand what exactly we tried, and how did we try it, and maybe you can modify your idea to adjust to what we tried before, to avoid that and try something different. Or maybe you would say, no, my idea is not what you tried, my idea is different, and you are just assuming that they are the same. So do not stop by no, and you will hear no a lot. Don't take it personal, but do not stop by no, because most of innovation started by those people going to their manager saying, let's develop this. The manager said no, they went outside, they started their startups and they did this new business. So they're not to stop by no, but understand why no. If there was enough research, learn from what they did before you, so you don't have to kind of repeat the same mistake. If it's no, because it's really, really, really a bad idea, a terrible idea, you will learn that, okay, this is what makes this idea terrible, and they can learn from that. So dig deeper and try to learn more. And then we call it half-on, and that's it. And I don't know if you heard this or watched this video before, but I'm gonna show you this video. Oh, the video is not available for some reason. The video is saying, the graph on this, the video is basically saying, here's the, here's a few, just two mistakes, which is for Karan. I like it right in the restaurant so bad, and here is you will find out. And it goes like this. As many mistakes you make, as many mistakes you fuck around, you will find out more. And that's basically what the video was saying, but he was more funny than me. And this is why I want you to watch it. And I would add to that, there is a third dimension, I don't know how to draw it yet, but there is a third dimension, keep this with low cost. If you keep it, but you can grow fast, but with lowest cost that you can, that will be great because as you make mistakes, you're losing, you're losing time, you're losing money, you're losing energy, you're losing people who are believing in you, and try to do with minimum cost, and then you will learn more. Definitely, that should be this way, whatever it is. It's just when you don't be afraid of making mistakes. The only way we as humans learn is by making mistakes. And otherwise, we will not be fine today, we will not have them at all. We will not be scuba diving, we will not be doing most what we are doing today. So make mistakes, but be aware of your mistakes, where it's gonna take you. I always tell my son, as long as your mistake doesn't cost you your freedom, your brain, like if you don't go with drugs or anything that costs you your mental health, and your health. These are the three things that, be aware of that. And if you're a spiritual person, you're a spirituality. Other than that, make mistakes. You break a bone, it will be fixed. You will do a mistake, you will lose a couple of thousand dollars, $10,000, $50,000, you will make it up. Because the amount of learning that you're gonna learn from this is, it's so huge. And this is what I'm saying. If you do this fast, like, pay fast, stand up fast, and try, and try it. Especially when you are younger age, it's you have a bigger room, because you have less responsibility, less impact, less kind of cost. Try more, fail more, stand up more, and be resilient. Okay, can you say these? Okay, when to present what? This is an important one, because if you have an idea, you need to know what's the right time for that idea. Because sometimes the company is not developed fast enough. Like, your idea is great for the company after it's going public. The company is still small. So either take that idea to a different company or wait for this company to grow. Knowing what to present, what it's critical. And one example for that, I was, when I was at Intel, I was putting slides for presentation and my manager went through the slides and she told me, remove the slide. I told her what, we are working with Microsoft. This is like, this isn't a good status. And she said, if this presentation can go to this level of VPs, if they saw this, they would think it's an escalation. And that will go to Microsoft as an escalation. Just remove it, since it's like, you don't want to escalate, remove it. So to know what to present to who is important, because there's different level of the company and something gonna be understood in a different way. So knowing that the right timing is critical. Say no when you have reasons. Also this happened kind of a few weeks ago, one of the, I was meeting with engineers and the engineer, they were discussing some architecture. I was just listening, but one of them said, if we develop in this way, the customers will see increase in billing because we bill them by terabytes or whatever the size. So if we just change this and the development, the bill gonna go this much. So that's a developer. And still that developer is smart enough to know the business model, how we charge our customers and to know that, hey, be careful. Don't mess up with this because it's gonna mess up with the billing. And that's what makes some people kind of business oriented. They grow fast in the company. They take higher positions. Okay, see the risk before it comes, anticipate the risk. If we do this, what might happen? We're limited in this way. Because even if we cannot cover all the cases, at least I know the risk because we're not covering all the corners and I need to anticipate. We need at least to keep that risk in our mind when we develop. Let's negotiate. And negotiating, negotiation goes all the way from the time you apply for job, from the time you receive the offer. Learn how to negotiate. All the way when you are working on your screen on these five features and your manager comes and say, hey, stop working on this or can you fix this bug? It would say, okay, if we look, this bug gonna take this number of hours or days. What do you want me to draw? Because there is an acquisition. You can't finish all of this plus this. Unless everything is critical, everything is kind of unread, then you'll work overtime, but also negotiate that that I'm gonna work overtime to do this. I'm gonna have five nights without sleep. I'm just studying, you know, and I'm gonna get it done because you're not gonna work all your life with four hours of sleep. If you can do it in a week when you have a release, but you're not gonna do it for a month. So those negotiations are important. Those kind of talks are important. Think out of the box. It's always important to think out of the box. If there is a solution that's cheap, not too expensive, not gonna take much time, propose that idea. And yeah, everything in life come with a price. There is nothing for free. Like everything that you, it's either you pay time, you pay money, you pay team members, relationship, you pay something. And be aware of that. Okay, when I do this, what is the cost of it? And be aware of it and negotiate depends on those costs. That you want me to do this, it will cost me this. Adapt to the culture, as I said, some companies, they want more logos of companies. They want more contracts. Some companies, they care about the size of the contract. Some company, what is the culture? What your companies care about? Care about. And change is the individual thing. Things are changing fast, especially in software, especially in cloud industries, especially like in high tech these days, every few months you'll find a new competitors, a new company, a startup, a new technology, something coming. And that means your plan will be changing all the time. So if you plan on something, don't hold on to it and be able to change. Yeah, one of the concepts about leadership, especially from the Hollywood that brings us, the leader is the one who comes with loud voice, charismatic, mostly beautiful or handsome. And that's great. We need few of those leaders, but what we need is the leaders that, if I know that you are blocked, I know how to enable you. If I know that we cannot do this thing because you're waiting for someone to review your code so it can be released, I will bring that one. And those are kind of leaders that we want them, we need them with everything. Yeah, they don't have to be charismatic, they don't have to be loud voices, but they are the leaders that they enable others to work, that they open doors, that they think out of the box and be that kind of leader. Because even in the beginning, if you feel that you're not recognized, you will be. Because those are the kind of people that motivates others to do, and people trust them and rely on them. And it takes time, but you will get there. And she's gonna take one thing out of all of this, whatever, we're now in lecture. This year goals, have a plan, be flexible with this plan. You might need to stop more often, you might need to go different routes, you might need to avoid some obstacles, but be flexible and really enjoy the journey because if you wait for big accomplishment, those comes really, maybe when you graduate and maybe when you whatever do something, launch something, they start a new job, but other than that, every day life, it is something to celebrate. Try to think about those small things to celebrate because they are the things that keep us going. And when we do the one or two weeks scrim, we try at the end of those two weeks to celebrate this new feature, even if the new feature is very small. But celebrating the small things is kind of making, it's making us feel that we accomplished things. So in your life, even don't wait for big things to accomplish, to celebrate. Celebrate every small step that you do, every small thing. How many credits you accomplish? What did you do in this year? Those things that are really, really worth celebrating and those are the things that keep us moving. Okay, this is what I'm happy to do today. I think I was talking a lot and giving you lots of information. Thank you so much. And I'm open for any questions? Questions every day, startups, big corporates, education, yes? Going back to Scrum, you said you had worked with China and other international teams, right? Was there any difficulty in meeting with those teams at certain times? Yes. Like, can you have to stay up to night to have a good meeting? That's one of the challenges is time zone. That sometimes you start meetings at 5 a.m. or 7 a.m. or what depends on their time. 11 p.m. meeting, you'll find those happens, I wouldn't say often, but they happens a lot. And then there's culture barriers. When they say something, do I understand it in the right way or not? And holidays. I think Malaysia is the country with most national holidays. And remember how many holidays they have, but it's kind of we plan on something and then we realize, oops, that's a holiday in Malaysia. We cannot count on them to work on that day. It's nice to have people work on the other side of the world because that makes the development 24 hours, that you develop in eight hours, then the next company, next country, and then the other country, but it's harder to kind of make sure that everything is aligned to get on time. Any other questions? They're all aligned, yes. What's the biggest challenge during COVID and during the pandemic? Yeah. In general, remote culture or remote work was a challenge, was a challenge for everyone. For if you want to move fast, you want to make sure that you are using the tools, right? Because we're not in the office, we're not relying on communication with each other, we need to rely on something, that this is the state of the tools or the set of facts. And whatever tools that you are using to track the work, whether it's Jira or Asana or whatever. Different companies are using different tools to make sure that those tools are up to date, that makes the job way easier. Teams that they do that, their life was way easier, the team that they didn't have that, it was really, really hard because it's kind of hard to communicate with each team to make sure that what is the status, where are we, what's finished, what's not. We're supposed to release next month, are we gonna postpone, are we gonna reduce the scope, sales are waiting, marketing, it's really tough. So using the tools and making sure to build the tools in the right way, customize it in the right way to serve the teams that's critical. Any other questions? Any questions online from Zoom? I have no idea what's going on there. We're all just listening and being, I've written down so many super quotes from you. I love your pry more, fail more, be resilient, love it. So something I was wondering though, is you talked really beautifully about the fact that everything has costs. When we're moving so fast to get to that, minimum valuable product, how do we account for costs that might not be born directly by say the company, right? But these kind of negative externalities, these costs that aren't ours, but nonetheless come from what we're developing. Yes. It's kind of in every budget, whether it's kind of a company budget, if there's a company budget, that there should be a room for those kind of development or work that some companies they have it as every week you have one day for free development. Some companies they have, they know that we're gonna start this project or this product, they put it in the market as open source and they say, okay, we're gonna make money out of it. And then they realize that no money come out of it. They kill the project. They keep it in open source, they kill the project, they kill the product. So there should be some budget flexibility or budget at least calculation for, we have risk and that risk, we can take it for 30% or 50% or depends on the size of the company. When if you're starting your own startup, mostly you're doing 100% risk because you're building something you don't know if it's gonna go in the market or not. After that, companies keep reducing this to say, but every company calculate for some project, otherwise innovation will not continue. They calculate for something that we're gonna build it and we don't know how the market's gonna receive it. And they put it in the side as calculated risk. But at least it's calculated. Like when you're building it, you know that this gonna take me this amount of time, amount of money and I'm gonna build it, it's calculated and I know that I'm gonna go with this for this period of time. I started a startup a few years ago to do kind of a renting peer-to-peer. Like if I have some, let's say I have at home a speaker and I have few things for parties or I have a kayak and I have a few, I'm an outdoor person so I have multiple kayaks and other people they just want rent that kayak for a day. Can they just go to my app and rent that kayak? It's like a Uber, but it's renting. Can they go online, see who's in the neighborhood have a kayak, they rent that kayak, use it for a day and then look back. So I did that, I developed the kind of the proof of concept, develop the app and start using it and then I faced a challenge of insurance. How are you gonna make sure that this is insured? So if they damaged it, somebody gonna pay for those people, communicated with insurance company and they found that the cost that they want is too high. So they want whatever, $50,000 just to start the contract. They say, okay, like after this, I had the proof of concept, I had the minimum valuable product but then I killed that product because I didn't have the budget to go through that test. So it's the amount of learning that they got from that was huge. So I said that, okay, the time and money and they put it into building this is kind of worth the learning experience how they got from it. It's how life goes. You cannot have it tied every hand. You're gonna try and try and try and tell something, yeah. Make it that.