Agile project management

(upbeat music) - Okay so you've decided you're going to try Agile, that's great, but what does it really mean? It's definitely changing more than just the processes, it's changing the way everyone thinks, that's the big paradigm shift. - To get real benefit from Agile, you have to start by addressing your team's mindset. You have to take a hard look at the reality of how your team works together. It's better to be a team that's terrible at Agile practices but understands the mindset. A truly Agile team should be able to ask tough questions about the way they work and be open to continuous improvement. If you see Agile as just an updated set of project management tools, then you'll probably be disappointed. Then best way to start Agile in your organization is to think small. Begin with a small core team, and make sure they correctly follow the Agile framework. If you work at a mid-size organization, then the team could have as little as four people. Then you expand Agile in your organization through conversion by contagion. So you convert one team to Agile, and then share their contagious excitement with the rest of the organization. Try to keep this core team happy. If they like Agile, then they'll be your strongest advocates for change. Give them time to be successful, they should see the benefits of the change. Being Agile means that you allow your customer to change the product. It doesn't mean that you're free to change the framework. Your team shouldn't think of Agile as a free ticket to work however they like. One time I worked with a team that was starting to use Agile for the first time. They didn't have the people available for a full Agile team, so they merged some of the roles. The scrub master and the product owner was the same person. One of the developers also acted as a project manager. They made all these changes and declared that they were creating their own Agile framework. It's important to not take this approach when you're starting out with your Agile team. Start out by following the framework as closely as possible. Only after your team is well formed should you even consider making changes to the Agile framework. In many ways the retrospective is about the team being Agile with their own improvement. They use the same ideas to turn their efforts inward to reflect on how they can be a better team. Typically the team will meet for two hours on the last day of every sprint. Then they'll reflect on things that went well, and what can be improved. Agile retrospectives are a very lively area. The retrospective is a time for improvement. Also, keep in mind, retrospectives are one of the most misunderstood Agile events. Some development teams see this as a bi-weekly brainstorming session, they focus on the software. This isn't the purpose of a retrospective, it's about improving the team, it's about helping the team work better together.