Right, we need to talk about the project managers, okay? They're going through changes, changes which they may not entirely understand yet. The transition from Waterfall to Agile project management wise is a really big transition. And the mechanical part is, okay, before we made big plans, now we work in these two week intervals. It's kind of what's supposed to happen mechanically, but it also has nothing to do with what's supposed to really happen. And how you get these agile outcomes. So the real difference is actually a lot more radical and a lot more fundamental. This whole area of project management, which is pretty well adapted to something like we're going to build a bridge and absolutely has to be done. And, there's going to be workers, they string cables up and they can only come at this time. And all of the cement has to come and be late at the same time. Or whatever those things are kind of what traditional project management is really good for. It's terrible for innovation and digital where the point is really how do we quickly respond to changes and iterate. because we can do that and our competitors are doing that and the point is here, in Waterfall, the people, the team members are kind of like cogs in this elaborate structure. That the project manager is trying to perfectly orchestrate with this scan charts and stuff. I don't know, is that what a chart looks like, I don't use them, I don't know. In Agile, the way that everybody works together is actually fundamentally different. The whole idea is that we have this sort of environment that we create through the application of Agile methodologies. Which are not so much rules, but guidelines about we work in a one week interval, we work in a two week interval. We do or we don't change the list of stories during this. And that's the methodology, but the real point is that the team is self-organizing. So we're not, as a project manager, we're not telling this person, it's not like being a football coach. It's kind of like being a motivational coach that creates a little bit of structure around the people do. But then you hope that sort of paragon practice with Agile is that the team is self-organizing. Meaning that we have certain inputs and certain ways of working. And then just everybody figures out what they should do on their own initiative, and that is a big change. So to on a one hand go from spokes, and wheel, and carefully orchestrating all these things to saying. All right, we're going to sort of set up the right pre-conditions, create the right working environment, and then just you know let people do their thing, that's a big change. And its hard, honesty, so they have a big challenge. You can help them, again by bringing in strong inputs. Nothing is going to help that coherent pull together by bringing in really strong inputs about who is this customer? What experience do we want to create for them and how are we going to know if it's working when we finish this stuff. So that we enter the next iteration with a nice clear view of what worked and what didn't. That's actually the best thing you can do. Understanding Agile is great and if you are in the role of product owner, it's important because you'll be participating in this process on a day to day basis. But the most important thing you can do is bring in good inputs. That's really going to help your project manager pull things together and create the right kind of focus.