Speaker 1: For all you traditional, predictive project managers who are wondering how to do a basic Agile project, that's what I'm going to explain in this video. The first thing to note is that there is no single way to do an Agile project. There are many, many methodologies and, of course, infinite varieties as we create different kinds of hybrid project to suit the needs of the situation and the culture within which we're working. Secondly, I am no Agilist. I am simply reporting to you what I have learned about the process of doing a basic Agile project. I don't have deep experience to call upon. As a result, this is going to be no more than a basic introduction and I'm also not going to talk about the Agile Manifesto or the 12 basic principles of Agile, nor indeed the fundamental philosophy that underlies Agile. The thought processes that make a project Agile and adaptive and incremental and iterative. I want this to be a practical introduction to the basics and finally, I'm not even going to try to define what I mean by a basic project. Just recognize that this is a simple process that you can apply to simple projects. If you want to deliver a big, substantial, consequential project using Agile project management, then you need to take whatever you learn in this video as nothing more than a starting point to expand your learning and to learn properly from an expert. All of that said, the first step is some form of project planning in which you understand the basic scope of what it is you're trying to do and evaluate the feasibility of doing it successfully. In Agile projects, we break our project up into short phases, which in Scrum are known as Sprints, but are more commonly and more widely known as Increments or Iterations. Crucially, we always aim to deliver something useful by the end of each of these stages. And each stage is a thing in itself, in the sense that at the beginning of each stage we figure out what we want to achieve in the stage. We plan how we're going to do it. We build the thing and we test it and subject it to review by our user group or our stakeholders. And of course, we take our stages in a logical order, taking the highest priority things first. These are the things that are either foundational or offer the greatest value or benefits to the user group, to our client or to our sponsor. We use a roadmap as a tool to articulate how our project will develop different features over time, so that successive sprints or increments will develop successive features, enhancing the feature set and the capabilities of the products that we're developing. We don't worry about the details and the planning for activities that are into the future. Rather, we just log the requirements that we will need to fulfill further down the line in what is known as a backlog or a product backlog. And then those tasks that we bring into the current iteration or increment or sprint become the sprint backlog or the team backlog or iteration backlog. In the near term of the roadmap, we do set out the features that we're going to develop in the early sprints. This is sometimes known as release planning. However, we do review and revise this frequently at the start of each sprint to ensure that our release plan is current and adapts to changes in priority and to what we learn from the previous sprint. At the start of each sprint, we draw down from our main backlog enough activities to fill up the sprint to meet the capacity of the team during the sprint. And the capacity of the team is, of course, the product of each team member's individual capacity by the number of team members that we've got. The longer the sprint, the more we can achieve in that sprint. Sprints tend to last for anything from one to four weeks, with two as a common and typical number. However, what is important is the concept of these increments of delivery rather than the actual duration of the sprint. During the sprint, the team takes each feature through the standard process of analysis, design, development and testing. And the team will meet regularly and frequently to compare notes with one another and to make sure that everyone understands where we are. Most often this is daily and the daily meetings are sometimes known as morning stand-ups or in scrum as daily scrums. These help the team to understand one another's progress and their plans for the coming day. And they also give team members the opportunity to ask for help and to offer ideas. It's these daily meetings that keep the team fully coordinated and also allow them to adapt as a team to setbacks or changes in requirement. At the end of the sprint, the team will demonstrate the work it has achieved to its users and to its stakeholders in a sprint review. This is where the users can carry out the final user acceptance testing before determining that they will accept the new products or the new feature set into beneficial use. Once this has happened, the last event of a sprint is a sprint retrospective. This is where the sprint team gets together to examine its process and to understand what it can learn from the way that they worked together in the preceding sprint. This will rarely involve users and outside stakeholders. And it focuses on the team's process rather than the results of what it did. The outcome of the sprint retrospective is a series of lessons learned that the team will implement to improve its process. This of course is followed by sprint planning for the next sprint. Throughout all of this, there are of course a number of ongoing activities exactly as you would expect as a traditional or predictive project manager. These include things like cost management, risk management, stakeholder engagement and communication, and of course quality assurance and quality control. Please do not take this as a rigid definition of an Agile methodology. It is just an illustrative set of activities that Agile projects frequently employ to embody the Agile philosophy of learning as you go and developing ideas incrementally and then fixing things that don't work iteratively to produce a solution when you can't properly predict and plan for it all at the outset. And if you find these processes and ideas appealing, then there are two things that you should do. One, you should start to use them and adapt them within your project process. And secondly, if you want to take it further, then get yourself some good Agile project management training and I'll put some links to courses that I recommend in the description. Please do give a thumbs up if you've enjoyed this video. I'll be creating loads more great project management content for you, so please do subscribe to the channel and hit the notification bell so you don't miss any of it. And I'll look forward to seeing you in the next one.