In terms of techniques for managing with Agile, you've learned a lot. Let's talk about a few focal points if you want to reflect on what is most important about managing with your team and how is it going. Here are six specific focal points that I would recommend keeping an eye on if you're having that moment where that's what you're considering. The first one is the strong inputs. Remember the pizza versus the tree bark. Well the effort is going to dry up and die and go hungry if you're just eating tree bark. You need to bring that pizza and drive narrative Collaboration with it. Weak inputs will reverberate throughout the whole project. So as the team lead, whether you're the scrum master or the product owner, or just generally sort of in charge of making the team work well, you need to make sure that they have the opportunity to get out there, see users, observe them, learn about them and bring those inputs into their work. Otherwise, no matter what else they do well they'll always be operating on a shaky foundation. Create an environment for self organization. This is one of the most important, and also most subtle items in managing with Agile. As I said in the very beginning here, it's very challenging. And it takes practice. So, be patient with yourself, but remain diligent about making this happen. Some of the hardest things to do here, are to pick the rules that you want to use with Agile. So the techniques from scrum, or XP, and make them explicit, which is one of the things that the suggests to us and is generally a good idea. And yet, minimize those. So you want to minimize the amount of a hard and fast rules that you're going to use for your Agile and you want to isolate them to the ones that you think are really important. Follow those relatively rigorously and then evaluate them as an experiment. And figure out which ones you want to change, which ones you want to discard, which ones you want to adopt, after the fact. The alternative is that you're always kind of like, well Agile sometimes says to do this, and sometimes says to do that. Sometimes we should accept big changes in the middle of a sprint. Sometimes we shouldn't. XP says yes, Scrum says no, what should we do this time, that time. It's important that you have a nice, explicit view of what practices your team is using at any given time. Otherwise, also the teams are going to feel like they don't know what's going on. What are the guidelines about how they worked and that'll create confusion and stress and a lot of waste. So adopt minimal set of rules, the minimum you think is important to achieving Agile outcomes, follow them closely and then evaluate them and change them as you see fit. If you are introducing Agile or rebooting Agile in your organization it is important to find the right project. And you hear about a case study later on a Salesforce with kind of went big bang with this and did it all across the company, and it was relatively successful. But I think what you'll generally hear is, if you're introducing Agile, or an Agile reboot, find a project that's not so big that it's super critical and there's going to be a lot of stress put on it, and not so small that it's kind of a hobby thing, and other things are going to end up getting on top of the co-opting in terms of importance. You want to find a project that's substantial but not absolutely existentially critical and that's a good place to start your practice of Agile. You want to make sure that also your team members are fully dedicated to the agile team, otherwise I think it's very hard to make the whole thing work, particularly if there are other teams that are on that are not on Agile. But even if they are there's this idea that you heard from XP of a whole team sitting together focusing together as a team. And the underlying belief about why that's important is that it is impossible to organize and choreograph all the interactions that have to happen for these successful Agile outcomes. The team has to be focused, sitting together, adopting these techniques and giving them a whole-hearted try, if they partway do it it's going to be very challenging to, iterate, get better, and get good outcomes. Release a lot. If you're releasing a lot and then doing good retrospectives and thinking about how it went, it least your problems will be short lived. You'll see them quickly and you'll see which ones are really important versus not that important because that's sometimes hard to know in the middle of an iteration, there'll be lot of problems probably. And it's not always obvious which ones are important versus not important which is a very challenging conundrum for a manager or scrum master or whoever is in charge of making Agile work. So releasing a lot will help you see which one of those things really manifested into something that's important versus which ones are not really that big of a deal, and then you can correct them. Invest in automation. If this is new or parts of it are new to your team, it may seem a little intimidating. It may seem like, we just started. We need to hit doubles, make friends, have some successes. I would recommend investing probably more time than you immediately feel comfortable with in this, everything else being equal. There are tools out there that are really great. And they don't run themselves, but for any team that's in a good place to do software development, I think you'll find them pretty accessible. Tools for build automation, unit testing, functional testing. There's a lot of both, really thought out tools out there, and documentation and the notes and discussion boards about how to use them to achieve good outcomes with Agile. So this is very accessible, although it's an investment. It takes work, and I think that you'll continually hear how important this is to successful Agile teams. Especially when they look back on what really helped them get good outcomes. And finally adopt a culture of experimentation. Unfortunately, there is no single playbook that will work well for every single team. There's this marriage of practices and principles, and the thing that marries them, the reverend of this marriage if you will, is your own good judgment. So, you and your team will have to collectively look at this whole thing as an experiment And be rigorous about it, and yet periodically and relatively frequently, look at what's working and what's not working and decide as a team, how you want to change things. And probably the hardest thing about that, that you can fix as a manager, is to just make sure that you're making time for it. To sit down, hold structures retrospectives where you decide what you're going to do. So those are some ideas about focal points for managing with Agile.
