All right, you've learned about the job of learning within software development. Now, let's talk about a few of the high points from the Agile methodologies we've covered, and how they helped you with that. So in Scrum, the role of the product owner, I would say in terms of the roles you've learned about, it's really the product owner who's kind of the lead on making sure that you're getting all the inputs and creating the right discussions to facilitate the learning process. To an extent, sure it's the Scrum Master they do the planning meeting and whatnot, but it's the product owner that's that kind of proxy for the user. And whose job it is to go out and get the right things and make sure that generally the narrative that you need to build good product is making its way out into the rest of the team. And that everybody's involved with it, improving it and understanding it. And then you have the planning meeting, where the Scrum Master will facilitate that. But it's really the product owner's job, I would say, to bring that meeting to life and make sure that the test cases you're writing against the stories, the detailing and improvement of stories that hopefully takes place, and the translation into all the little details that are going to have to be thought through to actually develop software. That all that is backed by a strong narrative in a way that's useful to the execution team. In XP, you have this very similar customer role, that's sort of the rough analog of the product owner, and there is a planning meeting. And then these, XP, as we mentioned previously, has a lot more detailed prescriptions for how you actually work. So in that sense it's got some kind of neat and more useful things that you may find useful. So what XP would say, I would say about the learning mission is, be collocated. It's really hard to do a great job here if that's not the case, and I think that's largely true. It can be a huge inconvenience if you have talent elsewhere and can you ever work around it? Sure, but it's really difficult, you're operating at a big disadvantage. So you've got to assess that, and figure out what to do, and bear that in mind. Create an informative workspace. We looked at how to do that with the story map, for example. That's a great tool to use as a kind of centerpiece for creating that informative workspace, and driving good discussions, and focusing them, and contextualizing them, and making sure that their actionable. And then this idea of the whole team, well how are we going to have those great discussions if the product owner is not around 70% of the time? It's going to be really hard. Because even if the product owner does a A+ job in setting up good backlog grooming meetings, these are kind of meetings that might happen to improve the stories before the sprint planning meeting. If they're going to the sprint planning meeting, iteration planning meeting, and doing a great job, it's just not going to be enough. Stuff comes up during the implementation. Questions about how what you've learned should translate into a solution where you really need the whole team sitting together, working together. No matter how great a job everyone does at anticipating what they need, the customer products, and supplying it, it's really hard to not have that happen. And it's good that it happens, and it's healthy that happens, that any developer, I would say, who's working against narrative will come up with these questions over the course of the implementation, even in a really short, one week cycle. And then finally Kanban would probably say, but the most important thing is reduce your cycle time. You'll make mistakes, inputs will be imperfect, but if you're getting product out into the field and observing and you've got a nice tight loop, well, then you're going to work it out for yourself. So I would say reducing feedback time, and we also learned about those feedback loops. I would say those are probably the two most important things from Kanban, with regard to this underlying job of learning. So as you go back, and I'm sure you'll go back and refer to the body of work around these methodologies, those are a few high points that I would take note of as you think about this job of learning.
