Agile Project Management Agile Manifesto, principles and values Defining the product vision and roadmap Planning releases and sprints Project Management 1.The lecture is divided into three blocks, where each block introduces an issue (1. What is a project and project management, Who is project manager and their role 2. Project management evolution 3. The main elements of a project, types of projects) 2.After each block there is a quiz for feedback on whether you have understood everything. 3. 3.We use MS Teams, a shared whiteboard for your engagement and reactions. Also we are working with MS Project. 4. 4.The class is supplemented with quizzes in vevox, the link is always in the presentation. • • • • • • How the lecture will be conducted? Contents 1.PART (30 min.) •Agile Manifesto, principles and values •Agile project management frameworks 2. PART (20 min.) •Defining the product vision and roadmap 3. PART (30 min.) •Planning releases and sprints • • • • • • • Learning objectives On the end of this lecture you should be able to understand and explain: •what is the difference between agile and traditional project management •What are values and principles of agile project management •What frameworks are used in agile project management • • • • Key readings You can find support in the following sources: Layton, M. C. and Ostermiller, S. J. (2017) Agile Project Management For Dummies. 2nd edn. Hoboken: John Wiley & Sons, Ltd. • • • • PART 1 What is agile project management? • Agile project management is a style of project management that focuses on: •early delivery of business value, •continuous improvement of the project’s product and processes, •scope flexibility, •team input, and •delivering welltested products that reflect customer needs. • • What is agile project management? •Agile, in product development terms, are project management approaches that focus on people, communications, the product, and flexibility. • •All agile methodologies (for example, crystal), frameworks (for example, scrum), techniques (for example, user story requirements), and tools (for example, relative estimating) have one thing in common: •adherence to the Agile Manifesto and the 12 Agile Principles. How agile projects work •Agile approaches are based on an empirical control method —> a process of making decisions based on the realities observed in the project. •By using frequent and firsthand inspection of the work to date, you can make immediate adjustments, if necessary. Empirical control requires: •Unfettered transparency: Everyone involved in an agile project knows what is going on and how the project is progressing. •Frequent inspection: The people who are invested in the product and process the most regularly evaluate the product and process. •Immediate adaptation: Adjustments are made quickly to minimize problems; if an inspection shows that something should change, it is changed immediately. How agile projects work •To accommodate frequent inspection and immediate adaptation, agile projects work in iterations (smaller segments of the overall project). • •An agile project involves the same type of work as in a traditional waterfall project: ØYou Create requirements and designs, develop the product, document it, and if necessary, integrate the product with other products. • ØYou test the product, fix any problems, and deploy it for use. However, instead of completing these steps for all product features at once, as in a waterfall project, you break the project into iterations, also called sprints. How agile projects work • Source: Layton, M. C., Ostermiller S. J. 2017. Agile Project Management, p. 15 Agile Manifesto and Principles •The Agile Manifesto: An intentionally streamlined expression of core development values • •The Agile Principles: A set of 12 guiding concepts that support agile project teams in implementing agile techniques and staying on track • The 12 Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The 12 Agile Principles 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity — the art of maximizing the amount of work not done — is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Four Values of the Agile Manifesto •Value 1: Individuals and interactions over processes and tools •Value 2: Working software over comprehensive documentation •Value 3: Customer collaboration over contract negotiation •Value 4: Responding to change over following a plan • Time for recap - let’s watch together https://www.linkedin.com/learning/project-management-foundations-15528659/what-is-agile-project-man agement • PART 2 Agile project management frameworks • • • Agile project management frameworks • Defining the product vision and roadmap •The first stage in an agile project is defining your product vision. The product vision statement is an elevator pitch, or a quick summary, to communicate how your product supports the company’s or organization’s strategies. The vision statement must articulate the end state for the product. • •The product might be a commercial product for release to the marketplace or an internal solution that will support your organization’s day-to-day functions. • •When creating a product vision statement, follow these four steps: •Develop the product objective. •Create a draft vision statement. •Validate the vision statement with product and project stakeholders and revise it based on feedback. •Finalize the vision statement. • Defining the Product Vision and Product Roadmap •The product roadmap, stage 2 in the Roadmap to Value, is an overall view of the product’s requirements and a valuable tool for planning and organizing the journey of product development. •Use the product roadmap to categorize requirements, prioritize them, identify gaps and dependencies, and determine a timetable for releasing to the customer. •As he or she does with the product vision statement, the product owner creates the product roadmap, with help from the development team and stakeholders. The development team participates to a greater degree than it did during the creation of the vision statement. • To create your product roadmap, you do the following: •Identify stakeholders. •Establish product requirements and add them to the roadmap. •Arrange the product requirements based on values, risks, and dependencies. •Estimate the development effort at a high level and prioritize the product’s requirements. •Determine high-level time frames for releasing groups of functionality to the customer. • • Defining the Product Vision and Product Roadmap •The product roadmap contains high level features and some tentative release timelines. The requirements on your product roadmap are the first version of your product backlog. •The product backlog is the list of all requirements associated with the project. •The product owner is responsible for creating and maintaining the product backlog by adding and prioritizing requirements. • •The scrum team uses the prioritized product backlog throughout the project to plan its work - like a streamlined project plan. • At a minimum, when creating your product backlog, be sure to do the following: •Include a description of each requirement. •Order the requirements based on priority. •Add the effort estimate. • Defining the product vision and roadmap • Vevox questions Planning releases and sprints •Release planning involves completing two key activities: 1. Revising the product backlog: the product backlog is a comprehensive list of all the user stories you currently know for your project, whether or not they belong in the current release. Keep in mind that your list of user stories will probably change throughout the project. 2. Creating the release plan: This activity consists of the release goal, release target date, and prioritization of product backlog items that support the release goal. The release plan provides a midrange goal that the team can accomplish. • •Don’t create a new, separate backlog during release planning. The task is unnecessary and reduces the product owner’s flexibility. Prioritizing the existing product backlog based on the release goal is sufficient and enables the product owner to have the latest information when he or she commits to the scope during sprint planning. • •The product backlog and release plan are some of the most important communication channels between the product owner and the development team. • Planning Releases and Sprints •In agile projects, a sprint is a consistent iteration of time in which the development team creates a specific group of product capabilities from start to finish. •At the end of each sprint, the functionality that the development team has created should be working, ready to demonstrate, and potentially shippable to the customer. • •Sprints generally last one to four weeks. Four weeks is the longest amount of time any sprint should last; longer iterations make changes riskier, defeating the purpose of being agile. We rarely see sprints lasting longer than two weeks, and more often see sprints lasting a week. • •One-week sprints are a natural cycle with the Monday-to-Friday business week that structurally prevents weekend work. Some scrum teams work in one-day sprints where priorities change on a daily basis. • •Market and customer needs are changing more and more quickly, and the amount of time you can afford between opportunities to gather customer feedback only gets shorter. Our rule of thumb is that your sprint shouldn’t be longer than your stakeholders can consistently go without changes in priority regarding what the scrum team should be working on in the sprint. • • • Planning Releases and Sprints Each sprint includes the following: •Sprint planning at the beginning of the sprint •Daily scrum meetings •Development time — the bulk of the sprint •A sprint review and a sprint retrospective at the end of the sprint • The sprint backlog is a list of user stories associated with the current sprint and related tasks. When planning your sprint, you do the following: •Establish goals for your sprint. •Choose the user stories that support those goals. •Break user stories into specific development tasks. •Create a sprint backlog. The sprint backlog consists of the following: •The list of user stories within the sprint in order of priority. •The relative effort estimate for each user story. •The tasks necessary to develop each user story. •The effort, in hours, to complete each task. • • Vevox questions References • •Layton, M. C. and Ostermiller, S. J. (2017) Agile Project Management For Dummies. 2nd edn. Hoboken: John Wiley & Sons, Ltd. • •