Welcome to our Impactful Projects and Planning microtraining series. In this session, we're going to talk about what agile means for teams and planning. If you're watching during the premiere, please engage with me in the chat - I'll be responding to your questions and comments in real time. If you're watching this video after the premiere, please leave comments and I'll respond as soon as I can you can also reach out to me directly - visit yazdaniconsulting.com/ipp to connect. So if you're new to the series, I'm Jami Yazdani and I started Yazdani Consulting and Facilitation to help people solve management problems. I'm able to support my clients in getting things done through our project management and project coaching services, our planning support and through leadership and management trainings like this series. So let's get started and talk about what principles and approaches from agile project management are most useful and can be applied to leading teams and planning. So first though, let's talk about agile. What is it? So agile is a category of project management and software development methodologies that are characterized by their iterative life cycles - meaning, instead of moving sequentially through phases in the project work from design to delivery, whatever we are creating or building is done in increments or small batches called iterations. In this and other ways, agile approaches center performance of the product over planning for the project. They focus on delivering something that works for stakeholders and can be improved or expanded in iterations and over time through feedback. Agile is probably best known for a more collaborative approach to project teams. Thus, agile approaches tend to work best when our outcomes aren't fully clear at the start of a project, if we want to continuously or incrementally deliver whatever it is we are creating or building, perhaps in stages or by growing or expanding or in trials, and when responsiveness to changing needs, often determined by testing and gathering feedback from stakeholders and users, is key to our project's success. There are lots of different flavors of agile, many of which are very software development heavy in their terminology and tool set. Even if you haven't heard of these specific agile methodologies and know nothing about software and app development, the tools and principles of agile are making an impact across industries and types of projects. If you've used Trello or a similar task management tool organized into cards on a board, you have been using a tool set from Kanban. If you've been invited to a sprint meeting as part of a project, you've just practiced a SCRUM ceremony. If you've used a just-in-time approach or pulled work from a list of tasks, you have been Lean. So, what are some of the approaches from these agile methodologies that we can apply across industries and outside of software and technology projects to our own projects, teams and planning? There are three principles I'd like to introduce in this session. The first is earlier stakeholder feedback. One of the core principles of most agile methodologies is that engagement with stakeholders or users should happen earlier in a project - shifting left in the workflow - rather than later. Many agile methodologies rely heavily on user stories to drive whatever is being created or built, and testing of what is built happens at the end of each iteration, and it is the feedback received from stakeholders that drives the work of each next iteration. So, how can we apply this to our our own projects, teams and planning? For our projects and teams, we can add in more stakeholder feedback opportunities before delivering on whatever outcome or deliverable we are creating. Instead of getting feedback or testing near the end of the project, are there other points in the middle of the project we can engage with our users? One way to do this is to create and test prototypes of whatever we are building or creating, even if that just means sharing a draft or running a basic idea by key stakeholders. Can we get input before we get too far into creating a final product? Generally, with our teams, we can think about creating a culture of assessment - building feedback points into any user interaction can help us think more often about our stakeholders. In terms of planning, if we are doing strategic or program planning, a simple strategy is to ask for stakeholder feedback on our draft plans and check in with stakeholders more frequently during our planning processes, not just at the start of the process, during that engage and gather phase, but throughout the entire process. Another common agile principle is to fail fast. Part of the reason agile processes propose developing in iterations and frequently testing what you are creating is that this allows you to fail faster instead of failing big. Non-agile approaches that leave testing to the end of a project only allow us to learn from our mistakes once we have put significant time, effort and resources into finishing a project, while agile approaches allow us to learn as we go. So we fail faster and in smaller ways. We can apply this to projects and teams by trying new things and encouraging our staff to test out new ideas. For this to be successful though, we have to treat failure as a learning opportunity and shift away from blame when the idea isn't successful. Now, for planning, one of the ways that we can fail fast is by rolling back whatever we are doing that isn't working. If our planning process isn't working, or an element of our plan isn't working successfully, stop doing it and pivot to something else! This type of plan resiliency can be baked into our plans by planning more frequently over shorter timelines and by creating shorter term objectives.

Another common agile approach we can apply is using collaborative self-organizing teams. One of the Agile Manifesto principles is that you should "Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done." So essentially teams should plan their own work, with team members pulling the tasks they can accomplish rather than having the task pushed to them. Agile teams have team leaders that help coordinate the work of the team, playing a supportive role instead of directing or delegating work as is common in other approaches. So for our projects and teams, a step, a simple strategy is to let your project team members determine the roles they will play on the team and allow the team to assign their own tasks, using shared task lists and allowing team members to pull tasks from those lists. Another way to encourage more collaborative teams would be to alternate team leads on projects and other collaborative groups, allowing different team members to play different roles. For planning, if we're creating a planning committee and we select representatives from various groups or departments, we don't need to let their job title or group identity drive the role they play on the planning team. The representative from finance doesn't have to do the budget and the team member for marketing doesn't have to necessarily be the one posting to social media. Let the planning team select tasks to accomplish based on their interest and availability and on the needs of the team. You can also utilize sub teams or subcommittees, allowing those smaller teams to organize their own work. So that's a very quick introduction to some of the most useful principles and approaches from agile project management that we can apply to our own projects teams and in planning. If you want more ideas and support for managing projects, teams and planning, visit yazdaniconsulting.com/contact for all of the ways to connect with us. Thanks for participating in our Impactful Projects and Planning microtraining series! Visit yazdaniconsulting.com/ipp to view all of our sessions in this series and learn about upcoming premieres. Thank you!