Lecture 1 - Introduction - Part A(2).pdf
Transcript
EM 554: Agile Project Management Lecture 1: Introduction Part A Assessment Scheme ⚫ Quizzes 03 = 45% (Every Two Weeks) ⚫ Assignments 03 = 25% (As Announced) ⚫ Final Exam 01 = 20% (Last Week) Reference Materials ⚫ La...
EM 554: Agile Project Management Lecture 1: Introduction Part A Assessment Scheme ⚫ Quizzes 03 = 45% (Every Two Weeks) ⚫ Assignments 03 = 25% (As Announced) ⚫ Final Exam 01 = 20% (Last Week) Reference Materials ⚫ Layton, M. C., Ostermiller, S. J., and Kynaston, D. J. (2020) Agile Project Management for Dummies, 3rd Edition, Wiley. (Purchase) ⚫ Highsmith, J. (2010) Agile Project Management: Creating Innovative Products, 2nd Edition, Pearson. (Library) ⚫ PMI. (2017) Agile Practice Guide, Project Management Institute Inc. ⚫ Cohn, M. (2006) Agile Estimating and Planning, Prentice Hall. ⚫ Goncalves, M. and Heda, R. (2010) Fundamentals of Agile Project Management: An Overview, ASME Press. Modernizing Project Management ⚫ A project is a planned program of work that requires a definitive amount of time, effort, and planning to complete. ⚫ Projects have goals and objectives and often must be completed in some fixed period of time and within a certain budget. ⚫ Agile is a descriptor of a mindset approach to project management that focuses on early delivery of business value, continuous improvement of the product being created and the processes used to create the product, scope flexibility, team input, and delivering well-tested products that reflect customer needs. The origins of modern project management ⚫ Around the time of World War II, researchers around the world were making major advances in building and programming computers, mostly for the United States military. ⚫ To complete those projects, they started creating formal project management processes. ⚫ The first processes were based on step-by-step manufacturing models the United States military used during World War II. ⚫ People in the computing field adopted these step-based manufacturing processes because early computer-related projects relied heavily on hardware, with computers that filled up entire rooms. The origins of modern project management ⚫ The 1940s manufacturing process used on these initial computers is the foundation of the project management methodology known as waterfall. Phases within include: 1. Requirements 2. Design 3. Development 4. Integration 5. Testing 6. Deployment ⚫ On waterfall projects, you move to the next phase only when the prior one is complete — hence the name waterfall. ⚫ The waterfall methodology was the most common project management approach in software development until it was surpassed by improved approaches based on agile techniques around 2008. The problem with the status quo ⚫ Computer technology has, of course, changed a great deal and at the same time, the people using computers have changed as well. ⚫ Unfortunately, however, software developers are still using project management methodologies from the 1950s, and all these approaches were derived from manufacturing processes meant for the hardware-heavy computers of the mid-twentieth century. ⚫ Today, traditional projects that do succeed often suffer from one problem: scope bloat, the introduction of unnecessary product features. ⚫ Scope bloat appears in all kinds of software, from complex enterprise applications to websites that everyone uses. Figure 1-1 shows data from a Standish Group study that illustrates just how common scope bloat is. ⚫ In the figure, you can see that 80 percent of requested features are infrequently or never used. The problem with the status quo ⚫ The numbers in the previous figure (1-1) illustrate an enormous waste of time and money. ⚫ That waste is a direct result of traditional project management processes that are unable to accommodate change. ⚫ Project managers and stakeholders know that change is not welcome mid-project, so their best chance of getting a potentially desirable feature is at the start of a project. ⚫ Therefore, they ask for: ⚫ Everything they need ⚫ Everything they think they may need ⚫ Everything they want ⚫ Everything they think they may want The problem with the status quo The problem with the status quo ⚫ The following list summarizes the major aspects of the waterfall approach to project management: ⚫ The team must know all requirements up front to estimate time, budgets, team members, and resources. Knowing all the requirements at the project start means you have a high investment in detailed requirements gathering before any development begins. ⚫ Estimation is complex and requires a high degree of competence and experience and a lot of effort to complete. ⚫ The customer and stakeholders may not be available to answer questions during the development period, because they may assume that they provided all the information needed during the requirements-gathering and design phases. ⚫ The team needs to resist the addition of new requirements or document them as change orders, which adds more work to the project and extends the schedule and budget. ⚫ The team must create and maintain volumes of process documentation to manage and control the project. ⚫ Although some testing can be done as you go, final testing can’t be completed until the end of the project, when all functionality has been developed and integrated. The problem with the status quo ⚫ The following list summarizes the major aspects of the waterfall approach to project management: ⚫ Full and complete customer feedback is not possible until the end of the project, when all functionality is complete. ⚫ Funding is ongoing, but the value appears only at the end of the project, creating a high level of risk. ⚫ The project has to be fully complete for value to be achieved. If funding runs out prior to the end of the project, the project delivers zero value. Introducing Agile Project Management ⚫ The seeds for agile techniques have been around for a long time. ⚫ In fact, agile values, principles, and practices are simply a codification of common sense. ⚫ The agile concept of product development is different from previous project management approaches and methodologies. ⚫ Agile principles provide a framework for how we want to work — how we naturally function when we solve complex problems. ⚫ When you have a critical looming deadline, your instinct is to go agile. Formality goes out of the window as you roll up your sleeves and focus on what has to get done. You solve problems quickly, practically, and in descending order of necessity, making sure you complete the most critical tasks. Build a tower, build a team | Tom Wujec - YouTube Introducing Agile Project Management ⚫ Agility Defined ⚫ "Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. ⚫ Agility is the ability to balance flexibility and stability" (Highsmith 2002) ⚫ Agility is more attitude than process, more environment than methodology. Introducing Agile Project Management Introducing Agile Project Management ⚫ In 2001, a group of software and project experts got together to talk about what their successful projects had in common. ⚫ This group created the Manifesto for Agile Software Development (commonly referred to as the Agile Manifesto), a statement of values for successful software development. Introducing Agile Project Management ⚫ Manifesto for Agile Software Development ⚫ We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan ⚫ That is, while there is value in the items on the right, we value the items on the left more. Introducing Agile Project Management ⚫ These experts also created 12 principles behind the Agile Manifesto that help support the values in the Agile Manifesto. ⚫ Agile, in product development terms, is a descriptor for approaches that focus on people, communications, the product, and flexibility. ⚫ If you’re looking for the agile methodology, you won’t find it. However, 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. Introducing Agile Project Management 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. ⚫ In the context of software development methodologies, an empirical approach can be effective in both new product development and enhancement and upgrade projects. ⚫ 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 product development effort involves the same type of work as in a traditional waterfall project: ⚫ You create requirements and designs ⚫ develop product features ⚫ document what was done and why, and ⚫ continuously integrate new features ⚫ you test the product ⚫ fix any problems, and ⚫ deploy the product 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: YouTube - User Story Mapping | Business Analyst Skills | EP 1 Channel: ThePrefectBA Link: https://www.youtube.com/watch?v=QYkYdfiwsCM Evaluating agile benefits ⚫ Moreover, with agile product development, the customers get to see their product at the end of every short cycle. ⚫ You can create the highest-priority features first, which gives you the opportunity to ensure maximum value early on, when less of the customer’s money has been invested. ⚫ An agile approach to product development will reduce risk during every iteration. ⚫ In addition, if your product has market value, revenue can be coming in even during development. Now you have a self-funding product. Agile Project Management Is Becoming Agile Product Management ⚫ Traditional projects, by definition, are organized into temporary, build-only team efforts designed to accomplish specific benefits projected in a business case. ⚫ Project initiation, which is when we know the least, is when budgets, schedules, and expectations are set. ⚫ When projects end, the teams are disbanded and unfamiliar operational teams are left to support the customer and product. ⚫ If more work is required, new team members are allocated to a new project and must refamiliarize themselves with the product architecture. ⚫ Projects typically end once deliverables are released into production, leaving others to support and evaluate the effect on business. Agile Project Management Is Becoming Agile Product Management ⚫ Today, products are considered long-term, value-creating assets requiring permanent teams who iteratively elaborate, design, develop, test, integrate, document, and even support products until business outcomes are achieved. ⚫ A high-performing team continuously inspects and adapts until the customer’s problems are solved, and the team retains this hard-earned knowledge. The team and customer collaborate to create value over following written specifications. ⚫ More and more we see a project-driven approach as a constraint to delivering customer value early and often. ⚫ Taking an agile approach to product development limits you not to time or money but to value. Agile Project Management Is Becoming Agile Product Management ⚫ Organizations most effectively deliver value when they use the following formula to determine when it’s time to shift priorities: AC + OC > V, that is, actual cost + opportunity cost > value ⚫ When the actual cost of working on a product’s additional requirements plus the opportunity cost of not working on a different investment opportunity exceed the expected value of delivering those remaining product requirements, the team shifts to developing the more valuable investment opportunity. Differences between managing a project versus developing a product ⚫ Three primary differences exist between managing a project and developing a product: ⚫ Products benefit most from stable, long-lived, and even permanent teams. ⚫ Products can be not only short-term assets but also long-term assets. Active products are never really finished because they require maintenance and improvements. ⚫ Products are part of a portfolio designed to maximize value over following specifications. Differences between managing a project versus developing a product ⚫ Permanent team over temporary team ⚫ Long-lived products are best developed and maintained by long-lived and even permanent teams. ⚫ The longer a team works together iteratively building an emergent architecture and expanding its capability and high performance, the better the team understands the customer and the more predictable the team becomes. ⚫ Project-focused teams come together for a specific amount of time and then move on to something new. ⚫ Lessons learned at the end of a project may not even apply to the next project because the context of people, technologies, and customers will most likely be different. Stable permanent teams enable transparency, inspection, and adaptation (empirical process control). ⚫ Permanent doesn’t mean that agile product teams don’t change and career aspirations are inhibited. ⚫ However, team personnel changes are an exception rather than the rule. People — especially people who become more valuable because of their expanding capability — are presented with career-enhancing opportunities. ⚫ Ideally, permanent team members behave more like a family than as a temporary, one-project-only group. Differences between managing a project versus developing a product ⚫ Products as long-term assets rather than project deliverables ⚫ Product development is risky. Uncertainty abounds at every corner. But uncertainty is what makes agile product development ideal! ⚫ Traditional projects are tasked with accomplishing specific system deliverables within a fixed time frame, but agile product development iteratively reduces uncertainty by building useable, fully functional product increments, gathering and implementing feedback throughout development. ⚫ The product becomes a customer-aligned, problem solving asset. ⚫ Active products are never finished because maintenance must be performed, and improvements can be made. Investments in time, money, and people, particularly with today’s capital expenditure strategies, change products into depreciable assets that improve bottom-line results for not only revenue but also cost savings. ⚫ Treating development as an asset creator rather than a cost expenditure changes the perspective of everyone involved. Differences between managing a project versus developing a product ⚫ Products as long-term assets rather than project deliverables ⚫ Continuous delivery of customer value through agile product development increases the likelihood of additional funding. ⚫ Capital expenditures, commonly known as CapEx, are funds used by a company to acquire, upgrade, and maintain physical assets such as property, buildings, industrial plants, technology, and equipment. ⚫ CapEx is often used to undertake new projects or investments by the firm. Differences between managing a project versus developing a product ⚫ Pursuing value over specifications ⚫ Early failure is a key tenant of agility. ⚫ Agile teams are obsessed with taking risks to create customer value. ⚫ Like scientists, they create a hypothesis, test it in the real world, evaluate the results, and then adjust the hypothesis and test it again. They repeat this process again and again, aligning the product more closely to the customer’s needs with each iteration. ⚫ Teams trade reams of documented specifications for real-world feedback from the customer. With agile product development, functionality priorities are set by the people most familiar with the problem to be solved Why agile product development works better ⚫ Agile approaches can produce more successful products. ⚫ The Standish Group study, “Software project success and failure,” found that while 29 percent of traditional projects failed outright, that number dropped to only 9 percent with agile techniques. ⚫ The decrease in failure for agile product development is a result of agile teams making immediate adaptations based on frequent inspections of progress and customer satisfaction. Why agile product development works better ⚫ Here are some key areas where agile product development approaches are superior to traditional project management methods: ⚫ Project success rates: The risk of catastrophic project failure falls to almost nothing with agile product development. Agile approaches of prioritizing by business value and risk ensure early success or failure. Agile approaches to testing throughout the product development help ensure that you find problems early, not after spending a large amount of time and money. ⚫ Scope creep: Agile approaches accommodate changes throughout product development, minimizing scope creep. Following agile principles, you can add new requirements at the beginning of each sprint without disrupting development flow. By fully developing prioritized features first, you prevent scope creep from threatening critical functionality. ⚫ Inspection and adaptation: Regular inspections and adaptation work throughout agile product development. Agile teams — armed with frequent feedback from complete development cycles and working, shippable functionality — can improve their processes and their products with each sprint. Understanding the Agile Manifesto ⚫ In the mid-1990s, the Internet was changing the world right before our eyes. The people working in the booming dot-com industry were under constant pressure to be the first-to-market with fast-changing technologies. ⚫ Development teams started exploring alternatives to these outdated approaches to project management. In doing so, they noticed some common themes that produced better results ⚫ In February 2001, 17 of these new methodology pioneers met in Snowbird, Utah, to share their experiences, ideas, and practices; to discuss how best to express them; and to suggest ways to improve the world of software development. ⚫ Over the next several months, these leaders constructed the following: ⚫ The Agile Manifesto (originally the Manifesto for Agile Software Development): An intentionally streamlined expression of core development values ⚫ The Agile Principles: A set of 12 guiding concepts that support product development teams in delivering value and staying on track ⚫ The Agile Alliance: A community development organization focused on supporting individuals and organizations applying agile principles and practices Understanding the Agile Manifesto ⚫ Manifesto for Agile Software Development ⚫ We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan ⚫ That is, while there is value in the items on the right, we value the items on the left more. Understanding the Agile Manifesto ⚫ Whereas traditional approaches emphasize a rigid plan, avoid change, document everything, and encourage hierarchical-based control, the manifesto focuses on: » People » Communications » Product » Flexibility Understanding the Agile Manifesto ⚫ Research and experience illustrate why agile values are so important: ⚫ Individuals and interactions over processes and tools: Why? Because research shows a 50 times increase in performance when we get individuals and interactions right. One of the ways to get this right is by collocating a development team with an empowered product owner. ⚫ Working software over comprehensive documentation: Why? Because failure to test for and correct defects during the sprint can take up to 24 times more effort and cost in the next sprint. And after the functionality is deployed to the market, if a production support team that wasn’t involved in product development performs the testing and fixing, the cost is up to 100 times more. Understanding the Agile Manifesto ⚫ Research and experience illustrate why agile values are so important: ⚫ Customer collaboration over contract negotiation: Why? Because a dedicated and accessible product owner can generate a fourfold increase in productivity by providing in- the-moment clarification to the development team, aligning customer priorities with the work being performed. ⚫ Responding to change over following a plan: Why? Because 80 percent of features developed under a waterfall model are infrequently or never used. Starting with a plan is vital, but the start is when we know the least. Product development teams don’t plan less than waterfall teams — they plan as much or more. However, teams take a just-in-time approach, planning just enough when needed in support of a strategic product vision and roadmap. Adaptation of the plan to the realities along the way is how teams avoid wasteful functionality and deliver products that delight customers. Understanding the Agile Manifesto ⚫ The creators of the Agile Manifesto originally focused on software development because they worked in the IT industry. ⚫ However, agile techniques have spread beyond software development and even outside computer-related products. ⚫ Today, agile approaches such as scrum are disrupting biotech, manufacturing, aerospace, engineering, marketing, building construction, finance, shipping, automotive, utility, and energy industries with companies such as Apple, Microsoft, and Amazon leading the way. ⚫ If you want early empirical feedback on the product or service you’re providing, you can benefit from agile methods. ⚫ Agile values and principles apply to all product development activities, not just software. Outlining the Four Values of the Agile Manifesto ⚫ Value 1: Individuals and interactions over processes and tools ⚫ When you allow each person to contribute his or her unique value to a product, the result can be powerful. When these human interactions focus on solving problems, a unified purpose can emerge. Moreover, the agreements come about through processes and tools that are much simpler than conventional ones. ⚫ A simple conversation in which you talk through a product issue can solve many problems in a relatively short time. Trying to emulate the power of a direct conversation with email, spreadsheets, and documents results in significant overhead costs and delays. Instead of adding clarity, these types of managed, controlled communications are often ambiguous and time-consuming and distract the development team from the work of creating a product. ⚫ If processes and tools are seen as the way to manage product development and everything associated with it, people and the way they approach the work must conform to the processes and tools. Conformity makes it hard to accommodate new ideas, new requirements, and new thinking. Agile approaches, however, value people over process. This emphasis on individuals and teams puts the focus on their energy, innovation, and ability to solve problems. You use processes and tools in agile product management, but they’re intentionally streamlined and directly support product creation. The more robust a process or tool, the more you spend on its care and feeding and the more you defer to it. With people front and center, however, the result is a leap in productivity. An agile environment is human-centric and participatory and can be readily adapted to new ideas and innovations. Outlining the Four Values of the Agile Manifesto ⚫ Value 1: Individuals and interactions over processes and tools Outlining the Four Values of the Agile Manifesto ⚫ Value 2: Working software over comprehensive documentation ⚫ A development team’s focus should be on producing working functionality. With agile development, the only way to measure whether you are truly finished with a product requirement is to produce the working functionality associated with that requirement. For software products, working software means the software meets what we call the definition of done: at the very least, developed, tested, integrated, and documented. After all, the working product is the reason for the investment. ⚫ Have you ever been in a status meeting where you reported that you were, say, 75 percent done with your project? What would happen if your customer told you, “We ran out of money. Can we have our 75 percent now?” On a traditional project, you wouldn’t have any working software to give the customer; 75 percent done traditionally means you are 75 percent in progress and 0 percent done. ⚫ With agile product development, however, by using the definition of done, you would have working, potentially shippable functionality for 75 percent of your product requirements — the highest-priority 75 percent of requirements. Outlining the Four Values of the Agile Manifesto ⚫ Value 2: Working software over comprehensive documentation ⚫ All development requires some documentation. With agile product development, documents are useful only if they support development and are barely sufficient to serve the design, delivery, and deployment of a working product in the most direct, unceremonious way. Agile approaches dramatically simplify the administrative paperwork relating to time, cost control, scope control, or reporting. ⚫ Product development teams produce fewer, more streamlined documents that take less time to maintain and provide better visibility into potential issues. In the coming chapters, you find out how to create and use simple tools (such as a product backlog, a sprint backlog, and a task board) that allow teams to understand requirements and assess real-time status daily. With agile approaches, teams spend more time on development and less time on documentation, resulting in a more efficient delivery of a working product. Outlining the Four Values of the Agile Manifesto ⚫ Value 2: Working software over comprehensive documentation Outlining the Four Values of the Agile Manifesto ⚫ Value 3: Customer collaboration over contract negotiation ⚫ The customer is not the enemy. Really. ⚫ Historical project management approaches usually limit customer involvement to a few development stages: ⚫ Start of a project: When the customer and the project team negotiate contract details. ⚫ Any time the scope changes during the project: When the customer and the project team negotiate changes to the contract. ⚫ End of a project: When the project team delivers a completed product to the customer. If the product doesn’t meet the customer’s expectations, the project team and the customer negotiate additional changes to the contract. ⚫ This historical focus on negotiation, avoidance of scope change, and limitation of direct customer involvement discourages potentially valuable customer input and can even create an adversarial relationship between customers and project teams. Outlining the Four Values of the Agile Manifesto ⚫ Value 3: Customer collaboration over contract negotiation ⚫ The agile pioneers understood that collaboration, rather than confrontation, produced better, leaner, more useful products. As a result of this understanding, agile methods make the customer part of the product development on an ongoing basis. ⚫ Using an agile approach in practice, you’ll experience a partnership between the customer and the product development team in which discovery, questioning, learning, and adjusting during the course of development are routine, acceptable, and systematic. This partnership results in superior products better suited for the customer’s needs. Outlining the Four Values of the Agile Manifesto ⚫ Value 4: Responding to change over following a plan ⚫ Change is a valuable tool for creating great products. Teams that can respond quickly to customers, product users, and the market are able to develop relevant, helpful products that people want to use. ⚫ Unfortunately, traditional project management approaches attempt to wrestle the change monster and pin it to the ground so it goes out for the count. Rigorous change management procedures and budget structures that can’t accommodate new product requirements make changes difficult. Traditional project teams often find themselves blindly following a plan, missing opportunities to create more valuable products or, even worse, unable to react timely to changing market conditions. Outlining the Four Values of the Agile Manifesto Value 4: Responding to change over following a plan Outlining the Four Values of the Agile Manifesto ⚫ Value 4: Responding to change over following a plan ⚫ Agile development accommodates change systematically. The flexibility of agile approaches increases stability because product changes are predictable and manageable — in other words, it’s expected and nondisruptive to a product development team. ⚫ As new events unfold, the team incorporates these realities into the ongoing work. Any new item becomes an opportunity to provide additional value instead of an obstacle to avoid, giving development teams a greater opportunity for success. Questions
