Speaker 1: The key with the different methodologies is to think, how big is my project or program? How much trust do I have among team members? And how many teams do I have? So when you think about how big is my project or program, the real issue is how do I scale? When you think about XP, XP is really good for a small, cohesive team that has a lot of trust, does not need a project manager. So you think about your five or six or seven team members who are all working together, they're all co-located, they don't need any outside intervention, they don't need any protection from the rest of the organization. When you think about Scrum, you think about needing facilitation, you think about people who are in the beginning of their transition to Agile. You think about a facilitator, a protector, someone who's helping the team help themselves transition to Agile and make sure that they understand all of the pieces of Agile, finding the rhythm, making sure that they understand how to look at themselves at the end of an iteration and learn about what they're doing from iteration to iteration. In XP, you would expect that the team would do that themselves, because the technical practices reinforce the fact that they are learning every single iteration and they don't need an outside protector. For feature driven development, you would expect that they're taking a feature from a responsible person, maybe called a product owner, maybe not, and maybe you have many feature teams all working in unison and they're understanding what they need to do. And maybe there is someone orchestrating this, as in a project manager or a program manager, and then you can orchestrate this several teams or many teams, but you have this notion of the feature driving or the features driving the teams. Kanban is actually a fairly, well, if you do it right with small features, is fairly easy to scale, but only if you have sufficiently small features. And what I see in teams is that if you don't understand how to have sufficiently small features, you try and move to Kanban, and all of a sudden, nothing moves across the board, because you have this humongous feature that's stuck in development, and it's stuck in development, and it's stuck in development, and nothing moves across the board. So the real key is how big is your feature, how large are your teams, do they have trust in each other, do they need protection, is what I call it, from the rest of the organization. Because if you're new to Agile, is there any way to keep this newness, to keep this transition going, and do you need facilitation in your transition to Agile? There is no one right answer, but let me impress this upon you, Scrum has great brand recognition in the Agile community. If you decide to use Scrum, that's wonderful, adopt it wholesale. If you decide to use XP, because you're an aficionado of the technical practices, adopt it wholesale. If you decide to use feature-driven development, because you understand what the features are, and you can use it for the team, adopt it wholesale. If you decide to use Kanban, because you say, oh yeah, we actually have really small features, and we have a team that trusts each other, and we don't want to really change what we're doing, but we think we can go to Kanban, adopt it wholesale. Whatever you choose to do, and those are just a few examples, adopt what you think might work for you as it stands. Read the books, get some training, adopt it, and then after you have some experience, then adapt it. Do not try and adapt anything until you actually have experience with it. First adopt it, then adapt it. Otherwise, you end up with CrystalBUT or ScrumBUT, and that's not with two T's on the end. That's just with one T. Or FDDBUT or XPBUT, and we hear, oh, we tried that and it doesn't work here. Oh, no, no, no. Just forget about that. Adopt it wholesale, try it, and then reflect on it, and see what you did not do, because I told you to adopt it, and then adapt it. Everything will work in some way for you, as long as you adopt it wholesale, and then adapt it.