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

PMI-ACP Exam Preparation Course Introduction

Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 1

© BetterPM.com

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-ACPSM (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-ACPSM) Handbook.

2

© BetterPM.com

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. The various sources of content in this course are separate from PMI but are directly related to the six knowledge domains.

3

Knowledge Domains

Value-Driven Delivery

Stakeholder Engagement

Boosting Team

Performance Practices

Adaptive Planning

Problem Detection and

Resolution

Continuous Improvement

© BetterPM.com

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

© BetterPM.com

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 3-4-5 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)

• Email 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

© BetterPM.com

Outline of Course Modules

Below is a description of all modules in the course. The PMI-ACPSM 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-ACPSM Handbook • Exam Overview: Eligibility and continuing certification requirements.

6

© BetterPM.com


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

© BetterPM.com


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

© BetterPM.com


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

PMI-ACP Exam Preparation An overview of The PMI-ACPSM Exam


© BetterPM.com

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.

11

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.

© BetterPM.com

PMI Agile Certification Eligibility Requirements

12

Requirement Description

General project experience

• 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.

Agile project experience

• 1500 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.

Training in agile practices

• 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. (http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx)

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.

http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx�

© BetterPM.com

The Domains of Knowledge Tested

13

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.

© BetterPM.com

The Knowledge and Skill Levels

14

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.

© BetterPM.com

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. http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx

http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx�

© BetterPM.com

Tools and Techniques Portion

The 60 questions comprising Tools and Techniques cover the following topics:

Tool Examples

Communications Information radiators, team space, agile tooling, osmotic communications for colocated and/or distributed teams, daily stand-ups.

Planning, monitoring and adapting

Retrospectives, task/Kanban boards, time-boxing, iteration and release planning, WIP limits, burn down/up charts, cumulative flow diagrams, process tailoring

Agile estimation Relative sizing/story points, wide band Delphi/planning poker, affinity estimating, ideal time

Agile analysis and design

Product roadmap, user stories/backlog, story maps, progressive elaboration, wireframes, chartering, personas, agile modeling

Product quality Frequent verification and validation, test-driven development, acceptance test-driven development, definition of done, continuous integration

© BetterPM.com

Tools and Techniques Portion (cont’d)

The 60 questions comprising Tools and Techniques cover the following topics:

Tool Examples

Soft skills negotiation Emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership

Value-based prioritization

Return on Investment (ROI,) net present value (NPV,) internal rate of return (IRR,) compliance, customer-valued prioritization, minimally marketable feature (MMF,) relative prioritization, ranking.

Risk management Risk-adjusted backlog, risk burn down graphs, risk-based spike

Metrics Velocity, cycle time, earned value management (EVM) for agile projects, escaped defects.

Value stream analysis Value stream mapping

© BetterPM.com

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

© BetterPM.com


Project and quality standards for Agile projects Stakeholder management Team motivation Time, budget and cost estimation Value-based decomposition and prioritization

© BetterPM.com


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

© BetterPM.com


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

PMI-ACP Exam Preparation Module 1: Introduction to Agile


© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

26

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.

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.

© BetterPM.com

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

© BetterPM.com

A Typical “Waterfall” Project Lifecycle

Why the name waterfall? Because other than some iterations in the build and test phases, everything flows downstream and doesn’t return.

28

Feasibility

Requirement

Test

Design

Build

Deploy

Errors and Rework

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.

© BetterPM.com

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.

© BetterPM.com

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:

http://www.agilealliance.org/the-alliance/the-agile-manifesto/

“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.”

http://www.agilealliance.org/the-alliance/the-agile-manifesto/�

© BetterPM.com

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.

© BetterPM.com

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.

© BetterPM.com

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: http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/

http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/�

http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/�

© BetterPM.com

Differences Between Waterfall and Agile

Waterfall Agile Plan driven Learning driven

Infrequent team communication Continuous team communication

Deliver once, Big design up front, typically 9-12 months

Deliver smaller, business focused phases, usually 1-2 months

Development done by layers, presentation, persistence, business, etc.

Develop end-to-end functional slices

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.

© BetterPM.com

Differences Between Waterfall and Agile

Waterfall Agile Integration occurs at the completion of each layer

Continuous integration (daily builds)

Testing occurs at the end of the project, mostly functional testing

Fully automated, continuous testing, unit level and functional testing

High cost to change Low cost of change

Must nail down requirements up front Expects, accommodates, changes to requirements

“Big Design Up Front” (also referred to as ‘Big Requirements up Front’)

“Rough Design Up Front”

© BetterPM.com

Agile Manifesto Tenets

Individuals and Interactions

Working Software

Customer Collaboration

Responding to Change

Process and Tools

Comprehensive Documentation

Contract Negotiation

Following a Plan

Over

Over

Over

Over

As you prepare for the exam, keep in mind these key items favored by the agile framework over the waterfall model.

Strong, collaborative teams

Over Individual Work Packages

Agile Waterfall

© BetterPM.com

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.

© BetterPM.com

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

Extreme Programming

(XP)

Pragmatic Programming

Agile Modeling

Scrum

Scrum implies Agile, but Agile does not imply Scrum. Scrum is an agile management technique.

A Note on Terms Examples of

Agile variations

© BetterPM.com

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 Work1 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 Today2, May 2011)

1: http://www.amazon.com/gp/product/0230308163/ref=as_li_ss_tl?ie=UTF8&tag=stevdenndotco-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0230308163 2: http://www.agileaustralia.com.au/AgileTODAY/Volume/2011/AgileTODAY-Vol-1-MAY-2011.pdf

http://www.amazon.com/gp/product/0230308163/ref=as_li_ss_tl?ie=UTF8&tag=stevdenndotco-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0230308163�

http://www.agileaustralia.com.au/AgileTODAY/Volume/2011/AgileTODAY-Vol-1-MAY-2011.pdf�

© BetterPM.com

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

© BetterPM.com

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.

© BetterPM.com

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.

© BetterPM.com

Scrum Lifecycle

2-4 weeks

Daily

Product Backlog as prioritized by the Product Owner These items are not necessarily the same relative size

Sprint Backlog Backlog tasks created by team

[Potentially] Shippable Product Increment

Daily Scrum Meeting or Standup

Sprint, or “Iteration”

© BetterPM.com

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




Code the 9 points

Test the 8 points

Code the 2 points

Code the 8 points

Test the 8 points

Test the 8 points

Code the 9 points

Code the 2 points

Test the 5 points

Test the 5 points

Code the 2 points

Test the 5 points

Code the 9 points

Code the 9 points

Code the 2 points

Test the 8 points

Code the 2 points

Test the 5 points

© BetterPM.com

Confused Yet? Agile, XP, Scrum, etc.

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

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.

© BetterPM.com

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.

© BetterPM.com

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

© BetterPM.com

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!”

© BetterPM.com

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.”

© BetterPM.com

Chickens and Pigs Today

The Official Scrum Rulebook1 (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: http://www.scrum.org/Scrum-Guides

© BetterPM.com

Scrum Roles

Scrum Roles

Scrum Master Team

Members

Users

Product Owner

Stakeholders

© BetterPM.com

Scrum 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

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.

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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!

© BetterPM.com

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.

© BetterPM.com

Variations of Agile

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

In the short lifespan of the Agile name, a large number of variations have emerged, each with their own rules and idiosyncrasies.

http://en.wikipedia.org/wiki/Velocity_(software_development)�

http://en.wikipedia.org/wiki/Dynamic_systems_development_method�

http://www.ivarjacobson.com/Software_Process_Simplification�

http://en.wikipedia.org/wiki/Agile_Unified_Process�

http://www-01.ibm.com/software/awdtools/rup�

http://www.eclipse.org/epf/general/OpenUP.pdf�

http://en.wikipedia.org/wiki/Feature-driven_development�

http://www.agilemodeling.com/�

http://www.scrumalliance.org/learn_about_scrum�

http://www.extremeprogramming.org/�

© BetterPM.com

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

▫ http://scaledagileframework.com/

http://scaledagileframework.com/�

© BetterPM.com

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

© BetterPM.com


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? •5 •20 •60 •3

PMI-ACP Exam Preparation Module 2: Agile in Action


© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

Scrum Roles

Scrum Roles

Scrum Master Team

Members

Users

Product Owner

Stakeholders

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.

© BetterPM.com

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”

© BetterPM.com

User Stories

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.

One tool used is a simple document template called a Story Card.

Information on a Story Card:

As a: ________ I want to:______ So that:________

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.

© BetterPM.com

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.

© BetterPM.com

Estimating User Stories/Backlog

1 2 3 5 8 13 20 40 100

Defects, small enhancements, etc.

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 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.

May or may not need to be decomposed further.

Large User Stories

© BetterPM.com

Product Backlog – Estimating Stories

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.

A B C D E

© BetterPM.com

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.

© BetterPM.com

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.

© BetterPM.com

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.

© BetterPM.com

Anatomy of a Sprint

Release every sprint Daily Scrum every 24 hours

Part of Product backlog becomes Sprint backlog.

Sprint Planning Sprint Retrospective

Sprint Review

2-4 week duration

© BetterPM.com

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.

© BetterPM.com

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.

© BetterPM.com

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.

76

0

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9 10 11

Iteration Timeline/Sprint

Rem

aini

ng E

ffort

Planned Actual

© BetterPM.com

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.

Daily Scrum Meeting

© BetterPM.com

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.

Daily Scrum Meeting

A reminder that other Agile methodologies may refer to the Daily Scrum as the Daily Stand-up Meeting.

© BetterPM.com

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 burn-down chart. If this data is not referenced in the meeting, there is a risk that the team will lose focus during the sprint.

79

© BetterPM.com

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.

© BetterPM.com

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, http://www.agilemodeling.com

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:

http://www.wiley.com/WileyCDA/WileyTitle/productCd-047127190X.html Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. Ambler, Scott W. John

Wiley & Sons, 2002.

http://www.agilemodeling.com/�

http://www.wiley.com/WileyCDA/WileyTitle/productCd-047127190X.html�

http://www.ambysoft.com/books/agileModeling.html�

© BetterPM.com

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.

© BetterPM.com

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#: 0471202827

© BetterPM.com

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 0-13-067634-9

© BetterPM.com

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.

© BetterPM.com

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.

PMI-ACP Exam Preparation Module 3: Value Driven Delivery


© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

Module Objectives


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

© BetterPM.com

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: http://www.agilebok.org/index.php?title=Value_Based_Analysis

91

http://www.agilebok.org/index.php?title=Value_Based_Analysis�

http://www.agilebok.org/index.php?title=Value_Based_Analysis�

© BetterPM.com

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

© BetterPM.com 93

Plan Driven

Value Driven

Agile Waterfall

Estimated Resources Time Features

Fixed Requirements Resources Time

In comparison with waterfall, agile flips the triangle in terms of what’s fixed and estimated.

VBA: Value-driven versus Plan-Driven Planning

© BetterPM.com

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

© BetterPM.com

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 Driven Planning

95

Performance

Valu

e

Pay particular attention to this image; we will revisit it later in the course as we discuss “Just Barely Good Enough.”

© BetterPM.com

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.

Plan Driven Planning

96

Performance

Value Release Milestone

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.

© BetterPM.com

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.

97

Cost Benefits Value = 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.

© BetterPM.com

Types of Value

98

Type Definition Example

Intrinsic An objective, actual value that has the same value or price among people.

Commodities such as precious metals

Extrinsic or Instrumental

A subjective value placed on an item due to some external event or personal experience.

Mementos; family pictures

Market The value of an object that others are willing to pay for in competition.

Artwork on the secondary market.

Book The value as placed by an objective third party.

Kelly Blue Book value of a used car.

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.

© BetterPM.com

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:

99

Value Anti Value

Water-tight boat hull epoxy Cracks in the hull

Fuel efficient gasoline Rogue particulates from the refinement process

High strength concrete Ineffective pouring methods

Bug-free product code Incomplete code branches at launch

© BetterPM.com

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.

100

Validation Verification The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.

The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation

From A Guide to the Project Management Body of Knowledge (PMBOK Guide) 4th edition

© BetterPM.com

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

© BetterPM.com

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: http://www.endeavourengineeringtech.com/services/value-stream-analysis-lean-management

102

© BetterPM.com

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.

2. Identify the high level steps, inventories and queues through the process focusing on the primary flow

103

You You in your car

You You in your car

Car Selection

Financing application Closing

© BetterPM.com


3. Identify any supporting groups and alternative flows. Think about what happens if there is re-work or a change of plans.

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

You You in your car

Car Selection


Sales Dealers

Denial of financing: Look for a different model

© BetterPM.com


4. Measure the Value Adding and Non Value Adding activities, calculate efficiencies, identifying waste, bottlenecks and improvement actions.

You You in your car

Car Selection


Sales Dealers

Value Add Non Value Add

4 hours 1 hour 2 hours

1 day 1 hour 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%

© BetterPM.com

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

© BetterPM.com

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.

107

For more information on Emergent Design: See this Wikipedia article: http://en.wikipedia.org/wiki/Emergent_Design

© BetterPM.com

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

© BetterPM.com

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.

109

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

© BetterPM.com

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.

110

How it Works

“Signals” are used to tell the producer what to produce, when to start, and what the quantity should be.

© BetterPM.com

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 email

notifications to generate the production signal.

111

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

© BetterPM.com

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.

117

Reference: http://www.agile-ux.com/2011/04/19/10-strategies-to-split-large-user-stories/

© BetterPM.com

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

http://www.dreamstime.com/royalty-free-stock-photography-people-different-culture-talking-group-image22146067�

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

121

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: http://en.wikipedia.org/wiki/Kano_model

© BetterPM.com

The Kano Model of Customer Satisfaction

Performance Needs

Excitement

Basic Needs

Cus

tom

er S

atis

fact

ion

Quality Low

H

igh

Absent Provided

Product is dysfunctional

Product fully dysfunctional

Customer fully satisfied

Customer dissatisfied

Customer Indifference

© BetterPM.com

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

© BetterPM.com

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 http://www.erdm.com/creating-integrated-marketing-solutions.05.php5

124

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

Incremental Delivery

127

Time

Value

ROI remains high in the early stages of planning

Long-term value increases as a result of planning.

Compared to a Waterfall approach, incremental delivery provides quick wins and a steady stream of value add.

Solid lines represent releasable deliverables to the customer.

© BetterPM.com

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

© BetterPM.com

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 , Rt ) 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

© BetterPM.com

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

© BetterPM.com

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.

© BetterPM.com

Decision Rule

As a stand-alone tool to compare an investment to "doing nothing,“ payback period has no explicit criteria for decision-making

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 + ny = 1 + ny - n÷p Where ny= 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

© BetterPM.com

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

133

Citation: http://www.reference.com/motif/science/discounted-payback-period-formula

© BetterPM.com


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

© BetterPM.com

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.

PMI-ACP Exam Preparation Module 4: Stakeholder Engagement


© BetterPM.com

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

© BetterPM.com

Module Objectives


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

© BetterPM.com

Module Objectives (continued)


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

© BetterPM.com

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

© BetterPM.com

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.

141

Colleagues

Customers

Community

© BetterPM.com

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

© Better PM.com / Innate Images, LLC

Empowering your Stakeholders

143

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-to-face 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.


How can a Stakeholder Raise an Issue?

144

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




Code the 9 points

Test the 8 points

Code the 2 points

Code the 8 points

Test the 8 points

Test the 8 points

Code the 9 points

Code the 2 points

Test the 5 points

Test the 5 points

Code the 2 points

Test the 5 points

Code the 9 points

Code the 9 points

Code the 2 points

Test the 8 points

Code the 2 points

Test the 5 points


Stakeholder Roles

145

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.


Help your Stakeholders Ensure Value

146

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.


Types of Stakeholders

147

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.

© BetterPM.com

Example of the relationship between the stakeholders and the project:

Who are stakeholders? (cont’d)

Other Stakeholders

Portfolio Manager

Program Manager

PMO Project

Management Office

Operations Management

Functional Managers

Sellers/ Business Partners

Users/ Customers

Sponsor

Project Management

Team

Other Project Team

Members

The Project

Project Team

Project Stakeholders

Project Manager

Source: A Guide to the Project Management Body of Knowledge (PMBOK® Guide ), 5th Edition (2013 Project Management Institute, all rights reserved)


Types of Stakeholders – The Business

149

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.


Types of Stakeholders – The Customer

150

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.


Types of Stakeholders – Domain Experts

151

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.


Types of Stakeholders – Developers

152

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.


Types of Stakeholders – End Users

153

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.

© BetterPM.com

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

© BetterPM.com

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.

Factors Affecting Stakeholder Involvement

155

Source: http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm

© BetterPM.com

Factors Affecting Stakeholder Involvement

156

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: http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm

© BetterPM.com

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.

Participatory Decision Making

157

PDM can be used in: • Team retrospectives • Stand-ups • Customer demos

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

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

160

The project overview document goes by many different names in different organizations. It is not a key PMI term.

© BetterPM.com

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.

161

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.

© BetterPM.com

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

© BetterPM.com

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.

163

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.

Remember that Agile promotes the minimizing of waste. You should document the project, but do not over-document.

So, what should you document? • Information that is owned by a single source • System overview documents • Executable specifications

© BetterPM.com

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

© BetterPM.com

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.

165

Waterfall Agile

Stakeholder Roles Categorized according to four levels using a RACI Chart: Responsible, Accountable, Consulted, Informed

Categorized according to potential impact to the project.

Involvement Style

More communicative than collaborative

Requires continuous communication and involvement

Awareness of development model

Most stakeholders have an understanding their expected role in a waterfall project.

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!” http://www.scrumalliance.org/articles/79

© BetterPM.com

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

© BetterPM.com

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: 0300125283 ISBN-13: 978-0300125283

167

© BetterPM.com


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.

© BetterPM.com


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

PMI-ACP Exam Preparation Module 5: Boosting Team Performance Practices


© BetterPM.com

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

© BetterPM.com

Module Objectives


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

© BetterPM.com



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

© BetterPM.com



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

© BetterPM.com

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.

175

Product Management Team

Product Owner Team

Architecture Team

SMEs/DBAs/Developers

Supporting Cast (integrator, testers, domain experts)

Working System Produced

http://www.istockphoto.com/stock-illustration-19354210-teamwork.php?st=cca16ed�

© BetterPM.com

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.

176

Many Levels = Many DoDs

Feature: Story or product backlog item

Sprint: Collection of features

developed in the sprint Release: Potentially shippable state

© BetterPM.com

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

© BetterPM.com

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: http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod

178

http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod�

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

181

Positives Negatives

Enables creative problem solving

One team member may begin to dominate

Scalable Can lead to unnecessary meetings just to be democratic

A wide range of skill levels and ideas

Egos are in play

Empowered to evolve the DoD as solutions are found

Time may be wasted with talking instead of working.

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

184

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.

© BetterPM.com

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 1970. • “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

Tools to Keep the Team Strong – Emotional Intelligence

© BetterPM.com

Healing

Characteristics of Servant Leadership

Awaeness

Healing

Listening

Foresight

Stewardship

Building Community

Commitment to the growth of

people Awareness

Guru/subject matter expert

Conceptualization

Persuasion

186

http://www.istockphoto.com/stock-illustration-19447025-business-management-strategy-and-human-resource-icons-prime-series.php?st=02f644a�

http://www.istockphoto.com/stock-illustration-19139545-human-head-with-wheel.php?st=0f2bc72�

© BetterPM.com

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.

187

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.

© BetterPM.com

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

© BetterPM.com

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.

189

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.

For the Exam

© BetterPM.com

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:

190

Element Description Honesty The team member acts with integrity and upholds

core values. Openness Open to share, learn new things, consider

alternate approaches Consistency Behavior and reactions that come to be expected.

Respect Treat people with the dignity and fairness that would be expected in return.

© BetterPM.com

From Forming to Performing

Forming

Storming

Norming

Performing

191

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.

Reference: Tuckman, Bruce: “Developmental Sequence in Small Groups” Psychological Bulletin, 63, 384-399 (1965)

© BetterPM.com

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 buy-

in 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

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

195

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.

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.

Interesting Note: a 5th Phase

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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

198

“Individuals and interactions over process and tools.” “Customer collaboration over contract negotiation.”

Remember the Manifesto

© BetterPM.com

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.) 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

Release Planning Meeting Inputs Outputs

© BetterPM.com

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.) 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

• Many teams arrive at an “iteration 0” which allows the opportunity to work through technical and logistical issues.

200


© BetterPM.com

Release Planning FAQs

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


© BetterPM.com

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. 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

Iteration Planning Meeting Inputs Outputs

© BetterPM.com

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. 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

Iteration Planning Meeting Inputs Outputs

© BetterPM.com

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.

204

* Reference: http://www.agilecoachjournal.com/index.php/2012-04-26/teams/managing-technical-dependencies/

http://www.agilecoachjournal.com/index.php/2012-04-26/teams/managing-technical-dependencies/�











© BetterPM.com

Iteration Planning FAQs (Cont’d)

How do you account for overhead such as email, 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

© BetterPM.com

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

© BetterPM.com

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.

207

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.

© BetterPM.com

Daily Standup Meeting – Other Characteristics

208

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.

© BetterPM.com

Daily Standup Meeting – Other Characteristics

209

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.

© BetterPM.com

Daily Standup Meeting – Example Impediments

210

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 3rd 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.

http://www.istockphoto.com/stock-photo-19765747-arrow-through-the-wall.php?st=7c23fb3�

© BetterPM.com

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.

211

This meeting is also known as the “Iteration Review” or the “Sprint Review.”

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.

© BetterPM.com

Review/Demo Meeting – Inputs and 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

Iteration Review Meeting Inputs Outputs

© BetterPM.com

Review/Demo Meeting – Inputs and 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

Iteration Review Meeting Inputs Outputs

© BetterPM.com

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.

214

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.

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.

© BetterPM.com

Retrospective Meeting – Inputs and 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.

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

Retrospective Meeting Inputs Outputs

Retrospective Meeting Inputs Outputs

© BetterPM.com

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

© BetterPM.com

Leadership Techniques for Team Commitment

The agile practitioner evolves his team from the perspective of: 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 2008. http:/www.shuhari.com/site/view/ShuharisMeaning.pml

217

Teaching Coaching Advising

http://www.shuhari.com/site/view/ShuharisMeaning.pml�

© BetterPM.com


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

PMI-ACP Exam Preparation Module 6: Adaptive Planning


© BetterPM.com

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

© BetterPM.com

Module Objectives


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

© BetterPM.com



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

© BetterPM.com



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

© BetterPM.com

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.

224

Predictive Waterfall

Mindset Approach

Adaptive Agile

© BetterPM.com

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

© BetterPM.com

The Five Levels of Planning

Portfolio

Product Roadmap

Release

226

Level What it is Frequency Who

Vision Statement 1x-2x/year Product Owner and Executives

Product evolution over Time

1x-2x/year Product Owner and Executives

Features/User Stories

3x-4x/year Team, Product Owner, Stakeholders

© BetterPM.com

The Five Levels of Planning

Iteration

Day

Release

227

Level What it is Frequency Who

Features (user Stores and tasks)

Tasks, Burndown/to-do items

Every day The team

Every Iteration Team and Product Owner

© BetterPM.com

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

228

Portfolio

Product Roadmap

Release

Iteration

Day

© BetterPM.com

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.

229

Effort/Time

Ret

urns

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.

© BetterPM.com

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.

230

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: http://www.agilemodeling.com/essays/barelyGoodEnough.html

http://www.agilemodeling.com/essays/barelyGoodEnough.html�

© BetterPM.com

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. http://availagility.co.uk/2010/04/06/defining-the-last-responsible-moment/

231

http://availagility.co.uk/2010/04/06/defining-the-last-responsible-moment/�

© BetterPM.com

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.

232

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.

Keep in Mind:

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.

© BetterPM.com

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.

233

Many characteristics of successful adaptive planning will remind you of the necessary team dynamics covered in module 4: collaboration, commitment, empowerment

• 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?

© BetterPM.com

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

© BetterPM.com

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.

235

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.

http://www.istockphoto.com/stock-photo-12212118-closed-road-with-stop-sign.php?st=2274121�

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

238

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.

http://www.istockphoto.com/stock-photo-5575794-navigator-with-sextant.php?st=28e9a6a�

© BetterPM.com

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

© BetterPM.com

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.

240

Now 1 month 3 months 1 year 2 years

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

© BetterPM.com

Progressive Elaboration

241

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.

Now 1 month 3 months 1 year 2 years

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

“Tasky” plans Higher level items and milestones Completed Work

© BetterPM.com

Continuous Planning

242

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

Release Planning

Iteration Planning

Daily Stand-up

Release

Iteration

Daily Work

Task Completion

Project Retrospective

Release Retrospective

Iteration Demos, Reviews, Retrospective

Daily Work Updates

Product Road Mapping

Release Planning

Iteration Planning

Daily Standup

Product Retrospective

Release Retrospective

Iteration Demos, Reviews, Retrospective

Daily Work Updates

© BetterPM.com

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

© BetterPM.com

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.

244

Information on a Story Card:

As a: ________ I want to:______ So that:________

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

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

247

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.

Poker with Points

© BetterPM.com

Ideal Time

Consider the typical eight-hour workday: How many hours or productive time do you get in, on average, between checking your email, 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

© BetterPM.com

Tools used in Agile Estimation: Point to Scale

1 2 3 5 8 13 20 40 100

Defects, small enhancements, etc.

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 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.

May or may not need to be decomposed further.

Large User Stories

Recall from Module 1 this mechanism for estimating user stories.

Exponential Sequence Estimations

© BetterPM.com

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:

• Product Owner • Delivery Team • Scrum Master

How it works • 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

Small Medium

Large

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

Product Backlog prioritized by Product Owner

Sprint Backlog

© BetterPM.com

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.

254

“Iteration” = “Sprint”

© BetterPM.com

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 • Features are intended behaviors of software or a system that is documented in the

design. Task

• 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

© BetterPM.com

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

© BetterPM.com

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.

257

0

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9 10 11

Series1

Series2

Ideal Actual

Iteration

Effo

rt

© BetterPM.com

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.

258

0 5

10 15 20 25 30 35 40 45

2010

0908

2010

0915

2010

0922

2010

0929

2010

1006

2010

1013

2010

1020

2010

1027

2010

1103

2010

1110

Stor

y Po

ints

Sprint Name

Velocity vs. Work Capacity Trend

Velocity Work Capacity

• 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.

© BetterPM.com

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

© BetterPM.com

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:

http://www.flickr.com/photos/jackdorsey/182613360/

http://www.flickr.com/photos/jackdorsey/182613360/�

© BetterPM.com

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.

© BetterPM.com


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.

© BetterPM.com


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. http://www.balsamiq.com/products/mockups

© BetterPM.com

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

Cycle Time

264

A common workflow for the typical agile team

© BetterPM.com


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

© BetterPM.com


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.

PMI-ACP Exam Preparation Module 7: Problem Detection and Resolution


© BetterPM.com

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

© BetterPM.com

Module Objectives


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

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

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.

272

- 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.

© BetterPM.com

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

© BetterPM.com

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.

274

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.

The 5 Core Risk Areas

© BetterPM.com

The 5 Core Risk Areas Common Across All Software Projects

In their 2003 book Waltzing With Bears: Managing Risk on Software Projects1, 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.

275

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.

http://www.amazon.com/Waltzing-Bears-Managing-Software-Projects/dp/0932633609

© BetterPM.com

Risk Area 1: Intrinsic Schedule Flaw

276

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.

© BetterPM.com

Risk Area 2: Specification Breakdown

277

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: http://www.projectsmart.co.uk/top-five-software-project-risks.html

© BetterPM.com

Risk Area 3: Scope Creep

278

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.

© BetterPM.com

Risk Area 4: Personnel Loss

279

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.

© BetterPM.com

Risk Area 4: Personnel Loss - Mitigation Techniques

280

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.

© BetterPM.com

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

Risk Area 4: Personnel Loss - Mitigation Techniques

© BetterPM.com

Risk Area 5: Productivity Variation

282

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.

© BetterPM.com

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 http://en.wikipedia.org/wiki/Parkinson's_law

283

© BetterPM.com

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: http://en.wikipedia.org/wiki/Student_syndrome

284

© BetterPM.com

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?

285

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.

© BetterPM.com

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

Risk Management Planning

PMI’s Project Management Professional (PMP) knowledge framework defines risk management planning as

286

Because neither the agile framework nor PMI directly address risk management techniques, the PMBOK guide is used for reference in the exam.

PMBOK Says….

Source: A Guide to the Project Management Body of Knowledge (PMBOK® Guide ), 5th Edition (2013 Project Management Institute, all rights reserved)

© BetterPM.com

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.

287

Risk

Accept Avoid

Transfer Reduce

Acceptance The risk is low

enough that we will do nothing about the risk

unless it occurs.

Transference Outsourcing or handing off the

risk to a different group

Avoidance Make the risk less significant by shutting down the situation or scope that generates the risk.

Reduction Lessening the severity of the loss or the likelihood of the loss from occurring

© BetterPM.com

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:

288

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.

© BetterPM.com

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:

289

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.

© BetterPM.com

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.

290

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.

© BetterPM.com

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.

291

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.

© BetterPM.com

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

© BetterPM.com

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

© BetterPM.com

Risk Probability of Risk (%)

Size of Loss (days)

Risk Exposure (days)

The features to be developed may require the purchase of 3rd party tools to develop.

20% 10 2

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.

20% 5 1

Partner C may require additional testing time across all operating systems.

25% 20 5

Validation of the features by Partner B will not be completed in time.

40% 5 2

Exposure: 10

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.

294

© BetterPM.com

0

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9 10 11

Series1

Series2

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.

295

Ideal risk burn-down Actual risk burn-down

Ris

k E

xpos

ure

(day

s)

Iterations

© BetterPM.com

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

© BetterPM.com

Use this table to determine when and how each method of risk communication should be performed.

Activity Suggested Communication When performed

Plan Create a checklist or populate the risk backlog with high-risk features. Communicate to the team as an information radiator

Once before the project starts

Identify 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.

Before implementation of the feature

Assess 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

After identification

Respond Create responses and make sure they're in proportion to total risk.

During feature implementation

Mitigate Communicate with the appropriate stakeholders any and all acceptances, transferences, avoidance or reduction.

Sprint Review

Monitor Revisit the risk backlog During each iteration/Sprint

Risk Communication Techniques

297

© BetterPM.com


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.

© BetterPM.com


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

PMI-ACP Exam Preparation Module 8: Continuous Improvement


© BetterPM.com

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

© BetterPM.com

Module Objectives


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

© BetterPM.com

Module Objectives (cont’d)


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

© BetterPM.com

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.

304

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.

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.

© BetterPM.com

A Brief History of Lean

305

Left: Henry Ford’s Model T became an American symbol of mass production and its improvements in costs and quality.

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.

© BetterPM.com

A Brief History of Lean

306

In the 1930s, engineers at Toyota realized that a series of simple innovations might make it more possible to provide both continuity in process flow and a wide variety in product offerings. They revisited Ford’s original thinking and invented the Toyota Production System. Below is a summary of what they did: To avoid overproduction, Toyota right-sized machines for the actual volume

needed. Self-monitoring machines were introduced to ensure quality Machines were lined up in process sequence, pioneering quick setups so

each machine could make small volumes of many part numbers. Established a mechanism where each process step would notify the

previous step of its current needs for materials.

As a result, Toyota was able to obtain low cost, high variety, high quality, and very rapid throughput times to respond to changing customer desires. Also, information management could be made much simpler and more accurate.

© BetterPM.com

Lean Today

307

As lean thinking spreads today, leaders are also adapting the tools and principles beyond manufacturing, to logistics and distribution, services, retail, healthcare, construction, maintenance, and government. Today’s definition of Lean: Lean refers to a set of tools designed to improve flow and reduce waste during a business process or in the manufacturing of a product. Lean can be practiced on its own or as a part of Six Sigma, which is a set of tools designed to control business processes by reducing defects and improving quality.

© BetterPM.com

Variations of Lean

Lean manufacturing – more commonly known simply as “Lean” is a goal that considers the expenditure of resources for any goal other than value to be wasteful, and is therefore target for elimination.

Lean’s goal is to create increased value with the lowest number of resources. Lean Six Sigma is a managerial concept that results in the elimination of the following

seven kinds of waste (aka “muda”) Transportation Inventory Motion Waiting Overproduction Over-processing Defects

308

Who is Tim Wood?

Tim Wood is a mnemonic for learning the seven kinds of waste.

© BetterPM.com

Three Key Features of Lean

The Lean discipline focuses on three key concepts: Waste – Waste is considered the opposite of value and its elimination is a primary goal

of Lean principles. Anything that the customer does not want or that delivers no value is waste.

Complexity – Lean states that simple and straightforward should always be a primary goal. Four items that add complexity are: Quantity of parts (the more parts involved, the higher the complexity) Volume, or size of the process Density, which is the ratio of the process size to the volume, and The Time required to complete a cycle.

Variation – anything in a production that has variation causes waste. Lean strives to identify the cause of variation, which come from System variations – such as a malfunctioning piece of equipment Special cause variations – (an assignable event, such as a weather event closing the factory) Structural variations – such as sales cycles: Q4 holiday shopping revenue versus Q1.

309

© BetterPM.com

Lean as Continuous Improvement

Most concepts of Lean, Six Sigma and the variations of the disciplines all focus on one key outcome: continuous improvement. Improvements that are not repeatable are not considered process improvements that are maintainable.

310

Do

Check Act

Plan One tool that promotes

continuous improvement is the PDCA Cycle, shown at right. This tool for carrying out change has no beginning or end and should be repeated for continuous improvement.

© BetterPM.com

Using Plan-Do-Check-Act

When to use: As a model for continuous improvement. When starting a new improvement project. When developing a new or improved design of a process, product or service. When defining a repetitive work process. When planning data collection and analysis in order to verify and prioritize

problems or root causes. When implementing any change. The Procedure Plan. Recognize an opportunity and plan a change. Do. Test the change and carry out a small-scale study. Check. Review the test, analyze the results and identify what you’ve learned. Act. Take action based on what you learned in the Do step: If the change didn’t

not work, repeat the cycle again with a different plan. If you succeeded, use what you learned to plan new improvements, beginning the cycle again.

311

Do

Check Act

Plan

© BetterPM.com

Being Lean – Minimal Marketable Feature

A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature.

Minimal: If a split results in a story too small to be able to market, it shouldn’t be done. Be sure to agree with your customer on the definition of “done.”

Marketable: Ask yourself if the feature is marketable. Feature: A feature is known as demonstrable behavior of the product.

Something that is perceived by the customer as having value.

What’s the difference between a user story and an MMF? • An MMF doesn’t decompose down into smaller sub-feature, but it is big enough to

launch on its own. • A MMF can be represented as a User Story — a short, one-sentence description. • But in contrast to how a User Story is typically used, the team would not break

down the User Story into smaller User Stories when using MMFs

312

© BetterPM.com

Being Lean – Enterprise Risk Management

Thinking in terms of your organization’s total cost of risk leads to discussion such as regulatory compliance, business continuity and emergency response scenarios.

Strong requirements up front serve as effective inputs to the agile team’s processes, and lead to strong incremental delivery as outputs. Exposing risks early pays off later.

313

© BetterPM.com

Section II: Kaizen

Similar to Lean its goals of continuous improvement is the concept of Kaizen, which is a Japanese philosophy which means “good change,” or “change for the better.” The term was coined by Masaaki Imai in his book Kaizen: The Key to Japan's Competitive Success Kaizen was first implemented in Japan during the restoration period following World War II. The methodology includes making changes and monitoring results, then adjusting. Large-scale pre-planning and extensive project scheduling are replaced by smaller experiments, which can be rapidly adapted as new improvements are suggested. The Toyota Production System mentioned in the start of this module is known for kaizen, where all production line employees are expected to stop the line if an abnormality if found, and then they must suggest an improvement to resolve the abnormality. On the following page is the cycle of kaizen activity, which operates very much like the PDCA model.

314

© BetterPM.com

The Kaizen Cycle

The cycle of activity in kaizen can be defined as: Standardize an operation and activities. Measure the operation (find cycle time and amount of in-process inventory) Gauge measurements against requirements Innovate to meet requirements and increase productivity Standardize the new, improved operations Continue cycle ad infinitum

315

Other Names of the Kaizen Cycle

• Shewhart Cycle

• Deming Cycle

• PDCA

© BetterPM.com

Kaizen Events

An application of the kaizen concept to effect continuous improvement is the use of Kaizen Events. They are an extremely efficient way to quickly improve a process and are also useful for convincing organizations new to Six Sigma. Kaizen Events are commonly referred to as events that: 1) Gather operators, managers, and owners of a process in one place 2) Map the existing process (using a deployment flowchart, in most cases) 3) Improves on the existing process 4) Solicits buy-in from all parties related to the process

The end goal of the kaizen event is to tear down and rebuild a process so that functions more efficiently and with less waste.

316

© BetterPM.com

The Five Levels of Kaizen Events

Kaizen Events can occur at five different levels:

317

Individual

Mini Point Kaizen

Kaizen Blitz

Flow Kaizen

Supply Chain Kaizen

© BetterPM.com

Kaizen Level 1: Individual

Definition: An individual should constantly strive to reduce waste and improve efficiencies from their vantage in the overall process. As kaizen is meant to be a constant process, it requires a personal, long-term commitment to change. How to Use it: • Challenge yourself to learn new skills • Keep a log file, a digital note pad, or use an online blog to record ideas that may help

the team later. • Get out of your comfort zone (yet still adhere to the rules of the project)

318

© BetterPM.com

Kaizen Level 2: Mini Point Kaizen

Definition: At the next level, the individual works with their team to improve a part of the process. This team typically should be the immediate team that he she is involved with, and it works best in groups of six. How to Use it: • The team works to consider changes to a particular process or workflow that has

immediate impact to their daily work experience. • The level is often done as an ad hoc event or potentially as a small workshop on the

spur of the moment. The idea is to come together quickly and brainstorm ideas that could have application to the larger group or process.

319

© BetterPM.com

Kaizen Level 3: Kaizen Blitz

Definition: Also known as the Point Kaizen, the blitz is a larger version of the mini point. The group can be larger, the duration of the meeting can be longer, and larger issues (such as cross functional processes) are discussed. How to Use it: Schedule it is a focused, multi-day event to deliver specific performance

improvements (but it could be shorter than five days). Participants include all the right people to analyze the problem, develop improvement solutions and begin to implement them.

Management must commit to the time and resources required, and to empower the Blitz team to “do what is needed” to achieve improvements.

320

© BetterPM.com

Kaizen Level 4: Flow Kaizen

Definition: Continuing in a natural progression of an increasing audience and larger issues, the flow kaizen addresses departmental or divisional concerns and involves process changes that are cross functional. How to Use it: Executive sponsorship generally initiates the flow kaizen, as it is a significant

transformative event that pulls together thought leadership from all disciplines to address full process cycles.

Flow kaizens are not performed on the spur of the moment, nor are they performed as a part of an Agile project, but individual teams may be called upon to contribute information toward these sessions.

321

© BetterPM.com

Kaizen Level 5: Supply Chain Kaizen

Definition: The supply chain kaizen increases the scope and audience yet again, this time involving other groups and organizations in the overall supply chain. How to Use it: Executive sponsorship from each company or group is mandatory for a supply

chain kaizen. It is likely that you will be made aware of them as part of overall transformational strategies or multi-year visions.

A product manager, consultant and documentation of all existing processes and the other kaizen levels are almost always present.

322

© BetterPM.com

Section 3: Continuous Improvement in Agile

Never underestimate the value of continuous improvement. Agile teams naturally get better over time, and there may be a tendency to skip certain steps or meetings. Yet continuous improvement requires you to constantly strive to do better, which means that even (for instance) a sprint retrospective should still be held even on a highly successful sprint. A good Scrum Master will always find ways for even the most refined process to be improved. And a truly successful agile team is one who constantly evolves by never entering the comfort zone that’s brought on by sticking to “tried-and-tested” methods. Techniques to use to continuously improve: Ensure that you are capturing value from the viewpoint of the customer. Eliminate any steps that detract from the creation of value. Fine-tune each value step that is involved in the creation process. The goal is to deliver

a steady stream of incremental value to the customer. Ensure that your customers are able to see value as a result of each release. Create a system and a culture of continuous improvement.

323

© BetterPM.com

Continuous Improvement with the Retrospective

The Sprint Retrospective is one of the most significant tools in the Scrum Master’s arsenal for ensuring continuous improvement. As a member of the team, it’s important to make sure you contribute to the process and expect the same from your team. If you skip or fail to generate value from the retrospective, you’re likely to fail to improve. Recall the Agile Manifesto • In the first sentence we see, “uncovering better ways.”

– Uncovering better ways likely requires trying new things and seeing how they work. This is where the retrospective is necessary.

• In the 12th principle, we see, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

– It is often called “inspect and adapt,” which start by doing things, learning, and improving along the way.

– Example: Just like you don’t know all requirements up front when you start developing a product, you start working with what is clear and needed and then change based upon the feedback. Retrospectives are a way to “embrace change” in the way you work as a team.

324

© BetterPM.com

Method Tailoring

One distinguishing characteristic that sets agile apart from other disciplines is its embracing of the concept of method tailoring, which allow project teams to adapt working practices according to the needs of individual projects. Method tailoring defined: A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments*

This situation-appropriateness is used explicitly in eXtreme Programming (XP,) which posits that no one process fits every project, but rather that practices should be tailored to the needs of individual projects. * Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use

325

© BetterPM.com

Method Tailoring in Agile

• Potentially all agile methods are suitable candidates for method tailoring. • Keep in mind that many organizations practice a blend of disciplines, with Agile

being among many, and with team members potentially being shared among projects. Variations in an organization’s use of the Agile framework to fit the situation is a good example of real-world method tailoring. ▫ A rigid, one-size-fits-all expectation for every agile project in your company will

likely lead to failures and adoption issues. ▫ Some organizations will adopt agile completely and across the board, whereas

others will have only some product lines perform agile. It is not uncommon to see a mixture of Agile and SDLC practiced in the same company, or for Lean Six Sigma black belts and PMP-certified project managers to be assigned to an Agile team.

326

© BetterPM.com

Incorporating Feedback

Agile methodologies seek customer feedback throughout the life of a project. Projects that run via an agile discipline know that for a project to be successful, the customer will need to be happy. And one way for the customer to be happy is to deliver incremental features to them and get their feedback. According to Jeff Sutherland, one of the principal authors of the Agile Manifesto, “Even when traditional projects finish on time, on budget, with all features in the plan, customers are often unhappy because what they find is not exactly what they wanted.” If you wait until the end of the project to give a preview to the customer, it will be too late and they will be unhappy, which ultimately leads to rework. All types of the agile discipline have built-in processes to ensure that the plans can be changed according to feedback from the customer. The results of the iteration demo should be taken seriously, as this is a key opportunity to hear from the customer.

327

Reference: http://msdn.microsoft.com/en-us/library/dd997578.aspx

© BetterPM.com


True or False: a flow kaizen is designed to be introduced quickly to a company once it realizes it is needed.

•True •False •Velocity •Sprint Estimation

If you are reviewing a test, analyzing the results and identifying what you’ve learned, you are performing:

•The Check portion of the Plan-Do-Check-Act process •The Act portion of the Plan-Do-Check-Act process •Test Driven Development •Risk mitigation

© BetterPM.com


A set of tools designed to improve flow and reduce waste during a business process or in the manufacturing of a product is known as:

•Kaizen •Kanban •Agile •Lean

The belief that that no one process fits every project, but rather that practices should be tailored to the needs of individual projects is a component of:

•Extreme Programming •Lean •Method Tailoring •Both A and C

What is another name for the Kaizen Cycle? •HaShiRa •Shewhart Cycle •Kanban

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

Documents