 So I've been given a very nice introduction, but really I start thinking about myself as a husband and a dad. I have two sons, Jason and Cole, who are 24 and 21 years old. That's my house in New Jersey in the United States. And you've seen the past roles that I've had, you know, everywhere from developer to business analyst, the project manager, etc. So I have a lot of battle scars from over the years developing systems and software. And my passion is helping people improve and to change the work environment so that's engaging and fun. So what's happening today is that the reality of things is the world is changing so fast. I'm sorry, is somebody talking over there? I'm sorry, get distracted. So what's happening today is that the world is changing at a rate in which the basic systems, structures and cultures built over the past century cannot keep up with the demands being placed on them. And then the incremental adjustments to manage and strategize, no matter how clever, are not up to the job. This is a great quote by John Cotter. This is what's happening in our world. And I think we've seen that earlier Scott talked today and he mentioned about bimodal IT, mode one being the slow and mode two being the fast. So that's what's happening. So as a result of this, enterprises cannot keep pace with the rate of innovation is happening. And as you know, almost everything today relies on software and systems. And companies have to respond really quickly. I mean, you've seen Uber, Airbnb just dominate markets. In fact, Airbnb represents 50% of the revenue of the world's largest hotel chain. And a different chain that Marriott was bragging the other day about that they're putting up 30,000 new rooms. Yet Airbnb said we're going to put 30,000 rooms up in a week. Wow, that's a big difference. So even small nimble competitors can make a big bite of even the largest giants. That's what the problem is today. And as I mentioned earlier with that quote, we don't have the systems and structures that support this change, especially in large enterprises. So Agile has been great. I mean, I can't believe Agile is 21 years old and it's produced incredible results and outcomes. But in reality, it was developed for small, collated teams. And if you hear in the different communities, that Agile was developed not to scale. That wasn't as intent, but we have to make it scale. So we've had to add new structures and things to it. And the other thing that a lot of the methods don't address. And Safe, as an example, stands upon the giants in Scrum and Combon. We're able to be in existence because of these methods. But those other methods do not address things like strategy. We can't have the accumulated opinions of the teams create a strategy. That would be impossible. It needs to come from executives and upper management who have the information and access to the knowledge to create this strategy. And it needs to be communicated up and down the chain. And strategy just can't be top down. It's got to go top down as well as bottoms up. So that's where we're at today. So one of the things that we want to look at is we need a more scalable approach. Not only scalable, but modular. Because each organization is going to be in a different place. In some cases, an organization isn't ready for the Agile portfolio management. Or Agile, HR, whatever it might be. So you need to be able to put in different parts of Agile in the enterprise. So my talk is going to be two-fold. Talking about the scaling mechanisms of Safe, as well as a more generic. What makes a framework scalable and modular? What are the characteristics of a scalable and modular framework? So one of the things that you want to be able to do is to start simple and expand to software and systems. You also want to be able to scale work across the enterprise at different levels. For example, the portfolio level, the program level, the team level. We want to be able to adapt to different size enterprises. You know, an enterprise may start out as a small business and quickly grow to a medium or line size business. The method needs to work. It needs to be able to grow as the organization grows. We want to be able to organize around value, not silos. And I'm going to go into each one of these over the next few slides. We want to be able to use a scalable requirements model and have a scalable content authority. We want to use principles and values to guide the implementation and make the framework work in your context. Because every organization is going to be the same and therefore we're going to have to make adjustments to it, adapt it. And so we have to rely on something to make sure that we're headed in the right direction, have that north star to follow. And those are principles. We want to foster informal learning networks and really be organized networks. And we want to empower teams in this new way of working and thinking. So as I mentioned, you can start simple with the scaled agile framework. This is two levels, three levels safe. We've got team, program, and portfolio. And interesting enough, basically a lot of people look at the diagram and they think that it's complicated. And in reality, we have three roles and we have the same scrum ceremonies that you would have on any team. And then we can use Kanban if we like. We can use XP if you like. And basically this is just showing the iterations in the backlogs and the fact that we have built-in quality. But what happens when you have teams of teams? You know, Dave West mentioned the other day that scrum doesn't have something that's native to it when you have to align multiple teams. Each team ends up becoming kind of, you know, selfish. In other words, they're just worrying about what their goals are. And then we get different alignments. This team is going that way, this team is going that way, et cetera. They're not aligned at all. We have to be able to align the teams to a common mission and vision. And that's where the program level comes in. And again, there's just three roles here. And then we have a common backlog for all the teams to work against. And then we have the portfolio. Again, just three roles. So when you break down the big picture, each level by itself is pretty simple. But it looks complicated because on this big picture, we have the roles, we have the artifacts, we have some practices there, and some concepts like develop on cadence and release on demand, where now it's called release anytime. So we have all these objects on there so that you can click on them and drill down and learn more about that particular item. Now, as your organization, perhaps it's working on software and large systems, complex systems. Maybe it's an F-15 jet. Maybe it's a spaceship that's going to Mars. So those kind of clients are using SAFE because it is scalable. And we have this new level that allows us to expand to these large value streams for these large complex systems. As an example, EMC has a value stream that has 20 trains in them consisting about of 125 people each. How do you coordinate these different teams of teams? That's not a really simple thing to do. So this new level here, this value stream level, allows us to scale. And it's kind of a fractal of the program level. So we have a release train engineer down here. We have a value stream engineer up there. We have a system architect down here. We have a value stream architect and a solution management instead of product management. It's just a fractal. And we have some additional events so that we can coordinate the work across the value streams. And we have guidance and advice on how to do that. So one of the other things I mentioned was we need to be able to scale across different levels of the enterprise. What happens when the teams are agile but the portfolio is not? Anyone here? Anyone experiencing problems because the portfolio is not agile? Yeah, what are some of those problems? Challenges with the business case. It's too heavyweight? Okay. What else? Right, the backlogs aren't prioritized. Right. Right. What else? The backlog is already outdated. Great. I mean, you've just given the business case for needing for different levels. And strategy needs to come from the top. But it's not just top down. We need to get feedback from the teams back up to the portfolio because that helps inform the strategy. So we need to use systems thinking to make sure that the entire system is agile. We just can't have agile teams. Another one that you guys didn't mention was that what happens, what do executives believe in? The more projects we start, the what? They think that the more projects will finish. Now, is that true if you think about lean thinking? It just doesn't happen that way. But that's what they think. So when we have the portfolio level here, we can put whip limits on new strategic initiatives so that the teams don't get bogged down too much with their existing work plus having to analyze new work and then have more work than that they can do and then for them to be task-switching between one initiative and the others. You lose about anywhere from 20 to 40% overhead from task-switching. So this is just a quick overview of the safe levels. We have the portfolio level. That's basically where strategy formulation comes in. That's where we manage the pipeline of demand of new strategic initiatives. That's where we determine what the value streams are within that portfolio. And a value stream is a series of steps to get from concept to cash. And we'll talk about that a little bit more in our next few slides. The value stream level is for those who are building the world's largest systems or software. And we have some new constructs in there to help with that effort, such as model-based systems engineering, set-based design, agile architecture, having customer and supplier relationships. How do we manage that? That's talked about in the framework. The program describes agile release trades. That's the team of teams that I mentioned earlier. And they build features. They build the solutions and the subsystems. And arts align to a common mission and purpose. And it's important for the teams to have a common mission and purpose. Do you think that people are motivated without a common mission and purpose? No, they're not. But when you're aligned with a common mission and purpose, there's no stopping that team of teams. That train is going to go really fast. And people are going to be really passionate about doing that work. Because otherwise, it doesn't matter what system you're coding, you're just coding. You don't understand why you're coding and what you're trying to achieve. And on your day-to-day work, you want to be able to understand how you can contribute to it. You know, Daniel Pink discusses mastery, autonomy, and purpose. And that's what we need to give the teams. Now, teams in SAFE are just like any other agile team. And they have choices. Scott talked about choices with Dad. And we have choices here, too. So teams can use Grum. They can use Kanban. They can use XP or Hybrid of all that. The other important thing with the framework is that you have different size enterprises. And this can't be a one-size-fits-all solution. We need to be able to put in different variants of the framework to adapt to those needs. So, for example, small businesses can get by with just one agile release train within a value stream. And they might have a portfolio. But you don't have to have a portfolio level necessarily. For example, at Scaled Agile, we have about 31 people in our company. And we have one agile release train within the value stream. And we have multiple value streams there. So we have sales. We have marketing. We have the framework team, which I'm part of. We have curriculum, community, et cetera. But we don't need to have those multiple value streams, because we're very small. So we just live in one value stream. Then you might have a larger business, and you may need that portfolio. And you want to be able to have multiple value streams. So let's say a banking company, you may have a value stream for deposits systems. You might have another value stream for loan systems. You might have another system for mortgages, mortgage servicing, et cetera. And each of them having their own value stream and maybe one or more arts. And if it's very complicated, like the EMC example where they have 20 agile release trains, you might need to have the value stream level to help coordinate all those value streams and all those arts. The largest businesses may even be more complex. So what we're seeing here, we're seeing multiple safe portfolios. We're seeing multiple instances of safe using both three level safe and four level safe. So we can adapt safe to meet the needs of whatever size enterprise you work in. And many organizations are like almost multiple companies. They used to work at IBM, and it was like working in 20 different companies. So each business unit would have a separate instance of safe. And they may use three level safe, they may use four level safe, or a combination thereof. But the trick is in most organizations, we implement safe with an instance of safe for each business unit. So that big picture that we saw before here, that's an instance of safe. The framework itself is an instance of safe. So another business unit may also have an instance of safe. So they have their own portfolio, they have their own value streams. So one of the things that I'm seeing today is that the hierarchical nature of how we're working puts a lot of friction on the system. So we have these hierarchies. So we're supposed to be doing agile, but we're in a hierarchy. And it's very difficult for work to flow when we're in a hierarchy. What we really need is more something like a network. Where each of these spheres represents a team, and the largest sphere is an agile release chain. And imagine a network of people that are working together. And one of the aha moments I recently had about safe was that it immediately implements a social network between 50 and 125 people. And immediately you get the benefits of this social network through PI planning. That's where we do a two day big room release planning. And during that release planning, people get to meet face to face for the first time. And as a result of that, we're able to plan and coordinate our work. And we also get to meet each other. Like I'm sure a lot of you haven't met each other before. There's a lot of people that I knew from India, but I have not met before. And it's been great coming here and meeting you. And it's very powerful to have this network. I had one client, the power went out there, had one client. They told me that 150 years of culture melted away after this one PI planning. They had never seen each other before, but yet they were working together. But they really weren't working together. They never seen each other face to face. It's much different experience when you see somebody and you're working face to face. But I don't know if Padma is in the audience. And she is in our safe LinkedIn forum a lot. And I speak to her through the forum. And it was really great seeing her in person. It was a whole different experience. I feel really connected to Padma now because I've seen her in person. All right, we don't have slides here. What's going on? Somebody pull out the plug? So I can talk through some of this while this is getting fixed. So many organizations rely upon silos. So you might have one of the silos being the business itself. Another silo being the systems engineering group, a development group, a QA group. Thank you, et cetera. And silos are not optimized for value delivery. They're optimized for vertical communications. There's frictions between the silos. I remember when I was working as director of development for a medium-sized software company, my goal was to get the software out as quick as we could with good quality. And the QA's goal was to make sure that software didn't get out the door until it was perfect. So we had this friction between us because our goals were different. So we really want to have an organizational structure which goes horizontal instead of going vertical. The communication across silos is extremely different, difficult. A lot of times these silos cause the splitting up of groups into different locations where you might have in the U.S. we're doing some development, but we're doing QA in India. How do you think that's going to work out? You're not going to have the teams really collaborating. They're going to be at odds. There's going to be a lot of friction, a lot of delays in the system. A lot of times there's political boundaries because the director of QA has a different goal than the director of development. QA's job is they want to create as many bugs as they can and prove the quality of the product whereas director of development wants to get the software out the door. So we're not aligned on our goals. So what we want to do instead is that we want to organize around value, not in silos. So what you can picture here is that each of these organizational parkies is a different silo. And then we have to get people from each of these different silos to form teams and then teams of teams. And then if we want people, we have to get permission from all these different managers. If we need to extend some of these time, again we have to go back to those managers and ask for more time. And sometimes managers just pull people off your project and you don't even know that they pulled them off the project. So it's not a very efficient structure. Instead we want to be pulling people from each of these different silos and then organizing them around a particular value stream. Maybe the other example I gave you around mortgage servicing. So that the people who are developers and testers are working with the business. And ideally they could be co-located. I was working with Citibank and what they decided to do was they took a whole floor in New York City and they cleared it and created an open space for both the business and for all the developers and testers who were scattered throughout the city. Now we're working together in a single value stream and it's much more efficient that way. We all are working towards a common mission. We're all working towards a common vision. So the R takes a systems view and we have a cross-functional train. We have cross-functional teams to create an organizational structure that can move with speed and agility. And then we have these roles which support scaling the themes. We have a chief scrum master called the release chain train engineer. We have product management in addition to product owners. We have system architects who help guide the solution and provide intentional architecture along with emergent design. We have a system team that helps the team integrate their work until they can do it on their own as well as test and enter and scenarios that none of the teams can do. For example, performance testing, that's difficult for to do across all teams. Do security testing, enter and scenario testing of the solution of different features. And then of course we have the business owners and the customer. The other thing that we want to have is that when we have these different levels of the enterprise we also want to have different work items so that we have a surface in which we can explain the type of functionality that we want to have. And at the portfolio level we don't want to be getting into features or stories that's way too detailed. We want to have epics instead of projects and we'll talk about why projects are evil and if you don't have to have them I would recommend getting rid of them. Projects kill agility. We have the epics which are like a large initiative. You can almost think of it as a project but it's not quite the same because it doesn't have all the baggage that a project has. And we can break those epics into capabilities if we're using the optional value stream level or we can break those epics directly into features so this doesn't have to be a linear model. You can skip different levels and skip different artifacts. And then we have enablers. Enablers are things which allow us to implement those features. It might be an architectural thing. If you're working in large systems you might need specification documents because when you're building an F-17 you just can't rely upon user stories. You need to have detailed specifications. You need to have manuals. Capabilities describe higher level solutions. They're kind of like you can think of them as a big feature. So the capability might be hardware acceleration and then the feature would describe in detail what those hardware acceleration features are. Then the features need to be broken into stories because that's where the actual execution is. And notice at each level we have different roles who are responsible for that content. So at the portfolio level we have the program portfolio management team responsible for the epics. At the program level we have product management who is responsible for the features. They have the content authority. They decide what's going into that program backlog. They do the prioritization of the program backlog. But it's not done in isolation. It's done collaboratively. And then we have product owners. They are embedded with the teams. So what are some of the problems that you have with product owners that are both responsible for the return on the investment as well as going to user conferences, meeting in executive meetings and having to work with the teams. What happens? Right. Yeah, you have what I call seagull product owners. They kind of come by. They drop their turd and then they leave. So they're not staying with the teams. But meanwhile the teams need answers. And if the teams don't have answers that causes delay in value. So what we do is that we have the product manager and they own the program backlog. They collaboratively work with a team of product owners who own the team backlog. And then they work with the team which implements value. So this way we're kind of splitting the responsibilities between product management and product owners. The key here is that we want product owners to stay with their teams and have to constantly leave to an executive meeting or to a user conference, et cetera. Of course we want them speaking to customers but we want them to be embedded with the team as much as possible. The other thing that we have is a scalable flow of value through an enterprise con bond system. This is new to SAFE 4.0. And what this does is help ensure that the flow of value happens quickly. We can have whip limits. We can understand what our cycle time is, what our lead time is using cumulative flow diagrams. For epics and capabilities and features, it's mainly about two things. One is getting readiness of that particular work item type. And secondly, being able to decompose those epics into either capabilities or features or taking capabilities and splitting them into features. So we're going through the process to make sure it's ready. So we're doing some grooming. We're doing some estimation. We may do some spikes and write some actual code to see if something is feasible, especially at the epic level. We might want to prove out some architectural concepts. We might want to prove out the business model at the epic level. And once we have broken those features, let's say the capabilities into features, then we want to move it through the con bond to make sure that that feature is ready to be implemented, that we understand it, that we know the acceptance criteria for it, and then finally to break them down into stories. And this really helps us understand where we're at in the process. What state are we in? Are we overloaded in a particular phase like analysis or design, et cetera? So this is just a deep dive into one of the con bonds just to give you an idea of what it looks like. So when a, let's say capability came down, we want to put it in the funnel, then we want to do some review and some analysis on it. And again, it's lightweight review, lightweight analysis. And then we can break them down into stories or features, I'm sorry, features. And then we'll go through a process of analysis. And then once it's been analyzed and it's been approved, it goes into a backlog, and then we start implementing it. And finally, it goes into a done state. As I mentioned earlier, safe teams have a choice of methods. They can use scrum, they can use con bond, they can use XP, or a hybrid approach of both. How many people here today are using scrum and con bond together? A lot of you out there, right? So scrum bond, a perfectly fine method to use with safe. A lot of teams, when they're, let's say, they're DevOps or maintenance teams, where the arrival of work isn't really predictable, find that con bond is a better method. Personally, I like scrum a lot for non-maintenance type projects, because I think it really helps, it pushes the envelope on improvement more so than con bond, where you kind of can keep your old ways of working. But together, safe and con bond is very powerful, because you get the discipline of scrum, plus you're able to see what's going on on big visual information radiators and have whip limits and make sure that the teams are getting to a done state. So the other thing that we have is we need some constructs to help us make safe work in a particular company's context. And even within a company, each business unit is going to have different needs so therefore we need a couple of things. One is that we need managers to become lean agile leaders who are going to teach lean and agile behaviors. They're going to teach continuous improvement, teach some tools for how to analyze for problem solving and how to address those problems and for them to act differently. We want them to be servant leaders and to get out of the way for the teams. Another informal organizational structure that we want to use is community of practices. Because if we're not working in silos anymore, how do we work on improving our craft? If all of the QA people want to improve their skills in testing, how do they do that if they're not in a functional silo anymore? Well, there could be a community of practice for that QA group. There could be a community of practice for developers to improve their software craftsmanship. What about release train engineers? Again, we might want to have a community of practice for them, but we don't want management dictating what the communities of practice are. We don't want management dictating how the communities of practice work. It's something that should be an informal mechanism that's used by the team to help them continuously improve. Finally, we want a set of values. We want to instill a lean agile mindset and use principles so that we can make safe work in your particular context or whatever scaling method that you're using. You need to have principles to provide that guiding light, that North Star. We talked about the communities of practice, and basically it's an informal network of people that are working together, experts, collaborators. You might bring in subject matter experts to talk about things. You might teach continuous integration. Whatever it might be in one or more domains, community practices are a great way to have an informal network of practitioners that can learn from each other. We talked about safe being a principle-based framework. I'm not going to read all these, but you can get an idea of the type of principles that we have. It's both lean principles, agile principles that really make safe safe. We want to embrace a lean agile mindset. In addition to embracing that lean agile mindset, we want to embrace the agile manifesto. Safe is perfectly aligned with the agile manifesto. There's nothing about the framework that isn't aligned about it. And the manifesto can scale. There's really very few things about the manifesto that would prevent the manifesto from scaling. And then we used the metaphor of the house of lean to explain these lean practices and principles of respect for people and culture, flow, innovation, and relentless improvement. Not just Kaizan, you know, it's relentless improvement where we always have this constant sense of danger. What are our competitors doing? You know, what things are going to bite us? We want to have our eyes and ears open to the different things that may happen. So we call that the constant sense of danger. There's a few more ways that we can adapt safe to your enterprise's needs. One is to use lean agile budgeting. And we want to get away from the project paradigm because project cost accounting gets in the ways of teams. It requires the use of time sheets and it causes delays in getting value to the customers. We have to bring the people to the work instead of bringing the work to the people. And we want to have stable teams, dedicated teams, and not being on five or six different initiatives. I mean, 5% allocated, 10% allocated, 25% allocated to a particular initiative, nothing gets done. And where are your loyalties? Which project should get your attention? So there's a lot of friction and overhead. Instead, we fund a value string. And that value string gets funded for at least six months. And therefore, we don't have to approve individual projects. We don't have to approve individual features. That is decentralized control. The agile release train and the teams make those decisions. Also, you know, one of the things about SAFE that people misunderstand is that the icons on there are really twofold. One is to give you an understanding of the SAFE model. It's a domain model. And the other thing is to navigate to particular guidance. So if we click on an icon, you get guidance. But we show the customer here and we show the customer here when it's in collapse mode. That doesn't mean that we're not working with a customer at the team level. That means we didn't have enough room on the big picture to also put the customer down at the team level. And also, if we had too many icons there, it would be even more complicated looking. So it really doesn't reflect, you know, exactly how it works. You know, all models are wrong and some are useful. And I think having this big picture is useful because it really gives you an idea of what the framework contains, what roles, the practices and some concepts, and that you can understand this whole big system. Because it's just more than teams. We need to have programs. We need to have strategy. We need to have continuous improvement, not only at the team level, but in the entire system. We have to use systems thinking in that regard. We have another thing called a spanning palette. And it's these icons here. And these icons can apply at any level. So we used to have a program vision and a portfolio vision, and the big picture was just getting messier and messier. So in reality, those items can apply at any level. We can have a portfolio vision, we can have a value stream vision, we can have a program vision, and teams can have a vision for themselves as well. We can have roadmaps at different levels, like a portfolio roadmap or a program roadmap. We have metrics at different levels. Agile and lean metrics. Not the kind of metrics which causes the wrong behaviors, like comparing velocities between the teams. We want to measure actual business value. Because who cares about how many stories you complete? Who cares about how many features you complete? That's just activity. We want to actually measure what the business value is. So we have guidance and advice on that. And the advice, of course, you know, you can, over time, as you understand the framework, you change it. You know, you don't have to use the reports that we provide as a starting point. You can come up with your own, use your own. But at least you have a starting point for this stuff, because most people get really anxious about, how do I start natural transformation? What should I do? Or you're just taking a scrum class, and you don't know what to do afterwards. We provide you that guidance so you knew what to do. You can put in a system that's going to work from the team level all the way up to the portfolio. All Agile teams are on one train, except for perhaps shared services. So the train plans together, they integrate and demo together, and they also learn together. And that's a big difference. When we heard Dave talk about, you know, all these missing constructs. But we have the constructs here to do that. And it's a success pattern we know works. We need to be able to scale from the team to the train. So all the teams meet face to face in a release planning meeting, or what we now call a PI planning meeting. And they commit to a set of objectives. They don't commit to a set of features. What's wrong with committing to a set of features? Teams finish all the features? Why not? Right, some are not really valuable, right? And as you go along, you're going to realize, well, to get the value, we can drop these stories, we can drop these features. So we really want to be looking at the business value that we're getting. So we have ways of doing that. We have different ceremonies for the teams that work together. We have scrum or scrums. We have a PO sync, similar to a scrum or scrums, but it's for the product owners. And then we have an art sync if you want to put those two ceremonies together. Sometimes organizations feel that the product owners and the scrum masters should be in all one meeting. They find it more efficient that way. But sometimes it's better to have just a PO sync and discuss, are we on progress with the features that we're developing? Maybe having some grooming sessions to get ready for the next program increment, et cetera. Teams, we do retrospectors at the team level and that helps them improve. Now what about program issues? Issues that affect all the teams. We have system issues which affect all of the teams. So we need to have an inspect and adapt ceremony at the program level so we can fix that. And who do you think is responsible for that, for removing those impediments at the program level? The RTE, right, because they're the chief scrum master for the train. Some ways of coordinating. So we provide advice on how to coordinate. So one of the important things is is that we want the whole system to iterate. So if we have one team doing two week iteration, another team doing a three week iteration, yet another team doing a four week iteration, it's really difficult to plan together. It's really difficult to integrate the work from different teams. And then you're constrained by the slowest team. So therefore we want to have the same start dates, same finish dates for all of the teams. And we want to have a common roadmap for them. I just wanted to mention to you that we're having a safe SPC class in Bangalore on April 19th to the 22nd. The instructor is going to be Joe Malone. And is it safe to adopt SAFE? Absolutely. 60% of the Fortune 100 companies are using SAFE. 10% of the Global 500 are using SAFE. We have 38,000 SAFE train practitioners in over 80 countries. Our LinkedIn forum has over 6,000 members. In fact, I just looked this morning, it now has 9,000 members. So we talked about 175% growth. Now it's even higher. And we have over 21 case studies, which proves that our patterns work. So if you want to learn more, you can go to our website, scale.joffirmic.com. And there, it's a free website. We don't ask for a blood sample. You don't have to give your e-mail address. You don't have to identify yourself in any way. The guidance and advice on there is free. You just can't take our copyrighted materials and create your own, but you can read the ideas and implement them. And often we have a company submit a case study to us. We don't even know that they were implementing SAFE. They just did it on their own, looking at the website. Not as good outcomes that way, because really you need the training and you need to follow an implementation method. So these are our two main courses, leading SAFE and implementing SAFE. And we have other courses as well for the teams. Well, that's it. Do we have time for one question? No time for any questions. Looks like I went over my time box. I appreciate that. I got a little bit fouled up in the beginning so I'm sorry if it wasn't as smooth as I normally am.