Okay, I've been practicing my Irish. Are there any Irish in? No one. Oh, just one. Then just for you. I'm glad so many of you showed up during the lunch break. That's great. I'm standing here. I may not have all the answers, but I'm willing to give it a go. And at least I'm able to share my experiences with you. So my talk is called The Seven Hurdles to Reach Scrum Group on Nirvana, Y7. I'm not quite sure, but it sounded like a nice number to start with. Of course, there are a lot of hurdles when you try to embed Scrum within your company, but I try to figure out what the biggest seven issues are. So who am I and why am I standing here? This is some facts about me. I've been working in open source for quite some time now. When I was about 14, my brother gave me a computer with Linux on it. So that's where my open source hippie heart opened up. And I'm still an open source hippie. And I will always be that, I guess. I call myself a semi ex-drupalista now, because I've made for my work my profession all the way around. I've made for my work my hobby again, I'm sorry. Because I'm not into Drupal anymore professionally. Maybe I will be once again sometime, maybe. But for now I'm working at VakonSelect as a Scrum Master, full time Scrum Master. And we do that net. Sorry. I'm loving Skid since DrupalCon London. He's in the audience. We're having our five year anniversary today at this DrupalCon. So that's very great. And thank you, thank you. And my open source hippie heart opened up for the agile part of it about four years ago. So I'm an Agilista and a Drupalista. I'm really curious what kind of audience I'm having. Are there any Scrum Masters? Please raise your hand. Okay. A couple of them. Product owners. Three. Okay. More. Project managers. More. Okay. Handball players. No team handball players. Guys, you really should. It's awesome. Okay. Here's a little thing, what I'm going to be talking about. First off, to truly understand the hurdles, I would like to give you some more in depth view and give you an insight on how I think the Scrum Master role is to be defined. That's why I will start with a little in depth on the specific Scrum Master role itself. And I think this is because a lot of people know the theory behind it. But what it takes to be a true good Scrum Master is to be defined, I guess, to get to the hurdles. Then I will talk some more about the seven hurdles. Using Scrum within digital agencies. I know that's broader than just Drupal agencies because I think this talk is also for other shops, so it's digital agencies. And after that we will have an answer round. Okay. Let me take you into Scrum Mastery a little bit. To start, I just picked up my Scrum Guide and check what Scrum Mastery is all about. This is what Scrum is according to the Scrum Guide. It's really easy to understand. Everybody understands Scrum, the way it works with all the circles and the adapts and inspects and the sprints and the stand-ups. Everybody gets that, right? That's not that hard. But really, to master Scrum, that's really difficult. So, I agree with a lot of experts out there that you should have a dedicated Scrum Master in your team. It's not a part-time job. Was that me? Probably nobody else is wearing a mic. If you say Scrum Master is a full-time job, what do you do all day? That's a question I get a lot. I don't know if you ever have asked the question. If you have asked the question, is Scrum Master a full-time job, then you're in the right place because I'm going to show you why it is. I don't think a team lead developer can be a Scrum Master at the same time. And I know that happens a lot, but I'm on stage so I can shout out whatever I like. I think you need a dedicated Scrum Master. Same goes for product owner Scrum Master role combined. That's a conflict of interest that will never work. Or any other company member doing the Scrum Master role next to their normal role. I don't think that's a good idea. For Scrum Master, I think we're kind of like the Drupal Association of the company. This is the goal of the Drupal Association. The Drupal Association is dedicated to fostering and supporting the Drupal Software Project, the community, and its growth. So I stroke out a couple of lines there. And I think it's very close to the Scrum Master role within the company. The goal of the Scrum Master is dedicated to fostering and supporting the Scrum process, the community, and its growth. I will take you back to the Scrum Guide again to show you what the Scrum Master does. Let's go back to the Scrum Guide. Responsible for ensuring Scrum is understood. That's basically the part everybody understands, right? The Scrum Master explains Scrum to everybody within the team. Make sure the three-year-interpractices are done. The daily stand-up is there. And that all the Scrum rules are being followed.  Sometimes I see job applications and it says the Scrum Master leads the team. No, the Scrum Master doesn't lead the team. The Scrum Master servant leads the team. But next to the team itself, you're also responsible for the organization around it. The thing is, the job title A-Jow Coach isn't in the Scrum Guide. The Scrum Master is the A-Jow Coach, basically. So it's not just making sure the retrospectives are being held, all the events are being held. But you also have to garden the organization and help them change. My next slide will give you an overview of types of Scrum Masters you can encounter within organizations. I stole that from Angel Medelila from his presentation, How to Develop a Great Scrum Master. And I think it gives a great overview of the types of Scrum you have. The Scrum Dude, that's typically the guy or girl who was a developer and some management thought, OK, we're going to do Scrum now.  So I think you also should be Scrum Master. Which is just fine. It works. So he or she schedules meetings and does all the things that has to be done. But you will never really grow the team. Because he only facilitates everything. The second one is a more dangerous one, the Scrum Mom. And I'll explain why it is. Because as a Scrum Mom, I've been there, done that, really. I've been Scrum Momming around all the time. Really protective of the team. Sending away a product owner, sending away stakeholders. No, you've got nothing to see here. Go away. This is my team and I protect them. So I will remove all the impediments for you. Give me your impediments and I will take them away. The idea of a Scrum Master is essentially that you make yourself obsolete. The team should be self-steering. If you ever encounter a Scrum Mom or recognize yourself in it, please remember that that is not the way to create a self-steering team. Because the moment you do something for your team, which they can do perfectly well themselves, you own it. So every time you do something, you own it. So you become Scrum Mom and the developers are happily developing and never will make the next step to becoming a self-steering team and get rid of their own impediments and not just yelling at you, please solve that for me, Mom, right? So the true Scrum Master facilitates, grows, helps, encourages and is a gardener. That's basically what a true Scrum Master does. I'm not quite there yet. I'll admit, I'm still somewhere stuck between here and that's okay, right? Everybody needs to learn. Trying to. The almighty Scrum Master checklist. Just one more giveaway about the Scrum Master roll. It has checkboxes and it has a Google Doc version in which you can fill out the checkboxes. So that helps, right? This is sort of a to-do list. And basically what you are doing for the rest of the organization. That won't work. I'll just skip it. It's in the presentation. It tells more about how you can help your product owner because they need a lot of love and nurturing too, of course, to help them get their backlog right, to help them get their stakeholder management right, but also achieve the final goal in having an HL enterprise. So on to the seven hurdles. Hurtle number one. Scrum and the customer. Who have you have a customer that really, truly understands Scrum? One, two, three, four ish, three and a half. My point exactly.  It's very, very hard. So they will ask for functional designs. They will ask for technical design. They will ask how much will it cost me? What will I get? And when will it be ready? So I got some tips and tricks which I found helpful to get over this hurdle. Start with the offer. So don't wait for the signing of the contract. Start with the offer. Make sure you get really clear the way you work, the way you want to work, the way the things you expect from your customer, the things they can expect from you. So please do so in the offering phase already so they know what they can expect. Get together. The way I've seen Scrum working best is when the team is at the customers or the other way around. Someone of the product owner of the customer is at the team. Because you have to work closely together, right? The agile manifesto says, conversation over contracts. Please keep communicating. So the best way to keep communicating is to get close to each other. So bond with your customer and get together. Work together. Mind the product owner. I'm going to make a stance now which is sometimes not really well received. I think a customer should never deliver the product owner. It happens a lot, but the product owner role is really hard. It's not something to think lightly about. It can be a full-time job depending on the size of the project. And it's a profession. And when customers start a web project or an application or anything like that, probably you will end up with someone from the communication department or some IT person who will have eight hours a week for you to fill their backlog and do stuff like that. Do the fill in the product owner role. From my point of view, that's not the best way to go. Have your product owner on your side with your team and let the client be the stakeholder. So you can have a dedicated product owner at the customer side, but I think the best projects are made with product owners who know their job and know their profession. And that takes a while to learn. And you can do that in a couple of months' projects. You cannot learn it that well. So a lot of people disagree with me on this, but that's okay. I can talk with you later if you would like more in-depth information about that. Educate, educate, educate. Start with workshops. Explain what you're doing. Explain what the events you are doing. Show them your backlog. Show them how you work. Show them your board because I'm definitely a fan of physical boards and not JIRA or, yeah, it can help, but keep on educating. And not only from the start, but keep on checking as a Scrum Master are my stakeholders still in with the game? Do they still understand what we're working on? Then we're up to hurdle number two, Scrum and Drupal Development. Scrum talks about team members. You have a couple of roles. Product owner, Scrum Master and team members. But of course, in every Drupal company, you have front-end developers, back-end developers. There's maybe in your team, but also junior, media, senior. And how do you make sure that everyone in the team is on the same page and can help each other with user stories? But sometimes there's some serialism in the user story, so the back-end has to go first before the front-end can do its work. It's kind of hard when you try to do Scrum.  The way I use it or I do this is anyone familiar with Daniel Pink? The puzzle of motivation? Not everybody? Okay, I'm going to explain something about it. You should go and watch his 18-minute TED talk about motivation of knowledge workers. That's really great. He says, of course, money is important, but it can never be a motivator. Motivational employees, they are motivated by three things. It's autonomy. I can decide what I am doing within the team. Second one is mastery. I have the skill set, I know everything I need to do my job the best way I can, and purpose. Everyone who's working at a website or application wants to do that for a greater good, and that's the way to keep people motivated. I do that individually with my team members. I'm a Scrum Master of three development teams, so I have talks with them. Do you need some more knowledge? Is the purpose clear for you? You can do it also on a team level. Is the team autonomous enough? Has the team all the mastery that you need to build the best web projects you can? And is the purpose obvious? And even, I'm about to make it one step further to see level, to get it all in line so that everyone in the company knows what the purpose is. Daniel Pink, what's that guy that he's so cool. So that's my way of being a gardener in my development teams. Do use the most powerful tool in the Scrum Guide. Anyone, whenever, try. It's an event. Thank you. Retrospectives. The only way to become better at what you do is to inspect and adapt. Keep on inspecting and adapting. The retrospective, please people, don't skip it ever. Don't. Because, thank you. Because that's the way to make your teams better. Because they stand still, look back, check what they're doing, and inspect what went wrong, and do it better next time. So you will get a better, faster, more happy team. Do use it, please. And for the Scrum Masters, I've seen a couple, have a Scrum Master toolbox for it. I'm really working very hard on it. I'm having three teams, and we're having two week sprints. So that makes up for 75 retrospectives a year. You will need a toolbox. There are great sides for it. Tasty cupcakes is a perfect side to find great ideas for good retrospectives. And try to mix and match them. There are different kinds of retrospectives. Sometimes you feel that there's a problem in the team with the communication. Find one that suits that problem. Sometimes it's technical depth. Sometimes it's a lot of bugs. Find a retrospective suited for each situation and each sprint. What I found out, the Scrum Master before me was actually a very great guy, so I'm not here to criticize him, but he used the same retrospective over and over again, and just people came with filled in post-its before the retrospective. Well, once they do that, change your retro. That's a great moment to change your retro. So create your Scrum Master toolbox. I work at the camping company, so I literally have a suitcase, which says Scrum back on it, and I use that as my Scrum toolbox. Scrum and the HR department. Now, this was for me personally a very fun situation. I was working as a product owner, but the role didn't really suit me, so I went looking for a job as a Scrum Master. So I uploaded my resume, and I got called by a lot of recruiters. If you ever consider a job change, try Scrum Master. There's a lot of work in it. Only the funny thing was that all the recruiters I talked to weren't looking for a Scrum Master. They were looking for a project manager. They were looking for sort of Scrum Master product owner, sales person account management, someone. I've had so much crazy calls of, yeah, it says Scrum here in the job description, so it must be a Scrum Master then. Please do educate your HR department. There was even one where I also had to test the software. I don't think so. Other people are better at that. To educate your HR department, get involved as a Scrum Master. You know best what you need in your team. I will get back to the Daniel Pink, the autonomy mastery, the mastery part of Daniel Pink. You know what's missing in your team, right? What kind of skill set and what kind of attitude you need. So get involved in the hiring process. Do that because HR people are not skilled Scrum people. Make clear what different functions are all about. Missing an S there, but you can read it anyways. And mind skills versus attitude. Because I've met some crazy, intelligent, very smart, ideologically fast developers who couldn't communicate at all. So, well, they could, but they weren't willing to. So that's an attitude thing. Skills can be learned. That's not a problem. You can teach anybody anything. That's at least what I believe. But attitudes you can change. You cannot change, I mean. So find the right person for the job and help your HR department with that. Four, I think this is the biggest hurdle of them all. I've never been to any Scrum events, Scrum meetings, Scrum, HL, Meetup thing where this wasn't a subject. But how do we do support? It's not in the Scrum Guide. But we deliver websites and we deliver applications. And we do have to do support. How? I'm not pretending I do have the sublime answer to this, but I do have some certain ways to try and fill it in and see what works out. Again, inspect and adapt. If it works for you, stick with it. If it doesn't work for you, try something else. There are a couple of the ways I've found to do so and try it. A burning issue backlog. Have a separate backlog for your support questions. And if they're due this print because they're absolutely blocking, have them on a separate backlog and have time boxes within the teams if you have more than one team. Say they have time boxes a day to work on the burning issue backlog. That is a way. I found that not to be ideal because you do have situations where the burning issue backlog is too big to fit into the time box and then you have to engage with your product owner again to see what goes out of the sprint and you will lose the momentum of the sprint and the cadence of the whole sprint process. So it is an option, but I'm not quite fine with it. This is the one I like best, but the problem is it's not always possible because of this... I'm sorry, I'll just finish this sentence. It's not always possible because the size of the company, of course. If you have two teams, you're not able to have an extra team for your support department. Sorry, you had a question? The time boxing team ensure that your burning issue backlog doesn't interfere with your sprint time. It's the whole point of the time boxing as I see it. True, but... Well, if Drupal Gadan comes along and your time box isn't big enough then it will interfere with your sprint anyways. Of course you try to time box it and try to keep it that way so that you can see in the future how much work you can do. But there's always... Everyone knows, I guess, that there's always burning issues coming along. For instance, if you do e-commerce and the payment thing isn't working, you have to fix it, right? So it can work, but it's not always the ideal option. A certain company now working in this way. Great. Well, that's good for you. Absolutely. Probably a good coach, right? He's an old colleague of mine. And he's a great programmer. I was talking about the dedicated team with Kanban and it works when you have enough body as a company to do that. I've seen that working at some big e-commerce companies in the Netherlands and that seems to be working just fine to fix the support problem. Currently, in my company, we are trying to work with chapters. So we have... Everybody knows the Spotify model? Maybe. You have the teams vertically and you can have chapters horizontally. So we have, in every team, we have a support engineer that are over the teams to get the support done. We're trying to let them figure that out themselves. So that's where I'm moving from the Scrum mom role to the Scrum master role. We just asked them to organize yourself and make it happen. And they're actually doing that right now. But it's fairly new. So I will let you know maybe next year how it worked out. And I've also seen the support engineer per sprint. You have one team member dedicated in your sprint who is only working on support issues of all the customers. The good thing about that is that the knowledge about all different projects is better spread within the team. You have to... Everyone within the team knows what projects there are and have technical knowledge of the site or the applications. I found that we do that. We have one person in the sprint that will do the UAT issues as soon as they come up. What we've done is we rotate that role amongst the team so that you're not the same person who doesn't do that every sprint. You have the knowledge spread around the team. So it's one of the things that works for us as well. Great. Thank you. I will repeat it because it's being recorded. A perfect addition from the audience is that the support engineer does rotate the role of the support engineer. Does rotate within the team. And it works for you. Great. Thank you. I think you're in stoop bubbles. There you go. Scrum and technical debt. It's always a hard one, right? Because... And this is also why I think the product owner should be within the agency. Because this is the hardest part to explain to a product owner what technical debt is and why it's important. Please be bold about technical debt. There cannot be one sprint coming through without solving technical debt if there is any. And everybody knows there's always technical debt. So please get rid of it and be bold about it. If you sense in the teams that they're only working on new features and never on solving problems, let the team explain to the product owner that they really need that. Educate your product owner about it. One thing I saw at another speech was figuring out the business value because technical debt does have business value. A lot of product owners says you will work on that for three days to solve a problem, but it has no value. What I've seen is business value can be on different quadrants. You can have business value for the team, business value for the customer, business value for the internal organization, business value for the customer of the customer, and you can make quadrants of it. And you can decide with the team and with the product owner to give out business value points to each quadrant. Business value isn't flat. It isn't just value for the end user, but it's also value for the team. If they can do their work three times faster, that's great value, right? So, figure out business value of your technical debt and use very much smart models for that to make the product owner understand. This is also a nice one, right? Last year in Barcelona, I talked about fixed-cope, fixed price. I don't know if anyone has seen this session, but scrum and project budgets, it's always a problem. A lot of management 2.0 is about Excel sheets and customers really want to know the costs and what they can expect and what will be delivered at what time. And basically, in the beginning of the project, or building the product, there is no problem at all because the customer still has budget, but once the budget is slinking and it's getting smaller, then the problem starts. To figure out, to get control of the budget of the different projects you are working on, keep the number of the projects low. I've worked at a company, sorry, where we did 14 projects in one sprint. That's not doable, and actually, he told me yesterday that they brought it down a lot, so that was a great tip for my presentation. Keep the number of projects low per sprint because ideally, and I know that's not always possible, have your project serialized instead of parallel. So try to do one project at a time, and I know that's Nirvana. But at least give it a try and keep the number of projects in one sprint very low. Let the customer pay per sprint, and not per hour. The biggest waste, I think, in IT is our registration. Thank you. Those are the developers, I guess. Of course, the customer has to know what to pay for, but I think if you can get them to pay per sprint or pay per half a sprint even, you will get a lot of frustration out of the way within your team, and they can do what they're good at.  You should write your hours because that's the worst job in the world, right? Skip the hours. Please, bill per sprint. Just no more hour registration. That's my final goal on this, that's on my bucket list. Hour registration out of this world. Explain the rise of value for money. If you skip the hour registration and you have the billing per sprint or billing per half a sprint, you can explain that because you do your retrospectives, right, that your every sprint, the customer will get more value for money because your team is inspecting, getting better, delivering more each and every sprint. But the price stays the same. So they get more value for money each time. You do a sprint. And please don't mess with sprint lengths. Time tracking. Time tracking, yeah, I'm sorry. Is that your opinion thing? Or just Dutch? I'm sorry. Yeah, time tracking. Right. Drink length, please. I know. As you know, we and I think most group of shops have always have multiple projects, multiple customers per sprint. So the only way to make sure that the customer gets what he deserves is to do some sort of time tracking. Make sure you distribute the hours accordingly to the project. So how are you going to manage that without time tracking? Oh, I think it's best to do that based on velocity, I think. Not quite sure. Does anyone have a better answer than I have? Then you could say, okay, you're paying for a sprint per developer and not just... And then it's easier to manage. But one of the goals is actually to have all the developers work on every project so we can spread the knowledge. And don't have projects being dependent on just one developer. Of course, but they don't have to work on the same project all the time. They could be like this sprint, this developer works on that and next sprint, it will be that developer. I just got a signal because nothing of this will be recorded. So it's not to be rude, but if someone has more smart things to say, maybe you shouldn't use the microphone that's over there. Okay, let's do that. Okay. Well, I already stressed this out enough, I guess. Don't mess with your sprint length because otherwise everything up will... just won't work anymore. The last one, scrum versus scrum bot versus water scrum. Please always try for the real scrum because that is what truly makes people happy. That's what I believe. I've heard someone say, yeah, we do stand-ups and yeah, we do things with post-its on walls but if you really, truly want to grow with the whole company and with the whole team, try to use it as much and as good as possible as well as possible. Scrum will work for you if you manage to take the six hurdles and I know it's hard being there, done that. Once again, please have a dedicated scrum master who can help you with it and make sure you get one who goes to events to get more knowledge from other scrum masters. Read the scrum guide and check it. Check if you really are following the scrum guide rules because most of the time you think you are doing it the right way but keep on checking. Again, don't ever skip the retrospective. Don't, please don't and have your management believe in an agile enterprise. I'm going to end this slide with a little story about this man. This is my CEO. He's called Luke and he's truly an agile and scrum believer. That's why he hired me so I'm very glad I'm working there at the moment. Luke started that 30 years ago with the camping site near the Lake Garda in Italy and he started with a field and then he built some infrastructure on it and then he built some toilets on it some sanitary things and so he built a camping and then it just went bigger and people weren't able to stay at his camping anymore so he booked them to other campings and in 30 years time he grew to an e-commerce company now and we do bookings all over your specialized in glamping glamorous camping so that's a two-story tent with a Jacuzzi but ok that was his dream it's awesome, it really is awesome so it's a European company now and the first time he hired an agile coach and he said explain to me what should we do I want to become the best e-commerce company in the Netherlands what should I do so he explained the agile coach explained the whole scrum process to him and he said well that's just like building a campsite right so he truly in his heart and in his gut understands how agile works and that's why I love to work for this guy and I will end with a quote from him because I love it so much when people call me crazy I know I'm on the right track thank you ok I want to do this a little differently I called the sheet answers and all questions can you please just take a look around see how many people are here I can assure you there's so much more knowledge in this room than on stage so why would I take the questions so I got more strewpuffles for the best answers in the room is there anyone with a great tip, trick or hint on one of the seven hurdles just to pick up on the sizing and the time tracking from before scrum doesn't have anything to do with ours there's no way in scrum we use story points I know it's a fluid size but when I size a project we leave a tender and offer the customer gets let's say not three months or six months and so many resources 1500 story points what's that and then you have a discussion about how do you the customer prioritize your story points so you can come with all your stupid request or very brilliant request in the duration of your project but you will only have this fixed size of story points and that sort of tames and disciplines your customer as well and that really helps we never talk about ours you get this amount of resources how you want to internally in your agency move people around that's your headache the customer already knows the bill beforehand and if you come and 215 I will speak much more about this at another session thank you is there anyone who has a great tip about how to handle technical debt yes sure is there anyone who has a great tip about how to cope with technical debt you have an idea it's the waffles right just plan it in advance build it into your time if you know that you're going to have to manage technical debt what you're going to need to do just plan a sprint in between the sprints for technical debt I've done this on several projects it's been really helpful technical debt sprint solves that problem great sort of legacy sprint why have you ever had them they're great okay anyone else any more great tips on support how to handle support within sprints or any of the other hurdles more service level any other great tips guys I need to get rid of these any questions then yeah sure can you walk to the microphone please or someone handed to him or hi I'm developer so I don't know many I don't know a lot about these scrum things but my question is do you people do estimates and then look back at how close you were to the estimate of the development like if you say I estimate it will take eight hours to complete this and then do you time track and evaluate it we don't use hours at all with Instagram we use elephants and mice for instance I think this feature is an elephant and I think this feature is a mice or story points but to look back and see how well you've done you know in your heart as a developer how well you have done you know it I don't have to ask you that and we don't have to report anything about that the next time you will have a planning session you will know better whether it's an elephant or a giraffe or a mouse or two hundred or two thousand story points or t-shirt sizing that also tends to work yeah oh I forgot the mic again sorry for that but I think it's too well for Worthy almost out of time right quick question you mentioned product owners and how sometimes they are really stakeholders or should be are you identifying someone within the customers realm who is a good product owner versus this guy should be a stakeholder what's the red flags you always can find the one wrenchable neck if you say okay I'm going to stop this project now the first one at your desk is your product owner because that's the one who really cares who really feels it in his gut most of the time that's your stakeholder but again I think it's better to have the stakeholder at agency side how do you define oh that's up to the team they know instantly because you use stories are not written well the product backlog isn't tidy and working out yeah product owner will be known instantly within the team not really no someone in the back no one more question the question yeah I'm sorry the question was how do you do scrum with a small team with just three or four people I think that's really hard anyways because the scrum has a sweet spot is between seven and nine five and nine developers right I never worked with a small team like that so I'm not quite sure actually yes you can he's up for the true profit that's the only reason the only reason I'm standing just to answer that the strict answer would be you can't so there's no way of doing scrum with that small team yeah it's not gonna it's not gonna happen at all I would suggest that you go for can band or something that's much more malleable it doesn't have as many rules that's cool it's absolutely no problem to work with small teams and scrum and he will explain in his session soon but you will get a lot of overhead if that's what you're asking for but the process stays the same if you're one or you're ten I've been on a scrum team with 15 and it worked but it takes some getting used to there's a lot of overhead when you're two that's why you work with five to nine people because then the overhead is okay thank you I think we work in we have a scrum team of five people so it's not quite as small but what we do is we either look at velocity driven capacity or capacity based planning so what we do at the beginning of a sprint is you look at how many development days you have available we always do two week sprints so we plan for nine days you leave one day out for meetings and all the ceremonies and based on those nine days of development we plan the work based on that so it's really about and then before we actually commit to anything I always give them a mirror of what they've committed to so each individual team member is actually looking at okay I'm actually committing to X number of hours or X number of story points or whatever way you want to measure it before you ever press the big green button to start the sprint and I find that I think it is down to whether you go with a velocity driven capacity where you're measuring story points per sprint on a team basis or whether you're driving it through a capacity based model where you're looking at all the available resources you have for that sprint and how many development hours or story points you have and I think that works to the other guys point there like I think it doesn't matter whether your team is three people or ten people that if you do it it's all about the planning and that's the way I've worked it anyway and it seems to be working fine okay thank you hey couple of questions from a product owner perspective number one any good tips on how to keep the stakeholders aware of what's going on so that they don't feel that things are moving too fast or I wasn't involved or I didn't know that we're at this stage already you do have a square mast yes that helps yeah try to involve him or to educate it keeps on coming back to education to help them understand what you are doing with your teams I don't know are you working with some sort of rolling roadmap is it visible for your stakeholders what the teams are working on now and the following couple of sprints well this relates to a specific project that we did with a scrum model some time ago and I was kind of the lie eyes as a product owner towards our organization kind of telling what's going on and then we had an external scrum master but some of the team members from our side were kind of confused at some point that have we already decided these things because things were moving faster than people who are accustomed to kind of committee type of working they thought that things take longer so I just thought that where did I drop the ball of informing people how to involve them you were too fast that's actually great well the other question is actually I forgot the other question but I'll stick back and think about it that's no problem at all because we're running out of time anyway really quick on a really big project we had several departments all with a common goal so it was a lot of stakeholders like 20 and we had decision meetings so they were regular, they were set and they were right before sprint planning when you needed to make a bunch of decisions that were going to help prioritize we would have that decision meeting and it was always like some major things coming up where do you, what's your stake and that helped us a lot let them sell their business value why they think it's important that's actually a good tip because one thing I thought that I kind of missed was to highlight the decisions even more that we are now making decisions or we have made decisions but yeah the other question was about managing the internal pressure and expectations as a product owner any tips for that because there's that kind of thing happening how is your management the management of the company feeling about agile and scrum well it varies because they can help a lot with keeping calming down the stakeholders because they can say okay we're going to choose that way so stick with it next to that you're the product owner so you're the one responsible and you have to have the authority to say to them okay we're going that way or that way so is your mandate big enough within the stakeholders and if you have a problem there I think you should talk to where we're in charge Matrix organization for example might be difficult to have a mandate that kind of covers everything because you have dotted lines going everywhere so that might be a bit tricky environment to work in I don't have a solution for it but try to get your mandate in order and use escalation lines for it to get it because you're the one who's to blame at the end of the day right exactly yeah so try to get the mandate that's the best tip I can give you I think we have to wrap it up I'll be here because otherwise we're going to be kicked out of the room I guess just one question how many of you are in your self-organizing teams include design in that two weeks print I'm impressed for Europe just like one sentence concerning the hours versus story points in one of our clients what we do is we have story points that are only base two so we have tasks that are two story points four, eight, 16 32 and 64 and those roughly are converted to hours just but not it's not strict so it's like two story points is going to be a really easy task could be finished by one hour, two hours and 32 story points it's like two days the problem with that is people are going to still think in hours if you really want to do it just don't do that because I have a team and a sprint isn't a fixed couple of story points right and the idea is that because you get back to the depth and get better as a team that your velocity grows and that you can do more in the sprint but your hours are still the same so if you turn them back to hours again you will be stuck with the same problem and you will never make your team fly because I have a team which started a couple of months ago with 70 and now they're at 260 I don't know how many hours one story point is so an experienced developer could do like 10 story points job in one hour while a non-experience will do it in five hours that's what you're saying but it will level out in the team but don't match it back to hours please because you will lose the strength of the story point thank you thank you all and I have to make and join sprints presentation yeah


I want to talk about a lucid dreaming app that I created a while ago about a year or so ago now Which gives you reality check reminders? So as you can see here It says how to lucid are you dreaming stuff and then there's a little alien emoji there one minute ago 30 minutes ago So i'm going to log in now and explain how this lucid dreaming app works and okay So this is the lucid dreaming app and more views this video gets and also the more supporters I have on patreon the faster it will become on android But it's i'm planning to release it on android hopefully in the next six months to a year so but But that being said there are a few updates i've got planned for this So this is not the final product, but i just wanted to show you where i'm at now with this lucid dreaming app And what i hope to do with this in the future So if you've been following my updates then you'll know about this But if not then here is basically how the app works So you'll log in here and you'll see that this is uh my logo here And uh, there's a link to watch my videos and then it basically just says a little bit about me Thanks for downloading and uh, hope you enjoy the app. That's the main home screen That's pretty much irrelevant for most of you. So here is the main features So you can go here and you can add a dream journal entry So you can put the title Let's say if your dream was something like uh, you were climbing a skyscraper You would put the title there climbing skyscraper. Maybe you put a little emoji there So you remember it if it was lucid you can check this box that says lucid And then it will be automatically logged as a lucid dream and you can search back for lucid dreams and non lucid dreams Which i'll show you in a second Then you can describe the dream I was climbing a skyscraper and Superman knocked me off Okay, so then you can it logs the date automatically the date when you had the dream here But you can also change the date if you want to back date it for example You then save the dream And it automatically logs it on the month where you had it So you can look back on your dream journal you can search through here for keywords. So for example sky Scraper and it would list all the dreams in which you've mentioned a skyscraper So then you can click on the entry and read it again very useful. You swipe back to go backwards You can also go into the month and then search through All dreams or your lucid dreams or your non lucid dreams And you'll notice that when I click non lucid the dream journal entry I just wrote disappears because it's not a lucid dream So that functionality is very useful for looking back and seeing Which lucid dreams you had which times you didn't have a lucid dream and so on now I've explained in previous videos why it's important to keep a dream journal on your phone simply because You're always going to have your phone by your bed And it's something which you can search through in the future You can look back through and just search for all of the dreams you had about a certain keyword or a dream sign Meaning it's easier to do reality checks and become lucid All right, so not much more explanation is needed for the dream journal section side of things But there is also a handy link here that says how to and then that explains more about how to write a dream journal And uh how it works Now one thing I want to say straight away about this. I know you're probably thinking this is a very bright app There's a lot of white space here and for nighttime That's probably going to be too bright when you're trying to write a dream at 3am I understand that And probably by the time you watch this video or certainly in the month or two after publishing this video There will be a brand new night mode in which this whole thing will be dark It'll be very easy to read and it won't be a bright like this So this is just I just wanted to give you a few updates on the app before I publish the updates. So This is the main feature here the reality check reminder So as I'm sure you're aware it's important to do reality checks throughout the day Because they're going to show up in your lucid dreams or in your normal dreams I should say and help you become lucid the problem is most people forget to do them. So this device here Reminds you to do reality checks and you can set the interval So it can give you a notification every hour every two hours or randomly And if you click the random section, you can see it asks you how many reminders you want throughout the day So for example 30, let's just set it as 30 Now the updates that are coming will include Uh a time bracket So you'll be able to say I want 40 reminders between the hours of 9am and 5pm So that it doesn't interrupt you during your sleep because at the moment the only way of Disabling notifications is to either manually turn them off here By clicking notifications off or by just relying on your iphone's night mode Which automatically disables notifications. So for those of you who are wondering Why isn't there an option at the moment to disable notifications at a certain time? It's because if this is only on iphone you already have night mode So you can just set that up and it saves a bit of development on my side But there will be that feature coming very soon. So don't worry. It's in the works. Okay And then here you have the option to actually edit the reminder that you get So say if you want it to say something really specific like are you dreaming? Right now John So by having your name it makes it more personal you can even add emojis in here And it will actually show that in the notification. So then when you turn notifications on randomly for the next well 40 times it's going to show you this This custom reminder here Then as you scroll down here, it says how reality checks work And how you can best use them it even gives you some examples of what reality checks to do And it links to a tutorial I write about how to do lucid dreaming reality checks so far so good, right? And I should mention that at the moment. This is completely free. There's no ads on this app It's completely free. I rely entirely on your support on patreon And also as i'm going to get into in a second the tools section, which I will explain now So as you see here at the bottom of the app the tools section gives you a list of useful topics So let's take binaural beats for example We I've spoken about binaural beats before special sound waves which help you meditate and help you induce lucid dreams But for example binaural beats from inora the unexplainable store I have actually genuinely tried all of their binaural beats and I can recommend them completely So as you'll notice in the tools section It's a mixture of useful resources and tools and also just information So for example acronyms, it tells you exactly what all the acronyms mean So that when you're going through lucid dreaming forums or whatever or when you're talking to your friends about lucid dreaming You can actually use acronyms. So you can understand them all here. There's loads of them that I wrote for you And then there's also things like tips and warnings explaining Various things about lucid dreaming I'm not going to show you everything in this app because I want you to download it and have a look But just for those of you who don't have an iphone Who are waiting for the android version? I just want to show you a bit about what's here and what's going to be coming up soon supplement guides Little tutorials on how to use supplements And then I do talk about the lucid dreaming bootcamp for those of you who are interested I'm going to also be including more About how it works and I might even include a seven day free trial of the bootcamp with the first seven days In the updates that are coming up for this app. So there's also then an about section where just basically A bit more about my story and that sort of thing But the main features of this app like I said is the reality check reminder and the dream journal There's going to be a night mode coming very soon I'm going to be updating this massively putting huge amounts of value here loads of articles loads of content for you And it's all going to be there for free for you on iphone It will be coming to android soon But I really and the reason I made this video you're probably wondering why am I telling you all this if it's not even ready yet I would like you right now to comment what you would like to see in this lucid dreaming app And exactly what you think about this now try not to mention things. I've already said For example, I've already said there's going to be a night mode. I've already said all of those things Try and comment something new some suggestion something you don't like about it or something that can be improved And I will take all of those things into consideration and I'll update this with your thoughts in mind So as always if you liked the video Make sure to subscribe because I post weekly lucid dreaming videos and tutorials And I'd love to hear what you think leave a comment and I'll see you in the next video


Okay, let's get started. Good afternoon everyone. Thank you for this opportunity to speak at new operation management summit here. We'd like to talk about quantitative method for open source contribution value and its impact on Sony's business strategy. If you have a question, please ask us at Q&A time. Please wait. Let us introduce ourselves. I'm Kazumi Sato. I am a Distinguished Engineer Sony Group Corporation. I have been working on Linux-based system software for various Sony products. I also have been working on OSS compliance and relationship with communities in Sony Group. Since 2002, when Sony started to use Linux, I have been leading system software development using Linux and introducing it to the products, complying the open source license. I am a member of the Software Strategy Commit at Sony Group. Hi, I'm Masayuki Kuwata. I'm an Osprey at Sony Group. I work on the open source strategy with the business unit. Since April 2022, I have started my career in Osprey. Before that, I was a software engineer, and now I am also an organizer of Japan Ospo Local Meetup. I had this meetup yesterday, and I gathered about 25 people. The activity is under 2D Group and OpenChain Japan Working Group. Let me introduce our co-workers who are in this room, Fukuchisa and Alin. Could you stand up? We worked with them to this analysis and discussed a lot. Thank you very much. By the end of this presentation, you will feel and understand how quantitative data is effective for open source promotion. Now, let's get things started from background. Ospo is expanding especially 2023. As you can see, the graph at the bottom. Collaboration on common challenges under 2D Group and OpenChain is very good. However, we have had still big challenges. Let me explain about that. Our challenges are to step the company up. It's staged from consumer to participant to contributor. But it is difficult to understand upper side benefit from lower side. So, how to convince engineers and management? That's our challenge. And our situation. Undoubtedly, everyone recognizes the value of using open source. As you can see, the left side of the consumer smiling face, it's easy to understand. It's clear for them, for everyone, the benefit of the consumer because just using. But difficult to make consensus, the value of participating and contributing to open source as part of company business activities on some business area. It's including our situation, our company. And from consumer, participation looks annoying from participant. And they don't think it is better to contribute for their code or something. They don't understand why it is good to contribute. Despite presenting examples of strategic utilization by other companies, limited acceptance of changing work practices. So, our three steps analysis. Let me pass the button to Kabin. Thank you, Kuwata-san. I'd like to talk about three steps, our analysis. Our three-step analysis is, at first, we assessed the company's current situation by analyzing our own open source activities. Then we visualized the overall landscape or open source activity by using OSCI analysis. OSCI is Open Source Software Analyzed Github by E-PAN Company. And then we showed the relationship between contribution and businesses. First, assessing the company's current situation. We listed our own open source development project and the number of contributors in each technical categories. As you can see, we have some open source development activity in several technology categories. But if we watch the activities with sales and profit, there is an imbalance between business and open source contributions. Right side bar shows the rate of contributors by technical categories. Left side shows the rate of our profit and sales and contributors map to business categories. As you can see, this is very unbalancing. And we explained our executive situation and it has been understood by our executives. Next, I'd like to explain about visualization, the overall landscape of technologies. We want to visualize the status of the open source project technology area related to the business by OSCI. We presented last year's OSSJ about another analysis with open source contributor index. Last year's OSSJ. The three major neutral foundations, Linux Foundation, Apache Software Foundation and Eclipse Foundation have published information on how to categorize their project. As you know, three major foundations have a lot of important open source software. So we analyze these three major foundations. So we categorize project from three major foundation into technology domain to understand the size of each development. Each foundation classifies categories differently, so we normalize them manually. This page shows developers by tech category and foundation. As you can see, cloud is a top category with 2,700 developers and almost all developers are contributing to Linux Foundation project. Next is AI and data with 1,400 developers and Apache Software Foundation has also a large amount of contributors. Third is IoT and embedded with 600 developers and again almost all under Linux Foundation. This page shows tech category contributors. You can see same contribution number covered by company. Cloud area is developed by cloud companies, of course. In AI and data, the biggest company is Meta due to PyTorch project. In IoT, we can see variety type of company, Intel, Google and semiconductor companies. This page shows developers by company. Our analysis is company basis and we can see IT giant at upper side and main category is cloud. But Facebook and Apple, their focus is on AI and data. And semiconductor companies have about 100 contributors and they are working on cloud, AI and IoT. Adobe also contribute web and contents. Our Sony contribute IoT cloud kernel network and contents. Each company contribute different kind of technology area. This page shows. Now, it is coming to almost interesting part. We showed the relationship between contribution and businesses. At first, we dive to development persons. Before sharing the quantitative data, let me show how we analyzed. We firstly looked at our raw data. As you can see, there are different frequency of each person. A lot of developer contribute only a few months. Limited developer works constantly. So, we focused on constant dedicated developers. We define dedicated developers at least 10 months and 40 commits a year. This pie chart shows pie torch dedicated developers. If you look at dedicated developer who work for their company, Metahertz, 36 persons and other total 38 extra persons more than twice the development power from Meta. Big tech and semiconductor companies value pie torch as infrastructure and appointed dedicated developer. We suppose that dedicated appointed developer is working at the company's wheel. This chart shows IT Tech contributors analysis. This table shows contribution repository in pie torch project and its contribution company. This table shows IT Tech contribute to enhance their platform. Google, Amazon, Apple, they are working for their SOCs. Microsoft look like work for Windows, I suppose. This page shows analysis of semiconductor companies contributions. Semiconductor company contributed to enhance their SOC value. We analyzed pie torch subrepositories commits by semiconductor companies and we understood that they are working for accelerating their SOC. Next part, I'd like to pass to Kuwata-san again. Okay. Thank you, Sato-san. Now let's look at progress in our company. Right. Before we got this data, our approach had only qualitative information, but no change in business strategy even though qualitative information could be understood. So we added quantitative data, as you can see with blue color in this slide. Conducting executive briefings to enhance understanding of global trends through data and igniting for bottom-up movement by delivering presentations with data. And as you can see with purple color, tailor data analysis for business unit, technology character. Convincing business units to initiate strategic activities through specific examples from other companies. Then quantitative information can convince business unit more. And business strategy including open source. Let's go into detail. First, let me share how we have conducted executive briefings. First step, we presented to software strategy committee. Second step, we conducted executive briefings to C-class executives. And third step, we presented a game with response from senior executives to software strategy committee including business unit software head. From this process, many of them are convinced with quantitative data. Next approach, to upstream of the business plan. Source information for business plan did not capture open source situation even though all technology includes open source. We approached key persons with business strategy planning and provided open source trend information with quantitatively analyzed data. Now, technology strategy includes open source explicitly. Third approach, convincing business units. Sony semiconductor solutions has a spool. Maybe some of you already attended morning session, but they made business unit understand the importance of open source. But qualitative information could not give an idea how to change the business plan. So, we provided information with quantitatively analyzed pie-torch data. Especially semiconductor companies activity, as Satoshi explained. With this trigger, strategic open source activity has been getting started. And now we came to final point. Even top-down message is shared. Engineers do not start action soon because they are not convinced without detailed explanation. So, we are conducting presentation to engineers by tailoring the information to each technology area for obtain their understanding about contribution value and aspectivity. Okay, that's everything of our company progress. So, let's move on to the key takeaways. One, quantitative data demonstrates the business impact of open source contribution. And that is useful to gain support from top-level executives. Two, analyzing technology areas with open source and providing input early in business plan discussions is valuable for business and its strategy. Three, it is important to tailor information by understanding organization's characteristics to effectively promote open source activities. And final point, bottom-up activities are also important to convince a lot of engineers. Okay, but still there are remain things. Ospo cannot have all technology area knowledge because open source is covering all technology areas. So, each technology specialist needs to join this activity, I believe. So, our approach can improve this situation. Okay, that's all. Thank you very much, and it's time for questions. Thank you for presentation. I have one question about three ideas. Please show the third idea. No bottom-up. Oh, bottom-up, okay, I see. I think it is important in Japan a lot of companies like DX and make employees to bottom-up idea or bottom-up actions, but it is difficult to conducting bottom-up action because in all of these... I'm sorry. A lot of people conducting business top-down, but now culture is bottom-up. Different culture. So, if I do this idea, this idea is important, but it is difficult to conduct this idea. So, how to conduct this idea in engineer or other employees? Can you understand? Yes, I understand your question. As you mentioned, it's difficult to get understanding and start action from bottom-up. Yes, exactly. Okay, maybe next slide will be better. As I described here, we just started this activity and currently still we are trying. Fortunately, in our company, we have several channels to access to younger generation. One is already Kazumi-san-den, but around the area, we have a chance to make a presentation all around the division. And a lot of younger generation have joined that presentation meeting. And I usually do. We say bottom-up approach is important, but someone says, please, top-down. So, we conduct some middle manager to do bottom-up activity. So, you access to the top, not top, middle manager. Young manager, such kind of staff engineer. I say we should involve bottom-up activity. So, manager do such kind of bottom-up experience. Then bottom-up people join this activity. Younger people say, we'd like to join some enhancement activity. Everyone say, but they themselves do themselves. So, we first say to middle manager to do bottom-up activity. So, middle manager say, you can do bottom-up activity. Then younger person do bottom-up activity. Okay, I got it. Thank you very much. Yeah. Any question? Thank you very much for the talk. I understand most of them. I would like to know what is the goal of your activity? So, to reduce your cost or to shorten your development terms, or to, I think that you are saying to teach the younger people to join the open source. But I don't understand why you are trying to do so. Thank you for your question. As you know, open source is a fundamental technology. So, our technology depend on open source. So, open source activity is very essential, I think. So, Sony say we are technology company, an entertainment technology company. So, we should do enhanced technology, but all technology depend on open source. So, we should encourage open source, I think. So, I do this activity. I would like to add that this slide is pretty good because if you are depending on open source, a lot of open source projects are trying hard to keep their quality, their stuff, they are exhausted. And what industry learned is that they should contribute and they do this a lot, so these projects get a lot of patches, a lot of patch reports. So, the next step is to participate more like review, take action. And this is what I get from this, so this is very welcome. So, one of the goals is not only to reduce cost but just to sustain open source in this high quality the industry depends on. This is a movement a lot more companies should do to take action so that we still in the future will have this powerful strong open source that we have today, otherwise it will collapse. That's what I think. Thank you for comment. Thank you for a good presentation and very interesting data, that I wish were more easily available for everyone. My question is, do you find a difference in, when you try to roll this out in terms of a bottom up or top down approach, what works, because Sony is a global company, what works in Japan does that directly translate into what works in Europe or the US or have you mostly worked with this in Japan so far? Yeah. Thank you for question. That's it. Our problems. Our company is, our founder is Japanese so almost main activity in Japan. But our subsidiary is oversea everywhere. So it is important to convince every, our company's engineer. But European or American, foreign, understand almost open source value. So, but we should more tight relationship with overseas colleagues in this kind of activities. Our company is conglomerate company, so not only electronic semiconductor, but also entertainment, picture and live assurance and music. So, we should do telling each situation. Maybe I should do any question. Thank you. Thank you for your sharing. I'm curious about how many years or how long have you spent to convince all your board community and to organize all the button-up activities that engage all the developers you have? Thank you. I'm not sure. But this presentation activity is this year activity. Yeah. The last year also. So, we just started our activity. If I could make a comment. I'm with Sony as well. So, we've been doing the qualitative approach for many years. Probably over 20 years. And this is a much better approach. The quantitative, it's really hard to convince upper management with kind of philosophical arguments. Although the philosophical arguments are correct, they're true, right? That if you invest, for instance, in contributions, that you'll get better software back. And there's a whole bunch of arguments that I've made them all myself in the past. But when you approach upper management with numbers, and especially if you show them the competitive landscape where it's like these companies are investing in this project, and you can say, and they're doing it for this reason, and this return on investment, that's a much better story. And that's much more convincing. And so this is a relatively new activity, this quantitative measurement stuff, but we're finding it's effective. I can come with another comment also from Sony, Europe this time. So, before this activity, we started educating the middle management with the power of open, what open means. And most managers don't get the idea just from the idea perspective. Open collaboration, open data, open source, open hardware, open code are concepts that they cannot grasp. But if you show them what other companies are doing in the same area, then it is a competition. And that they can understand. They can understand numbers. So it's easier to go and then preach the concept of open to developers once you convince the management. Thank you. Thank you. Okay. Only three minutes. Thank you very much.


the Yankee offense stall scores just one run against the Tigers and although there are no excuses you know the lineup with Gary Sanchez you're missing and do hard you're also missing John Carlos Stanton it's gonna be tough to score it I mean it's a different lineup I think you're gonna get to a point where what Aaron Boone's gonna have to play some guys more than he really wants to with this time of the year I agree I think Greg Bird Gary Sanchez they're a big part of your offense with the injury they have you got to get these guys in the lineup you got to get some kind of rhythm of putting some runs up on the board now the lack of offense obviously waste a pretty good pitching performance by Masayo Tanaka he looked good again yeah he did it was a real pitchers dual Merle Zimmerman on the other side threw the ball well off of his outing his first outing he was almost perfect through seven innings so give Zimmerman credit through a lot of good pitches Tanaka was right on point again just wasn't enough and Chapman got beat by a rookie in his first major league hit so there's one guy tonight Peterson who probably is not gonna sleep he's on cloud nine right now now when you look at the Yankees obviously this is a team that's gonna have to scratch some runs maybe they play a game a little bit differently than they used to we saw Tyler Wade steal a base today maybe they're gonna have to manufacture runs for a while well I mean this team has built so much around the stadium and hitting home runs that you just can't change things overnight but you know Tyler Wade got a hit stole the base there are some guys that can run the bases you know they've had a lot of opportunities to score runs and they just haven't had big hits you know tomorrow's a new day it's early in the season but you got to forget about what you're supposed to do go out tomorrow and win a baseball game now with the rubber game being tomorrow afternoon the Yankees will activate and call up Jonathan Lois again I know that you've always liked his stuff yeah I mean the Yankees depth is getting tested and they have some good young arms and if you look up and down the Yankees farm system their top prospects are all pitchers so that this is the strength of the organization Lois is has got as good as arm as anybody he's one of the guys that Cashman gets phone calls on all the time so it's gonna be interesting to see how he does this year the stuff is all there for him and one of the youngsters has already done well her mom with the win yesterday and now Lois I could win the series for the Yankees before they head out on the road