This is an exciting time. You're going to introduce Agile with your team or your going to maybe reboot your practice of Agile. You're going to make your company a better place. You're going to learn a lot of new skills that are going to make you stronger in your career, and probably more satisfied. Let's talk a little bit about things you should think through as you get ready to introduce Agile to your company team, whatever your scope of activity is. The first question, I would ask, is why? Now, why would you want to do Agile? There are a lot of good reasons. Maybe management looked at some companies that they admire and they said, these guys are doing Agile, maybe we should do Agile. And I would never fault a manager for making that kind of observation. It's a good idea to look at companies you think are executing well and think about whether some of their practices would make sense in your organization. However this is not a good way, this is a very arbitrary way to introduce it to an individual team. So before you introduce it to the people that are going to actually be executing, I would think about, we think this is a good idea, why is it going to be good at our particular company or for our particular product? What jobs, what problems do we think are a, important, and b, things we could do, places we could do better? What outcomes do we want to get from actually doing Agile? And I would test that, think about it, and once you get something you like, I would decompose that into what does that really mean for a product or project manager? What does that mean for a developer, a tester, all the roles that are going to be involved in this interdisciplinary team. How do we take this outcome that we want to do better at and what would it mean for all those different roles. I would get to that level with your kind of Agile charter before you go to a team and say we're going to go do this. Otherwise, you run the risk of it feeling kind of arbitrary to them. And it's very hard to have a self-organizing team that's successfully self-organizing against an objective that they don't understand or don't really buy into. Next I would think about where to do this. Now we talked about this before, everything else being equal probably the best place to do it is a kind of Goldilocks project. So, not so big that you are under enormous pressure to save the company or the product, and not so small that it's a hobby and people are working on it part-time. So something that's important material, every team member, the whole team is going to be focused on it. That's probably the right place to start, and then you kind of want to look at who is going to be on this team. And ideally of course, you want volunteers, people that think that this Agile experiment is a good idea, it's good for the company, good for the product, good for them individually. It's going to make their career better. And I would take your Why and translate it forward to this Who. Remember how we talked about how each user story should have it's own discreet reward? Something that we know the user got what we think that they wanted from this little narrative, even if it's super small. Well, think about that when you address the who. So think about we have this success definition, what does that mean for a product manager? And what are the first few things that should start happening for them in this practice of Agile where they know that it's working. So is it that they're going to get more time to spend with customers or users and really understand them in a way that they've been wanting to? And for example, what does it mean for a software developer? Are they going to get to see their product in action with customers sooner and more frequently so they can understand the significance of what they're building? Is it that they've been wanting to try some of these techniques from XP like peer programming or test-driven development. And they didn't have the time, or the training, or the space to give those things a try and they like that idea. What about the tester? Is it that they now get to spend more time doing automation? Or learning about some automation techniques they've been wanting to learn about but haven't had the time or the space to do. Those are just examples. You need to figure out what those really mean in collaboration with your prospective Agile participants, so that you have a nice clear idea of what you're doing, who's doing it and why. So that you can move forward into a strong self-organizing situation. An Agile friendly environment where everybody's bought in to this idea that these techniques, this working environment will help you iterate to more valuable outcomes for your user. And then you gotta figure out the how. What Agile methodology are you going to use, or what pieces from what methodologies are you going to use? And everything else being equal, less is more here. I would pick the Agile techniques that you think are really important. Try those out, and as we discussed before, I would apply them relatively specifically and rigorously while you're using them but evaluate them frequently and collaboratively as an experiment. And the worst thing that you can do is use a lot of these practices and use for instance Scrum as a crutch. Well just, you know, do everything the Scrum book says because that will work. Those very people would tell you that it's really your judgement and your application of those techniques and the principles behind them that's going to make you successful. So, don't use the methodologies as a crutch, or even worse, a whip to make people do things that they're not bought into. Think about how you're going to do it, agree on that as a team, try it out, view it as an experiment. And then, iterate. And this is the important thing. I think you've heard this a lot, and you will hear this from other practitioners. It's important to iterate, no Agile practice is ever perfect, it never ever is, it can always be better. And especially in the early days, it's like maybe if you've ever learned how to go skiing or surf, or maybe roller skating. I mean you're going to fall down, bad things are going to happen, you might even hit a tree. But it's important to get up again, give it a try and evaluate what's working, why things didn't go the way you wanted and figure out what makes sense. So, in the subsequent material here we'll talk about a few examples of how this happened at various companies. And I would encourage you to talk to your friends, talk to your peers if you're in the software business. I'm sure you know lots of people. What worked well for them with Agile, what didn't? What did Agile mean to them? All that stuff will really help you with this thing that you know the one hand is extremely powerful and useful. And on the other hand, takes a huge amount of individual judgment and practice to get right.
