Implementing an Agile approach to project management

1. Introduction: In the world of software development, agile project management has become a widely popular approach to managing the rollout of projects from start to finish. The framework behind agile project management is both simple enough to introduce across all its across all teams and flexible enough to allow for changes as the need arises. At its core, agile methodologies have built upon communication every level, allowing your team to work more fluidly and have an import where it might not be possible. With current work flows. In this course, I'll take you through the values and principles of agile project management. You'll learn how to adopt an agile approach into your company and explore the differences between the methodologies to help find a framework that works for you designed for all levels, whether you're unfamiliar with agile or looking to improve your workflow, the horses, a great starting point for beginners or refresher course on the key fundamentals that will help you perfect your approach to ensure it becomes a sustainable framework 2. What is Agile Project Management?: what is agile Project management Agile project management is a way of organizing and working through a project that values human communication and feedback over picking through a project that values human communication and feedback over processes and tools. By doing this, you'll find you can adapt to changes much more quickly and produce far better results than with traditional project management practices. Is there are four agile, well used that over watch this system of doing things, individuals and interactions ever processes and tools working software over comprehensive documentation, customer collaboration of a contract negotiation should and responding to change over following a plan. The good really world example of the agile project management system at work is in the Summit Shop subway. If you imagine the process of the employees making your son, which is the project that needs managing, then we can look at it in terms of the agile system. When you order a subway sandwich, the employees put your meal together and you give feedback as you move along the different sections so you can see straight away that the third value customer collaboration has been achieved. The employee asks the customers requirement for virtually every step in the process. Which bread? Which fitting any Senate, any cheese. You can also see that the first well, you is a did to, since the whole process is very interactive and involves the individual throughout, purse meant it very easily here because the entire process could be changed without any destruction. For example, the question might be plain cheese or spicy cheese. The outcome should be one or the other. But if the customer wants both cheeses, they can simply ask on. The employees will put both cheese on this both cheese on the sandwich rather than rigidly sticking to the plan. Whilst the 1st 3rd and fourth values might be self explanatory, I don't think the second value is quite is clip working software over comprehensive documentation. What this means is that it's far better to have software that does his job well, then toe have some software that needs endless pages of instructions in the manual in order for you to figure out how to use it. Obviously, in the subway example, this value doesn't really come into play, unlike the other three values. But if you squint slightly, you can sort of still see how it is still being followed. The first time you ever enter a subway restaurant, you won't know what to do. There's no instruction manual or comprehensive documentation you need to read. The employees will just ask you the first step in the process which bread and you go from there. So if though, if you imagine the process like a piece of software, you can operate it without any need for prior training. A lot of smartphones nowadays have no user manual in the box. This is because most of the software they use this simple toe work, and if there is any need for an explanation on how to do something, it usually pops up directly on. Most smartphones even have a virtual assistant such a Siri, Alexa or Cortana. These enable customer collaboration and individual interactions over processes and tools. 12 agile principles. Can it? In addition to the four agile values, there are also 12 key principles of agile that helped to guide all agile project management systems. The 12 principles, all number one, the customer must be satisfied through early and continuous delivery of a service or product number. Two changes in requirements must be embraced at any stage of the process, even late in development. Number three a product or service is delivered with high frequency from two weeks to two months, with a preference to the shortest time scale before work together and collaborate closely on a daily basis throughout the project. Number five build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. Number six face to face conversations should be prioritised whenever possible. This is the most efficient and effective method of conveying information. Number seven, A final working product, is the ultimate measure of success. Number 88 maintain a constant pace indefinitely. Number nine. Give constant attention to technical excellence and good design. As this enhances agility. Number 10 simplicity is essential. You should maximize the amount, the amount of work not done. Number 11 self organizing teams are most likely to develop the best architectures and designs and to meet requirements and finally number 12 at regular intervals. The team reflects on how to become more effective, more effective, then tunes and adjusts its behavior accordingly. So now we know what agile project management is all about. Let's take a look at how we can implement it into our own companies 3. Is Agile suitable for your company?: is agile, suitable for your company. Originally, the agile methodology was designed for the software industries, and this is why, in a lot of agile project management books and courses, the term in on the line a lot of agile project management books and courses. The terminology is based around creating software. However, nowadays many different industries used agile when developing products or services because of the highly collaborative and more efficient nature working this way, if you implement, if you implement the agile methodology in your own company, you will see your development processes with improved and become much more streamline. By using an agile system, you can rapidly identify any issues or defects and adjust accordingly. You will therefore end up delivering a better product. An agile based project is completed in short bursts. Known a sprints with each sprint, the team builds and improves off the lessons learned from the previous sprint. The term scrum is used a lot when people talk about agile systems and scrum is basically a workflow framework made up of flow framework made up of Sprint's benefits of agile. If you encourage your company to adopt an agile approach and mindset, you'll find improvements are made in all departments. You'll see increased flexibility, increased productivity and increased. You'll also get higher quality products or services with a decreased risk of missing objectives. Additionally, you'll notice every member of your team has more engagement with the projects and feels more satisfied. Overall, indirect improvements will also begin to manifest. Once an agile A professed once an agile approach is adopted as everybody becomes more and more custom to the values and principles behind agile your notice, solutions to problems are deployed more rapidly and you'll notice a huge reduction in waste , since resources will be minimized. Drawbacks of agile, just like with any system, there are advantages and disadvantages. Agile may well not be suitable to every project. It can sometimes be true that very large organizations are unable to implement an agile approach to their project management. This is because actual favors a lot of face to face communication, more flexible processes and is overall a much less formal way of doing things. In a lot of larger, more traditionally organized companies, there is often a significant amount of rigidity within processes, and teams are organized in a hierarchical way that doesn't allow for ease of communication . Some other drawbacks too agile is that projects can sometimes go off track, and since there is more flexibility in the processes, it can produce less predictable outcomes. Every company is different, so you need to consider the drawbacks as well as the benefits before deciding on whether or not it is suitable for your requirements. It could just be that an agile approach would be suitable for certain teams, but not of this or for specific products, so services that you offer. So before you commit to agile, you need to answer these questions honestly. Are you willing to start a project without knowing where you'll end up? If you're a control freak, an agile project management scheme might be extremely stressful for you. When you start out without trial, you're moving quickly and continually testing with real users. So before you a doctor teacher, ask yourself how comfortable you are with putting out a less than finished version of your product for uses to test. Can you really see yourself putting out a product before it's fully baked? How risk of this are you? Agile is all about continuously deploying and then learning from mistakes. This means you're taking on a higher level of risk than if you were to go with more traditional project management style. With agile, you can't really sit and wait until everything is perfect before you release something, so you should be prepared to take on any unknown issues that come up along the way. How flexible is your team? Remember that third value of agile was to work with the customer collaboratively. By doing this, you make the product better. However, this doesn't always sit well with designers or developers who may have a large ego. Ask yourself if your key players can put their ego aside and adjust their efforts and ideas based on customer needs. You can't have somebody in your team who will stubbornly ignore your customers. Requests for change, thinking they know better. How strict is your company hierarchy? The fourth principle of Agile was to work together every day, and this means with everybody. You must work collaboratively with others, developers and stakeholders every day. For some companies, this could be a bit of a stretch. If there's a strict hierarchy in place, it might be difficult for people to get time with other members of the team during the development process. And finally, how do you measure progress and success if you're the sort of person? Or you work at the sort of company who will run off and leave a product once the next exciting idea next exciting idea comes along, you won't get the best results With agile, you won't be making huge jumps in progress with agile, which is all about taking small study steps to get you closer to your end goal. Are you motivated? Only by making huge leaps towards the end when you can then leave the project? Or is the journey to the end goal just as exciting for you? 4. Adopting an agile approach: how to adopt an agile approach. In short, a John is a group of methods based on breaking down a project into short, incremental tasks that are taken on by self organizing teams, since agile isn't sent by self organizing teams. Since agile isn't simply a methodology but a philosophy to throughout the project, the team must keep in mind that they need to remain adaptive with a rapid and flexible response to change. So how should we go about implementing agile into our next project? Next project. Painting a War? Let's look at the most basic project we can think off and apply on our John approach to it so that we can see it in action. Painting your living room walls is a pretty simple project, so let's use that step one. Break down the project into short tasks. The first step is to break down the project into really short tasks. Decide on paint color research where to buy the paint by the paint by equipment for painting. Remove furniture your furniture. Cover the floors and any furniture that can't be removed. Paint the left wall, paint the right wall, paint the back wall, paint the front wall. Second coat left wall, second coat, right wall, second coat back wall. Second Kate front wall. By breaking down the project into small tasks, we can make more accurate estimation as to how long the entire project will take. It can also help us to prioritize if we're working to a deadline so we can rank which tasks are of the highest priority. Wouldn't you have created your list of tasks you should, she asks. You should share it with everybody in your team so that everybody is involved and can see the bigger picture. This transparency helps everybody to align and understand the goals. You can also add dates to a list of broken down tasks which represent the deadlines and help me to work out which tasks are of priority. In agile terminology, this list of tasks is called a backlog. Step two. Create a task board because the concept behind Agile is to inspect and adapt. We need to make a plan that involves what we call sprints. A Sprint is a short repeating period of between one and three weeks, during which time the team focuses on a small set of tasks and aims to complete them before the end of the sprint. Then, after each sprint, we can see what worked and what didn't and then learn and improve, ready for the next sprint. We can build a task board and place all the sprints onto it. At the beginning of each sprint, we check our backlog, the list of all the tasks that need to be completed and then move tasks into the sprint. According to their priority. The task board will basically have the dates during which the Sprint will take place. Sprint will take place, for instance, the 1st 3 weeks of March. It will have a list of all the task items from the backlog that need to be completed in that sprint, and it can also have a level of priority that each task has. But we'll talk about this in some more detail in a moment, just night that the Sprint timeframe needs to be the same sprint. So if you start off with a three week sprint time that all your sprint should be three weeks long. Step three assigned tasks to people on the team, so we now have a task board without sprints on it. on the toughs that need to be completed in each sprint. The next step is to assign each task to a person in the team. By doing this, it creates ownership of the tasks and ensures a balance split of work. Additionally, by clearly labeling on the task board who is to be completing each task, it makes sure that everybody knows who to speak to about each task. The good thing about this step is that it's a huge motivated of the team. Ownership definitely motivates when a task has a person's name or a little picture of their face next to it. It will motivate the owner to do a good job, since it's now their responsibility in a project. One person's task. One person's task will often rely on another person's task. So knowing who to speak to will ensure smooth collaboration. Step four at a status column. At the end of each task, you can create your task board on any simple spreadsheet, or even just on a large fist that everybody can see. But there are also some agile, specific software programs available that you can use to make a task board. Whichever method used to make your task board, you should add a column to the end that has the status of each task. By doing this, it keeps everybody constantly updated on everything, which also boosts, so boosts motivation. You can choose any terms for your status column, but they should be clear, and everybody should adopt the same terms. So everything works in sync. For example, you could have working on it pending review. Don't delayed and I need help or whichever labels best suit your team with agile. It's understood that things change and unexpected circumstances can prevent task from being completed by somebody. The Status Column. Just make sure that if a task is set to delayed or need help than anybody who is working on related tusks will be aware of this, and they can adopt that time planning accordingly. Step five. Prioritize your tasks. I know we've already spoken about prioritizing tasks back when we created the backlog, and you also move tasks from the back work to each sprint on each according to their priority. But the tasks in each sprint will also have different priorities. With an agile system, we accept that sometimes tasks might take longer than we originally estimated, and this can mean that some of the tasks assigned to a sprint might not get completed. Additionally, plans for the press for the project to your customers needs might change during a sprint, so it's important to know which tasks are critical. Whilst we should never add more tasks to a sprint. Once it has been set, it is important to know which tasks need to be worked on first. This way we can make sure that the critical tasks are completed before they waited before those tasks that are of lower priority in an agile system, we tend tohave four categories of priority critical, high, medium and low. So we can add another column to our task board, in which we can place the priority of each task. We know that contains the date This rent is to be completed in a column containing the tasks I call him containing the name of the person. Each task it's assigned to a column with the current status of each task and a column with the priority of each task, Step six estimate how long how long each task will take. Each member of the team needs to have a realistic amount of time in which to complete their assigned tasks. During each sprint, we don't ever plan out more than one sprint at a time. Remember, we started off with a huge backlog of all the tasks that need completing, and then at the start, then at the start of each sprint, we transfer a certain number of tasks from the backlog to the task board. The reason for this is that there may be sprints where time runs out before all the tasks have been completed, these incomplete tasks must be moved to the next sprint. Obviously, the aim is to complete all the tasks in a sprink. Complete tasks shouldn't become a regular occurrence, but an agile system does, except that they may arise by estimating how long each task will take. We could be more realistic and how many tasks are assigned to each team member every sprint . At first, the estimations will probably be wildly off the mark, but as we practice, we will improve in the accuracy of our estimations. So on on task board, we can now add another column that states the estimated time for each task the best way to a lot. Time is in hours. And finally step seven. Keep keep your team up to date and communicate. One of the values behind the agile methodology is constant communication. As we work through our tasks during a particular sprint, we need to remember to keep our tasks on the task board updated on to inform the team of any relevant details. Daily meetings with the whole team are vital to a short 10 minute face to face meeting at the start of each work day. Where everybody sits together is a good way to provide a quick overview on what they have worked on the day before and what they'll be working on today. If you're prone to having long drawn out meetings, it's a good tip is to have a stomach meeting. If you're standing up throughout the meeting, you're less likely to get comfortable and let it drag on. Nobody likes hanging about for longer than necessary, so be strict with yourself and make sure that you stick to whatever length of time you set for the meeting. 15 minutes should really be the longest immediate. A review meeting is also important at the end of each sprint by looking back on the previous sprint before moving on to the next sprint. We can learn from any mistakes made and improve the team's workflow, sit down with your team, review the task board and take off all the tasks that were successfully completed. This helps to motivate the team and improve morale by showing everybody how much has been achieved. Also, anything that hasn't been completed can be looked at and a discussion could be had on how to improve processes. The Sprint review can last a little longer than a standard meeting, but try not to bring in any power points or documents, points or documents that people need to read. You want to spend around an hour in the Sprint Review meeting, All the completed sprint should be moved to a completed section at the bottom of the task board. This allows us to keep a record of what's being achieved, and it also means that if a task needs to move back to the task board for a newt, it can be done so easily. Finally, once the sprint board is clear, the next sprint can be arranged and tasks from the back low can be added to the task board ready for the sprint 5. Agile Methodologies: other things to consider. With agile, we've looked at the basic steps to managing a protect with an agile methodology. But there are a few things to consider choosing the right methodology. Seeing the right methodology, agile itself acts as more of a blanket to him for ideal project management. A methodology, on the other hand, actors away to implement such ideals and ensure your teamwork to the agile framework we've discussed earlier. In this course, there are many different agile methodologies of a methodology is available for you to adopt . And whilst each of very similar they differ slightly in their tactics and practices, it's important to ensure you adopt a methodology that you are both comfortable with using and will support your team's workflow rather than imperfect. Let's take a look at some of the most common approaches and have screw a scrum. Methodology is the most commonly adopted methodology, especially within the software development industry, as it's considered a very simple and friendly approach to implement. We have touched upon the scrum methodology quite considerably in this course already, but let's take a look at the core concept. The concept is to have a product owner often referred to as a screw manager whose duty it will be to create a backlog of everything that is involved to reach the end result in software development terms. This can include book fixes, new features on feature in Huntsman's plus nonfunctional requirements, such a scalability, performance and security requirements. It is the role of the product owner to prioritize thes tasks into sprints. Breaking the prioritized work into sprints allows the demands to be scaled into short deliveries, making it easier to create targets and deadlines for your team, often times with larger projects, it is difficult to provide accurate deadlines for the overall delivery. Splitting the demands into shorter sprints not only keeps deadlines manageable, but also gives you the opportunity to re prioritize items without the need to revise every ICT initial scope. Once a sprint has been curated and begins, it is essential for the scrum methodology to work effectively that the sprint is not modified and sis will severely impact delivery ability Targets typically sprint to use in the scrum methodology will be full weeks each. Camba. This methodology focuses on the status of items allowing you to easily visualize where your priorities lie. It uses a very simple table structure called a Cambon board to split tasks into three status is doing. And don't. The concept of having a board for each sprint makes it easy to ensure that you aren't overburdening your team and that the Sprint will be delivered on time. The general idea of a comeback board is to ensure continual delivery. There are many different software probe where programs available, which support the Cambon methodology. But for a starting point, you can simply utilize a white board within the office with Post it notes for tasks. Moving them into different status is accordingly. Extreme programming Next extreme programming is a little different to the aforementioned sprint so much quicker and delivery, focusing on 123 week deliveries as a maximum. And it allows you to involve the end user much more throughout the entire project by advocating feedback at every angle. Customer feedback is obtained through a process called used stories and is intended to allow for changes in requirements. As the project continues its development cycle. The central requirement to extreme programming is testing, as the workflow is intended for continuous testing throughout sprints, as opposed to passing tusks through to testing as and when completed it. This is often referred to his paired programming or test based development, with the end goal being to deliver short of targets in a smaller time. Free extreme programming is further advocated through its encouragement for simplicity. It focuses on the simplest solution first functionality, where desired at a later stage in the development cycle, which helps to speed up the delivery. 6. Recap: So we've covered the principles of actual project management and how to apply these. In practice on, we've explored some of the methodologies you can adopt to achieve an agile framework. There are two key points worth remembering, which are essential to achieving is essential to achieving a successful, agile framework. Constant reviews Regularly reviewing the processes you have implemented. It's crucial to ensuring there in no weak spots, which may have potential to cause cracks in your workflow. It's important to remember that just not like the projects you're keen to deliver. Adopting the agile framework won't be perfect from the stopped. As such, you'll need to allow time to make tweaks here and there to keep things running smoothly. Fade back and communication reviews are great, but without feed from your co workers, it's possible you're going to miss crucial points of concern. The whole concept of an agile workflow is to involve your team members. Working is part of a team rather than sticking to the traditional company hierarchy that is quite outdated and can often leave members of the team feeling going interest it. Remember that that you are only as good as your team, so keeping them involved in listening to their concerns will serve you well with implementing new techniques depending on the requirements of the project. It's also crucial to involve the end user implementing the agile project management framework toe. Any business is no mean feat, and it's important to remember that there isn't a one size fits all remedy. Taking the time to adapt the process to your own companies needs will ensure acceptance across your team members and inevitably, the longevity of such a framework.