PMI-ACP Exam Preparation Course Introduction

Transcription

1 PMI-ACP Exam Preparation Course Introduction Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 1

2 Course Overview This course is designed to help you tailor the Agile framework to accommodate the needs of different types of projects, and will appreciate various tools and concepts used by the Agile practitioner. At the conclusion of the course you have learned the foundation required for taking the Project Management Institute s PMI Agile Certification Exam and achieving the PMI-ACP SM (Agile Certified Practitioner) certification. This course comprises seven learning modules and one exam review module. Throughout the course, references are made to key information from the PMI Agile Certified Practitioner (PMI-ACP SM ) Handbook. 2

3 Course Content The content from this course is tailored to adhere to the six domains of knowledge as detailed in the PMI Agile Certified Practitioner (PMI-ACP) Examination Content Outline. Continuous Improvement Value-Driven Delivery Knowledge Domains Stakeholder Engagement The various sources of content in this course are separate from PMI but are directly related to the six knowledge domains. Problem Detection and Resolution Adaptive Planning Boosting Team Performance Practices 3

4 Topics Covered in this Course About BetterPM.com A typical Waterfall Project Lifecycle Specifics regarding the PMI-ACP credentialing process Manifesto for Agile Software Development Agile How is it Different? Overview of an Agile project lifecycle Benefits and limitations of an Agile process Leveraging the benefits of multiple disciplines Scrum Other Types of Agile Current Trends and the Lean Startup PMI and Agile Project Management 4

5 Course Objectives By the end of the course, you should be able to: Confidently explain the differences between the Agile approach and a typical Waterfall project approach Know the basic pros and cons of each method Understand the basics of the Scrum approach Be able to recite the rule of Scrum: 3 Roles, 4 Artifacts, and 5 Ceremonies Know the differences between PMP, PMI-ACP, and Scrum Master certifications Upon completion of this course, you are entitled to earn 21 PDUs. Immediately download your course certificate right to your device (as a picture in your pictures folder) yourself the certificate for printing at home Register this course as 21 Category A (R.E.P Courses) PDUs. Go to your PMI.org profile, and enter course #PMAgile-1. We are provider #3330, BetterPM.com, Innate Images LLC 5

6 Outline of Course Modules Below is a description of all modules in the course. The PMI-ACP SM Exam Pre-requisites for the exam The application process Structure of the exam. Knowledge domains covered. Self Study recommendations Practice exam Module 1: Concepts of Agile Differences between the Agile approach and a typical Waterfall project approach Agile Manifesto values and principles Agile vs. Waterfall: Pros and cons, and coexisting disciplines. The Scrum approach Key aspects of the PMI-ACP SM Handbook Exam Overview: Eligibility and continuing certification requirements. 6

7 Outline of Course Modules Module 2: Value-Driven Delivery Value based prioritization Value stream analysis Decomposition Prioritization Incremental Delivery Module 3: Stakeholder Engagement Communications Management Feedback techniques for product Assessing and incorporating community and stakeholder values Active listening Business case development Facilitation methods The definition of Done 7

8 Outline of Course Modules Module 4: Boosting Team Performance Practices Building empowered teams Brainstorming techniques Information radiator Globalization, culture, and team diversity Adaptive leadership Module 5: Adaptive Planning User stories/user maps Retrospectives Burn down/burn up charts Cumulative flow diagrams Timeboxing 8

9 Outline of Course Modules Module 6: Problem Detection and Resolution Problem-solving strategies, tools, and techniques Test-driven development Continuous integration Acceptance test-driven development Module 7: Continuous Improvement (Product, Process, People) Knowledge sharing Coaching and mentoring within teams Time, budget, and cost estimation Agile communication tools Emotional intelligence 9

10 PMI-ACP Exam Preparation An overview of The PMI-ACP SM Exam Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 10

11 Module Overview Over the course of eight modules you ll learn from all required knowledge domains covered on the PMI-ACP exam. This module is intended to summarize the format of the exam and review the scope of the knowledge that s tested. In addition, this course includes a bank of sample exam questions to help you study. On the following pages we will cover: Eligibility requirements for the certification The breakdown of knowledge domains tested and the concentration of each in the exam. Helpful tips regarding the style and format of the exam. 11

12 PMI Agile Certification Eligibility Requirements Project Management Institute s eligibility requirement for the certification are listed below. This course is intended to assist you solely with the final step: the PMI-ACP exam. Requirement General project experience Agile project experience Training in agile practices Description 2,000 hours working on project teams These hours must be earned within the last 5 years Active PMP or PgMP will satisfy this requirement hours working on agile project teams or with agile methodologies These hours are in addition to the 2,000 hours required in general project experience. These hours must be earned within the last three years. 21 contact hours. This course fulfills this requirement. Hours must be earned in agile practices Examination Tests knowledge of all agile fundamentals PMI s exam requirements are subject to change at any time. Refer to their online listing to see the current requirements. ( 12

13 The Domains of Knowledge Tested The exam consists of 120 multiple choice questions with a three-hour time limit. Twenty of the questions are considered pretest questions for future versions of the exam and are not included in your score although they are randomly placed throughout the exam and you will need to answer them like any other question. The exam is split evenly between Tools & Techniques and Knowledge & Skills. 13

14 The Knowledge and Skill Levels The three knowledge and skill levels are weighted differently: Level one contains 33% of the questions. Level two contains 12% of the questions. Level three contains 5% of the questions. 14

15 Tools and Techniques Portion The following slides summarize the topics covered in each knowledge domain as listed in the PMI-ACP Examination Content Outline. This course was developed to help you learn about the core concepts identified by the exam outline. The full examination outline is available on PMI s website.

16 Tools and Techniques Portion The 60 questions comprising Tools and Techniques cover the following topics: Tool Communications Planning, monitoring and adapting Agile estimation Agile analysis and design Product quality Examples Information radiators, team space, agile tooling, osmotic communications for colocated and/or distributed teams, daily stand-ups. Retrospectives, task/kanban boards, time-boxing, iteration and release planning, WIP limits, burn down/up charts, cumulative flow diagrams, process tailoring Relative sizing/story points, wide band Delphi/planning poker, affinity estimating, ideal time Product roadmap, user stories/backlog, story maps, progressive elaboration, wireframes, chartering, personas, agile modeling Frequent verification and validation, test-driven development, acceptance test-driven development, definition of done, continuous integration

17 Tools and Techniques Portion (cont d) The 60 questions comprising Tools and Techniques cover the following topics: Tool Soft skills negotiation Value-based prioritization Risk management Metrics Value stream analysis Examples Emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership Return on Investment (ROI,) net present value (NPV,) internal rate of return (IRR,) compliance, customervalued prioritization, minimally marketable feature (MMF,) relative prioritization, ranking. Risk-adjusted backlog, risk burn down graphs, risk-based spike Velocity, cycle time, earned value management (EVM) for agile projects, escaped defects. Value stream mapping

18 Knowledge and Skills Portion Level 1 Active Listening Agile Manifesto Values and Principles Assessing and incorporating community and stakeholder values Brainstorming techniques Building empowered teams Coaching and mentoring within teams Communications management Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluation) Incremental delivery Knowledge sharing Leadership tools and techniques Prioritization

19 Knowledge and Skills Portion Level 1 Project and quality standards for Agile projects Stakeholder management Team motivation Time, budget and cost estimation Value-based decomposition and prioritization

20 Knowledge and Skills Portion Level 2 Agile frameworks and terminology Building high-performance teams Business case development Colocation (geographic proximity)/distributed teams Continuous Improvement Processes Elements of a project charter for an agile project Facilitation methods Participatory Decision Models (e.g., input-based, shared collaboration, command) PMI s Code of Ethics and Professional Conduct Process Analysis Techniques Self assessment Value-based analysis

21 Knowledge and Skills Portion Level 3 Agile contracting methods Agile project accounting principles Applying new agile practices Compliance (organization) Control limits for agile projects Failure modes and alternatives Globalization, culture, and team diversity Agile games Principles of systems thinking (e.g. complex adaptive, chaos) Regulatory compliance Variance and trend analysis Variations in agile methods and approaches Vendor management

22 PMI-ACP Exam Preparation Module 1: Introduction to Agile Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 22

23 Module Overview This module introduces the core aspects of the agile framework, and it is geared to better prepare you for the in-depth modules (2-7) which will cover many of the concepts in greater detail. At the conclusion of this module, you should have a good understanding of the agile framework for software development. Specifically In this module: The Waterfall Model as a contrast to Agile A History of Agile The Software Alliance The Agile Manifesto 12 principles of the Agile manifesto A history of the concept of Chickens and Pigs Comparisons between Waterfall and Agile Scrum A primer on scrum and how it relates to agile The product backlog The daily standup 23

24 Module Overview (cont d) Team Collaboration How the Chicken and Pig metaphor has evolved to expect everyone to have a stake in the project. Scrum Components Sprints/Iterations User Stories Estimating User Stories 24

25 Module Objectives At the conclusion of this module, you should: Understand the key differences between the Waterfall model and the Agile framework. Be familiar with the core principles that have arisen out of the Agile Manifesto. Be aware of the variations of agile and know how scrum fits in as a part of agile. Understand the mechanics of the daily scrum and the working of the product backlog. 25

26 Waterfall Model: Introduction, Pros and Cons Throughout this course, in conversations among project managers & software developers, and in current industry periodicals you will encounter a number of opinions on the various options for managing your project teams. In the past 15 years, the agile framework has begun to serve as a contrast to waterfall and a viable option to managing any project. Although agile arose from a need in the software industry, almost any project or process can benefit from the framework. So before we learn about agile, it s important to understand one of the predecessors that agile arose from. The waterfall development model originates from the manufacturing and construction industries, where after-the-fact changes were detrimental to profits and delivery times. In the 1970s and 1980s it was adapted for software development. 26

27 Waterfall Model: Introduction What is Waterfall? Waterfall projects were in use in many industries including software many years before Agile came into formal existence. It s a methodology in the Software Development Lifecycle (SDLC) and other industries outside of software which resists the revisiting and revising of any prior phase once it's complete. The waterfall model illustrates the development process in a linear sequential flow. The idea being that ones you passed a stage in development you rarely came back to revisit it or iterate (an operative word you ll learn about with Agile.) Any phase in the development process begins only if the previous phase is complete. It isn t forbidden to go back a step if requirements have changed, but it s an expensive proposition that s not easily accommodated by the discipline. The waterfall approach does not define the process to go back to the previous phase to handle changes in requirements. As a result, different projects may follow different approaches to handle such situations. The waterfall approach is the earliest approach that was used for software development largely because it was the only one available at the time.. Initially, most projects followed the waterfall approach because they did not focus on changing requirements. 27

28 A Typical Waterfall Project Lifecycle Feasibility Why the name waterfall? Requirement Design Because other than some iterations in the build and test phases, everything flows downstream and doesn t return. Build Errors and Rework Test Waterfall doesn t prohibit going back upstream to fix problems, but the methodology isn t well set up to support the process, and as a result significant time and expense are incurred. Deploy 28

29 The Emergence of Agile By the 2000s, the concept of iterative development as a less rigid alternative to waterfall began to take shape among many in the software development community. The term Agile was first coined in 2001 by a group of 17 software developers when meeting in Utah to discuss lightweight development models. Many of these developers formed the Agile Alliance to promote software development according the visions of their charter, which they called the Agile Manifesto. The Agile Manifesto has become a key foundational element in the guiding principles of what has become known to be simply, Agile. Strictly speaking, Agile is not a model, discipline or a methodology. It s a framework that is still evolving.

30 Agile Manifesto Below is the wording of the Agile Manifesto that originated in the 2001 meeting and is still used today. You can find the full text at this link: 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.

31 Agile Manifesto 12 Principles The Agile Manifesto is supplemented by 12 key principles, which are listed here: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome challenging 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 toward a shorter timescale. 4. Business people and developers must work together daily throughout the project.

32 Agile Manifesto 12 Principles (cont d) 5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. 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.

33 Agile Manifesto 12 Principles (cont d) 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. Reference:

34 Differences Between Waterfall and Agile So which framework is right? There s no right or wrong answer, and in many cases companies practice both among departments and groups. Below is a summary of some of the key differences between the two. Waterfall Plan driven Infrequent team communication Deliver once, Big design up front, typically 9-12 months Development done by layers, presentation, persistence, business, etc. Agile Learning driven Continuous team communication Deliver smaller, business focused phases, usually 1-2 months Develop end-to-end functional slices

35 Differences Between Waterfall and Agile Waterfall Integration occurs at the completion of each layer Testing occurs at the end of the project, mostly functional testing High cost to change Agile Continuous integration (daily builds) Fully automated, continuous testing, unit level and functional testing Low cost of change Must nail down requirements up front Expects, accommodates, changes to requirements Big Design Up Front Rough Design Up Front (also referred to as Big Requirements up Front )

36 Agile Manifesto Tenets As you prepare for the exam, keep in mind these key items favored by the agile framework over the waterfall model. Agile Individuals and Interactions Working Software Customer Collaboration Responding to Change Strong, collaborative teams Over Over Over Over Over Waterfall Process and Tools Comprehensive Documentation Contract Negotiation Following a Plan Individual Work Packages

37 Agile Projects: Control Limits The Agile framework is one of adaptation rather than prescribed or defined process. However, the framework is not without controls. Some tools used are: Product Vision: A high-level summary of the desired outcome. Release Planning: Conducted at the beginning of a release as stories are taken on by the team. A required agile activity. Iteration Planning: A list of prioritized features that is converted into work during release planning. A required activity Daily Standup: Short meetings where team members review what they accomplished, what is upcoming, and what issues they are facing. Also referred to as the Daily Scrum We will cover each of these topics in greater detail throughout the course.

38 Agile Practices and Management When studying for the exam, know that Agile respects certain components of the software development lifecycle (SDLC,) and its methodologies span both practices (building software) and management (coordination activities.) Management of complex agile projects is known as Scrum which is introduced in detail later on the next pages. Agile Practices Agile Management Examples of Agile variations Extreme Programming (XP) Pragmatic Programming Agile Modeling Scrum A Note on Terms Scrum implies Agile, but Agile does not imply Scrum. Scrum is an agile management technique.

39 Agile Isn t Just for Software Anymore Although the framework is relatively new in comparison to methodologies such as Waterfall, and although the software industry has been the first to champion the use of agile, the framework isn t just for software development. An alternative to the concept of cost accounting in business today (which focuses on cost cutting,) is the notion of Throughput Accounting. Proffered by Eliyahu Goldratt, the goal is to improve profit performance with better management decisions by using metrics that directly measure the effects of those decisions. Mark Addleson s Beyond Management: Taking Charge at Work 1 states, By looking for practices that are good for knowledge-work, which break the stranglehold of management on how to organize work, we can learn a lot from a mini-revolution in software development known as agile methods. Agile methods offer a way out of this impasse, with a far reaching, even radical solution to building good software Lonely Planet is using agile to have their team of in-house lawyers plan their work load and ensure priority items are done on time. (Reference: Agile Today 2, May 2011) 1: 20&linkCode=as2&camp=1789&creative=390957&creativeASIN= :

40 Agile Isn t Just for Software Anymore In the modules ahead, we ll learn about the following tools and techniques that are not directly tied to the software industry and can be used in various lines of business to improve the quality and success of products. All of these concepts that we ll cover can be used in a variety of industries: Using Kanbans to determine what has to be done next. Timeboxing Asking Who, What and Why by documenting a user story Frequent user testing Shorter and more meetings with only the relevant people. Pairing together subject matter experts Setting priorities as a team Iterative development

41 The Scrum Framework an Introduction In the next slides we will dive in to the Scrum framework. Scrum is an approach in agile that is heavily used when dealing with complex projects. Although scrum is not a necessary component of every agile project, it s possible that you ll be performing the activities on the following slides and refer to them as part of an Agile Project, not a Scrum Project or Scrum Steps. Below are key steps in how the scrum framework operates. A product owner creates a prioritized wish list called a product backlog. During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces. The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum.) Along the way, the Scrum Master keeps the team focused on its goal.

42 The Scrum Framework an Introduction (cont d) At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder. The sprint ends with a sprint review and retrospective. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. On the next slide is a visual of the scrum framework, which is a central image in the Agile Manifesto.

43 Scrum Lifecycle Daily Scrum Meeting or Standup Daily Sprint, or Iteration Sprint Backlog Backlog tasks created by team 2-4 weeks Product Backlog as prioritized by the Product Owner [Potentially] Shippable Product Increment These items are not necessarily the same relative size

44 What is the Product Backlog? A significant component to the previous image is the product backlog. The product backlog is a prioritized list of work (can consist of User Stories and Bugs) to be performed on a product Product Owner responsible for prioritisation Anyone can contribute on backlog items Below is an example of a backlog as an information radiator, which is defined in a later module. Story To Do In Dev Test Complete As a User, I 8 points Code the 8 points Test the 5 points Test the 8 points Test the 5 points Test the 5 points Code the 9 points As a User, I 8 points Code the 9 points Test the 8 points Code the 9 points Test the 5 points Code the 9 points Code the 2 points As a User, I 2 points Code the 2 points Test the 8 points Code the 2 points Code the 2 points Test the 8 points Code the 2 points As a User, I 4 points Code the 8 points Test the 5 points

45 Confused Yet? Agile, XP, Scrum, etc. By now in this module (and before we go any further,) you should be familiar with a number of new terms but are likely not yet able to keep them all straight. The grid below helps you differentiate between the different terms each methodology uses, with Agile and XP being most similar to each other. Agile XP Scrum Agile Product Manager Product Manager Product Owner Agile Facilitator Coach Scrum Master Stories Stories Backlog Items Iteration Iteration Sprint Iteration Demo Iteration Demo Sprint Review Iteration Planning Iteration Planning Sprint Planning Release Planning Release Planning Product Backlog Standup Meetings Standup Meetings Daily Scrum

46 Scrum Team Characteristics Below are the main characteristics of an agile (scrum) team. You will become very familiar with these themes, as they are a central part of the agile framework and are covered extensively on the exam. Self-organizing Cross-functional Seven plus or minus two people Responsible for committing to work Authority to do whatever is needed to meet commitment The early days of scrum and agile used a metaphor of chickens and pigs to help explain the roles. The following slides introduce the concept. As you review the story, keep the above bullet points in mind.

47 Scrum Teams: A History Chickens and Pigs Prior to 2011, the Official Scrum Guide referred to certain team members as Chickens and pigs. Below is a history: During the month-long sprints, the team holds daily meetings-- the daily Scrum. Meetings are typically held in the same location and at the same time each day - ideally in the morning, as they help set the context for the coming day's work. Each participant in the Daily Scrum is known as either a chicken or a pig, depending on his involvement in the project. From Agile Software Development with Scrum. Schwaber, Ken; Beedle, Mike

48 Scrum Teams: A History Chickens and Pigs And here is how the mythical conversation would go: Chicken: Let's start a restaurant! Pig: What would we call it? Chicken: Ham n' Eggs! Pig: No thanks. I'd be committed, but you'd only be involved!

49 Chickens and Pigs: The Message In other words: pigs sacrifice their lives for the project, whereas chicken only have to give up their eggs. Today s Message: The concept of chickens and pigs may occasionally be used, but keep in mind this core takeaway: All team members of the project must own it as having skin in the game. In agile projects, it s expected that the team take an attitude of, We re in this together.

50 Chickens and Pigs Today The Official Scrum Rulebook 1 (October 2011) by Ken Schwaber and Jeff Sutherland removes this reference. Chickens have evolved to be known as the customer unit and pigs have evolved to be known as the development unit. Although the pejorative names are removed, the goals remain the same the team has shared responsibility and must function with the same goals. The following slide visualizes the various roles of the team 1:

51 Scrum Roles Team Members Scrum Master Users Scrum Roles Product Owner Stakeholders

52 Scrum Team The Team comprises a number of different subject matter experts and also includes customer-facing roles. The customer unit is not necessarily as heavily involved as the core development unit, yet all roles play a key part in the team. Customer Unit People who are involved but not dedicated to the project are known as Chickens - they may attend Scrum meetings as observers Customer Product Manager/ Product Owner Marketing Executives Client Services Development Unit Members of Scrum Team are known as Pigs because they are committed to delivering the Sprint Goal Developer Product Analyst QA IT Project Manager Graphic Designer Technical Writer

53 Scrum Team Roles and Responsibilities Product Owner Product Vision & Roadmap Manage product backlog Ranks and prioritizes the backlog. Set clear expectations for acceptance Provide necessary details at the appropriate time for Development Unit Communicate Development Unit Estimate Plan and commit for the iteration Execute the iteration Demo Communicate

54 Other components of an Agile Project On the following slides we ll discuss a number of key components, concepts and tools used by agile teams to succeed on their projects. The items are presented in this module as an introduction to what will be covered in greater detail in the subsequent modules. Ahead in the next module: The Scrum Master and their responsibilities. User Stories and how to estimate them. The Sprint Burn-down charts The Daily Scrum (standup) 54

55 Sprint Review Demo - during this meeting the team presents to management, customers, users and the Product Owner the product increment that has been built during the Sprint. Closeout - the Sprint is closed out. All work is marked complete. Retrospective - all good and bad things that happened during the Sprint are documented and taken into consideration for the next Sprint. PowerPoint presentations are forbidden!

56 Agile s Variations and Derivatives In the following slides we will review a number of agile s derivatives in greater detail. Not all of agile s variations are covered here on in the exam, and not all of them use every tool and technique presented in the previous section, but the key concepts covered in the exam are discussed. In particular, we ll cover Agile Modeling, Empirical Process Control, and Velocity Tracking.

57 Variations of Agile In the short lifespan of the Agile name, a large number of variations have emerged, each with their own rules and idiosyncrasies. Extreme Programming (XP) Scrum Agile Modeling Feature Driven Development (FDD) Open Unified Process (OpenUP) Rational Unified Process (RUP) Agile Unified Process (AUP) Essential Unified Process (EUP) Dynamic Systems Development Method (DSDM) Velocity Tracking Note: Not all of these variations are covered in this course, nor are they covered in the exam. For more information about each variation, click on the hyperlink symbol

58 Future Directions Just as this course will point out that Agile promotes the concept of continuous improvement, the framework itself continues to be evaluated and will likely evolve just as other exam specifications and methodologies have. One such variation of Agile that is gaining acceptance in large organizations is the Scaled Agile Framework The framework (pronounced SAFe ) is an interactive knowledge base for implementing agile practices at enterprise scale. It is intended to apply the disciplines of agile allow for repeatability from the smallest of teams to the largest of companies. For more information: Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) by Dean Leffingwell

59 Sample Exam Questions When is the best time for the project team to come together to review what went well and how they can improve next time? During the daily standup In the retrospective meeting The weekly Scrum summary meeting The team lunch Which of the following least describes the Agile development framework? Emergent Self-organizing Rigid Empirical An Agile team can best be described as Highly skilled professionals who refuse to provide documentation A cross-functional team that knows how to resolve conflict A well-organized team that is managed by a product manager A cross-functional team that avoids conflict through planning

60 Sample Exam Questions A story card is most likely to contain Assignments for the developer Identification of required velocity Specifics about the implementation of project The desired end result of the customer Which value is not used in estimating story points?

61 PMI-ACP Exam Preparation Module 2: Agile in Action Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 61

62 Module Overview This module takes a deeper dive into the day-to-day events of the Agile framework. We will present the specific tools, techniques and meetings used by the agile practitioner. Value-based analysis Introduction Value and quality with charters and incremental releases Value-based prioritization and agile projects Value-driven planning versus plan-driven planning Investment appraisal methods Regulatory driven Customer driven Prioritization methods (MMF, MoSCoW) 1. Value Stream Analysis Value-stream analysis Value-stream mapping 62

63 Module Objectives At the conclusion of this module, you should be able to: Assess Ways to Maximize Value and Minimize Waste Discuss How to Increase Value through Quality Compare Value to Anti-Value Interpret Release Early, Release Often Describe Value Stream Analysis Optimize the Value Stream Demonstrate Value-Based Prioritization Illustrate Financial Operational Efficiency 63

64 Scrum Roles Recall from Module 1 the specific roles on an Agile team The primary role responsible to the project in terms of leadership is the Scrum Master, which we will discuss on the following slide. Team Members Scrum Master Users Scrum Roles Product Owner Stakeholders

65 The Scrum Master The Scrum Master is responsible for The success of SCRUM Establishing SCRUM practices and rules, shielding the team and removing obstacles Representing management to the project Running the Daily Scrum. According to Schwaber and Sutherland in The Scrum Guide: The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. A strong Scrum Master is: A good situational leader A guru A friend to the team An artist and SME in Agile A servant leader

66 User Stories As the project commences, the scope of work comes from the product backlog, which we discussed in Module 1. But what determines what gets into the backlog? User stories are the backbone of what becomes a part of the backlog. It s a device used by agile to gather the requirements that are needed to eventually begin development of a feature. The user story is used to capture the customer s (or your internal stakeholder s) desired end result. Captures the Who, What and Why of a requirement in a simple way. It is the primary task of the product manager to ensure stories are captured. Information on a Story Card: As a: I want to: So that: One tool used is a simple document template called a Story Card.

67 Estimating User Stories Before the work can begin, estimates must be put against the user stories to allow for proper forecasting of the work. A user story is the start of the input for determining what to develop. But just as with other methodologies and disciplines, you must have an estimate of the work before you assign the work and provide a realistic timeline to your stakeholders. Teams use relative estimating to estimate the user story or product backlog The unit of measure is the Story Point Why not Man Hours? Your Product Manager speaks your stakeholders' language and should be able to translate between story points and man-hours (or other units) as needed. Teams use devices like the Fibonacci sequence (1,2,3,5,8) as the estimating standard for near-term work (sprints within current minor release) and 13, 20, 40, 100 to represent future work.

68 Estimating User Stories/Backlog Most User Stories will fall here. Represents full functionality that can be accomplished in a sprint. User stories in future major releases User stories in current minor releases Defects, small enhancements, etc. Large User Stories May or may not need to be decomposed further. Epic Level Team cannot estimate effectively given current Understanding of work. Very large user stories that the team can handle but will need to break down by decomposition.

69 Product Backlog Estimating Stories A B C D E Example: Consider five stories, each of varying size. In comparing the stories we want to determine a baseline first (i.e. A story worth 2 points). Looking at the 5 stories we would say that story D represents a size that is not the largest nor the smallest, so we will say story D is 2 points. Now that we have a baseline we can determine the points for the other stories: Stories C and E could be 1 point. Story A 5 is points, and story B is 13 points.

70 Estimating Tools: Planning Poker A technique that is common in the agile framework is the empowerment of the team to contribute to the estimating process. By using members of the team to collaborate on estimates, a more realistic picture emerges of the true scope of work and the time required to accomplish it. Planning Poker is one such method: Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. When considering the work effort, one must think in terms of ideal time that the work would take in an uninterrupted setting.

71 Sprint Once the work has been broken down and it s determined what will be addressed first, the work is packaged into a fixed unit of time called a sprint. The packaging of this work is known as Sprint Planning. Below are the characteristics of a sprint: A fixed period of nn days to develop a deliverable product. New teams should start with a smaller period such as 1 week, and then move up accordingly. The Sprint includes design, coding, testing, and documentation; as well as build and deploy. Once a Sprint has started only the Scrum Team can add or remove items in Sprint backlog. No interference, even from the VP or CEO of the company, should be allowed to interrupt a sprint or add work. The Sprint Goal is to complete all items in the Sprint Backlog and demo them when sprint completes. Abnormal termination of Sprint is called for when the Sprint Goal no longer makes sense.

72 Sprint Any work not accomplished in the sprint is sent back to the sprint backlog, which is used as an input for the next round of sprint planning. Sprints are iterations in fact, you will see terminology such as Sprint Planning and Iteration Planning. These terms are equivalents of each other. The following slide shows the lifecycle of a sprint and its components.

73 Anatomy of a Sprint Sprint Retrospective Sprint Planning Sprint Review 2-4 week duration Part of Product backlog becomes Sprint backlog. Release every sprint Daily Scrum every 24 hours

74 Sprint Planning The Goal is to create a Sprint Backlog Determine resource availability Review Stories by priority Stories are broken down into tasks Team members pick tasks based on availability, knowledge level, and length of sprint Team provides actual estimates for the tasks Team ensures all work can be completed within the Sprint On the following slide is an example of a sprint backlog as an output of the planning process.

75 Example of the Sprint Backlog Story one - 40 points Financial analyst wants to see six quarters into the future and two quarters in the past so that she can view results and forecasts in the same screen. Story two - 5 points A gift giver wants to see which items their recipient has already received from his registry so that he does not end up buying him a gift that has already been purchased. Story three 8 points A Tier-I customer support rep needs to see all open trouble tickets in one single page sorted by oldest modified date so that he knows which issue should receive the next assignment. Always compare estimates with each resource s availability to the Sprint to ensure all work can be completed. Units of Value Stories are estimated in a unit of points, using the Fibonacci sequence as we showed earlier. The tasks and the effort required to complete the story will not list hours as a unit of value, although efforts such as planning poker will generally cause you to think of the effort involved when estimating your stories.

76 Burn-down Chart The agile burn down chart is essential for a team to see what progress is made during each sprint. The goal is to burn down the work and track actuals against the plan, culminating at the end of the time-boxed sprint with no remaining tasks Remaining Effort Planned Actual Iteration Timeline/Sprint 76

77 Daily Scrum Meeting A key component in the successful tracking of the execution of a sprint is known as the Daily Scrum meeting. On each day of a sprint, the team meets preferably at the same time of day and in the same room every time and reviews the progress of the project. If you recall the analogy of the chickens and pigs in module one, you know that agile places emphasis on the importance of committed individuals on the project Only committed team members are permitted the chance to speak and interact in the daily scrum, which means only the direct team may attend and speak in the daily scrum. It is not a meeting for stakeholders or casual observers to attend. On the following slide is a listing of the key characteristics of the daily scrum.

78 Daily Scrum Meeting Daily 15 minute status meeting Also known as the stand up meeting Team stands in a circle facing each other Each team member answers 3 questions: What have you done since yesterday? What will you do by this time tomorrow? Is there anything you need help resolving? Use of the Sprint Burn-down chart is a key tool used In the meeting. A reminder that other Agile methodologies may refer to the Daily Scrum as the Daily Stand-up Meeting.

79 Things to Watch out for in the Daily Scrum To prevent a loss of momentum, the following situations should be mitigated: External stakeholders should not be allowed in the meeting. If they arrive unannounced, they should be asked to observe only, not to speak. Although the team is empowered to make decisions, groupthink should not occur, nor should they make technical decisions without the agreement by the appropriate domain expert. Direct requests for status from external stakeholders risks impeding the structure and intent of the daily standup. The product backlog should be reviewed regularly. So too should the burndown chart. If this data is not referenced in the meeting, there is a risk that the team will lose focus during the sprint. 79

80 Additional Agile Tools and Techniques In the following pages we showcase a number of options that are available to an organization as they consider adopting Agile. Note that not all of these tools and techniques are mandatory components of the framework; some companies may choose to use them or other variations. In Module 8 we discuss the concept of Method Tailoring, which actually encourages the use of variations.

81 Agile Modeling Agile Modeling (AM) is both a management style and a system of discipline used for effective modeling and documentation of software-based systems. It is not a complete software process but it does complement the agile framework with recommendations for effective communication and documentation tools. The term was coined in 2002 by Scott W. Ambler in his book, Agile Modeling: Effective Practices for extreme Programming and the Unified Process. Ambler continues to evolve the concept on his web site, Ambler states that it s an art, not a science, that s a collection of values, principles, and practices * for modeling software that can be applied on a software development project in an effective and light-weight manner Assumes simplicity and embraces change. There are a number of specific best practices in the use of agile modeling, which are discussed on the next slide. References: Agile Modeling: Effective Practices for extreme Programming and the Unified Process. Ambler, Scott W. John Wiley & Sons, 2002.

82 Agile Modeling Characteristics Active stakeholder participation with a high return on investment (ROI) Stakeholders are expected to engage in a timely manner. The Unified Modeling Language (UML) is suggested as one such tool for modeling Initial architecting of the solution to achieve a high level vision. Iteration Modeling - The idea is that during the start of the iteration, you do just enough get-ahead work to confirm the design. Just Barely Good Enough items building a model or document that is just sufficient enough for the situation and no more. Ambler suggests to model with a purpose. Lookahead modeling Complex requirements may require initial investigation well upstream to reduce overall project risk. Model storming Reviewing a deliverable during an iteration to explore the details of a requirement.

83 Agile Modeling Characteristics Multiple models Using the right model for the right situation at hand. Since software can be complex, it is suggested that no one model can comprehensively address the entire solution. Prioritized Requirements Requirements Envisioning Taking time to review the scope and determine the prioritization. Test-Driven Development Writing a small test and then immediately develop just enough to be able to perform the test. Agile Modeling is a discipline that is still under development. The key text is referenced here: Agile Modeling: Effective Practices for Extreme Programming and the Unified Process John Wiley & Sons ISBN#:

84 Empirical Process Control Empirical process control is used by scrum through a process of frequent inspection and adaptation. Because our business reality includes processes that are not always perfectly defined, and can generate unpredictable results, adaptable and iterative frameworks such as agile still rely on controls. There are three key elements in the model: Transparency: The parts of the process that affect the outcome must be openly observable at every step until delivery to the customer. Examples of this used in scrum include information radiators (presented in an upcoming module,) a publicly viewable backlog, and sprint reviews and retrospectives. Inspection: The process by which you take your observations from the transparent information and envision how the product performs in the business workflow. Deliverables must be inspected frequently so that variances can be detected. Adaptation: The process by which you make adjustments based on your inspections, and then making those adjustments serve as continuous improvements. Reference: Schwaber, Ken; Beedle, Mike (2002), Agile Software Development with Scrum, Upper Saddle River: Prentice Hall, ISBN

85 Velocity Tracking The word velocity is often used during an agile project. The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed. Terms used in Velocity Tracking Unit of Work The unit chosen to measure relative progress among the team. Units of work can either be abstract like story points or they can be more specific, such as hours. Note, however, that the use of hours is generally discouraged in agile. Interval The interval is the duration of each iteration in the development process that we are measuring velocity against. The ability to measure velocity improves after a number of iterations are completed. We will cover velocity in greater detail in subsequent modules.

86 Module Summary: Key Concepts and Recommendations Agile places a lower priority on tools than on work and communication. Agile embraces change while you are working, and is an antithesis to the waterfall methodology. Because it is so dynamic, you must gather rapid feedback on your work. Adapt your use of Agile to meet the needs of your company s environment. Central components of agile and scrum are: User Stories Iterations/Sprints The Scrum Master The concept of a collaborate team that shares ownership and responsibility.

87 PMI-ACP Exam Preparation Module 3: Value Driven Delivery Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 87

88 Module Overview This module focuses on the PMI-ACP exam s Value Driven Delivery framework, including the role of value-based tools and techniques in bridging traditional project management with agile. In this module: 1. Value-based analysis Introduction Value and quality with charters and incremental releases Value-based prioritization and agile projects Value-driven planning versus plan-driven planning Investment appraisal methods Regulatory driven Customer driven Prioritization methods (MMF, MoSCoW) 2. Value Stream Analysis Value-stream analysis Value-stream mapping 88

89 Module Overview - continued 3. Prioritization Prioritization models Determining what to measure and track Methods of measuring/tracking/prioritizing Adding value with metrics 4. Incremental Delivery 5. Quantifying Value - financial measurement techniques Net Present Value Internal Rate of Return Return on Investment Payback Periods 7. Sample exam questions 89

90 Module Objectives At the conclusion of this module, you should be able to: Assess Ways to Maximize Value and Minimize Waste Discuss How to Increase Value through Quality Compare Value to Anti-Value Interpret Release Early, Release Often Describe Value Stream Analysis Optimize the Value Stream Demonstrate Value-Based Prioritization Illustrate Financial Operational Efficiency 90

91 1. Value Based Analysis - Introduction Value based analysis is a combination of financial modeling and strategic decision making that was introduced in the late 1990s. It was originally developed to serve as a model for managing investment in reusable software and has subsequently been modified to apply to different types of IT investments. Concepts to keep in mind in this section: Agile emphasizes value over waste. If something is not in the value stream it is aggressively taken out or minimized. Waste is considered Anti Value. Operating under an agile or lean model (discussed in an upcoming module) supports value based analysis, which requires certain quantitative measurements (which are covered later in this module.) We will continue to contrast Agile with Waterfall. In this module we focus on plan-driven versus value-driven planning. For more information: 91

92 Value Based Analysis Key Concepts Whereas the agile discipline focuses on clarity at the operational level, Value Based Analysis (VBA) adds to it by striving for clarity in the marketplace. In Agile, VBA addresses improvements in process designs, processes and systems. Value based analysis ties together the benefits of the agile discipline and asks if the improvements can be delivered without reducing the customer s expectation of quality, yet still be delivered at a profit to the company. The image on the following page shows how different the end result is between value-driven and plan-driven planning. 92

93 VBA: Value-driven versus Plan-Driven Planning Fixed Requirements Resources Time Waterfall Agile In comparison with waterfall, agile flips the triangle in terms of what s fixed and estimated. Value Driven Plan Driven Estimated Resources Time Features 93

94 VBA: Value-driven and Plan-Driven Planning Recall the difference between Agile and Waterfall disciplines. Value driven planning is an adaptive discipline, whereas plan-driven planning is a predictive approach. Plan-driven approaches work hard to enforce scope while value-driven approaches embrace scope change and address in iterative releases. In contrast of the tight controls over the schedule and scope with waterfall, agile turns the concept upside-down and uses collaborative teams and clear visibility into progress to focus on the rapid delivery of value. 94

95 Value Driven Planning Value Driven Planning focuses on achieving results as quickly as possible, with less intense wins occurring over time. The largest amount of value is addressed first, as is shown below. Value Pay particular attention to this image; we will revisit it later in the course as we discuss Just Barely Good Enough. Performance 95

96 Plan Driven Planning Plan Driven Planning focuses on realizing targets and milestones of completion instead of incremental delivery. It is possible to not see any delivery at all until a first milestone release well into the project. Task lists assembled from the project schedule assist the team in reaching the overall project objective. This is also known as the Work Breakdown Schedule (WBS) Plan Driven planning is very often used in the Waterfall methodology. Value A rigorous schedule, change control process and risk mitigation strategy exists in this stage to help the project reach the finish line, but no incremental deliveries occur. Release Milestone Performance 96

97 Determining Value Value is the relative worth of something in comparison to other items. In value driven planning under Agile, the value of a feature is related to the relative return on investment (ROI) in relation to other prioritized features. To deliver value, the feature or product must be relatively greater in its ratio of value and cost compared to the current state. High value at a high cost may not be treated by the customer as high value. The higher the ratio, the higher the value. Value = Benefits Cost Note that value may be very subjective in the eyes of the customer. The agile practitioner should always be mindful of the customer s requirements. 97

98 Types of Value Keep in mind that value can be many things to different people. Although cash flow and revenue are important to a company, consider these examples. Type Definition Example Intrinsic Extrinsic or Instrumental Market Book An objective, actual value that has the same value or price among people. A subjective value placed on an item due to some external event or personal experience. The value of an object that others are willing to pay for in competition. The value as placed by an objective third party. Commodities such as precious metals Mementos; family pictures Artwork on the secondary market. Kelly Blue Book value of a used car. 98

99 Anti Value and Risk Mitigation Consider that issues and risks exist as potential negative or anti value against your product, which should always be intended to add value. Risks erode value and should be mitigated. By minimizing risks (or anti value, ) you concurrently maximize the products value. Anti value is the antithesis of value. Consider these examples: Value Water-tight boat hull epoxy Fuel efficient gasoline High strength concrete Bug-free product code Anti Value Cracks in the hull Rogue particulates from the refinement process Ineffective pouring methods Incomplete code branches at launch 99

100 Quality Management in Agile Processes Since agile is a focus on frequent and early progress and value to the customer, you must include quality control in every phase of development, rather than just a distinct phase of the project. Because your product is developed iteratively, every change to it should be considered potentially harmful to its end state. Tools at your disposal are Verification and Validation: independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. Validation Verification The assurance that a product, service, The evaluation of whether or not a or system meets the needs of the product, service, or system complies customer and other identified with a regulation, requirement, stakeholders. It often involves specification, or imposed condition. It acceptance and suitability with external is often an internal process. Contrast customers. Contrast with verification. with validation From A Guide to the Project Management Body of Knowledge (PMBOK Guide) 4 th edition 100

101 2. Value Stream Analysis Value stream analysis is a technique used to analyze and design the flow of materials and information required to bring a product or service to a consumer. It takes an overarching view of the entire product and its lifecycle to ensure that waste is eliminated everywhere that it occurs. In this section we will: Explain the value stream Show how to map the current state of a value stream Guide you through the process of improving the value stream using agile tools and techniques. 101

102 Value Stream Analysis Value Stream Defined: A value stream is described as any process where materials or information flow to bring a product or service to a consumer. It is the sequence of steps in the production workflow, from start to finish. Value Stream Analysis Defined: Value Stream Analysis is a business process planning event driven by changes to customer demand or as part of a regular review cycle and is a key tool in the development or enhancement of a process. It provides a documentable standard for the continuous improvement process. Value Stream Mapping (VSM) is a process tool that arose from Lean (which we will cover in a subsequent module) that can help teams get an understanding of where some of their biggest problems are. When done correctly, value stream maps are produced by collaborative, high touch/low fanfare sessions that can lightly apply a structured discipline to identify waste and potential areas for improvement. Your goal as agile Practitioner: continually add value at every step until your work is complete Reference: 102

103 Creating a Value Stream Map (1 of 3) Creating a VSM provides the agile practitioner the ability to find opportunity to eliminate waste and improve process efficiency. Consider the example of purchasing a car: 1. Identify the starting point of the process (who initiates) it and the end point (who gets the end result) of the process. You You in your car 2. Identify the high level steps, inventories and queues through the process focusing on the primary flow You Car Selection Financing application Closing You in your car 103

104 Creating a Value Stream Map (2 of 3) 3. Identify any supporting groups and alternative flows. Think about what happens if there is re-work or a change of plans. Denial of financing: Look for a different model You Car Selection Financing application Closing You in your car Dealers Sales Keep in mind that the value stream rarely is point-to-point with no iterations or alternate branches. Be mindful of this as you perform a real-life map. 104

105 Creating a Value Stream Map (3 of 3) 4. Measure the Value Adding and Non Value Adding activities, calculate efficiencies, identifying waste, bottlenecks and improvement actions. You Car Selection Financing application Closing You in your car Dealers Sales Value Add Non Value Add 4 hours 1 hour 2 hours 1 hour 1 day 1 hour 1 hour Total Cycle Time = Value Add + Non Value Add Time Process Cycle Efficiency = Total Value Add Time Total Cycle Time Total Cycle Time = 11 hours Process Cycle Efficiency = 8 11 =73%

106 Value Stream Mapping Other Considerations In the preceding example, consider other options or scenarios. For instance: Think of the supply chain between Sales and Operations groups. Current state process maps that your company uses to document internal service levels. In the world of software management, think about the value stream that s involved with software upgrades and patches. Can your current state be optimized following a mapping of its value stream? 106

107 Ways to Optimize the Value Stream Emergent Design Emergent design is intended to deliver small chunks of deliverables with business value. Once a number of iterations has occurred, the commonality is reviewed to establish a final design. Consider the following: A development organization starts delivering functionality and lets the design emerge. Development will take a piece of functionality A and implement it using best practices and proper test coverage and then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what A and B have in common and refactor out the commonality, allowing the design to emerge. Acceptance Testing: An acceptance test is a formal description of the behavior of a software product that is intended to confirm if the requirements or specification are met. Acceptance testing typically expressed as an example or a usage scenario. In agile, writing the test precedes writing the code. In a subsequent module we will discuss Test Driven Development. For more information on Emergent Design: See this Wikipedia article: 107

108 Tools Used to Optimize the Value Stream When optimizing the value stream of software, you ll often use key terms such as these below: Cycle Time: The number of days needed between feature specification and production delivery. A shorter cycle indicates a healthier project. Lead Time: The time between the initiation and delivery of a User Story Other Tools In the following slides we showcase a number of agile concepts and tools used to measure and optimize the value stream. These include Just In Time and its use of Kanban signals. 108

109 Just in Time (JIT) Just in Time is a production approach that is intended to improve ROI by reducing in-process inventory and associated inventory and overhead costs. JIT is used by Agile teams as a mechanism to achieve continuous improvement. Relies on signals, or Kanbans, to alert the production team of what s needed next. Goals of JIT in Agile 1. Eliminate Waste 2. Utilize a pull-type system of demand 3. Reduce lot size, coding handoffs and rework 4. Zero defects 109

110 Kanban Kanban is a scheduling system used in Lean and Just It Time production so that inventory levels can be aligned with consumption. Controls the production chain to ensure that not too much or too little of something is produced. Is not an inventory control system. Advantages: Dramatically reduce inventory levels Increase inventory turnover Enhance supplier/customer relationships Improve the accuracy of manufacturing schedules. How it Works Signals are used to tell the producer what to produce, when to start, and what the quantity should be. 110

111 Kanban Cards and Boards The Kanban card serves as the signaling device to alert producers what to produce, in what quantity, and when to begin production. A Kanban board visually presents the supply chain showing individual statuses. Today, ERP systems such as SAP, Oracle and others use workflows and notifications to generate the production signal. 111

112 3. Decomposition Let s face it: businesses are complex. Software is complex. A user s requirement is complex. The opportunity to miss the requirement is large. Agile places emphasis on incremental delivery and Rough Design Up Front (versus Big Design Up Front,) but the agile practitioner still needs to be sure that the right features are being developed. A key process used by agile that allows the team to function in a way that adds value to the project comes by way of decomposition of the elements of requirements, known as user stories. Decomposing a requirement involves taking the result your user is looking for (stated as a User Story) and breaking it down into a number of tasks that the team can work on individually. 112

113 Decomposition Techniques in Agile Recall from Module 1 that a user story is a requirement of a system to be developed, written in a simple format such as, As a (User Role) I want (goal) So that (business value) Each user story must be estimated by the team and prioritized, but it must also be small enough to be delivered in a sprint. This is a necessity if you want to achieve real benefits in terms of value delivery, visibility, flexibility, feedback and continuous improvement. In the following slides we present a process by which you can break down a user story into the tasks necessary to be delivered in a sprint. 113

114 Decomposition Steps There are a number of ways in which you can organize and decompose your stories: Treat the user story like steps in a workflow Getting from Point A to Point Z usually requires a review of the steps (or workflow) in a process, and it s rarely if ever a straight line. A business requirement or user story can likely be broken down into smaller steps so that it can be developed incrementally. Each step might be a separate user story. Turn the story into a scenario The story may have come to you representing only the most likely or obvious path to the end state. Think about other people who play the role of your user. Consider using branch logic to be sure that other scenarios involved in getting to the end state are accounted for. You can also use a persona (reviewed later in this course) to ensure that every aspect of the user story is accounted for. 114

115 Decomposition Steps Sequence your Scenarios Place your stories and their scenarios into sequence so that you can reach greater precision and improve the planning process. Follow-on features would then likely be more apt to be chosen for development in later sprints. Split your story into operations One of the best ways to decompose is to split the story into operations. In software development, features involving Create, Retrieve, Update, Delete (CRUD) operations are an excellent way to reduce the story into smaller pieces because you can do so in a repeatable fashion. Separate your story by sizes or type Your story may be prone to being broken up either by language or by a unit of measure that is conducive to having separate pieces. 115

116 Decomposition Steps: Using Personas When documenting a user story, a powerful tool to help ensure that all requirements are met is to use a persona. A persona is a personalized, yet fictitious account of what the archetypical user might be like when using your product. Some characteristics of personas in Agile: Personas are representative of people, but they are not living, named people. A benefit is that personas are more specific that role-based use cases. For instance, bank teller would not be a persona. Judith McNight, 63, 10-year veteran teller at ABC Bank would be the start of a persona. The persona is personalized and often reads like a biography of a fictional person. The persona is meant to allow for personality and background types of the users. In the example of a bank teller, you would want to create multiple personas in order to ensure you ve captured all requirements. It is common to include clip art of an individual to help personalize the persona even more.

117 Other Decomposition Steps Levels of complexity or knowledge You can break down your stories by either the knowledge that is acquired on a feature or by the level of detail that a user consumes the product. Consider software where users make use of only 80% of the features, yet advanced users of the software use 100% of the features as super users. The latter group would likely involve a separate story to document. Separate your story by expected quality Elements of expected user satisfaction will help you determine how fine to break down the user stories. Concepts such as performance or usability are often not directly spoken and referenced in the story, but the connotation is there. Reference: 117

118 4. How Do you Know what to Build? In order to deliver incremental releases of value to the customer, it s necessary to have your finger on the pulse of the client. This will help you determine not only what to build, but in what priority. The agile practitioner must constantly strive to place emphasis on the value to be delivered to the customer. 118

119 Positive Value The Voice of the Customer The Voice of the Customer (VOC) is a market research technique developed in the 1980s by Professor Noriaki Kano. It classifies customer preferences into five categories that produce a set of customer requirements, organized into a hierarchical structure, and is then prioritized in terms of relative importance and satisfaction. Feedback loops are an important part of an agile team s arsenal. By prioritizing features based on customer requirements, positive ROI can result from product development. One tool to measure the VOC is the Kano Model, whose goal is to determine overall customer satisfaction. The Kano model offers some insight into the product attributes which are perceived to be important to customers. We will review the Kano model in an upcoming slide. 119

120 Customer-Value Prioritization Approaches Prioritization is a major concept of agile practice. Prioritization determines the order the agile team will work on the requirements. Prioritization models include: MoSCoW prioritization Must - The must requirements is given the top most priority Should -Next priority is given to the requirements that are high desirable, though not mandatory Could - The next priority is given to the requirement that are nice to have Won t -The final consideration is given to the requirements which will not work in the process at that point of time. (This is also known as Would, and always receives the lowest rank order.) The relative weighting method Relative weighing scheme is a simple model where prioritization is done based upon all the factors mentioned below. Benefit from having the feature Penalty for not having the feature Cost of producing the feature Risk incurred in producing the feature 120

121 Customer-Value Prioritization Approaches Kano Model of Prioritization This prioritization technique leverages the three attributes of Basic Expectations, Performance Payoff and Excitement Generators that take customer satisfaction from disappointment to not happy to getting delighted. Attractive Quality Provides customer satisfaction when achieved fully, but does not dissatisfy when not achieved. These attributes are not normally expected. One-Dimensional Quality Provides customer satisfaction when fulfilled and dissatisfaction when not fulfilled. Must-Be Quality Attributes are taken for granted when not fulfilled but result in dissatisfaction when not fulfilled. Indifferent Quality Attributes that are neither good nor bad, and do not influence customer satisfaction or dissatisfaction. Reverse Quality A high degree of product that does not satisfy every customer, as individual expectations are different. The Kano Model uses two questionnaires and an evaluation table to classify the requirements into categories. Reference: More information on the Kano model can be found in this Wikipedia article: 121

122 The Kano Model of Customer Satisfaction Customer Satisfaction Low High Product is dysfunctional Absent Customer fully satisfied Customer Indifference Customer dissatisfied Quality Excitement Basic Needs Performance Needs Product fully dysfunctional Provided

123 Qualities of Desirable VOC Data Credibility: How widely accepted is the measure? Does it have a good track record of results? Is it based on a scientifically and academically rigorous methodology? Will management trust it? Is there proof that it is tied to financial results? Reliability: Is it a consistent standard that can be applied across the customer lifecycle and multiple channels? Precision: Is it specific enough to provide insight? Does it use multiple related questions to deliver greater accuracy and insight? 123

124 Qualities of Desirable VOC Data Accuracy: Is the measurement right? Is it representative of the entire customer base, or just an outspoken minority? Do the questions capture self-reported importance or can they derive importance based on what customers say? Does it have an acceptable margin of error and realistic sample sizes? Actionability: Does it provide any insight into what can be done to encourage customers to be loyal and to purchase? Does it prioritize improvements according to biggest impacts? Ability to Predict: Can it project the future behaviors of the customer based on their satisfaction? From Ernan Roman, ERDM.com (2010): Voice of Customer (VOC) Relationship Research 124

125 5. Incremental Delivery A key difference between Agile and Waterfall is the delivery of product in incremental segments, rather than all at once in a major release from Waterfall. Incremental delivery creates quick wins for the customer and provides opportunity to course correct if requirements were not adequately captured. In the upcoming pages we will present an in-depth look at incremental delivery. 125

126 The Importance of Incremental Releases Agile teams should release products and software as early as possible and during frequent iterative releases. This mitigates risks, gets products to market earlier, and keeps your stakeholders engaged. The longer a project is run, the greater the risk of failure, changed requirements and lost opportunities. Incremental delivery allows the customer to be engaged in the development process to ensure that they get the product they want. Incremental delivery allows for higher long-term value (next page.) 126

127 Incremental Delivery Compared to a Waterfall approach, incremental delivery provides quick wins and a steady stream of value add. Long-term value increases as a result of planning. Value Solid lines represent releasable deliverables to the customer. ROI remains high in the early stages of planning Time 127

128 6. Quantifying Value At the start of this module we mentioned that it s not enough to deliver product in a lean, efficient way to produce value. We need to be able to deliver value to the business and executive stakeholders, who are interested not in the number of backlog items worked down but in the financial and strategic value to the customer or the firm. In other words: if you can t measure it, you can t manage it. To know you are delivering value, you need to know now to measure the expected value. In the following pages we review a number of methods used to quantify value to the business. 128

129 Net Present Value (NPV) Net present value (NPV) or net present worth (NPW) of a time series of cash flows, both incoming and outgoing, is defined as the sum of the present values (PVs) of the individual cash flows of the same entity. A positive NPV means that the project is expected to add value to the firm and will therefore increase the wealth of the owners. Calculates how much money you must invest today to realize a specific amount tomorrow. Since our goal is to increase owner wealth, NPV is a direct measure of how well this project will meet our goal. Given the (period, cash flow) pairs ( t, R t ) where N is the total number of periods, the net present value is given by: Decision Rule If the NPV is positive, accept the project

130 Internal Rate of Return (IRR) Internal Rate of return is a rate of return used in capital budgeting to measure and compare the profitability of investments. It is also called the discounted cash flow rate of return (DCFROR) or the rate of return (ROR). IRR is the return that makes the NPV = 0 This is the most important alternative to NPV It is often used in practice and is intuitively appealing It is based entirely on the estimated cash flows and is independent of interest rates found elsewhere Decision Rule Accept the project if the IRR is greater than the required return

131 Return on Investment (ROI) Return on Investment (ROI) is a performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. It is one way of considering profits in relation to capital invested. Measures how quickly the project expense will result in an increase in value. In Agile retrospective meetings, ROI calculations can measure the effectiveness of project duration (from development to release to market) Return on Investment formula (%) = Net profit / Investment 100 Decision Rule ROI has no concrete decision point, as it is a more subjectively used by companies.

132 Calculating a Payback Period A payback period is a the amount of time required to earn back the initial project investment. Payback periods are usually expressed in years. Payback period is easy to use and simple to understand, but has significant limitations and should not be used alone for making decisions. Calculation: Payback Period = (p - n) p + n y = 1 + n y - n p Where n y = The number of years after the initial investment at which the last negative value of cumulative cash flow occurs. n= The value of cash flow at which the last negative value of cumulative cash flow occurs. p= The value of cash flow at which the first positive value of cumulative cash flow occurs. Advantages Disadvantages Easy to use and understand Ignores time value of money, opportunity cost, risk and financing Useful in relative comparisons to other payback periods Should not be used in isolation Decision Rule As a stand-alone tool to compare an investment to "doing nothing, payback period has no explicit criteria for decision-making

133 Discount Payback Period The discounted payback period formula takes into account the time value of the money. In contrast, a normal payback period formula just uses the initial cost of investment and the amount of time it will take to recover the cost. A discounted payback period formula discounts the amount recovered, resulting in a longer payback period. The formula: years of full recovery + cumulative cash flow/unrecovered Citation: 133

134 Sample Exam Questions Which equation most accurately expresses value? Value = Benefits/Cost Value = (Benefits-Cost) Value = Benefits x Cost Value = Benefits (2 x cost) Which of the following best describes an agile methodology for modeling software systems? Extreme Programming Agile UML Agile Modeling OpenUP The CEO is visiting the factory floor and is curious what product the supply chain owner is soon to be in need of reordering. What should he look for? The results of the latest decomposition analysis. Kanban board The latest ROI analysis The product backlog

135 7. Sample Exam Questions A Scrum Master understands that: The project baseline cannot change. User stories properly decomposed will result in a project with little or no change. Changes on a project should be held back for a future release. Change on a project is inevitable Which statement is true? Incremental delivery always exceeds waterfall-based delivery Incremental delivery is more expensive than delivering a single, major release. Incremental delivery allows for changes and missed requirements to be caught as early as possible. ROI is low in the early stages of incremental delivery.

136 PMI-ACP Exam Preparation Module 4: Stakeholder Engagement Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 136

137 Module Overview This module focuses on the PMI-ACP exam s Stakeholder Engagement knowledge domain, which focuses on emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution and servant leadership In this module: 1. Stakeholder needs 2. Stakeholder involvement 3. Stakeholder expectation 4. Sample Exam Questions 137

138 Module Objectives At the conclusion of this module, you should be able to: Identify and engage effective and empowered business stakeholders who are engaged with the team in order to ensure that the team is knowledgeable about an agreed, prioritized feature set reflecting all stakeholders interests. Identify and engage all stakeholders (current and future) by promoting knowledge sharing early and throughout the project to ensure the unimpeded flow of value throughout the lifespan of the project. Establish stakeholder relationships by forming a working agreement among all stakeholders to promote effective collaboration and participation of stakeholders on project activities. Maintain proper stakeholders involvement by continually assessing the changes in the project and organization that affect the stakeholder landscape in order to ensure new stakeholders on the project are appropriately engaged. 138

139 Module Objectives (continued) At the conclusion of this module, you should be able to: Establish and maintain a shared understanding of success criteria, deliverables and acceptable trade-offs by facilitating awareness among stakeholders in order to align expectations and build trust. Communicate team progress and development capabilities in order to help the business stakeholders make informed decisions about scope, time, and cost. Manage stakeholders expectations around minimal/most likely/optimal project outcomes, balancing accuracy and precision, so stakeholders have greater assurance that those outcomes will help them meet their business objectives. 139

140 Section 1. Stakeholder Needs Most project management disciplines adhere to strong stakeholder management directives. It is no different for the agile practitioner. But what is a stakeholder, and what are their needs? In this section we ll identify: Identify who are the stakeholders. How to practice continuous engagement with your stakeholders. Best practices for communication and collaboration with your stakeholders. 140

141 Who are the Stakeholders? Stakeholders can be anyone on the project, either internal or external to your organization. Identify as much information about your stakeholders as is necessary so that you can determine their potential support. You should identify all of your stakeholders as being neutral, a supporter, a negative influence or one with a certain vested interest on the project. Customers Community Colleagues 141

142 Why is Stakeholder Participation Important? People are generally not very good at defining what they want, but they are good at indicating what they think they want and what constitutes a successful product. One key necessity in working with your stakeholders is to establish requirements: As opposed to Waterfall where Big Design Up Front (BDUF) can lead to a If you don t ask for it you won t get it approach, Agile involves stakeholders in a different way: It is much easier to fix a requirements bug in the requirements phase than a bug in the development phase. Sufficient design is completed up front to provide a framework on which to build in the design detail as the project progresses. This is known as Rough Design Up Front (RDUF.) 142

143 Empowering your Stakeholders As opposed to other project methodologies for project managers where stakeholder management is recommended, the agile practitioner should engage in stakeholder empowerment. An engaged stakeholder is more likely to help keep the project on course. A key principle of Agile is live communication. It s important to note that face-toface communication is always the preferred mechanism. This is true with empowerment of any stakeholder. Express with your stakeholders that business involvement is critical throughout the project. You can also empower your business stakeholders by inviting them to design reviews and retrospectives. Better PM.com / Innate Images, LLC 143

144 How can a Stakeholder Raise an Issue? Stakeholder empowerment can be encouraged by promoting the following tools and processes: Use stand-up meetings to discuss the product backlog (shown below) Retrospectives are a good way to communicate and improve for next time. Issues may be placed on a visible task board for all to see. But the stakeholder should NOT attend the standup meeting unless they are a team member. Story To Do In Dev Test Complete As a User, I 8 points Code the 8 points Test the 5 points Test the 8 points Test the 5 points Test the 5 points Code the 9 points As a User, I 8 points Code the 9 points Test the 8 points Code the 9 points Test the 5 points Code the 9 points Code the 2 points As a User, I 2 points Code the 2 points Test the 8 points Code the 2 points Code the 2 points Test the 8 points Code the 2 points As a User, I 4 points Code the 8 points Test the 5 points Better PM.com / Innate Images, LLC 144

145 Stakeholder Roles Stakeholders can be aligned to specific roles on the project, but keep in mind it s not always easy to immediately identify all stakeholders at the onset. As you identify your stakeholders: Align them to the proper roles of the project: advisor, lead architect, core end users, team member, etc. Determine what is needed from each stakeholder. Determine what each one brings to the project, and what is required to keep them empowered. The primary role they play is in keeping the project on course through what was chartered. This ensures that maximum value is secured from the product. Better PM.com / Innate Images, LLC 145

146 Help your Stakeholders Ensure Value Keep your stakeholders empowered so that they may provide maximum value for your project. Prioritize your deliverables so that high ROI is derived from the input of your stakeholders. Remember: Multiple stakeholders may yield multiple priorities. Make sure you have identified your stakeholders by role, by influence and by expectations. A prioritized list will ensure that incremental delivery and value is achieved while providing your end users with the right solution to their needs. Reference the value stream and map your stakeholders to each phase of it. By ensuring close and frequent communication, feedback loops in every phase of the value stream allow for the proper management of change. Better PM.com / Innate Images, LLC 146

147 Types of Stakeholders 1. Business Sponsors, executives, a steering committee 2. The Customer - Product Management Group or product owners 3. Domain Experts and Subject Matter Experts 4. Developers Codes, Testers, QA, etc. 5. The End User In the following pages we will identify what each user brings to the project. Better PM.com / Innate Images, LLC 147

148 Who are stakeholders? (cont d) Example of the relationship between the stakeholders and the project: Portfolio Manager Other Stakeholders Project Stakeholders Sponsor Operations Management Functional Managers Project Team Program Manager PMO Project Management Office Project Management Team Project Manager Other Project Team Members Users/ Customers Sellers/ Business Partners The Project Source: A Guide to the Project Management Body of Knowledge (PMBOK Guide ), 5 th Edition (2013 Project Management Institute, all rights reserved)

149 Types of Stakeholders The Business The business sets the scope of the project. 1. Determinations are made on market coverage and financial objectives. 2. The business has a wide range of users to draw from to ensure the right scope decisions are made. 3. The business will make key decisions on what to develop versus what to acquire The business is incented to increase its market share through maximizing value to the customer. Better PM.com / Innate Images, LLC 149

150 Types of Stakeholders The Customer The customer s role is to ensure that the goals of the project charter are met. They put forward the business case required to launch the project. The customer is not the end user. The customer s focus is on ensuring that the needs of the business are met on time, within budget, and within scope. The customer is therefore a likely engaged stakeholder to the agile discipline. They are highly vested in ensuring that the process supports success. The customer is among the very first set of stakeholders that you will engage in the project, as they will be necessary to support the tools and processes as they champion the agile discipline to others. Your customers are incented by seeing the possibility of bringing new products to market, which improves their standing in the organization. Better PM.com / Innate Images, LLC 150

151 Types of Stakeholders Domain Experts These people are the technicians and the subject matter experts of the project. They are the people the business turns to with the expectation of knowing the technical solutions to solve a business need. The Product Manager is one of the trusted domain experts on the project. As an agile practitioner, be sure to keep the domain experts communicating on an equal footing. Problem domain experts and solution domain experts may require active facilitation by you. Better PM.com / Innate Images, LLC 151

152 Types of Stakeholders Developers The developers are the ones who execute the project from the perspective of coding and testing the solutions. They are the most likely stakeholders you will rely on to get development estimates. Developers are among those with the deepest technical knowledge, yet may lack the amount of business acumen held by the business and domain experts. Because of this, be sure to engage them as stakeholders who determine feasibility of a solution rather than the cost effectiveness of it. Better PM.com / Innate Images, LLC 152

153 Types of Stakeholders End Users The end user is the consumer of the product. They are not the customer. Among the most important factors this stakeholder brings to the project is the revenue that the business wants to gain. The end user s expectation is that the delivered product performs as it was intended. You are working to please the end user, not the customer. The customer is your advocate to help translate what the end user wants. The end user will then tell you if what is delivered does what it was expected to do. Better PM.com / Innate Images, LLC 153

154 2. Stakeholder Involvement Recall that Agile maintains and expects a high degree of stakeholder involvement throughout the value stream. This gives more visibility in the project than non- Agile disciplines provide. Stakeholder involvement throughout the project yields a higher degree of assurance that the product will live up to expectations. Continuous stakeholder involvement ensures that the project will stay aligned with its chartered purpose. The following pages detail information, techniques and tools used to ensure stakeholder involvement. Included are: Key factors that affect stakeholder involvement The Participatory Decision Making Model How to effectively use documentation while communicating to stakeholders, and how to avoid documentation pitfalls. 154

155 Factors Affecting Stakeholder Involvement There are a number of factors that impact the engagement style and participation on the project. As you work to serve as facilitator of participation, it s important to identify how stakeholders participate with a solution delivery team. Factor Range Potential Impacts Participation Style Reactive Proactive Stakeholders who are highly proactive participants with the team might possibly have an agenda that could threaten the project Stakeholders can tend to derail the project if they ask tangential questions and slow down the team Reactive stakeholders may signify that there s a negative relationship between parties that goes beyond this project. Relationship Negative Positive When the relationship between IT and stakeholders is negative the stakeholders will likely participate less frequently. Communication Channels Formal Informal Formal communication can increase time delays and cause bureaucracy on the team. Agile always favors in-person communication and informal communication strategies. Source: 155

156 Factors Affecting Stakeholder Involvement Factor Range Potential Impacts Availability Irregular Continuous When stakeholders aren't regularly involved with a project team (such as missing the retrospective) there s a larger chance that the team will face rework and missed requirements. Interaction Facilitated Active When interaction with stakeholders needs to be facilitated by a third person, (such as between team and the stakeholders) you run the risk of miscommunication and increasing the team's time to delivery. Remember the game of Telephone? Location Co-located Global When the team is co-located with stakeholders it is much easier to achieve consistent communication. As the team becomes more geographically distributed, the chances of project success decrease. It must be noted, however, that the use of global, distributed teams in agile is still acceptable. Source: 156

157 Participatory Decision Making Involved stakeholders are active participants in helping make decisions about the project. The leader must think of the best possible style that will allow the organization to achieve the best results. According to psychologist Abraham Maslow, workers need to feel a sense of belonging to an organization. The important thing to remember about practicing PDM is to make your team feel important to the project. PDM is also known by these terms: Shared Leadership Employee Empowerment Employee Involvement Dispersed Leadership Open-book Management Industrial democracy PDM can be used in: Team retrospectives Stand-ups Customer demos 157

158 Documentation - An Agile Business Case Wait documentation on an Agile project? Really? Although Agile favors the elimination of waste and unnecessary documentation, it would be incorrect to suggest that no documentation at all occur. As mentioned earlier in this chapter, your customer s involvement in the project as a stakeholder includes the creation of a business case. The business case is meant to generate buy-in from your organization and gain the support of an influential project sponsor. The business case justifies the reason for the establishing the project. It includes cost and value justifications, such as ROI. The business case will speak to each business stakeholder in a variety of ways. For instance, making a case to strengthen the product portfolio and therefore the business s core offerings. Items such as resourcing and risks should also be covered. 158

159 Documentation - Agile Charters Another tool that is necessary to ensure the delivery of value to the stakeholder is the project charter. The project charter is typically much more lightweight than it might be in other disciplines, but the charter is still a valuable tool in agile. Things to include in an agile charter 1. Vision: The vision defines the Why of the project. This is the higher purpose, or the reason for the project s existence. 2. Mission: This is the What of the project and it states what will be done in the project to achieve its higher purpose. 3. Success Criteria: The success criteria are management tests that describe effects outside of the solution itself. An agile project charter should also include a Project Overview Document, Which we cover on the next page. 159

160 Documentation - Project Overview The Project overview document is a summary of critical information such as: The vision for the system Primary user contacts, technologies and tools used to build the system The critical operating processes (some applicable to development, such as how to build the system and some applicable to production. References to critical project artifacts such as the source code and where other documents are. The project overview document goes by many different names in different organizations. It is not a key PMI term. 160

161 Documentation - Progress Reports Although Agile and Lean concepts recommend eliminating waste, an essential part of stakeholder involvement is the progress report. An Information Radiator is a large display of critical team information located in a spot where people can see it as they work or walk by. A good information radiator: Is large and easily visible to the casual observer Changes over time Is understood at a glance Is easily kept up to date. Examples of information radiators include customer demos, the vision statement, release and iteration plans, and burn-up charts. A burn-up chart (right) tells how much work the project contains and how much scope has increased at each iteration. 161

162 Documentation - Product Roadmap The product roadmap is an overall view of the product's requirements and a valuable tool for planning and organizing the journey of product development. Created by the product owner with help from the development team. The roadmap is used to categorize requirements, to prioritize them, and to determine a timetable for their release. Your product roadmap can be as simple as sticky notes arranged on a white board 162

163 Documentation Traps to Avoid Documentation is considered to be a less effective means of communication than in-person communication. Although Agile doesn t entirely eschew documentation, there s a certain level that is considered wasteful in an agile project. The important thing to keep in mind is to create reports that add benefit, not measure unnecessary statistics. Avoid these types of documents Velocity Reports across teams You should deliver velocity reports, but not measure velocity across teams because each team creates estimates differently. Quantitative reports Lines of code and number of stories should not be tracked as individual reports. Speculative concepts You should document stable, specific concepts versus what-ifs. So, what should you document? Information that is owned by a single source System overview documents Executable specifications Remember that Agile promotes the minimizing of waste. You should document the project, but do not overdocument. 163

164 3. Stakeholder Expectation Managing stakeholder expectations is likely the single most important role for any project manager. Agile projects offer some unique challenges as well as advantages: We need buy-in for the iterative/incremental build approach. We need support for the ongoing business involvement, we need trust in letting teams self organize and pull work from the prioritized backlog. These items need explaining and approving with sponsors and business representatives. In addition, the team also needs to know what is expected of them, undertaking a variety of roles, often without complete information and likely to iterate to the true requirements. 164

165 Waterfall and Agile Approaches to Stakeholder Management Although both Waterfall and Agile expect a high level of involvement and communication with stakeholders, there are some key differences. Waterfall Stakeholder Roles Categorized according to four levels using a RACI Chart: Responsible, Accountable, Consulted, Informed Involvement Style Awareness of development model More communicative than collaborative Most stakeholders have an understanding their expected role in a waterfall project. Agile Categorized according to potential impact to the project. Requires continuous communication and involvement Stakeholders will need to be sold on the benefits of Agile if it is newly introduced to a company. Reference: It s the Business, Stupid! 165

166 Ten Principles of Stakeholder Management As you manage communication and collaboration with your stakeholders, keep in mind these principles that must be kept in mind when managing them during the project. 1. Stakeholder interests need to go together over time. 2. We need a philosophy of volunteerism to engage stakeholders and manage relationships ourselves rather than leave it to government. 3. We need to find solutions to issues that satisfy multiple stakeholders simultaneously. 4. Everything that we do serves stakeholders. We never trade off the interests of one versus the other continuously over time. 5. We act with purpose that fulfills our commitment to stakeholders. We act with aspiration towards fulfilling our dreams and theirs. 6. We need intensive communication and dialogue with stakeholders not just those who are friendly. 166

167 Ten Principles of Stakeholder Management 7. Stakeholders consist of real people with names and faces and children. They are complex. 8. We need to generalize the marketing approach. 9. We engage with both primary and secondary stakeholders. 10. We constantly monitor and redesign processes to make them better serve our stakeholders. Citation: Managing for Stakeholders Authors: R. Edward Freeman, Jeffrey S. Harrison, Andrew C. Wicks Publisher: Yale University Press (October 30, 2007) ISBN-10: ISBN-13:

168 Sample Exam Questions Which of the following is not an aspect of stakeholder management in an agile project? Stakeholders are expected to attend the daily standups The stakeholders may need to be "sold" on the benefits of Agile. Stakeholders are categorized according to their level of impact to the project Stakeholders are expected to have a continuous level of involvement and collaboration in every phase of the project. What is a burn-up chart? A graphical chart that shows how much work and scope have been accomplished over time on the project. A chart that shows which risks have risen to issues on the project. A graphical chart that shows how much work the project contains and how much scope has been added at each iteration. A graphical view of all work to be prioritized and estimated following the gathering of user stories.

169 Sample Exam Questions Which of the following is not considered a type of participatory decision making? Employee involvement Shared leadership Industrial democracy Centralized leadership What is a potential impact of overly formal communication methods on a project? Stakeholders who are proactive personalities risk becoming aggressive. Negative relationships between parties Time delays and bureaucracy Unnecessary additions to the burn-down chart

170 PMI-ACP Exam Preparation Module 5: Boosting Team Performance Practices Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 170

171 Module Overview This module focuses on the PMI-ACP exam s Team Performance knowledge domain, which focuses on In this module: 1. Team formation 2. Team empowerment 3. Team collaboration 4. Team commitment 5. Sample Exam Questions 171

172 Module Objectives At the conclusion of this module, you should be able to: Facilitate the team in collectively creating ground rules and internal processes in order to remove fear of conflict and strengthen members commitment to shared outcomes Help form cross-functional teams by ensuring all skills and resources necessary are readily available in order to enable the team to deliver on their commitment. Identify team members that have the right combination of soft and technical skills and encourage them to be generalizing specialists in order to maximize teamwork and reduce bottlenecks. Ensure the team has a common understanding of the values and principles of agile and a common knowledge around the agile practices and terminology being used. 172

173 Module Objectives (continued) At the conclusion of this module, you should be able to: Empower the team to self-organize around the work in order to manage the project s complexity and produce effective solutions. Create a safe team environment by allowing people to experiment and make reasonable mistakes so that they learn and continually improve the way they work. Continuously discover team and personal motivators and de-motivators in order to ensure that the team remains motivated and productive throughout the project. Establish collaborative behaviors among the members of the entire project team by applying group decision making and conflict resolution techniques in order for them to take responsibility for outcomes and improve their effectiveness. 173

174 Module Objectives (continued) At the conclusion of this module, you should be able to: Facilitate close communication within the team and with necessary stakeholders through colocation or collaborative tools in order to reduce the cost of miscommunication and rework. Facilitate commitment by protecting the team from outside distractions in order to establish a predictable outcome and optimize the value delivered. Align project and team goals by sharing project vision and aligning team objectives with project objectives in order to ensure the team understands how their objectives fit into the overall goals of the project. Encourage the team to measure its capacity by tracking and measuring actual deliverables in previous cycles in order for members to gain a better understanding of their velocity and commitment. 174

175 1. Team Formation A high-performing agile team relies on the strengths of the individual, cross functional contributors to function as a self-empowered, decision-making team. Although this may cause overlap with traditional forms of management, normal corporate roles should not influence team formation. Product Management Team Product Owner Team Architecture Team Working System Produced SMEs/DBAs/Developers Supporting Cast (integrator, testers, domain experts) 175

176 High Performance Team Characteristics: Definition of Done A high performance team: 1. Identifies measurable tasks. 2. that have clear prioritization 3. that achieve team agreement. This is the Definition of Done. The Definition of Done (DoD) is a simple list of activities that add verifiable and demonstrable value to the product. Many Levels = Many DoDs Feature: Story or product backlog item Sprint: Collection of features developed in the sprint Release: Potentially shippable state 176

177 Using the Definition of Done in the Team There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release. For activities that cannot be included for a sprint/feature, teams should, discuss all of the obstacles that stop them from delivering each iteration or sprint Common root causes for impediments include: Team does not have the skillset to incorporate activities into the definition of done for a sprint or for a feature. Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.) Team members are executing their sprint in mini-waterfalls. 177

178 Definition of Done Key Characteristics The DoD is a checklist of value-based activities to produce the software or system. This allows focus to be placed on value-added steps and to eliminate waste The DoD is the primary reporting mechanism for team members. In it s simplest form, it s the ability to say, this feature is done. The DoD is an auditable checklist It validates whether all major tasks are accounted for. The DoD is not static Organizational support and the team s ability to remove obstacles should allow the DOD to evolve. The DoD is informed in reality The goal is to produce potentially shippable software Reference: 178

179 High Performance Team Characteristics: Measurable Competence A high performance team is cross functional but at the same time has specific levels of competence and expertise to minimize power struggles. The agile team has role clarity with an expectation for each member to meet or exceed their expected competency level to complete their tasks. For example: The agile project manager keeps an eye on the product backlog and protects the team from changes once the iteration has begun. 179

180 The Distributed Team Model Agile favors face-to-face, in person communication. When that can t happen, such as when business partners or outsourcing are used, Agile acknowledges that there are still benefits to be gained as a disparate team. Agile teams can operate within the concept of the Distributed Team Model. In the years leading up to the Agile Manifesto, it was expected that teams remain small and be placed in one room. But Agile has evolved to expect and support large teams in a distributed model. In a distributed model: Teams see each other infrequently or not at all. Sometimes known as Virtual Teams. Tools such as Planning Poker and the Participatory Decision Making are invaluable as mechanisms to ensure the distributed team members still have an equal voice. Team members may be on different floors or in different countries and time zones, such as with offshore teams. Teams may be larger than the traditional size of an agile team. 180

181 The Strengths and Weaknesses of a Team Agile teams do not operate without risks. A core concern is to continually ensure that all team members have a voice in the project and are not dominated by one person. And yet, the need to be democratic can lead to wasted time if not kept in check by the agile project manager. Positives Enables creative problem solving Scalable A wide range of skill levels and ideas Empowered to evolve the DoD as solutions are found Negatives One team member may begin to dominate Can lead to unnecessary meetings just to be democratic Egos are in play Time may be wasted with talking instead of working. 181

182 Risks to Team Success It is possible for an agile team to be established under the best of intentions and operational climate yet still fail to achieve success. The following are the key risks to success: High geographic distribution leads to environmental differences Electronic tools such as electronic documentation and instant messaging should be supplemented by a physical meeting space or war room that still promotes the concept of a group. Lack of clear goal setting If goals are unclear or are under-communicated, the team members will perform their tasks in the absence of attention toward a common vision. Waste will occur. Agile teams must work to ensure that shared decision making and shared responsibility occur so that team members feel empowered. Unclear roles Agile teams must include a clear leadership structure, shared responsibility, and an impatience for power plays or passing the buck. 182

183 Risks to Team Success (cont d) Poor Communication Personality conflicts and competitive relationships threaten to undermine the success of a team. Agile teams must constantly promote open dialog and in-person discussions. Failures of process One-way, top-down or unspoken communication channels will disrupt the success of the team. Well structured standups that enable each member to report on their accomplishments and concerns is a core tenet of the agile framework. Agile teams must include a clear leadership structure, shared responsibility, and an impatience for power plays or passing the buck. 183

184 Tools to Keep the Team Strong Team Contract Agile teams use a variety of tools and methods to ensure that the risks of team dynamics are mitigated. The Team Contract Also known as a Working Agreement or Ground Rules, the contract is a simple document which can be changed every iteration or sprint, or whenever necessary. Anything goes here that all developers agree on. 184

185 Tools to Keep the Team Strong Emotional Intelligence Traditional leadership generally involves the accumulation and exercise of power by one at the top of the pyramid. By comparison, the servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible. Emotional intelligence is the ability to identify, assess, perceive, control, and evaluate emotions. Servant Leadership was coined by Robert K Greenleaf in The Servant as Leader, an essay first published in The servant-leader is servant first It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. The servant leadership style is an excellent concept for the agile practitioner to follow. You are expected to balance yourself between being a contributor and a collaborator, between short-term goals and long-term goals of the project. The following slide shows the variety of functions you perform as a servant leader. 185

186 Characteristics of Servant Leadership Conceptualization Stewardship Building Community Healing Healing Listening Persuasion Guru/subject Awaeness matter expert Commitment to the growth of people Awareness Foresight 186

187 Things to remember as a Servant Leader Place yourself in the role of between a contributor, collaborator and leader. Don t focus on just the strategic and tactical aspects of the work you also must act as a coach and advocate for the team. Monitor the dynamics of the team. Focus on the work as well as the team s health. For the Exam Be aware of questions that test for your knowledge of the importance of team. Being an agile practitioner means that you are working to keep the team healthy and productive, and you re not focusing squarely on any one thing be it tactical, strategic, or self-fulfilling items. 187

188 Growing as a Team Member There are many ways in which you can grow as a team member yet continue to fulfill the role of servant leader for the team as a whole. It s important for each member on the team to grow as an individual, which will then make the team stronger. Affirm your strengths. If you re a good problem solver, or a good questioner, leverage this as a positive addition to the team. Not every member has the same strengths, so each person should use this to their advantage. Avoid situations where your strengths are not valued. Remember that a core principle of agile is to add value and eliminate waste. If you are expected to be a problem solver on the team, be sure to place yourself in situations where problems are waiting for your help. If you are a subject matter expert in a particular area, make sure you are able to focus on those deliverables rather than be placed in other work streams. 188

189 Growing as a Team Member (cont d) Be an observer of the team Is there a particular strength still needed on the team? Would the team benefit from a new idea that can only be seen from the macro level? Improve upon your weaknesses by drawing on the strengths of others. If you re a poor communicator, watch the strong communicators on the team and focus on learning their skills. For the Exam The exam expects you to show your knowledge of teams as being cohesive units that democratically work toward a common goal with little distraction in achieving it. The exam does not expect the team members to be so homogenous that there s no individual distinction, and yet it also expects you to know that rising ego or conflict due to the overpowering of others. 189

190 Team Trust Agile principles require that you build projects around motivated individuals. Give them the environment and support they need to get the job done, and trust in them that they can achieve their tasks. Trust is a core tenet of Agile. Once trust is broken, it is not easily recovered. Trust allows the team to stay problem-focused, it promotes efficient communication, and it improves the quality of collaborative outcomes. Trust has four core elements: Element Honesty Openness Consistency Respect Description The team member acts with integrity and upholds core values. Open to share, learn new things, consider alternate approaches Behavior and reactions that come to be expected. Treat people with the dignity and fairness that would be expected in return. 190

191 From Forming to Performing Agile makes use of teambuilding concepts based on the Tuckman model, popularized in the 1960s by Bruce Tuckman, a pioneer in the research of group dynamics. Tuckman s model posits that as time advances, a small group gradually matures by moving through common stages as they grow and begin to tackle increasingly complex problems and ultimately deliver strong results as a cohesive team. We will review each stage in the following slides. Forming Storming Norming Performing Reference: Tuckman, Bruce: Developmental Sequence in Small Groups Psychological Bulletin, 63, (1965) 191

192 Team Development - Forming What it looks like When the team is in the forming stage, the group members are waiting for leadership and they may still be very formal with each other. Goals and vision are not yet established. The team members are unclear of their role. How you can help Facilitate the team to begin writing its charter or mission statements, and buyin starts to get established. Get the team to perform tasks that will allow them to get to know each other. Begin to empower the team to set expectations and boundaries. Begin to communicate and reassure. 192

193 Team Development - Storming What it looks like The team members are ready to get moving on the project Personalities emerge. Strengths, egos, and conflicts begin to appear Some members may sit on the sideline as stronger personalities take over, or as conflicts emerge How you can help Communicate openly and with no surprises Participate in all meetings and value diversity Acknowledge others strengths and accomplishments to defuse any conflicts Start to play the role of supporter and advocate 193

194 Team Development - Norming What it looks like Team members begin to see how they are alike A sense of team takes hold, and they realize that they are all in this together. Social walls break down and communication begins to occur If this goes too far, they may forget the true reason they are together not to have a good time, but to tackle a task. How you can help Acknowledge that the team is similar with like characteristics Train people as necessary to keep the team consistent Keep the team focused on the goal Encourage the team members to get comfortable with each other 194

195 Team Development Performing What it looks like The team members are trained, have a clear vision, and are ready to get started. The leader will begin to challenge the team and begin to develop them further. The team will begin to expect more from you in terms of processes and rules. How you can help Acknowledge the efforts of each team member. Give new challenges to them Encourage continued growth. Remember that the Definition of Done will evolve as the team gets stronger. This is your opportunity to help make that happen. Interesting Note: a 5 th Phase In 1977, Tuckman added a fifth stage to his model and called it Adjourning. The idea behind adjourning is that a closure process is acknowledged in which the team completes their tasks and moves on. The Sprint Retrospective has many parallels to adjourning. 195

196 Review: Characteristics of a High Performing Team Teams can succeed on a project where one person cannot. A high performing team requires the ability to build a strong team with individuals who are able to interact well with each other. The following are key characteristics of the agile team: Able to work in close proximity or as a distributed group. Favors low-tech communication tools over complicated systems. In-person communication is always preferred. Competent members of from a cross section of knowledge domains. A climate of collaboration Creates a framework yields an agreement on the Definition of Done. A clear goal to achieve results-driven value and minimize waste. 196

197 2. Team Empowerment Not only are agile teams highly cross functional and with a strong set of competencies, they also operate with a high degree of empowerment. The team is responsible to establish a framework that permits them to perform their work with the primary objective being to find solutions. Teams of highly skilled individuals that are cross functional with high competency are still apt to fail if they cannot be permitted to rapidly solve problems within their own guidelines and rules. The team decides on their Definition of Done for the tasks, feature or project. 197

198 3. Team Collaboration Agile encourages close customer communication and collaboration. Typically, the customer is represented in the design and requirements documents. But for communication with the team that involves live communication (a core tenet of agile), documentation is less significant on the project compared to team meetings. These meetings are essential to team collaboration on an agile project: Release Planning Meeting Iteration Planning Meeting Daily Standup Meeting Review/Demo Meeting Retrospective Meeting Remember the Manifesto Individuals and interactions over process and tools. Customer collaboration over contract negotiation. 198

199 Release Planning Meeting The Release planning meeting is used to produce a high-level release plan with delivery dates, number of iterations and the primary stories that will be delivered. Initial release planning meetings rarely last longer than a day (sometimes two half-days.) Inputs Release Planning Meeting Outputs The customer presents the prioritized features to be delivered. Features and themes are reviewed and prioritized. Ideally, the developers have already devised rough estimates of how much work is required to implement each of those features. The team determines which features are delivered within the timeframe identified. Velocity (both prior or estimated) is used to determine this. Velocity will be covered in an upcoming module of this course. 199

200 Release Planning Meeting Outputs The Release planning meeting is to produces a high-level release plan with delivery dates, number of iterations and the primary stories that will be delivered. Initial release planning meetings rarely last longer than a day (sometimes two half-days.) Inputs Release Planning Meeting The Preliminary Release Plan is created. Although it rarely satisfies all parties (not enough functionality vs. too much time,) the teams looks at the hard truths and plans around them. The plan is understood to be rough. It is enough to get the team started. Key dates and milestones are established Iteration 0 Outputs Many teams arrive at an iteration 0 which allows the opportunity to work through technical and logistical issues. 200

201 Release Planning FAQs Inputs Release Planning Meeting Outputs How long is a release? Releases typically range from 2 to 12 months. For longer releases, it may make sense to break it down into smaller releases. How many iterations are in a release? The number of iterations within a release is typically driven by the schedule. If a release is 6 months long, and iterations are 2 weeks, then 13 iterations should be scheduled for the release. Who participates in the release planning meeting? For small teams, it s acceptable for the entire team to attend. For large teams, it s recommended that a cross section of representatives attend. 201

202 Iteration (Sprint) Planning Meeting The agile software development team holds a planning meeting at the beginning of each iteration to identify the stories that will be developed, and to break each of them down into specific technical tasks and acceptance criteria. Inputs Iteration Planning Meeting Outputs The product owner or product manager presents the stories they are considering for the iteration to the team. Each story is discussed to clarify its meaning and scope. Larger stories are broken down and estimated as necessary. Existing story estimates may be adjusted if during story clarification, new information comes to light that changes them significantly. 202

203 Iteration Planning Meeting Outputs The agile software development team holds a planning meeting at the beginning of each iteration to identify the stories that will be developed, and to break each of them down into specific technical tasks and acceptance criteria. Inputs Iteration Planning Meeting Outputs The team takes the candidate iteration backlog and breaks it down into lower level execution details. The design of the items in the iteration backlog is extended by decomposing the stories into tasks and clearly-defined acceptance criteria. The team estimates each task, typically in hours or ideal days. Once this decomposition analysis and design is complete, team members confirm that the estimates they have identified do not exceed the team s anticipated availability/capacity for the iteration. The team can then commit to the iteration backlog and the iteration begins 203

204 Iteration Planning FAQs How do you handle dependencies between tasks? As part of iteration planning, the team should strive to minimize task dependencies as they divide features up. Agile teams embrace simple, adaptable designs that are lightly coupled to minimize dependencies. The teams are empowered to work vertically to build what they need. Whereas traditional project management practitioners may expect to see items such as Gantt charts, Critical Path Method data and complex estimation charts, agile practitioners empower the teams to wait for dependencies to be completed * and raise issues in the daily standup if the dependency resides in the backlog. How much should a team member sign up for? A team member should rarely sign up for more than the total estimate of the tasks they were able to complete in the prior iteration. How do you plan iteration if the team size varies? With iterative development, there is typically some history that is built up over time to use as a basis for planning. If you team is cut in half, then a simple calculation should lead you to plan no more than ½ of the original ideal days for the upcoming iteration. * Reference: 204

205 Iteration Planning FAQs (Cont d) How do you account for overhead such as , meetings, etc? Teams generally do not spend much time tracking minor overhead items. Over the course of a few iterations, these interruptions become a constant amount of predicable time that can be factored in during planning. How do you account for bug fixing during iteration planning? One of the simplest is to include bugs as explicit input to iteration planning, prioritizing it, and estimating the tasks involved. Bugs are essentially equivalent to features in terms of units of work for planning purposes. Why should iterations always be the same length? Iterations with the same or very close lengths provide a rhythm that teams rely upon for estimating and planning. Without fixed-length iterations, it can be difficult to achieve and measure steady velocity (which is covered in a later module.) How do I account for testing and documentation time? This should be planned and prioritized just like everything else. These items are often created as tasks under specific features, but may also be grouped as their own feature. 205

206 Iteration Planning FAQs (Cont d) Should feature estimates be revised during iteration planning? Feature estimates should only be revised during iteration planning if the original estimate is found to be way off base and the new level of effort will have a significant impact on the team's ability to complete other work Should task estimates be revised during an iteration? The original task estimate should not be revised once the iteration planning has been completed. However, the estimates for future iterations should be continually revised to reflect an accurate assessment of remaining work. Should all teams operate on the same iteration schedule? It is recommend that this occur whenever possible. This allows for the rolling up of iteration status across teams and measuring velocity across teams. A disadvantage of this approach is that some teams may have members that are on both teams. A staggered approach may give the resource(s) room to breathe. What is the duration of the meeting? It lasts approximately one hour per week of sprint work planned. 206

207 Daily Standup Meeting Agile development processes depend on a high level of communication and collaboration for success. This is no truer than in the daily standup meeting that occurs during an iteration. The Three Questions in a Daily Standup What did you do yesterday (or since the last standup)? What will you do today (or before the next daily standup)? What impediments are preventing you from making progress? The Daily Standup is known as the Daily Scrum in extreme Programming (XP) Scrum Master is accountable to the team and must deal with any impediments as quickly as possible. This may mean scheduling a follow-up meeting with the necessary people right after the standup. 207

208 Daily Standup Meeting Other Characteristics Meetings are typically held in the same location and at the same time each day. Ideally, the daily scrum meeting is held in the morning, as it helps set the context for the coming day's work. The daily standup meetings are strictly time-boxed to 15 minutes. All team members are required to attend the meeting. Since both the Scrum Master and Product Owner are committed team members, they are expected to attend and participate. All ancillary stakeholders (such as a departmental VP, a salesperson or a developer on a different project) may attend but is allowed to only listen, not speak. It s not a problem-solving session or issue resolution meeting. Issues are taken offline with the facilitation by the Scrum Master immediately after the meeting. 208

209 Daily Standup Meeting Other Characteristics It is not a status-gathering meeting where the boss gleans which team members are behind schedule. It is instead a meeting where team members make commitments to each other. Consider: Standup Meeting Today: Today I will finish the Widget X module. Standup Meeting Tomorrow: The team members will expect either a status of completion, or a identification of an impediment that precluded completion. The vast majority of teams conduct the daily Scrum meeting by having each person answer the three questions in order. You answer all three, then the next person, then a third, and so on. Some teams find it helpful to talk through one product backlog item before moving on to the next. In this way, an individual may give an update at multiple different times during the same meeting. 209

210 Daily Standup Meeting Example Impediments It is the responsibility of the Scrum Master to quickly resolve impediments either directly, or by engaging other team members to assist. Impediments are typically handled immediately after the standup meeting. Example impediments include: The 3 rd party s helpdesk has not yet gotten back to me with an answer. I m having trouble learning this new software package or application. I can t get time with the group to answer my questions. Our offshore team cannot access our VPN. I can t debug a particular line of code. 210

211 Review/Demo Meeting The review meeting is an opportunity for the team to demo the results of the iteration to the customer and the stakeholders. It is generally held on the last day of the iteration or the first day of the next iteration. This is a great opportunity for stakeholders not allowed in the standups to get an idea of progress. It s also an opportunity to get initial feedback on what has been developed. Duration: The review generally lasts approximately one hour per week of sprint work planned. The meeting is open to a wider group than is allowed in the standup: Invited members include the customer, team management, stakeholders, and the project team. The goal of the review meeting is to successfully demonstrate the features and functions completed during the iteration. Feedback from the stakeholders is welcome and helps the team eliminate waste. This meeting is also known as the Iteration Review or the Sprint Review. 211

212 Review/Demo Meeting Inputs and Outputs Inputs Iteration Review Meeting Outputs The meeting is started with an accounting of what was originally planned but not completed. This sets an appropriate expectation for the meeting. The backlog and the burn-down chart are key pieces of information used. User stories that are complete are demonstrated. This meeting is more than a discussion: it s an opportunity to demonstrate what s been built. User stories that are not complete are identified with an explanation of why they are incomplete. 212

213 Review/Demo Meeting Inputs and Outputs Inputs Iteration Review Meeting Outputs The stakeholders are given an opportunity to comment on their likes and dislikes of the features reviewed. This is an opportunity to get an indication if rework or a major course-correction is necessary on the feature. It also can serve as a great way to validate if the feature is on track. The feedback is used for the planning of the next sprint. Rework on the features demoed would initially be placed in the backlog for consideration in the next iteration planning meeting, After the review is over, the date for next review is announced and the team moves to Sprint Retrospective. 213

214 Retrospective Meeting Continuous improvement is a fundamental tenet of today s agile teams. Retrospectives serve as the opportunity for teams to collaboratively examine and expose opportunities for improvement in terms of process and practices. It is also a chance to discuss what went well. The meeting is a time to discuss issues that affected the team s overall effectiveness, productivity and quality as well as the team s satisfaction with the project. The meeting is time-boxed to last no more than three hours. If the team did not complete all of the user stories in the iteration, then the agile coach will discuss what and why it happened. Just like iteration planning and release planning, retrospectives take place in a regular rhythm. Many of the more effective agile teams conduct retrospectives at the conclusion of every iteration. 214

215 Retrospective Meeting Inputs and Outputs Inputs Retrospective Meeting Outputs During a retrospective, specific impediments, action items and/or stories are identified and prioritized. The meeting is facilitated by someone with the experience to ensure participation by everyone on the team. Inputs Retrospective Meeting Outputs Very often, the highest priority items are scheduled and dealt with in the following iteration. The key benefits agile teams get from holding regular retrospectives include improved quality, team capability, improved throughput and higher trust and morale. Things could improve so well that definition of done changes. 215

216 4. Team Commitment In an agile project, the people who are closest to the work (and who are completing the work) are the best to know how much time is required to accomplish it. The agile framework works because the team and the product owner form a communication channel that enables this commitment to occur. Anything that goes against this commitment-based discipline should be removed. Recall that the team members are given empowerment. This means that the team is left alone to create their charter and meet their target. They are expected to have the commitment needed to achieve their goal, however they are permitted to reach out to management when they need assistance. 216

217 Leadership Techniques for Team Commitment The agile practitioner evolves his team from the perspective of: Teaching Coaching Advising Teaching: Showing the student of Agile the rules to buy into the process and help them conclude on their own that Agile is better. Coaching: Helping the team member take what they have learned and use it on a daily basis as part of their operational approach and way of thinking. Advising: Your goal is to be able to step away from your role of teacher or coach once the team has become precisely what agile desires: a self-empowered team that needs only occasional assistance or advising. You want to teach the team to fish. This concept mirrors that of the Aikodo Shu Ha Ri, which guides a person from a stage of innocence to sophistication to alertness/spontaneity. It means that you First learn, then detach, and then transcend. Reference: The Meaning of Shuhari, November

218 Sample Exam Questions Which of the following is not considered a type of participatory decision making? Employee involvement Shared leadership Industrial democracy Centralized leadership What is a potential impact of overly formal communication methods on a project? Stakeholders who are proactive personalities risk becoming aggressive. Negative relationships between parties Time delays and bureaucracy Unnecessary additions to the burn-down chart

219 PMI-ACP Exam Preparation Module 6: Adaptive Planning Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 219

220 Module Overview This module focuses on the PMI-ACP exam s Adaptive Planning knowledge domain. In this module: 1. Levels of Planning 2. Adaptation 3. Estimation 4. Velocity/Throughput/Cycle Time 5. Designing during Adaptive Planning 6. Sample Exam Questions 220

221 Module Objectives At the conclusion of this module, you should be able to: Plan at multiple levels (strategic, release, iteration, daily, etc.) creating appropriate detail using rolling wave planning and progressive elaboration to support the necessary level of understanding. Engage the team and customer in planning activities to create practical plans that balance priorities and team capabilities in order to gain increased levels of commitment. Make specific commitments to project sponsors and manage expectations around those commitments based on actual project experience in order to set and manage sponsor expectations. Coach the team to adjust the cadence and the planning process based on project characteristics and/or the size/complexity/criticality of the project deliverables. 221

222 Module Objectives (continued) At the conclusion of this module, you should be able to: Inspect and adapt the project plan to reflect changes in requirements, schedule, budget, and shifting priorities based on team learning, delivery experience, feedback, and defects in order to maximize business value delivered. Encourage the team to create estimates that reflect current understanding of the effort to deliver the project by including all the aspects of delivery (analysis, development, test, refactoring, deployment preparation, etc.). Refine estimate ranges so that they reflect the current level of uncertainty and the team s own ability and skills in order to manage stakeholder expectations 222

223 Module Objectives (continued) At the conclusion of this module, you should be able to: Capture a measure of the accepted work completed in a given time frame in order to gauge progress and extrapolate completion. Adjust planning capacity by considering maintenance and operations demand to ensure team does not over commit 223

224 Adaptive Planning Recall that adaptive planning is a major tenet of Agile, which contrasts with the predictive approach of Waterfall. This module will show how planning, design and documentation can occur in the agile framework yet still be adaptive by nature. Mindset Approach Predictive Waterfall Adaptive Agile 224

225 1. Levels of Planning Agile software development typically consists of five levels of planning which we will cover in detail in the following slides. In plan-driven and waterfall methodologies, planning involves large upfront design, aiming to predict accurately how much work is involved in each project activity. Dependencies, full work estimates, and detailed requirements are built. This effort leads to a large investment early in the project, and yet it is by no means certain that the designed functionality will be delivered exactly as expected. Change and rework is therefore expensive. Any agile approach to large-scale developments has to avoid the above concepts of waterfall or the reintroduction of the Big Design/Requirements Up Front (covered in module 3.) One solution to large-scale agile projects is to add planning levels to incorporate a view of the whole picture. 225

226 The Five Levels of Planning Level What it is Frequency Who Portfolio Vision Statement 1x-2x/year Product Owner and Executives Product Roadmap Product evolution over Time 1x-2x/year Product Owner and Executives Release Features/User Stories 3x-4x/year Team, Product Owner, Stakeholders 226

227 The Five Levels of Planning Level What it is Frequency Who Iteration Features (user Stores and tasks) Every Iteration Team and Product Owner Day Tasks, Burndown/to-do items Every day The team Release 227

228 The Agile Planning Onion These levels are sometimes referred to as the Planning Onion. Agile teams plan at least at the Release, Iteration and Day levels. Some organizations may depict a 6th skin of the onion representing strategy Portfolio Product Roadmap Release Iteration Day 228

229 The Law of Diminishing Returns In Agile, you ll often hear, don t do significant up-front design work. In Waterfall, you ll be expected to do so. The agile manifesto says that "Continuous attention to technical excellence and good design enhances agility." It doesn't say no design or documentation before you build. So how do you know how much is considered enough design? Consider the law of diminishing returns, which makes it clear to stop once the effort trumps the return. Returns In general, you can keep developing after a certain point, but after the quick wins are done take a moment to evaluate what to do next. Effort/Time 229

230 Just Barely Good Enough As you continue the course, you ll notice a few terms that act as good Mnemonics not only for the exam but as terms you ll treat as vernacular in your day-to-day work in Agile. In this module we ll discuss JBGE - Just Barely Good Enough LRM: Last Responsible Moment. Just Barely Good Enough (JBGE) is a concept from Agile Modeling that states that work should involve a sufficient level of quality and performance but no more. In the preceding image of the law of diminishing returns, the ratio of value over time begins to wane. Rather than continuing to develop additional product enhancements, JBGE suggests that once the customer confirms acceptance of the feature, additional work would be wasteful. Although JBGE occurs during sprints (the build portion,) the decision to not develop additional items of a feature is a result of the JBGE data points when performing subsequent iteration planning. Reference: 230

231 The Last Responsible Moment The Last Responsible Moment is the point in the planning stages where the benefits of delaying a decision outweigh the costs of delaying a decision. Your plan is responsibly deferred, and therefore the more flexibility you have in your plan. Some things to consider: The typical waterfall planning of dates, durations and tasks in ideal time as eschewed by this principle which accepts that uncertainty and change will always be with the project. Therefore, it s okay to responsibly defer your planning as you iterate. You benefit from avoiding the waste that would have otherwise been created from unused plans. In this methodology, you identify multiple options, but do not defer critical decisions that would result in scheduling conflicts. Use planning horizons to only plan out as far as the project allows you to see. The last responsible moment doesn t necessarily tell you to not decide things early, it just tells you to avoid over-planning items that may be subject to change anyway. For further reading: Defining the Last Responsible Moment by Karl Scotland

232 How to use JBGE and LRM: Examples During the build phase, team members should consider the concepts of JBGE as they develop their features. For instance: Re-coding a feature to take two seconds to communicate to the database instead of your code s current three seconds would be wasteful if the customer states that anything within five seconds is acceptable. But you should perform the re-code if you know the three second delay would cause larger issues in other features. For use of LRM, the scrum master may determine that the decision whether to recode doesn t need to be decided yet, because the follow-on features have not been solidified. And it s not worth wasting time to plan for this event because future releases requiring it have not yet been determined. Keep in Mind: JBGE and LRM can only succeed if iterative communication with the customer occurs. A project using JBGE but that skips review meetings would risk misunderstandings of functionality. 232

233 Key Features of Adaptive Planning Adaptive plans that ebb and flow during development provide better visibility to stakeholders. How? The burn-down chart is transparent to the team members The multi-level stage of planning allows for the team and customer to inspect the development processes and reprioritize any items in the backlog. Just remember to display these information radiators and not skip any reviews! In adaptive planning, the team takes a committed approach to the functionality it can deliver at the start of each iteration. Stakeholders benefit from the visibility of knowing that commitments don t occur until the scope has been determined to be achievable in an iteration. This concept requires that everyone in the team be truly committed. Seem Familiar? Many characteristics of successful adaptive planning will remind you of the necessary team dynamics covered in module 4: collaboration, commitment, empowerment 233

234 Key Features of Adaptive Planning (cont d) Adaptive Planning requires trust, commitment and collaboration by the team. Because the plan is expected to evolve under concepts such as JBGE and JIT, it requires the team members to understand that the scope and plan is evolutionary during the project. This may be difficult for the Waterfall practitioner to accept. Trust also comes from the product owner and the management in the way of allowing the team to determine on their own how much it can deliver in an iteration. The team is expected to be empowered. The agile practitioner as Scrum master supports the team by guarding the scope with the product manager and championing the best practices of agile while playing the role of servant leader. 234

235 Impediments to Adaptive Planning Assumptions by the stakeholders and team can emerge which rely on problems to evolve by fixing themselves. Just because a plan is structured to be evolutionary does not mean that it will evolve to a positive outcome. How to mitigate: The team must continue to trust each other and work toward the objective of the project. Each team member could be at risk of losing focus. If the product owner or scrum master doesn t stay involved, the team loses visibility. If the business owners and/or customers disengage, misunderstandings will form between the two parties. 235

236 Impediments to Adaptive Planning (cont d) Organizations that are risk-averse or wary of change A high-performing agile team that exists inside a company that isn t fully accepting of the agile framework s fundamentals will eventually become lost and the team will fail. How to mitigate: The organization and its leadership must adopt the same trust that the agile team practices. Long-term vision, priorities and direction must come from the very top of the organization. A strong focus on business value will create an environment in which agile practices can take root. Create a culture of incremental delivery, the elimination of waste and collaborative problem solving. If you do these things and communicate your success upward, the organization will adopt the concepts of adaptive planning and agile even if they don t reference them by name. 236

237 2. Adaptation Almost the very definition of the word Agile, adaptation is a concept embraced by the agile framework and is one of the primary ways agile projects are kept from being managed too rigidly. Consider adaptation as being a concept that allows for looking ahead and course-correcting as necessary, as is explained on the following pages. 237

238 Planning Horizons When setting and revising goals, it is important to remember that we cannot see past the horizon and that the accuracy of a plan decreases rapidly the further we attempt to plan beyond where we can see. Consider the nautical analogy: You re standing on a small boat and your eyes are nine feet above the water. The distance to the horizon in this case is slightly over four miles. If you are planning a 20-mile trip, you should plan on looking ahead at least five times, once every four miles. Because you cannot see past the horizon, you need to look up occasionally and adjust your plan. 238

239 Planning Horizons Short Planning Horizons Used for detailed, specific plans Useful as tools to counter increasing uncertainty surrounding a situation; the shorter the plan, the shorter the planning horizon, and the more opportunities for you to stand up in the boat and take another look. Long Planning Horizons Used in general planning when there is more certainty and less risk of change. There will always be uncertainty and a risk of change; set your horizons accordingly! The more commitment that s required, the longer the planning horizon should be. 239

240 Rolling Wave Planning A general rule of estimating is that the more you know about something, the easier it is to estimate. The less you know, the harder it is to estimate. It s important to highlight a key set of tasks and a well-defined work breakdown for the near-term activities and rely merely on milestones for future work. As the future work approaches, you break down the milestones into tasks. Sprint Work items are small and well - defined. Larger functional goals Specific problems to solve Strategic product goals Strategic product line goals Tasky plans Higher level items and milestones Now 1 month 3 months 1 year 2 years 240

241 Progressive Elaboration Progressive Elaboration occurs in the rolling wave planning process as time progresses to the larger pieces of scope. Consider the original image after time has elapsed. Sprint Complete Larger functional goals broken down to sprint items Specific problems to solve broken down to larger functional goals Strategic product goals broken down to specific problems to solve Strategic product line goals broken down to product goals, or product line strategy evolves Completed Work Tasky plans Higher level items and milestones Now 1 month 3 months 1 year 2 years 241

242 Continuous Planning Keep in mind that each cycle feeds the next. The agile practitioner and the planning team are likely involved in a number of planning and review meetings concurrently: Product Road mapping Product Road Mapping Release Planning Release Planning Iteration Planning Iteration Planning Daily Stand-up Daily Standup Release Iteration Daily Work Task Completion Project Retrospective Product Retrospective Release Retrospective Release Retrospective Iteration Demos, Iteration Demos, Reviews, Retrospective Reviews, Retrospective Daily Work Updates 242

243 3. Estimation In agile projects, we accept the fact that project requirements, scope and the definition of done are subject to change. There s a certain level of uncertainty that is accepted as a part of the reality of a project, yet that doesn t mean that the agile practitioner doesn t use tools to improve estimates and get quantifiable information together for planning purposes. This section guides you through the techniques used in agile to achieve solid estimates for the project. 243

244 Planning from User Stories Recall from Module 1 that a user story is a key tool used in agile to determine requirements. It can be as simple as one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. Adaptive planning requires the user stories to be captured so that they can then be broken down into tasks that can be executed by the team. There are Three C s of user stories: Card (shown at right) Conversation Confirmation Information on a Story Card: As a: I want to: So that: 244

245 Decomposition Decomposition involves taking the result your user is looking for (stated as a User Story) and breaking it down into a number of tasks that the team can work on individually. Decomposition in Agile takes many forms: Feasibility study projects When an organization performs a strategic view of their vision, decomposition at this level leads to separate projects that can then be budgeted. This approach is counter to the rolling wave style of planning. Decomposing strategy into executable projects A basic execution sequence consists of Vision, Release Date and Minimum Marketable Features. This approaches the need to decompose user stories into features that will fit into certain releases. 245

246 Decomposition (cont d) Decomposing user stories 1. Starting with the three 3 C s of your user stories (Card, Conversation and Confirmation,) first place the stories that belong in the current feature of the most current release. 2. Estimate and prioritize features for the current iteration and the following three iterations. 3. Create detailed requirements and customer tests for the features in the current iteration. 246

247 How to Estimate Velocity When estimating velocity, it s important do to so according to the Definition of Done. Points are used to estimate the relative size of stories. Once the points are determined and actuals come in, this information can then serve as a record of velocity that you can then make future estimates from. Poker with Points Module 1 discusses the use of points as relative values to help determine the relative size of stories. The team collaborates on the estimates through tools such as Planning Poker. 247

248 Ideal Time Consider the typical eight-hour workday: How many hours or productive time do you get in, on average, between checking your , multitasking on a separate project, answering ad hoc questions and phone calls, and other general distractions? In other words, if you are given an eight-hour task, how can you be assured that you can accomplish in one workday? Many agile practitioners use Ideal Time in estimating work. Ideal time is considered the pure amount of time required to accomplish a task uninterrupted. In a software project, ideal time would be considered the time spent on programming. In a discipline such as construction, ideal time would be the time spent building the structure but not the time spend reading the blueprints. In contrast with ideal time is elapsed time. In the example at the start of this slide, how many hours in elapsed time do you think it would take you to accomplish an eight-hour ideal time task? The key is to not mix ideal time and elapsed time estimates on your project. 248

249 Tools used in Agile Estimation: Point to Scale Exponential Sequence Estimations Recall from Module 1 this mechanism for estimating user stories. Most User Stories will fall here. Represents full functionality that can be accomplished in a sprint. User stories in future major releases Defects, small enhancements, etc. User stories in current minor releases Large User Stories May or may not need to be decomposed further. Epic Level Team cannot estimate effectively given current Understanding of work. Very large user stories that the team can handle but will need to break down by decomposition.

250 Tools used in Agile Estimation: Affinity Estimates Affinity Estimating is a technique to quickly and easily estimate a large number of user stories in story points. This is a useful technique if you re just starting a project and have a backlog that hasn t been estimated yet, or in preparation for release planning. Participants include: Large Medium Product Owner Delivery Team Scrum Master How it works Small Stories are be printed on large sticky notes. The team presents a set of reference stories the team has done in the past, i.e. good examples of a point 1, 2, 3, 5, 8, etc. stories. Team members are told to silently size each item relative to other items on the wall. The more stories to estimate, the larger the space is needed to do the exercise. 250

251 Tools used in Agile Estimation: Top-Down Estimates Top Down Estimating is a great way to get meaningful estimates at the start of the project. Styles of top-down estimating include: Expert Judgment Leveraging your domain experts to make an educated guess Wideband Delphi Method A consensus-based approach using a combination of individual, anonymous estimates from the team. Forms are used and the sessions are held in multiple rounds. Analogous Estimation Uses a similar past project to estimate the duration or cost of your current project, thus the root of the word: analogy. Not as accurate as other techniques. Parametric Estimation Determined by identifying the unit cost or duration and the number of units required for the project or activity. More accurate than analogous estimating. 251

252 Tools used in Agile Estimation: Bottom-Up Estimates Bottom-Up Estimating is a more analytical method than top-down practice for estimating user stories. But to achieve a stronger analytical output, a large amount of inputs are needed: Work Breakdown Structure, project plan and schedule Customer and user requirements Specifications both functional and technical 252

253 Tools used in Agile Estimation: The Release Backlog The release backlog is the collection of all story cards that have not yet been scheduled with a particular iteration. Backlog items can consist of user stories, features, bugs or anything that remains to be delivered. Sprint Backlog Product Backlog prioritized by Product Owner

254 Tools used in Agile Estimation: Iterations An iteration is a time-boxed set of items that fall under a common category or theme. Iterations are defined in the iteration planning meeting. Iterations are completed in the iteration demo and review meeting. Iteration = Sprint 254

255 Tools used in Agile Estimation: Other Tools and Devices Persona A personal is a fictitious person devised to fully represent a user story in planning. Feature Task Features are intended behaviors of software or a system that is documented in the design. The most granular unit of work that is generated from the decomposition of features. Tasks are generally assigned to one person on the team. WIP Queue The Work in Progress Queue consists of items such as code to be tested or documents to be created. 255

256 4. Velocity/Throughput/Cycle Time As the saying goes, if you can t measure it then you can t manage it. Many useful measurements are used in an agile project to determine its health and status according to the timeline. In the pages ahead we ll explore a number of the ways in which agile projects are measured. 256

257 Burndown Burndown Burndown is the rate at which the entire project is eroding (or burning) the requirements included in the feature list. You need to keep the current burndown in mind when making long-term and release plans. Your initial iterations have not yet achieved enough burndown data to allow you to make accurate estimations of future iterations. By the third or fourth sprint you should be able to make accurate estimates. Effort Iteration Ideal Actual Series1 Series2 257

258 Velocity Velocity Velocity is tracked on a burndown chart as a depiction of the total task points remaining per iteration. Once the team knows their burndown rate it allows them to determine their ability to meet their project commitments. To calculate velocity, a team first has to determine how many units of work each task is worth and the length of each interval. During development, the team keeps track of completed tasks and, at the end of the interval, counts the number of units of work completed during the interval. Story Points Velocity vs. Work Capacity Trend Sprint Name Velocity Work Capacity 258

259 Velocity Key Things to Remember Objective: Customer satisfaction Measure: Stories (or story points) delivered; ideal hours delivered. Only completed items count in this metric Trend: An upward or stable trend is expected. When measured: Velocity is a continuous measure. 259

260 5. Wireframes, Sketches and Prototypes We all have heard the phrase, A picture is worth a thousand words, right? When understand user stories and ensuring that we are capturing the essence of what the customer wants, the use of wireframes and prototypes is an effective way to help the team visualize the solution to be built. Consider the origin of personal, online newsfeed and communication software. In 2000, an idea was born by Jack Dorsey for a service called twttr. By 2006 he had a working sketch and developed an application using it. His original sketch is pictured here. You can see Dorsey s full explanation of the genesis of what we now know as Twitter by reviewing his story at the following address:

261 Wireframes, Sketches and Prototypes In Agile, the product manager will often not only gather the voice of the customer but also validate the requirement by presenting a sketch, a wireframe or a prototype. It generally works like this: Immediately after reviewing a user story, the product manager would create (or enlist a team member) to sketch the story into something visual. As soon as the sketch is created and finalized, the product manager would review the image with the customer and gather feedback. An iterative feedback loop develops by which the image can be updated as necessary until the product manager and customer feel that they have a very close mockup of the story. The product manager then returns to his desk and creates light documentation (using a wiki or similar tool) to formalize the sketch into something that can be built by the developer.

262 Wireframes, Sketches and Prototypes What the product manager and team use to visualize the user story can vary. Some agile teams will do nothing more than a simple sketch. Others will go so far as to create a working prototype to then show the customer. And some teams use the concept of the wireframe to serve as something in between a simple sketch and a full-blown prototype. A wireframe generally looks like a more formal drawing and is more easily editable than an ink-and-paper image since it s done with software. There are a variety of styles in wireframe tools, but as Agile continues to evolve the most commonly acceptable format is one of a certain sketchiness. On the next page is an example of a wireframe that uses specific software.

263 Wireframes, Sketches and Prototypes Software-based Wireframes such as the one shown here are common ways to quickly create electronic sketches that can be reviewed with the customer. This particular wireframe shows the mockup of a corporate Intranet using Balsamiq Mockups.

264 Cycle Time Story Cycle Time: The number of iterations it takes to complete a story Cycle Time: The average time between the delivery of completed work items (in successive deliveries.) Lead Time: The time between the initiation and delivery of a work item. Backlog Ready for Dev In Dev Ready for Validation Validating To be Deployed Deployed A common workflow for the typical agile team 264

265 5. Sample Exam Questions A depiction of the total task points remaining per each iteration is known as a measure of: Burndown Cycle Time Throughput Velocity You are given a report that shows the average time between the delivery of completed work items in successive deliveries. You are looking at a report on: Cycle Time Throughput Burndown Velocity

266 5. Sample Exam Questions You are looking at a story card that has 100 points listed on it. The level that this task represents is: Scope creep Minor defect Epic Level Enhancements level True or false: When measuring velocity, it is not necessary to know the Definition of Done: True False A retrospective is occurring one morning, and later in the afternoon the scrum master will be tied up in a release planning meeting. Is this a problem? No, but a separate scrum master should attend one of the meetings. Yes, the scrum master should be focused on one iteration at a time. No, each cycle feeds the next as part of continuous planning. Yes, multitasking on agile projects is a recipe for disaster.

267 PMI-ACP Exam Preparation Module 7: Problem Detection and Resolution Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 267

268 Module Overview This module focuses on the PMI-ACP exam s Problem Detection and Resolution knowledge domain, which focuses on how to resolve impediments and mitigate risks to your projects. In this module: 1. Creation of a safe, collaborative working environment 2. Key risks to watch for 3. Agile risk management according to PMI 4. Communication Techniques 5. Sample Exam Questions 268

269 Module Objectives At the conclusion of this module, you should be able to: Create an open and safe environment to surface problems and impediments that are slowing the team down or preventing its ability to deliver value. Proactively engage the team at various points in the project to identify risks and create mitigation strategies. Ensure impediments are resolved and/or reset expectations in view of impediments that cannot be resolved. Maintain a visible list of risks and impediments in order to elevate accountability and track ownership and resolution status Communicate status of risk and impediments in order to manage the expectations of the impacted stakeholders. 269

270 1. Creation of a Safe, Collaborative Working Environment As previous modules have suggested, a collaborative environment with open communication is a key foundational structure for any agile team. By enabling this safe, collaborate working environment the agile practitioner will have established the best possible outcome for the identification and mitigation of risks, which we will explore in the subsequent pages of this section. The following concepts should be kept in mind when establishing a positive work environment: Your team members are trying to do a good job but may need your facilitation toward better communication and a clearer direction of their responsibilities. Agile promotes the building of team charters and working rules which have a direct impact on team member performance and the level of risks that arise. Confrontation and egos are disruptive to the process, especially during sprints. You should do everything you can to reduce the chance of this occurring. 270

271 Conflicts in the Work Environment Even after all attempts to create this safe, collaborate working environment, conflicts will arise, which is not unique to agile projects. As an agile practitioner or Scrum Master, it is your responsibility to set the tone for a principled work environment that supports high performance from the team. Follow established conflict resolution methods on your projects. When conflicts arise: Don t avoid the conflict. You should look for conflicts that are emerging and you should address them as soon as you become concerned. Do not overreact, but make sure you defuse any situation that risks affecting team performance. Play the role of coach, servant leader and intermediary at any time that you see conflict. As a central figure to the success of the project, you set the tone for the positive work environment to exist. 271

272 Conflicts are Impediments Note that conflicts can lead to impediments. Your assessment of conflicts requires similar techniques used in risk mitigation. Below are examples for ensuring not only a safe working environment but also one that enables clearing of impediments: Detecting problems is the first step to resolving them. Daily stand-up meetings are an excellent way to identify any issues that team members are facing. Tools: Teams can also track issues by calculating cycle times for tasks. - If the cycle time is too high, it might indicate a potential problem or that the team has undertaken more work than it can complete. 272

273 Resolving Conflicts and Impediments with Risk Mitigation Strategies Despite our best efforts, some defects may make their way through to the final product. Escaped defects are the most expensive to fix and are potential risks that should be identified. We will learn about risks such as this in the subsequent sections of this module. Just as with the risk mitigation that is required to solve the above example, it will also be useful in addressing conflicts and impediments. As we begin to explore risk identification and mitigation, keep this in mind: The entire team is responsible for conflict resolution, elimination of impediments and identification of risks. You must act as a facilitator to open communication, and you must also use your role of servant leader to ensure the team follows the path of team-based methods toward resolution. 273

274 2. Risk Identification Risk is present in any project, including those that are operating within the agile framework. Because the framework places emphasis on continual communication among the team members using the least complicated methods, the ability to identify and mitigate risk is a key benefit of agile. But the risk is still there and must be addressed, and this section covers the key areas of risk on Agile projects that you are likely to come across. The 5 Core Risk Areas Although the Agile framework does not specifically reference risk management, the PMI-ACP exam focuses on five core risk areas that are common to all projects. These risk areas are introduced in the next pages. 274

275 The 5 Core Risk Areas Common Across All Software Projects In their 2003 book Waltzing With Bears: Managing Risk on Software Projects 1, Tom DeMarco and Timothy Lister state that any project worth starting will be vulnerable to risk. And since greater risk brings greater rewards, companies that completely avoid risk will be left behind by the competition. The agile practitioner must be mindful of these core risk areas on their projects: Intrinsic Schedule Flaw Specification Breakdown Scope Creep Personal Loss Productivity Variation On the next pages we ll review each of these risk areas. Note that these risks do not apply solely to software projects

276 Risk Area 1: Intrinsic Schedule Flaw Intrinsic schedule flaw is a result of overly optimistic estimates or task durations that have extended well beyond their baseline. Schedule flaw can result from wishful thinking or rounds of planning poker that involved group think. What it means Given the intangible nature and uniqueness of software, its development is inherently difficult to estimate and schedule. Recommended Solution Get the team more involved in planning and estimating. Use collaborative techniques such as Planning Poker to find a common ground in the estimates. Get early feedback from stakeholders and address slippage immediately. Your Takeaway By working in short increments the true velocity of the team quickly emerges and is visible to all stakeholders who are now more closely involved in the project. 276

277 Risk Area 2: Specification Breakdown Specification breakdown results from the inability of the stakeholders to reach consensus on what to build. In agile, you should look for warning signs that lead to deadlock or incomplete specifications that would become a problem during the build phase. What it means In a software project, it s when coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements. In other industries it s no different: the builders become unclear what to do based on incomplete or erroneous specs. Recommended Solution Use a dedicated Product Manager to make critical trade off decisions. Your Takeaway Agile projects utilize the concept of an ambassador user, subject matter expert (SME), or customer proxy to play the role of product manager. The idea is that a person or group needs to be readily available to answer questions and make decisions on the project. Reference: 277

278 Risk Area 3: Scope Creep Scope creep occurs in agile projects just the same as other frameworks methodologies such as waterfall. As the project build phase progresses, scope creep occurs in the form of the requirements inflating over time in a way that extends the finish date of releasable software. What it means As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines. Recommended Solution Constantly involve your customers and developers. Challenge them on items that appear to be the most difficult requirements. Your Takeaway Agile projects plan in the regular trade-off discussions about features and estimates at every iteration boundary. Changes and requirements inflation are accepted as a fact of software projects and must be aggressively monitored by the agile practitioner. 278

279 Risk Area 4: Personnel Loss Loss of key stakeholders, the Scrum Master, the main executive champion of the project or even the customer can result in a risk to the project that must be addressed. What it means Key personnel leave the project taking critical information with them that significantly delays or derails the project. Recommended Solution Increased collaboration and information sharing on the team so that no one person or group keeps all of the knowledge in their heads. Your Takeaway Agile projects practice information sharing techniques and frequent reporting at daily stand-ups specifically to reduce the risk that only one person has specific knowledge to a feature. 279

280 Risk Area 4: Personnel Loss - Mitigation Techniques As the old saying goes, think about what would happen if a critical team member were to get hit by a bus or was to win the lottery. These information sharing techniques are a good way to reduce the risk that comes from knowledge sitting in the head of only one person: Pair Programming Pair programming is an agile technique in which two programmers work together at the same workstation. One person is the Driver, who writes the code, and the other is the Observer, or Navigator, who reviews each line of code as it s typed. The two people change roles frequently. Collective Code Ownership Collective code ownership states that, we are a community that owns the code. The expectation is one of a single style across the team so that any team member can modify the code at any time. Although this is a proactive way to mitigate personnel loss, it does cause consternation among team members who maintain a pride in ownership. 280

281 Risk Area 4: Personnel Loss - Mitigation Techniques Collective Code Ownership (cont d) This is an argument not only that a team should pair and explore the project's code, but also that they should be doing so at all times. The team should always be able to cover for members who are disrupted by family emergencies or personal illness. Your Takeaway Agile projects practice information sharing techniques and frequent reporting at daily stand-ups specifically to reduce the risk that only one person has specific knowledge to a feature. 281

282 Risk Area 5: Productivity Variation Productivity variation results from a difference between the actual performance of the team and the planned or assumed performance. Productivity variation manifests itself in the form of timeline extensions, additional iterations and/or the need to retrain members of the team. What it means Given long project timelines, the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained. In addition, incorrect estimates can lead to this effect. Recommended Solution Keep your iterations short, place the right people on the team, and keep the team involved by playing the role of a servant leader and coach. Your Takeaway By having short iterations, work is time boxed into a manageable iteration (typically 1-4 weeks) and there is always a sense of urgency. 282

283 Other Factors that Influence Productivity Agile methods do not specifically address getting the right people on team, coaching and team development, but core leadership roles applicable to both agile and traditional projects. While acting as a coach and servant leader, keep in mind these potential risks to productivity: Parkinson s Law Parkinson s law is an adage coined in a 1955 essay by Cyril Northcote Parkinson which states that Work expands so as to fill the time available for its completion. Another way to consider this concept is: The amount of time which one has to perform a task is the amount of time it will take to complete the task. In other words: In a software project, there s inherent risk in knowing your deadline to complete the work before you estimate and perform the work. Knowing the deadline up front can allow human nature to operate at a natural pace which may actually finish early. The Scrum Master should keep in mind that agile estimation techniques should be used to help mitigate this risk. Reference 283

284 Other Factors that Influence Productivity Student Syndrome Student Syndrome is a concept established by Eliyahu M. Goldratt in his novel Critical Chain. It states that people will start to fully apply themselves to a task just at the last possible moment before a deadline. This leads to wasting any buffers built into individual task duration estimates. Student syndrome is similar to procrastination, however it originates from more altruistic intentions. For instance, a student may ask a professor for an extension on a project so that it can be delivered with higher quality. But in the final analysis, procrastination does set in and the new deadline approaches with the student finding themselves in the same situation that they began. In project and task estimating, student syndrome is manifested in a time- or resource-buffer that is wasted as a late start rather than a reserve for a late finish. Reference: 284

285 3. Risk Response Strategies In the preceding pages, we have shown that risk is ever-present, even in agile projects. We have also suggested that the agile framework is set up to provide constant opportunity to mitigate the risk. But how, exactly? In the following pages we recommend specific PMI process strategies to identify and address project risk. Following those pages is a discussion of a number of risk management tools used by the agile practitioner. 285

286 Risk Management Planning PMI s Project Management Professional (PMP) knowledge framework defines risk management planning as Increasing the probability and impact of positive events, and Decreasing the probability and impact of adverse events. Risk management planning processes: Planning risk management Identify risks Perform qualitative risk analysis Perform quantitative risk analysis Planning risk responses Monitoring and controlling risk PMBOK Says. Because neither the agile framework nor PMI directly address risk management techniques, the PMBOK guide is used for reference in the exam. Source: A Guide to the Project Management Body of Knowledge (PMBOK Guide ), 5 th Edition (2013 Project Management Institute, all rights reserved) 286

287 Risk Response Strategies So if risk must be taken on to stay competitive, what options are available to the agile practitioner to identify and mitigate risk on their projects? The image below introduces the risk response strategies that are used. The following pages review each strategy in greater detail. Acceptance The risk is low enough that we will do nothing about the risk unless it occurs. Accept Risk Avoid Avoidance Make the risk less significant by shutting down the situation or scope that generates the risk. Transference Outsourcing or handing off the risk to a different group Transfer Reduce Reduction Lessening the severity of the loss or the likelihood of the loss from occurring 287

288 Risk Response Strategies - Acceptance Risk acceptance means that you accept or absorb the loss that ensues from a risk when it occurs. At the same time, any positive benefits are also absorbed, although generally there is more loss than gain. Other characteristics of risk acceptance: It s a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. Self Insurance is an example of acceptance. All risks that are not avoided or transferred are retained by default. An example is an insurance deductible: Anything not covered due to the deductible becomes a retained risk, while the insured amount is transferred. 288

289 Risk Response Strategies - Avoidance Risk avoidance means that you choose to not perform the activity that carries the risk. You withdraw from the risk altogether by shutting down the scope involved or eliminate the department responsible for the risk. It s a decision to withdraw from or stop involvement with by closing down that feature. Avoidance may seem to be a good answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits. Examples of risk avoidance: Choosing to not develop a feature that would introduce the risk of rework, feature creep or litigation with a competitor. The agile framework is structured to intrinsically mitigate this risk by promoting iterative development and retrospectives. Electing to not outsource your software development or QA work to eliminate any risk of communication or language concerns that would extend the timeline. 289

290 Risk Response Strategies - Transference Risk transference can be considered as the corollary to acceptance. In the example of an insurance deductible that s the accepted part of the risk, all items covered by the insurance policy are risks that are transferred to the insurer (the third party.) Transference is also known as risk sharing. In the example of a third-party insurer, the onus of owning the risk financially is with the insurer, however in most situations the legal liability is still retained by the buyer of the contract. Examples of risk transference: The outsourcing of some development to a third party under a service level agreement (SLA) that is beneficial to your timeline or exposure is an example of the transference of risk. Note that outsourcing models can potentially add risk to the project by simply transferring the original risk to another group that still could impact your deliverables or timeline if the risk occurs. 290

291 Risk Response Strategies - Reduction Also known as optimization, risk reduction means reducing the severity of loss or the likelihood of loss from occurring. Since it s not practical to completely eliminate or absorb risks, reduction aims to strike a balance between negative risk and the benefit of the operation or activity, and the risk reduction and effort applied. Avoidance may seem to be a good answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits. Software methodologies such as Waterfall suffered from the fact that they only delivered software in the final phase of development. Any problems encountered in earlier phases meant costly rework and often jeopardized the entire project. By developing in iterations, agile projects can limit effort wasted to a single iteration. 291

292 Risk Management Tools Used in Agile Some may be concerned that agile or Scrum ignore risk management completely, and in fact PMI s PMBOK guide is necessary for referencing risk mitigation techniques. Although the agile framework does not explicitly reference risk management techniques, it does so implicitly throughout the framework through its various process and tools. This section references two such tools that are necessary items in the Scrum Master s toolkit when risk management is involved. Risk burn-down charts A risk burn-down chart is created by plotting the sum of the risk exposure values from a census of the top risks identified for the project. It is a graphic visualization that looks similar to the burn-down charts that we have shown in previous modules. Risk-adjusted backlog The Risk Adjusted Backlog focuses on where investment needs to be undertaken, based on risk. A risk assessment database process provides a decreasing list of priorities from the risk calculation: Potential Consequence x Likelihood. 292

293 Risk-Adjusted Backlog In an Agile environment it is the joint responsibility of the whole team to identify risks on an iterative (sprint) basis. The Risk-adjusted backlog is a tool that involves the collection of three data points Listing of each risk to the project Assigning a likelihood score (probability of rich occurrence) Assigning a consequence (impact/size of loss in days) and then calculate a risk score (called as risk exposure, in days) The backlog is then revisited during each iteration with the data values updated. The resulting backlog and burn-down chart are shown on the following pages. 293

294 Preparing your backlog for a Burn-down The first step of creating a risk burn-down chart is to prepare the data in the form of a risk matrix, shown below. This can be done in a simple spreadsheet. Just as with a traditional burn-down chart, the exposure levels should be gathered on a frequent, consistent basis. Risk Probability of Risk (%) Size of Loss (days) Risk Exposure (days) The features to be developed may require the purchase of 3 rd party tools to develop. There will not be enough time for the customer to provide adequate feedback on feature A, which will increase the likelihood it will be considered an unacceptable deliverable at release time. Partner C may require additional testing time across all operating systems. Validation of the features by Partner B will not be completed in time. 20% % % % 5 2 Exposure:

295 The Risk Burn-down Chart The final step is to create the burn-down chart by plotting the sum of the risk exposure values from the census as a frequent occurrence Risk Exposure (days) Ideal risk burn-down Actual risk burn-down Series1 Series Iterations 295

296 4. Risk Communication Techniques It is the responsibility of the agile practitioner to communicate clearly, openly and at a high frequency to encourage awareness of the project s risks by the full team. Keep these things in mind as you communicate risks to your team Your goal should not be to act as the sole person (or bottleneck) who manages the intake and communication of all risks. Instead, encourage your team to take collective ownership of the project s risk mitigation strategies. As with other techniques in agile, you should ensure that you create a culture of collaboration and a sense of team. Encourage your team to place themselves in the position of the customer. Risks will emerge most clearly when the team considers all stakeholders and acts as a collective unit to own the mitigation of risks. 296

297 Risk Communication Techniques Use this table to determine when and how each method of risk communication should be performed. Activity Suggested Communication When performed Plan Identify Assess Respond Mitigate Create a checklist or populate the risk backlog with high-risk features. Communicate to the team as an information radiator Decide whether the feature is high-risk or not by engaging knowledge experts and the broader team. If the feature is a high-risk, book risk identification to sprint backlog, otherwise use light methods like brainstorming or the Delphi technique. Add the impact and probability of the risk by including it on the risk backlog. Use concepts similar to planning poker to ensure that there is a consensus on the impact and probability rankings Create responses and make sure they're in proportion to total risk. Communicate with the appropriate stakeholders any and all Once before the project starts Before implementation of the feature After identification During feature implementation Sprint Review acceptances, transferences, avoidance or reduction. Monitor Revisit the risk backlog During each iteration/sprint 297

298 Sample Exam Questions A team of framers on a construction site is unable to determine from the blueprints what should be done with the format of the north-facing wall. They are unable to complete this activity because of: Specification breakdown Inherent schedule risk Incorrect documentation The lack of a scrum master to provide direction You need to quantify the risks on an agile project and use it as an information radiator. You should: Create a risk matrix and then plot a risk burndown chart. Create a RACI chart and then plot a risk burndown chart Paste a detailed risk matrix on the wall for everyone to see. Determine the likelihood of risk and then create a burndown chart.

299 Sample Exam Questions Which of the following is not a risk response strategy in an agile project? Accept Avoid Transfer All are acceptable The scrum master realizes that there is nobody on the team with the skillset required to properly build a feature in an upcoming feature. To keep the project on track, he hires a business partner overseas. This is: An unacceptable risk because it transfers the risk to another party An unacceptable risk because it avoids the true problem An acceptable risk as it transfers the risk to another party An acceptable risk because it avoids the problem

300 PMI-ACP Exam Preparation Module 8: Continuous Improvement Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 300

301 Module Overview This final module focuses on the PMI-ACP exam s Value Continuous Improvement framework, which addresses Product, Process and People toward an effort of eliminating waste and achieve quality improvement. In this module: Concepts from Lean Introduction and history Learn how to incorporate Lean into your organization How Lean and Six Sigma can be combined with Agile Kaizen The Kaizen cycle The five levels of kaizen Continuous Improvement Methods in Agile The Sprint Retrospective Method Tailoring Incorporating Feedback 301

302 Module Objectives At the conclusion of this module, you should be able to: Tailor the process to the project by adapting practices for the team, organization culture, and delivery goals in order to ensure that the team is effective within established organizational norms. Incorporate feedback by conducting frequent retrospectives in order to improve process, individual, and team effectiveness. Adjust team composition and work practices to improve efficiency within the existing process with a goal of keeping a team together long term. Remove wasteful process elements by challenging existing process elements in order become more efficient. 302

303 Module Objectives (cont d) At the conclusion of this module, you should be able to: Create systemic improvements by disseminating knowledge and practices across project and organizational boundaries in order to avoid re-occurrence of problems identified, improving the effectiveness of the organization as a whole. Improve team member knowledge and skills by pairing team members in order to improve overall team effectiveness and lowering risk around knowledge silos. Evaluate work efficiency in order to identify opportunities to reduce waste. Experiment with new techniques and process ideas for short periods in order to discover more efficient and effective ways of working. 303

304 Section 1: A History of Lean Why Lean in an Agile Course? Just as we mentioned in earlier modules that the elements of Agile existed in industries besides software years before the Manifesto was born, so too have other elements of Agile s vision: namely, continuous improvement has been a core tenet in many disciplines. Agile is rooted in many concepts that started as Lean. A Brief History of Lean Starting as early as the Industrial Revolution in the mid-1700s, a process to improve quality became a necessity as a result of the transition from manual production to mass production: mass production was shown to initially produce more waste before processes were refined over time. Above: During the Industrial Revolution, Lowell, Massachusetts was the place to be. Here is the inside of one of the old textile mills in the Boott Cotton mills complex. 304

305 A Brief History of Lean It wasn t until the early 1920s in America that Henry Ford became the first person to truly integrate an entire production process. Gone were the days of manual tinkering with parts to yield minor variations in every product delivered. Other automakers caught on and improved upon the process to lower costs, which did occur. But their process improvements with heavier machinery increased throughput times and inventories. Left: Henry Ford s Model T became an American symbol of mass production and its improvements in costs and quality. 305