Speaker 1: So I'm going to wrap up the day with an introduction to how Torrance Learning manages projects and how we have now worked with probably more than a thousand people at this point, hundreds of people, in how to manage projects in the learning and development space. And our field is not really well known for its project management ethos. So I say that delicately and yet, right, the room kind of giggles and stuff. So this is something that, quite frankly, like the software industry, particularly a couple decades ago, was known for basically being late, over budget, and not exactly what we asked for. So the software industry adopted or created Agile project management methods in order to resolve some of that. How do we keep up with a project that is constantly changing? And by the way, I believe firmly that a project should change, right? From start to finish, every single day you learn something more about the project that you're working on and the underlying organizational conditions that caused you to build that learning experience are probably changing, unless you're on a really boring project no one cares much for. So this change is indicative that we are doing something strategic and bold and awesome. So it's a good thing and we want to embrace it, right? But how we do that and how we adapt to that without being constantly pulled in a million directions, without constantly being tweaking and tweaking and tweaking and tweaking and tweaking and tweaking and never finished, are really some of the things that those Agile methods look to address. And at Torrance Learning, I have a whole bunch of friends who are software developers and starting about 2009, we started using Agile methods ourselves. And we started adopting a very, very software-driven like model. We did exactly what all my buddies were doing. It seemed to make a lot of sense, except there were a few things around instructional design and around the nature of our work that didn't quite fit. So we tweaked and changed and adapted the model until it became just far enough away from traditional Agile methods that we referred to it as the lot-like Agile management approach or LLAMA, which is why we have glittery LLAMAs and pop LLAMAs. We have LLAMAs all over this place. We've been doing a lot with LLAMAs for a lot of time. And so in our session this afternoon, we'll wrap up and look at what some of those methods might be and how they might change the work that you do. One of the key things with Agile that we change and one of the things that we in LLAMA do differently than Agile software development is how we estimate our time. And we do this because...and who was I talking to this morning? I was talking to somebody this morning who said, right, that what weather forecasters are the only people who get to be consistently wrong and keep their jobs, right? Because forecasting the weather, they're not weather promisers, they're weather forecasters. They are estimating. And the same thing, when somebody says, how long is it going to take you to do something? You're providing an estimate, okay? And when we think of that as a promise and that's a different thing altogether. So those of you in the room, I'm looking at a few of you who I know are old enough to remember the early days of the Dilbert cartoon. Dilbert was sitting down at his desk and his pointy-haired boss comes in and says, I have a bug that I need you to fix. How long is it going to take? And the thought bubble goes up and it says two hours. And the speech bubble goes up and it says two days. So the next panel on this cartoon is the pointy-haired boss and he's sitting down and his boss comes in and says, how long is it going to take Dilbert to make that fix? And he says, two weeks. And the next panel, and it's two months. And it gets to the CEO's desk and it says, it's going to take Dilbert two years. Do we do it or not? Okay, CEO says, no, we're not going to do it, okay? So everybody in Dilbert's world is like, yahoo, no work, right? Even if she said, yes, we're going to do this, even the folks in Dilbert's world are not so incompetent that they can't deliver two hours' worth of work in two years. What is happening here, though, is that everybody is making a decision based on a lie, right? A lie based out of fear. And a lot of our organizations are driven around, right, very subtly, right, little lies and decisions made out of little bits of fear. And we end up with these laughable yet highly dysfunctional arrangements between providers and receivers of services like ours that are delivered as projects. So you see these walls and things built up. So one of the key things that we do in Agile differently is we estimate differently and we talk about those time estimates very, very differently. So one of those techniques, and we'll go through it this afternoon, is really how do we estimate the work to be done without padding as this item that is separate from the deadline by which I will give it to you. So with that funny story, I want to kick off the next part of the download. See people kind of coming in. I'm going to turn off my mic so George doesn't have to listen.