 Hello guys, please welcome our next speaker, Alison Matlak from Red Hat. Thank you all very much for coming. To tell you the truth, I was not expecting so many people because most of the talks related to DevOps are always about tools and new processes, and it's rare that you get what we call the squishy human element. So I'm very happy to see all of you here today. I wanted to start by telling you a little bit about myself and why I'm here. I am a program manager for a department with several global distributed teams. We have about 130 people total, spread all across the globe. And our mission statement is to provide the platform and tools that enable associates and partners to deliver enhanced subscription value. And those are a lot of buzzwords to say that we run the Red Hat Customer Portal, which you can find at access.redhat.com. And I'm also an open organization ambassador. The open organization is a book that was written by our president and CEO, James Whitehurst, along with a few other Red Hatters. And it describes how Red Hat behaves on our best day. We are transparent, we're open, we're a meritocracy. And I really think that our teams behave that way. I'm not a software engineer, but what I do engineer is culture and ways for people to collaborate, finding better ways to be more efficient and engaged in the work that they're doing. I help our teams solve problems of coordination, communication, planning, and engagement. And I'm also the open organization ambassador. I really believe in what Red Hat does and the way we're doing it. A little about this talk called People Over Processes. In my work coordinating teams, which is the hallmark of open leadership, I found that it's people over process every time. And I'm here to convince you that most of the problems that you're facing are not a matter of finding the right tool or making sure everyone is using the right tool. It's really about the people and how they're communicating or how they're not communicating. And as we go through this talk, I hope that you'll think of ways that your own teams could become more efficient just by communicating a little better and making sure that the right people are working on the right things. I'll tell you in advance that at the end, if you ask a question, I've brought along books with me and I've carried so many of them all the way from Raleigh. I'm looking forward to giving them out to our audience today. So please, as we go through, think of questions that you might have to ask at the end. So about the teams I'm going to be talking about, this is the customer platform. We deliver all of these things through the customer portal that allow our associates and partners to deliver the value our customers need, whether that's support, planning throughout their entire technology life cycle. We deliver partner certifications, knowledge-based platform, product security resources, downloads for updates. And today, I'm going to be focusing on several of the teams that deliver resources for our support engineers. So this is kind of where we are in the ecosystem of customer platform. We have three teams who help our support engineers. We have a front-end that's customer-facing, which we call portal case management. So when a customer goes to the portal to open a support case, they're using the tools created by our portal case management team on the front-end. Of course, you need a back-end to support that. And you need the middleware to abstract the back-end for multiple clients, like our front-end. And together, these three teams are really delivering one product. Today, I'm going to tell you a story of what I call the tail of the action plan. And you can see this tab at the end here. This is a screenshot from our portal case management where people go to open support cases. And we had a request from our main stakeholder, support delivery, to add a new tab for an action plan where our support engineers can leave notes for customers, it's customer-facing. But of course, it's not as easy as just creating a new tab on a web page. We have three impacted teams starting with the back-end. And every team that we have is a DevOps team. We've got our developers, we've got QA, we've got release engineers. Everyone is self-contained, and we thought we had the right people working on all the right things. But when you look at all the different tools we're using, it's very hard to coordinate between them when everyone is using different tools and processes. Our back-end team is on a three-week scrum sprint. In this instance, we use Salesforce as a database, Solanopsis to deliver, Bugzilla for issue tracking, and Rally for project planning. And when you start to think about coordinating teams, it's difficult to get one issue in Bugzilla to an issue in Jira, or Trello, or some other system. So we're really three different silos trying to deliver one product. Our web service API, JBoss Middleware, when the front-end makes a request, the Middleware web service API retrieves it from the database and hands it off. This team is using continuous delivery with Docker, Rays, and Jenkins, and Jira for issue and project planning. The front-end team also on a three-week scrum sprint, writing an AngularJS, using Jenkins, and Jira for issue and project planning. So this is really what we're looking at here. Tools, additional tools, and different processes are not going to solve a problem of coordination. Because what happens right now is you have a three-week scrum sprint, another three weeks for the Middleware, even though they're doing continuous delivery, they can't hand off to the front-end team until the next sprint has started. Three more weeks for the front-end team to complete their work and deliver. So a total of nine weeks from ask to delivery. This was a little too slow for us. We shouldn't be taking nine weeks in an agile environment to deliver something our stakeholder requested. I was asked to investigate scaled agile solutions, and I know that you can't read this, that's kind of the point. There are so many different scaled agile solutions that we can implement on top of our teams. The problem was that all of these require revamping everyone's processes. We had to take teams that were working very well and totally redo the way that they're doing everything. I settled on less because it allowed all of our teams to continue running the way that they were running, and all we had to do was add planning and retro at the end, where we had leads from each three team meeting to communicate. And what happened was instead of having to wait for each team to plan, groom, schedule each feature, we were able to come together in a room, say, we want to deliver the action plan. What do we need? Well, we need the back end to add the field, and we'll give you the first four days of the sprint. You let the middleware team know when you're done, they'll go ahead and do their part to get ready. They'll let the front-end team know that their work is done so the front-end team can complete development, and all of a sudden, we're delivering a new feature in three weeks. And this is a best-case scenario, but the most interesting thing that happened was even if something came up in the middle of a sprint, we had established relationships with each other and open communication channels, so we felt more comfortable communicating and saying, oh no, emergency, we need you to fit this into your sprint, and we knew who to ask and how to fit it in, so even if we couldn't deliver in three weeks, we were delivering in six rather than nine. Another problem, three weeks was a little too fast for our stakeholders. Support delivery had to go and make sure they had the feature documented that all the support engineers were informed of the new workflow and how they should use the new field, and so that was one of the lessons that we learned along the way. Make sure that you are working closely with your stakeholders as well as with each other. And kind of what we learned here is that the relationships between the people are more important than the tools and processes that they're using. As I showed you, each team had its own method of doing, its own way of doing things. We have two scrum teams working with a continuous delivery team, but all we really had to do was get everyone together in the room to decide how to do things together. If you think you need a scaled framework, choose the one that's least disruptive. So instead of trying to redo everyone's processes, you should just use the simplest solution. Instead of trying to do safe, or there's one called rage even, all we had to do was add a meeting at the beginning of the sprint and at the end to do more coordination. It's important to manage your stakeholder expectations appropriately, as we learned. So when we were moving from nine weeks of delivery to three weeks of delivery, our stakeholders weren't very well prepared. Another one, don't let any one person dominate the conversation. Engineers love their products, and they love talking about it. So when you get everyone in a room, you sometimes find that one person tries to speak more than the others, and it's important to kind of manage those conversations. And try things that don't be afraid to fail. This is the main message of Agile, that it's okay to fail if things don't work. So what happens when we try to deliver something, and it doesn't happen in time, it's okay. We figured out what didn't work, and we can do it better the next time. So it all really comes back to making sure the right people are working on the right things. And this is a problem that I feel that we face. Red Hat was a very small company, and we're growing very quickly. And the issue of scaling is one that we're constantly thinking about right now. Because when you become a large company and you're making lots of decisions, you can't be involved in everything, right? We can't have one developer involved in every single project, but we need to have awareness of what that developer is doing so we don't make redundant efforts or make sure the product is going to be used. So really the key is making sure those right people are working on the right things. And it seems like I've gone through this very, very quickly, so I'm going to ask if anybody has any questions or anything that I can explain more further to make sense, right? So if we have a process to make right sense, but not make sense right, so if we have processes focused on the back end instead of delivering value to the clients. Alright, so to repeat again, what do you do when your manager is expecting you to deliver more work more quickly and your processes don't allow for that? So I think this is something that we learn and that's why we were trying to look at the scaled agile framework because you can have a team that has processes that are working that is blocked by another team. Is that kind of what you're asking? So for us, we had some issues where we used to rely very heavily on an IT team for delivery and we realized that sometimes teams that have formal processes that seem to be a blocker, you can still get them in the room and talk about it, right? So it says, what do you need in advance to deliver this thing? And if the answer is more money and more resources, that's a whole other thing. But if they say, you know, we need this much lead time, we need this information, then that's something that you're able to plan for. So I would encourage still trying to find the people who are responsible for making those decisions, sitting down and really having an open conversation about it. So you're moving too fast for your company, basically, and everybody else is saying, well, we can't do that. So how can we get other teams to improve their processes or break their processes or forget their processes so that we can actually deliver more quickly? So does that go back to the problem of, are we trying to follow processes or are we trying to deliver what the client wants? Right. Got you. Instead of doing the right things, we are doing things right. And the processes of doing things right too slow. So is that a question still? I feel like I should answer every question with finding the right people, right? So who can we talk to to say this isn't working? My team was able to deliver this more quickly and this is the process that we used. So maybe it's a matter of explaining, this is how we were able to do it. Can you implement it this way? And if they respond with, no, we need you to fill out this change form and we need this information and we have to fit it into a six-week process, I can see that's a very big problem. So management buy-in. That's a tough problem because I think that management support is something that's been essential in this process. When managers are seeing that it's taking too long to do things the right way, then how do we convince them that it's better to deliver what the client wants when the client wants it? It's a tough problem to solve. I'm very lucky and that's something that our team is very lucky for. Our managers are very open to trying and failing. So I don't know if there is that sense of safety in that it's okay for you to fail. What if we break some of these teams up of their processes and they try and it doesn't work? It all does really become back to trust. If your managers trust you and because there's a sense of failure too, so if we try something and it doesn't work, are we going to say, oh, it wasn't my fault? Or are we going to say it didn't work? Here's why. Here's how we're going to make sure it doesn't happen in the future. I think that's how you build up that trust that when there is something that doesn't work, accepting responsibility and changing in the future. And that leads to kind of the collaboration and sense of what we call the Oakland Organization spirit that I would love to see in more places. Yeah, so, yep, the problem of management though and I don't know how many managers are here in the room. Maybe we should make them close their ears, but I think it's important for managers to know that they are also safe, right? How do we make the managers feel safe? How do we make them understand that in order for them to succeed, they need to enable their teams to succeed? Very good question. I don't know that I have the answer. If I did, I don't know. We have world peace. For us DevOps means having a self-sufficient team, right? So we have our developers, we have our QA, we have our release engineers, all working on one product. Yes, depending on the team. So we have some of our teams that are, and not specifically our support, but some of our front-end Drupal teams, we don't really have a QA role. We have developers who are doing test-driven development. So, the kind of thing. But yes, we do actually have roles still. However, I found that our teams are a lot more open to working with each other when they need help. And I think that sometimes when you have specific roles, you know, I'm a developer, I don't do that. I'm a QA engineer, I don't do that. I don't know that we have that kind of sense. We're very collaborative. So for me, DevOps means that we have the right people on a team to deliver a feature or a product that is kind of self-contained. And I think the problem that we came into was that we had a back-end DevOps team, a middleware DevOps front-end, and there was no way to coordinate between the three of them. So to repeat the question, if we need to implement a new process, who is making the decision of what process we are using? So again, and I don't want to speak for our whole company, but in customer platform departments, we have managers who will say, we see there's a problem. We need to do something. And then we talk about it, right? So come back and give me some suggestions. So you'll go out, you'll maybe do some research. You say, here's what I think will work. Say, okay, let's try it, you know? So it's really the developers with going back to this gentleman's question and statement. It's about trust and about working together. There is not a command and control dictator who is telling us this is what we must do. There's someone saying, we have a problem that we need to solve. How are we as a team going to solve that and having that discussion and really not being afraid to fail? What do you mean by scale dynamically? So this is something that I and some of our managers would like to see. The question was about do you scale dynamically in terms of, oh, I'm losing my, do we scale dynamically, which is do we have the same people working on the same teams, or when we need more resources, are we sharing between teams if I'm understanding the question correctly? Yep, yes. Our managers are very in favor of doing that, of lending resources. Again, we're talking about people, so we're not really like... Sorry, the happiness in employees versus... First part of your question, when we have people who are doing work, they are dedicated to one project or product depending on the context. But our managers are trying to do more of that lending within our department, so when we see that there are needs, like we've built a QA team that can move around between different products. We're also trying to go outside of our department. We have realized places where we could help, and people are saying, well, we don't have resources to do that, so we can say, okay, here is a resource. And that's something that we're trying to think about, but we haven't implemented. In terms of the happiness of associates and getting them the opportunity to work on different things and get more exposure, we've just recently started a mentorship program that has allowed our senior and principal engineers to offer... to be a mentor to our junior associates who are interested. We're not forcing this upon anyone, but what has happened is we've got people from different regions and different work streams in these mentor relationships, and we also have a small group formed around Python, which is really, really exciting, but that has really allowed for more people to get more exposure to different technologies. For instance, we have an associate who's working on a customer platform who wants to learn about Linux kernel coding skills. That's something that's totally outside of our domain, but we've been able to find someone in engineering who is willing to mentor this associate to give him more exposure to that, and hopefully also career opportunities. In my opinion, it's much better for us to train people and help them grow to keep them within the company, even if it's not on our team. So I think that's something we've tried. I'm trying to remember who's getting books here. So if we find we need more people, do we break the rules and create, make the scrum teams bigger? Yes. We do. So when we find we need more resources, we talk about whether we have those in other areas that we can shift, but we end up usually hiring in our department. We're very lucky that we end up getting the budget to scale. I know that's not true in everywhere. So this is a great question. So how does this really work within a three-week sprint? So each team still has a three-week sprint, except for the middleware with the continuous delivery. They're a different beast, right? But our back-end and front-end teams have full three-week sprint cycles. But what happens is, and I can go back to that, there's a whole lot more stuff in large-scale scrum less than just this, but the part that we took that worked for us is adding the planning in retro. As you can see, each team is still doing their three-week sprint. But what happens here is we're meeting to say, is there one feature that we need to add together, this sprint, and that's the feature that we're working on together? Each team has their own backlog. They have their own issues that they're working on, their own bugs, their own features, and they're still doing that in their three weeks. But we're able to add one that we're all doing together. So we're just coordinating at that top level if that makes sense. We're able to say here, our back-end teams need four days to add this field in Salesforce. The middleware might only need two to kind of expose the field, and the front-end might need four more days to make the field visible to our customers. All during those three weeks, we're still doing other work. That's not the only thing that we're working on, but we're able to fit it into the existing structure. So first question, who is in these less meetings? Is it the whole team, or is it just the Scrum Master? And the answer is that we tried having a program lead and a technical lead. So what ended up happening was we had a product owner and then a developer, the senior developer on the team who was able to speak to the details. The product owners were saying, okay, yes, this is a feature that we want. Let's do it. And then the developers are saying, you know, this is how or this is a bad idea. So no, it's not the whole team. And that goes back to having the right people working on the right things and making sure we're not wasting anybody's time. Because when you start adding more and more meetings to everyone's schedule, you're losing valuable development time, right? No, no, no, it's a dedicated lead. So most of our teams have a senior engineer, a senior principal. The back-end, it was a principal engineer, I think for middleware another principal engineer and for the front-end. I might have just had the product owner who was also at the time the lead engineer. It was a very weird kind of thing. But all three are very familiar with the whole ecosystem which makes it a little bit easier. And once you really conform those relationships, the conversations seem to happen not just inside the planning meeting but they happen outside as well. And in terms of your second question was Scrum Masters and how we use them, do they rotate? The front-ended and back-end teams have their own Scrum Master. We used to have a dedicated Scrum Master who had a Scrum Master title and role. He moved to another department and we started rotating people through. So it's been interesting, kind of guiding and coaching those individuals through that process. And thoughts about it? And thoughts about that. I think it's been okay. The thing about Agile is it's more of a set of principles than a set of rules. So when you're able to find what's working for your team, you can kind of take and leave what you need. So I think each team has their own way of working. And we haven't, to my knowledge, you might need to be correct in here, but to my knowledge we haven't forced anyone to take on the Scrum Master position. We've kind of asked people, is this something you're interested in? And I think our front-end team has a more... They rotate more quickly just to kind of share the load a bit. But so far it's been okay. So was there any time wasted? No, for the Scrum Master, so when the back-end team lost their dedicated Scrum Master, there was a little bit of time where we were trying to figure out what was happening. For our front-end team, because everyone is familiar with the process, they're familiar with each other, we were not bringing in anyone new. It's an easy transition, and I think we've been able to kind of coach each other. Sure, so to repeat the question, are there any kind of signs that something's going wrong or that the process is not working or the right people are not involved? So, making sure the right people are in the room, you start to see after we have two or three of these big planning meetings who's contributing and who's not, and who needs to be there. So the issues that we saw in that are not that the wrong people were there, but only a few people were contributing to the conversation. So it's a matter of, how do we bring every voice to the table? In terms of when we need a scaled process, just thinking about that whole nine weeks, and I can go back to that, this is really what led us to it, right? There's no reason why one feature that each project team needed to contribute to was taking a full sprint. We can see that if we just had some kind of coordination, that it would be a little bit faster, and it's not always perfect, but because the relationships and communication is already open, everyone started to feel more comfortable with each other, so we were able to communicate outside of this process as well. I don't know if that really speaks to your question, but in terms of blockers, it's really, why is this taking so long? Why can't I get my question answered? Why is this process in the way? It just doesn't seem necessary, and why can't we just sit down and talk about it? I feel like when you start asking those questions, that's when it's time to just sit down and talk, and that goes back to that whole environment of trust, and is it safe? And is it safe to say, I don't think this is working? The question was, are we constricting self-organizing teams by adding more processes to them? How do we watch that from happening? So the whole self-organizing team idea is interesting for me, because these teams have already kind of been there for quite a while, and so it's a matter of how are we shaping them so that it's the most efficient for us? So the self-organizing part in my mind is more about how involved are the people in it? Are they free to speak and say this isn't working? Are they saying we need something else? How are we making sure that they feel safe to have those kind of conversations? And are they safe to say, this process is pointless and not working? Can we talk about it? I am a proponent of using the simplest tool for the job. When I was doing project management, I have my to-do list just in a notepad. I'm not using anything complicated. When you start trying to throw tools and processes on top of a problem, you're not really solving it. You're just kind of masking it. So I think when you look at process, it's not what can we implement? It's what do we really need? And maybe we don't need a full-scale process, but we just need this little piece of it. And that's kind of what that whole large-scale Scrum framework was. Yes. So each team has their own project backlog, and we're just trying to make sure that we're coordinating at the top. But there's not a whole lot of additional... I'm not trying to add work. Yeah, and that's exactly what happened. So an existing engineer took over the Scrum master responsibility, in addition to the work that he was doing. But he had never been a Scrum master before, and that was why we had a little bit of a gap there. No. Beijing and Brisbane, you missed them? No. Okay, so the question is, are all the teams co-located, or how do we manage the distributed teams and communications? This is something I've been saying as I've been traveling. As someone who's based in Raleigh in North America, I don't realize how difficult it is for someone in Pune to wait half the day for me to come online. And then I only have four hours where I get to talk to you and that. And I've noticed that even here in Brno, I log on, I've got all these emails I've got to go through. And I usually take care of immediately during the day. So I think that something that we need to do better is have some empathy and understand our ways of working, the fact that usually North America is asking other teams to stay online very late or extremely early. Can we balance that load a little bit and come online? So for our teams, back to my little team that'll work. Back-in team is mostly based in Raleigh with some in Pune. Middleware I think is in Raleigh and Pune. And front-in we have Brno, Raleigh, maybe Westford might have some in Beijing. I personally work with Brisbane, Beijing, Pune, Brno, UK, West Coast, East Coast. It's all a matter of juggling. And when I'm trying to meet with all the managers who are across all these things, it's difficult. And the best thing we can do is be empathetic. What are your preferred communication styles? How can we meet in the middle? How can we think about our goal? So instead of me wanting to communicate something, if my goal is to work with you to come to a solution, then maybe I need to change my communication style so that I can meet your needs a little bit better. It's a tough question working with distributed teams in different countries. But the more that we're able to have open conversations, the more some of these issues will come through, I think. I was speaking with one of our associates last night who works with a team in Pune mostly. So just one or two people here and a dozen, 20 people in Pune. And I think one of the best things we could do is send him there. There's something about meeting face-to-face. Even we have all these video conferencing tools that we use and all of that, but there's something about being able to meet a person face-to-face to build the trust that you need to work more closely. I wish I had an answer. And how to engage remotees, full-time remotees, that's another question I'm always asking myself. Well, speak with me afterward and let me know if you have good suggestions for that. Thank you for keeping this going, yes. So have we considered creating a unified team to address one requester feature and then have people go back? That's kind of what we were trying to do here except instead of pulling people from their teams, just making sure that we're coordinating better. So I don't know, again, with the self-organizing teams, I don't think that we're quite there. I think that we have dedicated teams, but we're trying to figure out how we can do that better. But that's something that we haven't really done yet. Yeah, it's not something that we consider, I think, because we're not... I mean, I personally would like to see our teams with more of the resource lending, more of we need the skill, let's come together, we need these four skills, we have these four engineers, let's bring them together to deliver this product. But the way that we are right now with... I mean, each of these teams has a backlog of... Well, big backlogs. I think when I joined the backend team several years ago, the backlog was four or 500 issues large, which is unmanageable and ridiculous. So pulling people from that team might not be something that we're able to do at this time, but we really do need that coordination piece. How do I manage such a big... Who asked the... How do we manage a big backlog? So that's something that I really wanted to address as soon as I joined that team. And the very first thing... Let me back up a little bit. We were also working with an engineer whose philosophy was even if we're never going to fix this issue, we should leave it open because someone might have the same question in the future. And so it's managing expectations. Do we want to take that approach or do we want to say, you know what, we're never going to do this, it's not going to happen, it's not on our roadmap, we need to close it out. So we had to manage that relationship a little more and say, okay, if it's really that important to leave it open, okay. So what we've been working with our product owners to use JIRA a little bit better because there are ways to have different... You have one master backlog and then different backlogs that people can pull from. We're trying to get better at that process. But really, a few product owners will go to a bar on Friday afternoon and we call it beer and backlogs and they will go through and start closing or addressing some of the issues. It's a work in progress. I think we're down to 300 issues. And also, every time there's a new product owner, they go through every issue again. Is this still an issue? Do we still need this? Do we still want this? For work in progress, like Per Sprint, or yeah, for Per Sprint I think we have 10, 12. It depends on the size of the issues and the size of the team. In our working, yeah, it's... But again, it depends. For our working backlog that we're actively pulling from that are groomed, probably 50, but in each Sprint maybe like 10 to 12. The teams are pretty big though, especially I think our front-end team is pretty big. The middleware team, maybe they have three or four issues per... Well, now it's continuous delivery, different beast, but any other questions? Yes? Right, so how do we prioritize issues? So the main stakeholder for this set of teams is our support delivery engineers. And they have their own ways of prioritizing the issues that they want and that can take months and that's fine with us when they... You can come to us when you finally decided what you want to do. But for our teams, it's a matter of meeting what our stakeholders want while sanity checking, right? So maybe they've asked for something that we don't think is something we can deliver right now, managing those expectations. When something breaks and is urgent, we do stop and address that issue, but if it's not a completely urgent issue that's broken, we try to fit it into the next Sprint and try to be very conscientious of the time that we're taking from our developers. It's very disruptive to add those issues in. Now, each developer has their task for the Sprints, but in terms of blockers, if one team is blocking another, that's what we're able to solve by that communication to say, hey, I told the other team that this is blocking us, this is an urgent issue. We need to make sure it's addressed and that communication helps a lot. So I guess, yes, one more. To try and address the problem. We had one senior manager take over all three of these teams at the top level, and he tried the siloed approach because everything was disorganized when he came in, and these silos were working very well. We got them all efficient. Everyone's doing their own thing, and then we realized that problem. This is taking too long. There's no reason for this to take so long. We need to solve it. And he actually came to me and said, figure out scaled agile. And that's when I went and looked and I saw that whole list of scaled agile going, this is just too much. This is disruptive. And the question like, how can we make this the least disruptive as possible and just adding meetings where we're talking about things. And I really do feel it's as simple as making sure those people are in the room and having that conversation. Yes, so the question of, and I don't know if I can paraphrase it very well, but basically is each team still working on their own thing, or what happens when one team has a request that they don't need the other teams for bad paraphrase. But coming back to the last model that we used. As I mentioned, all three of these teams have their own backlog of issues. And it's true that not every issue touches every other team. There are a lot of bugs and feature requests that only each project team would need to address. But that's why we have those planning meetings. It's saying, hey, there's a feature coming up that does require all of us. We all need to be aware of it. We all need to see when we can schedule it in and how we're going to make that work. So each team is still working on their own issues. Yes, so they can do work in parallel. Yes, absolutely. They didn't have to wait, but the problem is that if it's not here, they were able to start doing the UI and some of that before the field was in place, but they couldn't actually display it and make it work without the back end and the middle piece there. But yeah, absolutely. Knowing in advance what we're going to do allows us to do that kind of work in parallel. Last question. I think we're losing people. People who ask questions, please make sure you come get a book and we might have extras. Thank you. Thank you. And if you need to contact me, that's here. Thank you all for the questions. My presentation was very short. Probably have lots of extra. You asked a question. You can have both of these. I only have five of these, so. Okay. Thank you very much. Can you take your books? Where are my other gentlemen? Sure. Yes, so this is a companion. It's just a bunch of articles that were published on opensource.com. I asked a question, Allison. Absolutely. We have extra. You're okay for tomorrow at 4.30? Yes. My lean coffee? Me.