So, I'm very happy to be here, thanks to Pramod Sadlige and Nareesh and Ravi for inviting me here for this talk today. So, I'll be talking, my name is Raj Anantaraman, I work for Intel and based in Bangalore. I'm an agile coach, I basically also lead a team right now in terms of managing that team's deliverables and stuff like that, but my primary goal is to make sure that we are following agile and scrum in the right way, the right approach versus just scrum butt, right, that's the goal here. So, and I'll briefly share our journey of how we have adopted this on a specific Windows platform that we have delivered, which is called the Betrayal tablet that we've just deployed. So, you know, like I said, the aim is to showcase how we have done distributed agile along with a good combination of tools because, you know, you can teach people agile and scrum pretty well and they will get it, you can pretty much do it in a whiteboard, but when you get a team of people together that is cross-geolocated, you are dependent on tools, right, and the tools better be good, right, so that it can integrate and deliver value at the end of the day, right. So, I think for distributed agile to work, I think we need two essential components, one is the method itself and the other is the tools, right. So, what I'm here to share is how we have delivered both on the methods as well as on the tools and how we have delivered a product quite successfully by reducing both the time to market as well as the improving the quality on the product significantly, right. So, that's what I'll do, I'll give you a brief context, I don't know how many of you are, anybody hardware and software here, okay, one of you are, a few of you here. And for those of you that are doing software and hardware, this may be of interest, right. For the others, I'm sure this will be interesting as well, right. So, going the wrong direction. So, this is the Bay Trail tablet that we just deployed, in fact, it is right now in the Mobile World Congress in Barcelona, we've just deployed another version of this tablet. So, you know, pretty good stuff, right, in terms of a tablet user experience. This tablet, you know, that we've deployed on the Windows platform. And if you look at the, what we have actually developed at Intel is this penny-sized SOC, right, we call it the system on chip, which means that pretty much all of the logic that goes into calculations, computing and video graphics delivery, audio delivery, everything is in the size of that small chip. Can you believe that? We call it the atom processor, and that's what is contained within this, you know, SOC that we deliver. From an agile journey perspective, we started out doing, you know, our agile journey on, you know, for those of you from the hardware and software background, you probably understand the complexities involved in merging the two things together, right. You have hardware which tends to be predominantly waterfall-based, and they focus only on milestones and, you know, broad deliverables, upfront requirements and what not. Well, in a big company like Intel, software tends to mimic what the hardware teams tend to do, right, because we support, software tends to support the hardware, right. So we started out, when we started out this program a couple of years ago in September, we started out with agile and scrum being practiced in a very few teams, and by February 2013, we had a few more teams participate, and then what I'm going to share with you here is the first experience of where we have adopted scrum at a platform level, and how we have done there, right. So this, the specific version of this program is called Bay Trail, and this is another small penny-sized chip set that I showed you on which you've delivered this whole platform, right. So when I call platform, what does it mean? I'm setting the context here, by the way, so you understand, you know, where am I coming from, right. So you have this, you know, system on chip, which is basically the whole, you know, all of the hardware components that are going into a small, you know, kind of a device. And Intel, by far, if you look at the lines of code that we deliver, somebody was saying that Intel would be the second largest company only after Oracle, in terms of delivering lines of code, right. We deliver a ton of lines of code through our drivers, firmware, installs, DSP, third party IP and middleware, right. So there's a lot of stuff that we do in terms of software, and driver code is not, you know, small by any means, it's pretty large, right. So this is what constitutes what we are delivering. And especially when you look at a platform like a tablet, there are multiple teams, in fact, 20-plus teams collaborate to deliver software on this product, right. So you have some things like as basic as your BIOS, when you boot the machine, the BIOS takes over and starts to, you know, boot the operating system on that. Knows the IO devices and says, this is where I need to boot, right. Your audio drivers, how do you listen to, you know, listening to audio on a headset is actually pretty interesting, but then, you know, there's a lot of things that happen in the back end to make that experience happen, right. So there is all sorts of DSP and, you know, firmware that goes in the back end to make that audio experience happen for you, right. Things like graphics, how do you make sure that when you turn the tablet, there's actually rotating, right. Rotating by 180 degrees is a lot of software that goes into making that happen, right. There is a gyroscope in the bottom which knows how the turning should, where is the turn angle and then based on that it sends signals to your graphics drivers so that it turns it out and all that, right. So a lot of these components, so you have sensors, you have storage, power, IO, camera, CW stands for wireless, security, power and performance. So again, anybody from the mobile software development company here? Which company are you guys from? McAfee, okay, so they are our sister organization here. So glad to see you guys here. So anybody else from the mobile devices? Yeah? Which? Target. Target, okay, you guys devise, develop, okay, great, okay. So I mean, for those that are working in the hardware software space, I mean, especially from companies like Samsung or Nokia or whatever, right. When you put all these together, it's actually a fairly complex activity, right. But then the margins are pretty brutal, right. Meaning, Samsung just delivered their S5, like yesterday or day before, right. And Samsung is this company that has figured out how to deliver products, at least two products in a year, two big products in a year. And at Intel, they've historically delivered our comfort zone is on the server side and the client side, right. And we can afford to deliver products once in a year or perhaps once in two years, right, this is our refresh cycle, right. But moment we decided to compete in the mobile market, we decided that the methods that we are following in terms of our regular development models will not work, right, will absolutely not work, right. Because it's a completely different mindset altogether. You have competitors like Samsung and Nokia who are extremely aggressive. I don't know anybody worked with Samsung here before. Okay, it's not a pleasant experience to work with them. Because, I mean, they are so results oriented, right, that they will want things yesterday, not today. They will not tell you that, can you deliver this in a week from now? They'll tell you, can you deliver it yesterday, right? It's that kind of cutting edge focus and we cannot compete in that kind of market, right. So, we had to change our method. So that is what I'll talk about today, is how did we collaborate? Again, I think the story is just starting out. I wanted to share our experience but there's a lot more to it as we kind of continue this journey, right. Between all these teams, the good thing was everybody wanted to have a common goal, right. How do we deliver high quality on time platform software that really works and we can ship it on time, right, that was our goal there. So the challenges that we faced, of course, with a lot of distributed teams worldwide with very low overlapping working hours, right, so it's not fun to be in meetings at 6 a.m. in the morning or 11 p.m. in the night in India, it just gets to be, you are very, very tired in the night, you just can't afford to kind of be productive in those meetings, right. But that's the nature of sort of a globalized environment that we live in. Late software integration was another big challenge for us. I'll talk about some of these challenges very briefly. Complex requirements, anybody heard about the V model here? V model, some of you have heard it. It's a term popularized by the Europeans. I mean, they've done a really nice job. I love that model, whether it's really good, but in an agile environment, how do you make the V model work, right? It's a big challenge actually. Planning, tracking dependencies across multiple ingredients, right. I told you about 20 plus ingredients earlier. There are lots of dependencies. For example, for an audio driver to play music on the device, it is dependent on IO, right? So IO has what we call as an I2C driver, from which we have to take the audio file itself and then stream it to the IO, right? So there are dependencies. So I'm dependent on the IO guide to deliver his part of it before I can start integrating, before I can start testing my audio, right? It's a very mind boggling integration activity that we perform, right? So it's planning and tracking dependencies is a big deal. I told you about the mindset of waterfall, which is typically what happens in big companies like what we do here is hardware tends to be very waterfall mindset and then software tends to mimic that same thing. The last big challenge that we had was multiple tools landscape, right? If you have worked in any MNC company in the past, or you do right now, every team operates like its own individual business unit, right? They have their own processes, they have their own tools, right? And it makes so hard to integrate. I was just at the booth earlier talking to some of the folks from Siemens and other company here, and especially with JP Morgan earlier. They were telling me that rolling out scrum is not the difficult part. I think getting people to talk on the same tools is actually the most difficult thing, right? There is still a debate, pretty big debate, whether you should standardize on a single tool set or should you have, because we are agile, we let team self organize, right? The best thing to do is to let them choose their tools, right? You can choose your own tools provided you are a single unit by yourself and not collaborating with a thousand other people, right? But moment you talk about collaboration and getting people together, I think aligning on a single tool set is very important, right? So that is one of the challenges that we faced, which I'll talk about. So from a low overlapping hours perspective, everybody in this presentation so far has put up a world map. So I thought I'll do that as well, right? We are also located in multiple geographies, right? So we have presence in Bangalore, one of our biggest design centers here in Bangalore. We have presence in PRC, Israel, Poland, of course in the US as well, right? So fairly distributed in terms of where the teams are located. And if an IO guy is sitting in Bangalore and working with an audio team in Santa Clara, it's pretty difficult, right? How do you get these two guys to talk? And you want the engineer to talk to the engineer. And you don't want the scrum master to talk to the scrum master, right? Because maybe not much will get come out of that, right? So again, this was a very big challenge. I talked about software integration, right? So in a predominantly hardware company like Intel, everything revolves around this hardware, right? We are delivering a piece of silicon and a system on chip. That is the main focus. So our processes are absolutely waterfall based at the high level, at the waterfall level, right? I mean at the system level, that is. So when the software guys came along, they said, oh, we will tell them when the device is ready for the first, the way it happens is the designers for the hardware do the designs in what is known as an RTL language. Anybody heard about RTL? Yeah, some of you know what RTL is, right? So RTL is basically code also where you type, put in the registers and whatnot and say, this is what should go in and come out and all that stuff, right? So that is all written in hardware. Basically that goes on in the hardware development. So the design guys develop it. They send it to a small manufacturing unit where they take the designs and produce some sample chips that we can then use it for integration and testing, right? So the way that we used to do it before was we would wait till the first sample arrives for the hardware and then start writing your software and then start to integrate and test it and everything, right? Absolutely won't work anymore. So and what is the most difficult part here is that the validation times for software becomes so narrow that by the time you develop your software and validate it, there will be a lot of bugs. So that leads to push over of your milestones and delivery dates and everything like that. This is the current problem that we were facing before we adopted Agile, right? This is the V model that we've been using. So this weather waterfall or Agile doesn't matter. The whole idea is that it all starts with use cases, right? So I'll give you an example of a use case. If I have to click a photo using my camera and I want to hear this haptic feedback or this sound that produced when I do the click. There are four components that need to come together, right? First I talk to you as the IO driver. Then is the audio guys who are delivering the, taking the sample and beaming it through the IO. Then you have the camera itself which actually takes the pixels from the image and then stores it into the device itself, right? So there is lots of things that need to come together. So a V model is of absolute importance to us. So we start with the use case that is defined at the platform level. What are all the 300 plus use cases that we need to deliver in a platform? Like this tablet that I showed you earlier, we don't create these products ourselves. We give it to the OEMs or these Dells and ASUS and all these companies. And they put our reference designs together and they put the label on top and then they sell it, okay? That's the kind of the way that it happens. So we understand the use cases really well. Use cases are then broken down into components and component level requirements and so on. But how do you fit an agile sort of a model in that V model, right? It's kind of the, what's the challenge as we adopted this? I spoke to you a little bit about the dependencies where you have, at the top level you have the platform schedule itself. And then you have the development team schedule for development team one, two, three, four, and all these guys run as independent business units, right? Collaboration becomes a very big challenge when that happens, right? So whenever one team hits an impediment that's shown in red there, how do you communicate that that team has set an impediment, okay? So this was a big challenge. I mean, we used to do a lot of these PowerPoint presentations and whatever methods that we use for communication offline. When a team hits a kind of a roadblock on one schedule, how do you communicate? The older ways was to do a PowerPoint. You used to bring the leads together in one meeting, you know, upwardly say, and we call this a traffic light problem, okay? Here is what it means. Dev team one says that they're actually stuck. They have an impediment, right? They put together a nice PowerPoint, green, red, whatever color code that they use for reporting status up in a PowerPoint. It goes to the second line of management. They say, ah, this is all right. This becomes an orange at the next level. Then it goes to our senior VP and the VP says, ah, it is actually kind of a, it's green, right? And then they pipe it upwards and say, this is wonderful. And whatever this person, this team is reported as red as we are struggling. Sort of gets translated upwards and it loses its meaning. Earlier we played this Chinese whisper game here, right? Ravi was leading us through that. It's amazing that we only got 50% of the people here got the right answers, right? So very similarly, we play Chinese whispers in big corporations. We do this upward presentation of, presentation goes upwards, upwards, upwards by the time it reaches the CEO, it's lost its meaning altogether, right? So how do you prevent such a problem from happening? Where reported status is actually what shows up as really as the end deliverable here, right? So this is another problem. I think I've already spoken quite a lot about this waterfall mindset, too much affluent design, requirements, bulk and late integration. I'm not gonna belabor that. The last challenge we had was this multiple tools landscape issue, right? So when I started on this job of, for platforms worldwide, I'm the coach for this platform team. I'm coaching them on how do you do things better from an agile standpoint and deliver it well. When I did an evaluation, there were eight SCM tools. You had tools like Perforce, JIT, TFS, so many, right? Eight SCM tools. So people are all checking in code in various SCM databases. And then you had about three or four project management tool. And guess what was the most popular project management tool? Excel, there you go. Excel never goes away, right? It is still, I love Excel too, but do not use Excel for your global collaboration project management, right? So the last one is defect management and there were a ton of those also, right? There were a rec pro from one company and then JIRA, blah, blah, blah, right? So there are so many, so many of them out there that it becomes hard to know. When I'm deploying a platform software, platform, when I'm deploying it, I want to know the count of defects, high and critical bugs that I carry at any given point of time. If I have to do that in the world that we were in before, I would have to ask three or four program managers and find out, where are you guys? What is the defects data?  And my job as a program manager is pulling together data from so many different sources. Anybody been in that board before? I have some empathizers in the room here, excellent. So you guys understand what I'm talking about, right? It's a very, if you're talking lean and eliminating waste, the first thing we should eliminate is all PowerPoint and Excel in terms of updates, right? In terms of status updates and rolling up information. So in a collaborative distributed agile world, I mean, we made it a goal that we're not going to let so many tools out there, right? So how do we standardize on one tool for SCM, one tool for project management, one tool for defect management, and that's it. No more bridges, no more piping of information. And this was the most difficult battle more than agile or scrum itself, right? Because what happens, tools are like a religion for people, right? They say, my tool is better than your tool. They say, rally is better than version one. This tool is better than that tool, right? I mean, every tool has its pros and cons, right? I mean, everybody has done a fine job of the tools itself. But I think the key in terms of distributed agile is standardizing on one or two tools that really makes sense for us, right? And the job is to convince people that guys, focus on development, hardware, work, or whatever. Do not focus on the tools and what the tools offers. Yeah, there'll be some issues here and there, but live with it guys. Our bigger goal is to deliver a product. Not to talk about this tool has this nice UI, blah, blah, blah, versus the other tool. You guys get what I'm saying? Yeah, so this is the one. So what solutions have we provided, right? The first and foremost, again, which is of one of the easiest things to solve, was this shift left, right? So where we earlier, I showed you this picture where the green thing on the software was actually kind of only intersecting at the development phase, right? Now because of a lot of simulation environments that is available to us, we can take the RTL code that the hardware guys are developing, put it into a simulation environment like SLE or FPGA. For those of you from the pure software world, don't worry about these terms. It's just a simulation environment on which you can load the software and you can do the testing on that as if it simulates your hardware environment. It simulates that system on chip that I talked about earlier, right? We also have generation N minus 1 hardware. So for example, before Bay trail, it was Clover trail, right? So you can use that previous generation of that product and do the testing as well. It may not be exactly the same, but at least you can test some part of your code in that machine, okay? So these are all the three things that we did and we adopted an iterative life cycle there, of course, with Scrum. We standardized on Scrum across all of these teams. I mean, going there and coaching teams, educating them was the most easy part when I compare that to the tools part of it. But I think we got good buy-in from the teams, right? So this was the first solution that we put together and by doing this, true vertical slicing. How many of you know vertical slicing? You've heard, right? So vertical slicing is if I'm gonna deliver this experience that I call with this use case of where I can listen to audio through my headset. I break it down to a thin slice, make sure that that full, I'm able to deliver at least a slice of a feature at the end of a sprint. Versus saying I delivered just this one portion of the IO driver or the audio driver or whatever, right? That's not the goal. I need to have a thin slice that is working and verifiable at the end of this sprint. So this was a hard part as well, right? Educating teams on how do you do thin slice and deliver it was a hard part. But I think with the coaching and training, we got over that part. And then we did this Scrum of Scrums roll out. Which was, I mean every team, we had a Scrum of Scrum meeting, which focuses on use cases and impediments and dependencies, right? Use cases I'm sure all of you understand, right? Use cases what the customer feels when they get the product on their hands, right? That is a use case. The Scrum of Scrum is very focused on use cases that we are delivering. Is it verifiable, right? That is a done criteria. Is it verifiable that it is working? And I can actually, if I decide to stop my Scrum process, can I ship that product out right now, right? That's the Scrum of Scrum process with the use case. And then each of the ingredient teams focused on what we call as features and user stories and sprints, right? So this is sort of the other approach we did. And we standardized on a one week sprint, okay? It was pretty drastic because people are all used to three week, four week kind of a sprint. Standardizing on one week across everybody was a very difficult activity. But that forced people to say, what are the things that they can absolutely commit for that week, right? This was very essential and there are pros and cons with sprint timelines, I think, but we just picked one week. That is my decision. I said one week, we'll just do it. And we just rolled it out that. The next important thing that worked for us was management support. We had a wonderful VP who really understood all this methodology. And he helped us quite a lot in both sponsoring and championing the scrum of scrum rollout. Adopting a single tool for each purpose, like I talked about SCM, scrum, defects, requirements, etc. He was a big force behind that, right? So he used to kind of whenever I used to report impediments to him saying, hey, this team is saying they only want to use JIRA or something like that, then like, okay, guys, at least for this platform, can you migrate. So he would talk to them and get their buying, which is pretty useful, I think. And he helped remove roadblocks, right? So which was every impediment that any team raises, we created a dashboard in which it's escalated and anybody can view the impediments. Meaning anybody who's working on the program can view the impediment. And the VP used to review that on a weekly basis. There were some teams who said, scrum, we don't follow scrum. We follow this rapid prototyping model, whatever they call it, right? But we had to ask them to kind of, we had to seek his influence to go make non-participating teams to participate. And again, tools integrations was a big deal. I mean, he funded that. And the last thing that I wanted to highlight here is in a distributed model, especially when you're working on thin timeline margins and high quality goals, you cannot afford to miss commits. But it's very hard to miss commits. And you need a mechanism. Even though scrum talks about self-organized, you take your own goals and stuff like that. The model that we implemented was called managed personal accountability. We said, if I'm gonna commit to something, I better make sure that I go and deliver that within the end of that week, right? If not, you explain to me why you didn't deliver, right? So this may seem a little contrary to self-organized goals, but actually really very simple, right? If I'm committing to something, I better make sure I'm committing the right things before I go and deliver it for that week, right? So this helps each individual in the organization sort of focus very clearly on what are they gonna deliver, right? So this was another good thing that happened. We integrated, we were able to get this single unified tool. We are using a rational team concept which is from IBM for our scrum tool processing, right? The UI is not that great, but I think the beautiful thing about RTC is that it integrates so well with any tool in the world, right? You can pretty much go to pretty much any tool that supports this restful API, and you can integrate with them very nicely, right? So we integrated SCM tools like Perforce, JIT onto this. Build tools, we are using Team City right now, and that's working out quite well for us. Test execution, we are using HPQC, which is working out quite nicely. Defix tool, we have our own homegrown tools, because we come from a software hardware background. Our hardware guys use a very focused tool there, and we have, since we have to collaborate with them, we have to use the database that they use. The one big change that we introduced after this V model was this platform requirements tool. We are using a tool called JAMA, called Contour. Anybody heard that? So it's a very small company, but they've done a nice job of rolling out this breakdown of the model, right? So we've integrated all this, and then it all rolls up to a business intelligence dashboard, where I can track where things are, what is the status, is it working well, not working well, and so on. So that's the, I mean the biggest part of the journey was getting the tools integrated and getting people to use the same set of tools, right? So that was the interesting part. From a work item hierarchy perspective, I think it's very important to in any lean or any, I mean any kind of scrum practice, right? You need to have a good work item hierarchy or a work breakdown structure, right? We start with the use cases. Of course, use cases are at the platform level. You say that I need to get the click sound when I press the button is actually a use case. Use cases are supported with test cases, right? So automated test cases that I should be able to verify whether it is working or not, right, at the platform level. And we break that down into features. Each feature is basically is like an epic, for example, right? It cannot be delivered within a sprint, but perhaps it may take two or three sprints for you to deliver. A use case is like a larger epic. The reason we didn't call each of them epics or whatever was, these were terms that people understood, right? If we introduced epic and whatnot, we felt that it was too much to educate people on what they are. So we decided to steal some old terminologies. We said, OK, use cases you are familiar, features you are familiar, we'll stick to that. We'll only introduce this concept of story. And story to us was something that you must deliver within a sprint, right, within that one week. So it made them forcefully think what is it that they can deliver, then of course, at the task level. Every story, in order for them to claim done, they have to demonstrate that the test cases are actually working. Automated test cases should be working. Automated or manual that are executed in HPQC reports status back into the scrum tool and says whether things are working or not. I'll give you a quick demo of this. We call this reported status should be equal to verifiable status, right? It is not OK to say something is done if I cannot verify that, OK? What we found out when we rolled out all these scrum processes was it was all trust-based, right? I said, I trust you. I trust that you will deliver it well. But we have seen this mentality that people just claim they are done, even though they are not really done. They'll just mark something. Anybody from the validation team here, from QA team or whatever, you probably understand what I mean, right? So the development team says, yeah, we are absolutely done. But when you open that code and start testing it, it is not done at all, right? It doesn't work as design. There are lots of issues with it. So what we said for the QA team to accept, for the validation team to accept it, they have to demonstrate that they have run the test. In fact, we have tied the unit test system with the RTC tool, which I'll show you a quick demo here, or a slide here, because of what we've done. So we have requirements, which talks about use cases and features. And we have test cases underneath each one of those. And within that test case definition in one of the tools, we have marked them as must pass test cases. These must pass before we can call something as done. So what happens? It syncs up with the scrum tool. We bring the use cases over and the features over. The team members break that down into stories and tasks. They say, I'm going to deliver something in workweek 10. Workweek is basically the calendar week that you're on, right? And at Intel, we communicate everything as workweeks. Now, then what happens? A developer starts to work on code. They check in. It goes to the SCM tool. It creates a change list. And when they do that change list creation, they must select the feature for which they are checking in the code. If I'm checking in a code for an audio driver, I will go and say that it is for this Dolby DS1 driver that I'm checking in code. So then it triggers a build using our back end system. And the build goes in. It executes the specific test that we had defined in the requirements engine. It does the test execution. At first time, none of the tests are passing. When the developer checked in code in workweek 10.1, which is the Monday of that week. On 10.2, she again checks in code. Now, one test is passing. In workweek 10.3, she checks in some more code, build, and now all three tests are passing. Then I can claim that it is code complete or done. So till then, the status of marking something as code complete is not in the developer's hands. Frustrating for developers? Any developers here? Do you like a test system to tell you whether things are done or not? Probably not, a real honest answer. So it was a difficult transition for us to get that over, but then this worked beautifully because reported status should be equal to verifiable status. But this was another transition that we went through. In terms of metrics to track, we had what we call as an S curve, which is nothing. I mean, anybody heard of S curves? Some of you have heard it. S curve is a fairly standard terminology in the industry where you say, OK, these are all the features that I think we are going to deliver by this week. Again, upfront planning. But then there has to be some amount of high level plan, without if you go blind into this, without knowing the sort of, I'll design as we go, it becomes hard. So this is one way of sort of seeing where are we trending right now. Are we trending in the right way? So you look at how many features or use case that we committed have you really delivered. So this blue line on the top shows the plan. And then the other blue bars basically talk about the actual that was delivered. So we get to know, are we really behind or ahead? Our tracking or planning meeting structure was we start our sprints on a Monday, 7.30 to 9.00 PM. The whole program management for this was done out of India. So we met 7.30 to 9.00 PM India time to start our retrospective and scrum planning from India. This worked out quite well for the other geographies as well. The only geography we couldn't get hold was the PRC guys, because they were three hours ahead of us. But that we sorted out through the daily stand-up meetings. They had to get their plans up into a tool so that we can have a quick retrospective of the scrum of scrum levels. And then we would have a daily stand-up with all the scrum masters participating in that. 9.30 to 10 o'clock in the morning, everybody would come and participate. So that's kind of how we did it. And we kind of, so not the most perfect. When you're working with so many geographies, we can't solve this time zone problem at all. It's impossible to solve it. But with tools that integrate, hopefully at least all the dashboards and everything is very clear, that you can get information from it very quickly without them having to participate in these meetings. The other thing that I talked about was holding people accountable to what they're delivering. We had this work items. So you can either commit to a feature or a use case or a story or whatever to a particular week. And we say that, OK, all right, you've committed 10 work items. At the end of the week, how many work items did you deliver? I mean, it's not a perfect science. It doesn't tell you that by story points, complexity could be different. I could deliver five stories of really low complexity. But another team could be delivering one story of very high complexity. I mean, it's not a perfect science. But at least it told us something that if some people are really consistently lagging, then we know that there is a problem. It's just an indication of how many work items did you commit, how many did you actually deliver. And we use that as a way to understand how, from a retrospective perspective, how do you correct it for the next time. So we also track this quality of plan. And we said that it has to be within a certain band. Yeah, you can go between 75% to 100%. You can be in a band. But if you consistently go below 75% of your commits, then you need to explain in a scrum meeting as to why you couldn't deliver. This is one thing that we did. Because without a band, it's very hard. You cannot say everybody's self-organized, do whatever you want. You had to put some kind of a band to say, guys, at least meet between the 75%.  But it doesn't mean that whatever you're committing, you're consistently under-delivering is not good. So that was it. From a business results perspective, we pulled in this product. It was targeted for a holiday spring refresh. So we have this terminology called spring refresh and holiday refresh. Spring refresh means for the school season, the spring time, which is from January through March, is what we call as a spring refresh time. We were originally targeting deliver this product in spring refresh, but we delivered it in holiday refresh, which is 2013 Christmas time, which is the time when people buy all these products and everything. So we delivered it for holiday refresh. So it was a three-month pull-in, actually, which was pretty fantastic for a giant company like ours, which is always delivered product in two years, timelines, or whatever. So three-month pull-in or one-quarter pull-in was pretty good. At beta time, when we were testing all the use cases, we had 100% of the attempted test cases with 99% passing, which is unheard of. We always had 85%, 80% type passing test cases, but 99% passed because of this discipline. Because of the discipline that verifiable status, I mean reported status is equal to verifiable status. And then we eliminated pretty much all PowerPoint or Excel based roll-ups. Everything was through this dashboard kind of a tool, which is right from the scrum level, where the individual developer is working, all the way up to the use cases, you had full traceability, where I can pretty much drill down from a use case all the way down to the last task that was performed in that use case through that whole system that we designed. And we had pretty good design wins from OEMs. So here is our CEO, Brian Krasanich, who went up to the stage and demonstrated the first Bay Trail tablet in San Francisco in 2013. We had pretty good design wins from ASUS, Dell, and all these guys. In fact, in Mobile World Congress that is just going on right now, we just had another good design win as well. So it's pretty important for Intel that we deliver good products on the tablet side. We're also working on the phones as well. So we did deploy a phone in India called the Zolo Lava phone, which we learned quite a lot from that experience. We didn't do a big marketing gig or anything. Anybody heard of the Zolo phone? Intel launched? Yeah, some of you have heard it. I mean, it's a good phone, but obviously we couldn't compete with the likes of Samsung or anything, really high-end, right? But we are learning a lot in terms of how to do this. And we have really improved through this sort of agile mindset. How do you deploy products in a good way? I mean, we do have areas for improvement. Our test automation rigor is not that high. I mean, people kind of get behind this excuse that it's hardware, so it's very hard to test, right? You cannot test hardware, right? So we had to kind of teach them how to do it. People, since we support each of the software development teams support multiple products or platforms at the same time, they get a lot of interrupts, right? We've been working with Samsung on some things and some other companies, and they would say, oh, this is absolutely a high priority. So they drop everything that they're doing and start working on this defect, right? So we need to get better at that handling interrupts. I talked to you about multiple platforms and setting priorities. We haven't yet empathized with the need for a good product owner at every team level. We have one single product owner for the platform. But the change we are driving in, at the HR level, we want to create this formal role called as a product owner and scrum master who can drive these things internally in the organization. That is still not there in that extent. And also we want to drive this business value based decision making. So for example, if I deliver a use case, if I can associate a business value as simple as low, medium, high, right? It's pretty good actually. So then I can say, OK, is this product more valuable than some other product, just purely based on the value that we are delivering? So we are working on some ideas like that right now. Hopefully for our next generation of the platform that you are working on, we will introduce these things. So I want to wrap it up. Just say that I think for a distributed agile to really work, management buying and sponsorship is absolutely essential, right? So if you try to do this distributed agile without management support, it won't work. So shift left, I think, delivers immense benefits for us. Having a clear work breakdown structure is absolutely important. If you don't have a good work breakdown structure that is common across all these teams, you'll all be speaking different languages. Some teams will say features. Some teams will say stories and epics and whatnot. You have to standardize on the same terminology. Integrated tools, eliminating all offline updates is very important, critical for a distributed agile. And the last thing I want to say is that I cannot over stress that enough. Agile is all about trust and all that. I absolutely agree. I think we need to have a trusting mindset. But also let's make sure that reported status is actually verifiable status. Without which, you can do a nice scrum of scrums and all this, but really you won't get anywhere because it just doesn't work at the end of the day, right? So that's it. Can I answer any questions people might have? Yeah. Excellent. Great question, actually. So after seeing this, I mean, till now, what was interesting was Intel was a company where hardware was doing fantastic and software was the laggard, right? We couldn't never mean our systems were all buggy and drivers would not install when you put it in an OEM machine and all that. After this experience, they have come to us and they said, Raj, we really want to do agile on hardware now. So we are just starting coaching on some hardware teams right now. And it is an unbelievable mindset change that we had to go through, right? We just started the coaching. So in the next platform that we are delivering, we are actually coaching a lot of hardware teams into adopting this. So I mean, this concept that I've talked about is nothing new, right? I mean, nothing foreign in terms of hardware. Pretty much the feature, use case, everything is absolutely applicable, right? But just because they have gone on as sort of a mindset that worked for them, we didn't even force you. So I'm glad you asked that question. Thank you. Yeah, I mean, they are really open for change right now. So the coins have turned now, where software is leading and hardware is lagging, right? So we are saying, I told you so, guys. That kind of opposition. Thank you. I mean, shift left is, if you have in a waterfall paradigm, you have requirements, design, development, validation, right? This was the hardware sort of lifecycle. On the software, you wait typically when the hardware is delivered, and then you start writing software. But what we did was we shifted left so that even as you do the design, which is done in this RTL code, you start integrating. So shift left on software means you are pushing your software integration early in the cycle versus waiting till late. That's what shift. Any other questions? Yeah. Yeah, excellent question. I mean, this is that work breakdown hierarchy I talked about, right? So V-Model talks about use cases. It doesn't talk about what you should do beyond that, right? It talks about the use cases and maybe some component level requirements. But then we thought that if you have to do that thin slice of feature that I talked about, it worked quite well because, you know, I mean, V-Model does talk about how many of you know the V-Model? I'm making that assumption. Some of you know, right? Anybody don't know the V-Model? Obviously, those of you that didn't raise your hands. V-Model is this, like, you have sort of what needs to be delivered that gets broken down into smaller definitions. And the other part of the V is, is it working, is it working, is it working, is it working, right? One part of this breakdown, the other part of it is, is it working, right? So the beauty about V-Model and I think it works quite well is because, you know, you can now, because of this what works thing, you have this ability to, you know, kind of slice into smaller features and say, I'm gonna, you know, have a feature on use case being delivered at the higher level and then stories which are thin slices, I would be able to fit that into a sprint, right? And then I have my test cases that are supporting whether I'm really what I have delivered works or not, right? So I think it is possible, right? Yeah, yes, yeah. Great question actually. So, you know, we defined what we call as integration camps, right? So once in a month or a quarter depending upon where we are in the life cycle, we would have this co-location of some of the developers, for example, audio developer, BIOS developer, IO developer, you know, firmware guys, whoever is needed to make a feature work. So we would say at the end of this milestone, at this end of this integration camp, I want four features working that are verifiable. So when we bring everybody into the same place and have them test, you know, that whole thing and make sure it is working, then we let them go.  So yeah, I mean, that concept is, I feel in a big company or organizations that are delivering complex products, you should really have only cross-functional teams, right? Don't have those audio blah, blah, blah teams like expertise-wise break it down, but then do something like I want Skype working by the end of this Skype, which is the Microsoft product. Up and running, I'm able to chat with somebody, right? Till then I need to get that working, right? So this kind of what we call as an integration camp, based mindset would work pretty well. We are learning some things actually, you know? But you know, it's so expensive, right? To co-locate so many people from different areas and have them come to one place, it's pretty expensive. So that's why we are kind of running with this model right now. Any other questions? I have time for one more.  We didn't do this on the hardware, right? The hardware teams, we didn't even involve.  At the software level, I think it was, you know, a matter of teaching them how to break down work that is fittable within that one-week sprint, right? This was a very foreign concept for them, for teams that didn't know any, didn't know how to break down work. The initial part of all this was just coaching them how to do the work breakdown, right? Once we taught them, they understood it, right? They would always first resist and say, oh, firmware, we can only deliver it in four weeks for it to be meaningful.  So I can basically do multiplication as a series of additions, right? So to teach them how to do that, ah, I see, okay, you can actually do that, right? So it was that difficult part was helping them understand how do you break down requirements. But once you teach them, I think they figure it out, okay? All right, folks, thank you so much. I really enjoyed talking to you today. If there is any questions that you want me to answer, I'll be here.


All right, today I'm going to break down how I make more money as a cardiology fellow, how I did this early in my training, how much I made, and how much I expect to make this year doing something called moon lighting. Let's break it down. Hey friends, welcome back to channel. In case you're new here, my name is Lux. I'm an internal medicine board certified physician and currently a first year cardiology fellow here at the MD journey. We make content to help people like you succeed on your medical journey, but doing it with less stress. So in today's episode, I'm going to break down exactly what moon lighting is, what your roles and hours would look like. Most importantly, how much money you can expect to make per shift. And then at the very end, I'll break down how much money I made as a resident, as well as how much money I expect to make now as a cardiology fellow, it's probably more than you expect. So let's get into it. First, let's talk about exactly what moon lighting is. Moon lighting is basically taking extra shifts in your area of practice using your experiences, but usually outside of your current job description or even your current employer. So it's basically taking extra shifts, being whatever kind of doctor you're already trained to be. So for example, I'm a board certified internal medicine doctors. As you'll see when I do moon lighting, I could just work as an internal medicine doctor, even though currently my day job is training to be a cardiologist independently in two years. And to give you a few examples of moon lighting that I've done as well, examples that I've seen, let's go ahead and start talking about moon lighting that I did back when I was a resident in internal medicine. And to give you guys a better idea, here are a few examples. Back when I was a resident, so I did a three year internal medicine residency and that basically was all taken place during the COVID pandemic.  So I had my MD, but if you had your DO, you're technically a doctor. You just at that point need some supervision while you're doing stuff, but they may say, Hey, Lux, we have a Saturday evening shift where we need help admitting patients from the emergency room. We only have two doctors that work there. We usually need four doctors for the volume that we normally see. We have two open slots. Can you take one of them and work from 7pm to 7am admitting patients with somebody supervising your admins? So that would be a very common example of moon lighting shifts that I would do where I would just come to the hospital and admit patients as they came and how a supervising physician, if I would just talk about my plan since I wasn't officially a licensed board certified physician like I am now. But on the flip side, sometimes the hospital will say, Hey, we actually don't need any help with admitting patients from the emergency room. We just need somebody to help cross cover all the patients where all the doctors are gone for the day. So you can imagine if you have 10 doctors in a day time taking care of everybody, there needs to be somebody there at night time to be able to take care of any emergencies or be able to answer questions for nurses. And so they may say, Hey, here are a list of 30 patients. If the nurses call you about these 30 patients, then you have to be able to help whether it's take care of an emergency, answer basic questions from their chart, whatever it may be. But otherwise, that's all you're there for. If you're not called for anything, you just kind of hang out. So that's called cross cover. So we've talked about moonlighting admissions shifts. We've talked about moonlighting cross cover shifts.  You may cross cover some patients as well admit some patients. But those are very typical examples back when I was a resident of things that I did, especially during the COVID pandemic, where the necessity for residents and trainees to take these shifts was really high. Towards the later part of this video, I'll talk about exactly how much I made on those shifts. So again, stay tuned. So those were examples of moonlighting experiences as a resident. And now I'm going to talk about more that you can even do as a fellow. Now a quick overview for the lingo, if you're not familiar, resident is basically somebody who's finished medical school and is going through their three or seven year training to be that kind of doctors. I spent three years to do internal medicine residency. And now I'm doing subspecialty even further to just be a cardiologist. So three year fellowship, but usually between your residency and your fellowship, you get board certified in your broad field. So I got board certified in internal medicine. I can work and as an independent medicine doctor, which I actually have done as a year as a hospitalist, if you guys are interested, I'll go ahead and link that video up here or as well in the description. But as you can imagine, because a fellow has more certifications, they have more opportunities to work both independently as well as oversee other trainees. When I was a resident working in the ICU, often sometimes there wouldn't always be a supervising attending in-house in case we had an emergency, but there would be a moonlighting fellow that'd be usually in cardiology, a pulmonary who had their medicine licensed. It could just oversee us making decisions. So we had no indication to bother them because we kind of knew what we were doing overnight. The fellow made a decent amount of cash, which we'll go to in a second and really not do anything. They would just kind of sleep and be available in case you needed them. But they would still get paid on the flip side again, because you have your license, you can practice independently. So just how I worked as a hospitalist, admitting patients and triaging them. I can take extra shifts with my old employer or any similar employer, which I currently do. And we'll talk about that in a second, basically doing what I did as a hospitalist, which is showing up, admitting patients, taking care of the patients who are already on the list, discharging them and so forth and getting paid a certain amount for that. So now that we talked about exactly what mood lighting is and the various roles that you can take on, let's talk about the time commitment of what these shifts look like or have looked like for me. So back when I was a resident, most of the shifts that we would take for mood lighting would be anywhere from 10 to 12 hours. You would work from 7 to 7 p.m., 7 to 5, or you would work a night shift where you would work from 7 to 7. Those would be the longer shifts. Sometimes, depending on how flexible the person who is giving you the shifts were, you could say, hey, I want to work a half shift. I may work 7 p.m. to 1 a.m. and then have a decent night sleep before I go do my clinical duty for the next day, or I may work a half of an afternoon, enjoy the rest of the evening as well as the nighttime before I go back to my normal rotations. But most of the shifts that I ended up doing were 10 hours or 12 hours. Now, currently, as a cardiology fellow, a lot of my mood lighting is actually spent working for my former employer when I was a hospitalist just picking up extra shifts when they need them. And so for those shifts, usually I'll wake up at 7 o'clock, get ready, go to the hospital, go through my list of patients, which could be anywhere from 15 to 18 patients. Always be ready for admissions. You may get anywhere from 2 to 3 within a 3 or 4-hour window. And so you basically have taken care of, like, 20 to 21 patients in the matter between 7 and 3. Usually, I would say that I would not be taking any more admissions after 3, so you give them a big chunk of time where they could give you patients and you take care of old ones. And then from 3 to 7, I was available from home in case there was an emergency that had to go back to the hospital or do some triaging or whatever it may be, but I was not open to admission. So I was technically working from 7 to 7, but 7 to 3 would be my admission window where I'd have to actually be physically in the hospital. And then 3 to 7, I would have to be nearby and available for the nurses and other doctors if they had any questions. And then probably my favorite part about these shifts is that you are the decision maker. There's nobody above you in terms of supervision. You are the head honcho, the decision maker, the tending. And so it's really nice in terms of efficiency and just being able to take care of patients quicker. So now let's break down the most burning question, which is how much do you make on these shifts? Now in general, to give a good range, I've seen shifts being offered anywhere from $1,000 to 1,500 per shift. Anywhere from the 10 to 12 hour shifts that would be kind of the range. Again, it would depend on the role that you would be taking on during those times slots. So if I was working in the COVID ICU back as a resident, I would get paid on the higher end of that because these were sicker patients. You needed to be in-house. You would have to admit sicker patients. So because of the workload usually being higher, the pay was higher too. Versus things that were more cross-covered. So if I was working a night where I didn't have to admit and I just took care of patients in the hospital that were already there, usually there's a chance that there's not much that goes on. You may answer a page here and there, but you could possibly even get some sleep. And so those shifts may be closer to the $1,000 mark. And so a lot of times when I would be taking these shifts, I would look for that number of 1,200 for a 12 hour shift and usually would take a night shift because that meant that if it was a chill night, I had some admissions, cross-cover wasn't too bad. I could possibly get some sleep, wake up the next day and have a day off or go to my clinical responsibility, whatever kind of part of my structure there was and still get paid a decent amount while getting that experience as an early training, being an independent provider. Now currently as a fellow, knowing that that was my threshold as a resident and knowing that I have more experience, I usually use that 12 to $1,300 mark as kind of my initial cutoff. And depending on the shifts or how necessary it is for somebody to fill them, some of these companies will offer bonuses to encourage more people to take shifts where they are really severely down in terms of providers that have available. So personally, I would look for those shifts to have those bonuses because it makes sense if I'm gonna show up to go work, even if I have to work hard, I'd rather make more money versus not being so busy but still being present in the hospital. Now that we talked about numbers and roles, let me just go ahead and break down how much I've made through moonlighting both in residency and now in fellowship. So in residency, about halfway through my second year, I was officially approved by my program to be able to moonlight. And this is also where the opportunities were starting to increase because COVID numbers were going up midway through my residency. And so I probably took anywhere from 20 to 30 moonlighting shifts in a span of a year, year and a half. Each of those shifts, again, making anywhere from $1,000 to $1,200, some of them were half shifts. I estimate during that year and a half that I made between $24 to $30,000, not including taxes of course. And as a reference point, my salary for those three years were about 15 to 60,000. So I'm making essentially half of my residency pay in the span of maybe 20 to 30 shifts, which is like a month's worth of work. That's like pretty awesome. And in a second, I'm gonna talk about exactly where this money goes, personally for me, where I decided to put it, but in retrospect, a lot of that money into going into investment accounts as well as a big down payment savings for us to ultimately buy the house that we have right now. And then finally transitioning to how much money I've made via moonlighting as a fellow. So I am in my first year of fellowship and after about a month, three or four, I was given the thumbs up by my program to say, you can moonlight, you are a good fellow and you can manage your responsibilities. If you wanna take extra shifts without going against your clinical hours and timing, then go for it. And so I basically worked for my old company and have now taken about 10 shifts and right now is the making of this video. We're in March and I have more coming around the queue. So with the 1200 kind of base salary plus the bonuses, I'm estimating that I've already made about $15,000, a little bit plus or minus, and then have the rest of 2024 to go. So before I break down what I do with that money, I'm really curious in the comments section if you made it this far on this video, do you think that's a lot? Is that too little? Have you heard of places that make more or less? What do you guys think about those numbers and the whole idea of moonlighting? But now I wanna break down really quickly my plan as well as again how I dispersed the money and how my wife and I decided to financially be responsible with the extra income that I'm making. So first thing is that I don't wanna take too many shifts. The income is nice, but in reality, I have a daughter at home, I wanna hang out with my wife and being busy as a cardiology fellow is crazy enough where I come home often very tired. And so I wanna make sure that when I take these shifts, I don't do it in a way that's gonna be too much for myself and my family. So I intend to not take any more than two to three shifts a month. Again, numbers-wise that would put me at about three to $5,400 a month in terms of extra income which is more than enough. In addition, I plan on alternating weekends at moonlight. So if I moonlighted last weekend, I won't do it this weekend and buys versa. That way, I always have some opportunities for family time and just honestly some relaxation. So that's the structure in terms of how many shifts I plan on taking this year. But now let's talk about how we intend on that money being used, how it's been used for my past mid-lighting shifts. From my wife and I, we'd like to think of everything as a bucket so if we make $100, X amount goes here, X amount goes there and it's the same for our moonlighting income. So there's a percentage that goes into things like investment. So funding our Roth IRA, for example, there's a percentage that goes into just creating a buffer for our home expenses. So owning a home is not cheap for a variety of reasons and things always come up. There is a bucket that is meant for things like travel or trips that we want to go on future or having a fund, just being able to buy gifts for families and friends. So because we have these various buckets and the amount of percentages that we want to go towards things like investing or charity or family time or future trips, essentially every time a dollar comes in, we know where that money will go. And this is my personal experience and opinion you may disagree with me, but that also helps that bucket system, helps me avoid going into a shift and saying, oh, their shift can pay for a really fancy dinner or a car or vacation, et cetera. Instead, it goes into these various buckets where the money doesn't seem as large anymore because you may have from $1,000, 200 go here, 200 go there and that pull grows over time. But these moonlighting shifts and the pay that come with them can easily be associated with high expenditures if you're not careful. So because I look at everything as a bucket, it one makes me focused on understanding that all that money is not going towards some crazy expenditure, but two, it also raises my threshold to take these shifts. But in reality, moonlighting is not that difficult. As you've kind of seen throughout this episode, is that if you pick the right roles that comes with the best rate, you can find the best combination of efficiency where you're not having to work the hardest but you're still getting paid for your time. But because personally for me, if I'm taking a moonlighting shift, I'm taking an afternoon or a morning or an evening shift away from hanging out with my wife and my daughter. And that has to be worthy enough to say, this many shifts a month or a year are going to be worthy enough for our future goals or personal goals, wanting to go on trips. And if it's not, it's easier enough for me to say the money would be nice.  And personally, that's how I look at it. So having that bucket system, again, allows me to avoid those high expenditures of saying, oh, I'm making $1,000 today, I can use that on X, Y and Z. It's much easier for me to not get caught up in that when I basically automatically goes elsewhere and I basically don't see it. But during both residency and fellowship, I have found that it's given me a ton of buffers as well as opportunities instead of doing things like buying a home or going on amazing trips with my wife and now with my daughter. But that guys summarizes my big overview on moonlighting. Hopefully you guys enjoyed these style of videos, these topic of videos. And if you did, go ahead, let me know in the comment section what you want me to cover in future videos. But as a quick aside, if you've made it to the end of the video, all I really ask is you hit that like button or follow or subscribe if you're listening to on a podcast. It just increases our viewership, helps me grow the channel to be able to make more content like this for you guys. If you're on your medical journey early on, you're like, man, I just need some help, doing X, Y, and Z, like studying productivity, whatever it may be, go ahead and check down below our Med School Blueprint, which is like my A to Z of everything that I did correctly, as well as things that I didn't do, and I'm like, hey, this is what you should do instead to get the results that you ultimately want. If you're not sure if it's for you, just go ahead and check out the hundreds of reviews we've collected over the past five, seven years. And if you're interested in any of our free programs or free videos or free downloads, I'll link those down below as well as our more intensive coaching experiences that we also have, I will link that down below as well. But as always, my friends, if you enjoyed this video, go ahead and check out this episode right here on My Day in the Life as a Cardiology Fellow, as well as this video right here, My Day in the Life as a Hospice. Hopefully you guys enjoy these, but as always, hopefully I was a little help to you guys on your journey. Thank you so much for being a part of mine. I'll catch you guys in the next one. Peace.


Epidemic Sound have just released a mobile app, and I'm going to be looking into that right now to show you how you can use it to not only curate your musical content for your content creation and your different playlists and things like that, but you can also use it just to actually listen to the vast array of music that is available through Epidemic Sound. So let's just get straight on into it, shall we? This is what the app looks like. It starts with this sort of discovery page where it's going to be scrolling through a sort of carousel, if you like, of different playlists. So new releases, latest tracks, now trending, things like that, and a staff picks as well. So you can just click on any one of these to go straight into the latest tracks that have been added. There is just a play button up at the top. So it's very similar to any sort of music player that you'd have on your mobile device. This is iOS, obviously, that I'm using it on. And you can just click on play from there. So you could literally just come and listen through to various different playlists, things like that. If you see something that you're interested in, you can just come and tap on whatever it happens to be. Click on the three little dots next to the name of the track. Here you have the option to either like the track or you can download the track as well from there. And you can also add it to a playlist, either an existing playlist, or you can just come in and create an entirely new playlist from there as well. So I'll just press the pause button and come back to that main screen. So that is basically what you're gonna see right at the top. But if we scroll down a little bit further, you're gonna see more of what you like, which is based on previous downloads that you've had. Obviously, if you are an epidemic user, this will look very similar to the web interface because it is basically the same sort of groupings of things. So we've got different curated themes, either epidemic essentials, greatest hits, ads, promos, and trailers. By the way, that's one thing that I think a lot of people maybe don't realize is if you have the right subscription plan on epidemic, you cannot actually use all of the content from epidemic on full on ads on either Facebook, social media marketing, that sort of stuff. But also with the highest level of plan, then you can also use them in TV ads and things like that. So really, it is a complete resource for all of your musical needs and sound effects. I don't really use a lot of music in case you hadn't noticed on my channel, but nevertheless, there is sort of intro music, outro music at various different times. So we've got to be secure about these things and making sure that we are on the right side of any copyright claims. Unfortunately with epidemic, you don't really get copyright claims because you just go in and whitelist your channels that you're going to be using the music on. And then that's it. You don't have to worry about these things. I did have a bit of an experience with Adobe Stock using their service where the tracks I would still have to go in and enter licensed details for every time I used the track. Even though I had the right to use it, it was just not anywhere near as seamless as using epidemic. So definitely highly recommend that. So these are the curated themes, as I said, very similar to the web interface. You've got different genres as well. So they split the music by genre here as well. Once again, you just click on any one of these ones to go into the track list. You can scroll down through the track list, click on any one of these to play. This is going to be very random, whatever I happen to be pressing on at the moment. But let's just pause that one coming back out again. We've also got different moods. So they split the tracks in epidemic into not just the different genre, the sort of musical style, but also the mood.  Suspense, I need more suspense on my channel, I think, don't I? And then down here, we've got featured playlists. So these are going to be the ones that we've just seen up at the top. Actually, the Stuffpix latest tracks now trending. And then also one there, which is your own liked sounds or all the tracks that you've actually liked yourself. Down at the bottom, you've got the epidemic logo just down there on the bottom left hand side. That's the one that we're in at the moment.  And so here, just like in epidemic on the web, you can now search for different tracks and you can search by genre, by mood, or by theme once again, searching into those. And once you go into something, so if I just tap on the first one, for example, then there are the same sort of filters.  And then we can do sorting by various different things, the newest or the most popular. We can also filter by genre. You can do filter by mood and so on. So again, really just mirroring what we've got on the website. So that is the search. And then you've got this one that looks like the little bookmark. That is basically for all of your saved searches and playlists and things like that. So here you've got three different playlists and you can, sorry, I've got three different playlists at the moment. One of them is just liked sounds. That's one of them that I just liked earlier. And then we've got the different playlists there. So I don't do a huge amount of curation of music because as I've said, I don't really use a huge amount on my channel. But if you're someone who's building lots of background tracks and things like that to use in your live streams, perhaps then having these different curated lists are a really great way to do that. And as I say, with so much music on there, then I can now see how you would definitely want to perhaps use this to create sort of background music, maybe working music, maybe tracks that you just want to listen to. And it does actually become a mobile music player as well. So that is what the app looks like. And just in case you are not totally aware yet, then Epidemic Sound is a resource for thousands of tracks across all different genres and moods and various different things like that. And as I've said, you can use them not just on your content channels, so on YouTube, TikTok, Instagram, all of the places. And you can whitelist those channels so that you're free to use them wherever you want. However much you want as well, there's no limit on the usage. But as I say, you can also use them with the right licensing or the right subscription, I should say. You could also use them in ads on Facebook, on marketing campaigns, even up to TV ads as well if you have the right subscription level. So takeonetech.io slash Epidemic, I highly recommend it. I went down the Adobe stock route because I already had an existing Adobe stock license and figured, well, I can use some of the music that I get included in that. It just ended up being too much hassle and too much time and involved in actually entering those license numbers and codes in all of the time. So Epidemic for the low monthly fee that it is is highly worthwhile if you're doing anything related to content creation, I highly recommend it. So the mobile app is really a great addition to it. Now what I'll do is I'll leave a link to some other YouTube content creation tools over in my YouTube playlist over on the right hand side. So I'll see you in those videos.


Hello and welcome into the coach's corner. I'm Joe Wombo joined now with Dave Trombo head coach of the women's volleyball team And it's a a somber day for us today Dropping that first-round game in the NCAA tournament. However, there's gonna be positives to take away from it Yeah, it was a Little devastating, you know, we we were in the match and we really never believed we were never gonna lose And so sometimes you're in a match and you kind of know you're gonna lose We did never thought we were lose. We thought we'd go five we you know, we won the first set we hit really well and second set they played much better than us so we go in one-to-one in the third set and you lose 26-24 and And 25-23 in the fourth so There were a lot of positives, but there were some negatives as well And some of those positives are some of the individual performance first Chelsea Ireland involved in nine of the 14 total block Yeah, Chelsea had a really good match as far as blocking actually the whole team did with 14 total blocks Which is I believe the most we've had all year something that you know I think a good scouting report and be on a read the setter and read their offense Contributes to that but Chelsea, you know got on the board with nine block assist I think that is the most she's had this year and those blocks just helped, you know Elevate the level of play, you know after a block that the team just is Yeah, yeah, yeah, because there's a lot of blocks that the other team just digs right back up But for them to go to the floor and be a point, you know, it's actually and statistically it's counted as a hitting era for the other team So you know 14 of them and in four sets is darn good and you talked about it a little bit With some of the individual performances before we hit record Deanna Bradbury having as many digs as she did. Yeah I thought Deanna probably played one of her best matches of the year with 29 digs You know, it's over seven.  We out hit them by 40 points. We out blocked them by four Unfortunately, the you know, we've talked about this all year. It's a passing and serving game We made a few more service errors than they did and they had a few more aces than we did and that turned out when you know When the total if you out of all the points we lost by three points and you know And those things become a little bit more glaring. What does the season that you have? They just had what does that do in terms of optimism a heading into the offseason for indoor? And then some of these players are also playing on the beach team I think when they step away from the season to tell you the truth that we don't go the NCAA tournament It's the season is not successful and we did do that. We just fully expected to go a lot farther than what we did so I think when they look back at The win against Eastern when they were number 13 the win against Hopkins who did go to the second round upset Chris for Newport, I'm not sure that was that much of an upset But Hopkins was the sixth seed and they upset Chris for Newport. So it'd be Hopkins the win against Stockton And of course Messiah was was a huge win in the championship game. So there's a lot of really good things I think that they come away with a lot of confidence knowing full well that they can play on that national stage And we didn't play bad. You know when you hold a team to hitting 098 and you lose Yeah, it's a little tough to swallow. I mean because our defense, you know, which includes that blocking Really played very very well. And of course tip of the hat to the seniors that leave us after this season and Had an outstanding career in performance all season long. Yeah, well Kristen Brooks in this same match last year against the same team the first round NCAA struggled a little bit passing and We didn't have to tell her Chris They're going after you what they did She received 40 balls and the coach and the other team told her at the end We finally just stopped serving you because she passed so well and she graded out as our top passer That particular match but to just show she took 40 receives Deanna took 22 and Annika took 19 So she took double event almost double of anybody else and she responded which was great for her Sarah Ballinger had you know, I thought a fan fantastic year to Be a good leader and get second team law conference and she was only setting three rotations I thought that was pretty well very well as as well and Kelsey stave Jackie Zepa Were really vocal and in practice they did play some during the year They did not play in the NCAA tournament game, but great contributions in their four years It's tough to play a sport for four years and they made amazing contributions on and off the court She they absolutely did all across the board and we tip our hats to you and the the seniors and the members of the team and Congratulations on a season well had in the six straight time into the country to the tournament. Yeah Well, we're gonna go for seven now. We just want to go farther. We wish you the best of luck coach. Thanks, Joe He's Dave Trombo. I'm Joe Waman. This has been the coaches corner


The project is called Sanshar Shakti that actually translates into the power of communication and Shakti also means the female goddess in the Hindu pantheon. So the idea is to empower the women through the ICT, that is information and communication technology tools, which is what has been also said in the Millennium Development Goals. Actually India is a linguistic federation. In fact, we have the local languages and in fact more than the local languages are local dialects. Therefore, we really need the content to be communicated through the value-added services mode in the local language so that women can understand. Yes, it is actually it has got four constituents, women who are engaged in occupation like for example, agriculture or textiles. We give them content about the weather condition, what is the price of seeds, what is the market condition or for example, if it is textiles we help them to sell the products which they have made so that by we establish the forward and the backward linkages for them. Absolutely because the technology which is actually utilized through the mobile value-added services and given to them in the local content, the information which is making them actually empowered. The information is about the cost of the raw materials, the prices at which their products can be sold at the state in which they manufacture and far out states. So, the information of the commercial information is absolutely useful to them and that is how the technology is helping them to get the backward and the forward linkages in their occupation. Yes, as of now we have 21 of these pilot projects operating and once it takes off. In fact, it has been taking off so fast that we have requests from the various states so that this could be put and this has been really a very successful project.


We got we got Poppy. Oh my god. We got Poppy. We got Papadilla Got Dennis Evans That purple on it Purple and it is for Weber State. It is Dylan Jones Podper Russia one of one First bowman card number one in the set a lot of ones on this card a lot of ones Congrats to the Weber State spot This kid potential first-rounder. He might be a late first That's Lucas E. Congrats Lucas


Okay, thanks guys, thanks John. If you haven't registered for the event tomorrow, really, if you're serious about APIs, go there.  If I look at the 600 people who are probably coming, many of you are presenting as well. So thanks John for the opportunity to really just rehearse some of my slides. Many of you will know that we all kind of do them the night before. I actually finished them last week, so I'm quite happy. It's going to be a busy week for us, right? So Axway has three sessions. My dear friend Emeline is here as well. She's going to speak tomorrow. We have a technical hands-on session. I think we are still able to have folks joining us where you get to know some of the bits hands-on as well. Yes, my talk's going to be about open banking, but really, I'm a geek. I'm a developer, right? And I wanted to look at this from that perspective. So I haven't rehearsed this much. My idea really is to say, let's, we are among friends. Let me show you the slides that I've prepared and what I had in mind in presenting it to the audience. So yes, I'm a developer advocate. I work for Axway, based in Singapore, traveling a lot, find me on LinkedIn, stalk me on LinkedIn. I will welcome that. My slides, and including this one, I haven't put them up yet. But I make it a habit before I start a presentation. My slides are in my GitHub repository. Am I standing in the way? It's probably better if I'm here. Right, so if we talk about social media, right? There's other platforms as well. And as I get to travel, I'm also a foodie, right? And I like seeing architecture. I like things. So there's other platforms that I use as well, besides LinkedIn, besides GitHub. And obviously, I like to take photos, right? So at some point, since I'm a geek as well, I was curious. So we hear a lot about this AI stuff, machine learning these days. And it's always really high level. And can we have some practical examples? And I was curious. So if a machine looks at my 1,000 plus photos, what would it see? And I said, yeah, let's take a lunch break and build this. And I'll show you the results before I show you how it's done. So I think if you showed me this 20 years ago, and you talk to me about, so there is a machine, it looks at photos, and it makes this. Because this is not something I built. This is something a machine built. This is science fiction. Today, people have an idea that machines can do this. Not sure about the how, but it is possible. So how did I do this? OK, I'm a Python dude. I use APIs. And in this case, I use Microsoft Cognitive Services. I could have used probably IBM Watson or Google as well. But I chose this one. And it didn't take me more than a lunch break to build this using APIs. This is where my clicker is dying. Oh, fantastic. OK, here we go. I was going to give you the examples, where, hello, I'm just going to click there myself.  This is the reverse version, where you say, here's a photo, there is no exif, no metadata, anything. Here is just a photo. Tell me what you see. And the machine says, this is a close-up of a pizza. And I'm 92% confident. And here is a couple of tags. And I do this for another photo. It says, oh, this is a cup of coffee. And I'm not really happy with this clicker. A wooden table next to a window, 83%. A sunset over the ocean. So I mean, I have no idea how the machine does it, but it's spectacular. But yeah, a bunch of bananas. No, right? But it's only 37% confidence. So the only thing that I actually have done with the script is, when you build that word cloud, just take the photos where you're 80% sure or more. So I use this to set the scene. I'm an API guy. What is this API stuff actually about? And why should we do it? Because that's what we want to talk about, right? Open banking, the evolution in the roadmap. What is this about developers who get thrown into this? What's kind of the history in a few minutes? Because I work a lot with these people. What are the typical challenges and roblox that we see? And what do we need to build great APIs? And my point is, obviously, I'm a foodie, and the machine proved it. But I think my point is that today, when you use APIs, and when you have APIs that are designed the right way, it doesn't take you longer than a lunch break to build something like this. Because AI, cognitive services, is something really complex. There are days where I would like to understand how it works, but actually, I'm really good enough if I just use the API. So it abstracts something really complicated, and I don't care if this runs on a Raspberry Pi or on a main frame. I just know how does the interface work. And my point is, if you have a great API, people will use the service more. So in this case, cognitive services for Microsoft, it gets a lot more sample data. Because people use it more. The product gets better. People use it more. So that's kind of the message. And how do we apply this to the big topic? Because, ultimately, we want to talk about, oh, fantastic. Can you please just? Yeah. OK. We want to talk about the two walls, right? Open banking. There is the theme that was introduced by the regulators to the large banks, imposed. And there is everything that we are looking at from the Fintech and the financial services perspective, to create new offerings. And where you can do banking as a service without having that monster machine behind you. Offer and consume financial services in a new way. So to me, the big bang is in 2015 in the EU, where PSD2 launched the new way of doing things where the regulator said, we'll allow specialized and licensed startups to access your banking details on your behalf, where you are able to outsource that to a third party. And the banks are obligated to provide access. And what was the intention? To make things safer for the payments, to increase visibility, make things safer for the customer, and to have innovation. That was the overall theme. And then the guys in the UK said, yeah, that's awesome. But can we do a little more? And we want to talk about the individual phases, where we say payments is only the start. This is phase one. And then we speak about what do I need? I need to have access to accounts, which is the first phase. I need to initiate the actual payment. And I want to find out, has the payment actually happened? And what is the history behind this? So this one is talking about this part. And then this gets adopted worldwide, where the individual countries have their own interpretation, their own approach of looking at open banking, the way we have it here in Singapore is different from the way in Australia, the guys in Hong Kong felt. You know what? Let's just do it the way the guys in the UK have done it. So there is multiple renditions of those. Who knows this guy? OK. Maurice Moss from the IT crowd. Because what does it have to do with developers? Those are really special people. Marketing works very different if you are a developer. They can instantly verify stuff. They are very resistant to fluff as well. So how do you make it relevant for them? Because I get asked, so I'm bank number X. I'm bank number Z. How do I attract developers to work for me? What sort of environment do I have to create to make it acceptable? What sort of things are they interested in doing? And I'll take DBS as an example. It's a very visual bank over here in this part of the world. And when you go to the API portal, which is open to everyone, you can sign up, register, and have sandbox access to 200 APIs where you learn about how APIs work in general. And DBS can go to the National University and run a hackathon. You have no background about how our systems work. You actually don't need it. The only thing that you need is the API, the service catalog. Because my theme is, how can I build a Hello World program in five minutes? If you have somebody who joins your department and they take six months to figure out how your system works, how can I onboard a partner in a few days? How can I open my silo database to a different business unit? Or how can I enable someone from the community to leverage my systems to innovate new stuff? That should be the theme. The challenges that we see are very much about the interface design, the documentation. People will say, yes, we have APIs. And I spent a whole day with someone just to figure out how the API actually works. They have to call someone. There is an outdated Word document. The Word document might be up to date, but there is 17 parameters in it, and I have no idea what they do, where they come from, right? Which has a direct impact to security, right? If I want to make the API secure, it's got to be in the documentation. It's got to be in the Swagger document. Otherwise, a proper API management solution will block it, right? I'm not very religious about the cloud, right? You can use the cloud. You don't have to use the cloud, but it sets the expectation. If I'm a developer, I want access to a resource in, it doesn't have to be five minutes. Give me five hours. That's good enough, but I certainly don't want to wait five weeks, and then it still doesn't work, right? So how do I get access to resources? Quick prototyping. How can I quickly see something? How can I, you know, we have all these talks about elastic and Kafka and Kubernetes. This is all science fiction, right? Because we want to start something today. We don't want to set up a massive infrastructure just to get going, just to experiment, right? And plausible mock data, right? Semantic experience, where it's not just Lorem Ipsum and ABC123. There is many others, but I think I'll focus on just a few. Design first, right? Again, I'm pretty sure this is an experience audience today, but I never, never stop highlighting that we really, as much as I'm a geek, as much as I love coding, we've got to stop that and say, let's look at the contract first. What does the API do? What's the data model? How do I authenticate? Maybe what's the license, right? And then there is stoplight, there is swagger, there is postman, right? Which should be part of the initial steps before you code. And even when you code, you're like, do I really have to code or are there tools available that do the work for me? Because ultimately, and I mentioned that in several discussions before the meetup, if we do this the right way, right? What we are consuming, what Uli is consuming in his lunch break to build that Instagram bot, right? I want to go to an API portal. I want to sign up for a key. I want to download a swagger definition. I want to get API keys. Maybe there is OAuth in the picture. It's all about JSON, HTTP-based messaging. That's all I care about, right? And we have all these complex backends in the backend. And it's a great new world where all individual developers and teams can choose the tool that they like. But we need to have that managing infrastructure in the middle that I compare it to, it's a mix of a bodyguard and a translator, right? Got to see your ticket, otherwise you can't access my API. Oh, you speak SOAP, the API that's JSON. Let me translate that for you, right? I'm sure this is something that you're all familiar with. I've personally started a project, an open source project in 2017, which gives you open banking related docker containers. I've also put some of them live in a live environment which you can consume, right? So this is an ATM locator, this is payments, this is currency conversion, account management, right? Like seven, eight containers. And you can run them on OpenShift, you can run them on your Mac, you can run them on Kubernetes, you can run them on Windows. Basically every environment that gives you docker and you'll have immediately in an offline fashion, if you like, available containers that produce reasonable data in an open banking environment. Another method to get you started quite quickly. And yeah, that's basically my talk, right? Where I try to imagine that there is probably several folks in the audience who say, how do I get started? How can I have some quick wins? What should I do? And I don't want to do a thank you slide. I say, guys, use Postman, use Stoplight, use Swagger, if you are not already doing that. Check out my stuff on GitHub, follow me on LinkedIn. There is material that you can use for free. And join meetups like the API craft because it's all about how we share and help each other. Thanks.


My name is Coleman Bates, father of the late Brody Bates, creator of the Brody Bates Foundation. The Brody Bates Foundation was created in 2020. It was a foundation we started in the honor of our son, Brody Bates, who passed away in 2019. Our goal is to help or benefit other families that have lost a sibling. So growing up, Coleman and I got to know each other through sports at the local recreational league. A few years ago, Coleman came to me, they were interested in buying a sportsman boat, so we helped him go through that process. Not long after, the tragedy occurred. At the same time, we were a sportsman looking to figure out a way to get youth more involved in the outdoors, specifically fishing and boating. And so through that process, we were trying to establish a tournament down here in Charleston, South Carolina. And as I kind of walked down that road with Coleman, one thing that kept coming to my mind was it would just be a wonderful opportunity to name the tournament in honor of his late son, Brody, and that's exactly what we did. Brody Bates Red Fish Open was started in 2020 in honor of our late son, Brody Bates. With the help of Salt Fish and League and Sportsman's Boats, they created a tournament in the low country. Middle school and high school kids could compete while catching red fish with a chance to earn college scholarship money.