PMI-Agile Certified PractitionerPMI-ACP Prep Workshop

LeadingAgile Atlanta2180 Satellite Blvd Suite 400

Duluth, Georgia 30097(678) 935 -4664

Rick Austin– Enterprise Agile Coach

PMI-ACP: Support Team LeadPMI Agile Community of Practice: Volunteer

About me…experience applying agile to small teamslarge distributed teamschange management

Agile Project ManagementVolunteer and Leader

Expert in Financial Services Industry

Georgia State Grad

Agile TransitionDirector, Program

Manager

Applications DevelopmentManager

SolutionsDirector of Development

Information TechnologyDirector

3

Let’s introduce ourselves, find out why we’re all at this session

• What is your name?

• Why are you here?

• What is your level of expertise with Agile?

Introductions

4

Write your questions on Sticky notes as they occur to you & affix them to our Learning Backlog.

Learning Backlog

Backlog

5

Participation is a Key to Success

• We will move quickly, but spend appropriate time on material you find especially useful

• I should be asking a lot of questions

• The key to success for our session is participationo Share your ideas and learning

o Tell me when to move on

o Tell me when to go into more detail

Approach

6

Course AgendaRiskBurndownsQualitative vs. QuantitativeImplicit vs. Explicit

ScrumBasic UnderstandingScrum Process OverviewPlanningRequirementsEstimation

Roles & ResponsibilitiesProduct OwnerScrumMasterThe Team

The Scrum ProcessInitial PlanningProduct BacklogRelease PlanningSprint PlanningSprint BacklogSprintSprint ReviewDaily ScrumSprint Retrospective

Simulations and ExercisesCommand-and-Control ExerciseSelf-Organization ExerciseBatch and Flow ExerciseTeam Collaboration ExerciseTheory of Constraints Exercise

User Story WritingPlanning PokerAffinity EstimatingIteration 0/Release PlanningSprint PlanningDaily StandupReview and DemoRetrospective

Exam Content OverviewWhat is the PMI-ACPDomains and TasksContent DistributionTools & TechniquesKnowledge & SkillsCommunity Guide of the PMI-ACP

Agile HistoryLeaders over timeWaterfallAgile Manifesto

Why Agile?Understanding the basics

Agile MethodsLeanKanbanExtreme ProgrammingScrum

What is the PMI-ACP?

8

PMI-ACP is not:• A replacement for the PMP®• PMI’s own flavor of Agile• Without support from the Agile community• Going to make you an Agile expert

Agile is not:• Something New• A silver bullet• An excuse for little or no planning • An excuse for little or no documentation• An excuse for poor quality• Undisciplined • Unproven

What the PMI-ACP and Agile are Not

≠

9

Based on Geoffrey Moore’s Technology Adoption Life Cycle Curve

PMI-ACP and Adoption CurveThe

chasm

PMPACP

We are here!

10

Knowledge & Skills (50% of exam)Percentage of Knowledge and Skill Content / % of Exam

Level 1 (66% / 33%)(18 knowledge/skills)

Level 2 (24% / 12%)(12 knowledge/skills)

Level 3 (10% / 5%)(13 knowledge/skills)

Active listening Agile frameworks and terminology Agile contracting methods

Agile Manifesto values & principles Building high-performance teams Agile project accounting principles

Assessing and incorporating community and stakeholder values

Business case development Applying new Agile practices

Brainstorming techniques Colocation (geographic proximity)/distributed teams

Compliance (organization)

Building empowered teams Continuous improvement processes Control limits for Agile projects

Coaching and mentoring within teams Elements of a project charter for an Agile project Failure modes and alternatives

Communications management Facilitation methods Globalization, culture, and team diversity

Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations)

Participatory decision models (e.g., input based, shared collaboration, command)

Innovation games

Incremental delivery PMI's Code of Ethics and Professional Conduct Principles of systems thinking (e.g., complex adaptive, chaos)

Knowledge sharing Process analysis techniques Regulatory compliance

Leadership tools and techniques Self assessment Variance and trend analysis

Prioritization Value-base analysis Variations in Agile methods and approaches

Problem-solving strategies, tools, and techniques Vendor management

Project and quality standards for Agile projects

Stakeholder management

Team motivation

Time, budget, and cost estimation

Value-based decomposition and prioritization

11

Tools & Techniques (50% of exam)Communications

• information radiator, team space, agile tooling, osmotic communications for colocated and/or distributed teams, daily stand-ups

Planning, monitoring, and adapting

• retrospectives, task/Kanban boards, timeboxing, 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/test first development, acceptance test-driven development, definition of done, continuous integration

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 Metrics

• risk- adjusted backlog, risk burn down graphs, risk-based spike MetricsIncluding but not limited to: velocity, cycle time, earned value management (EVM) for agile projects, escaped defects

Value stream analysis

• value stream mapping

13

Community Guide of the PMI-ACP

Source: PMI.org/Agile

Agile History

16

• On February 11-13, 2001, at Snowbird ski resort, seventeen people met to talk, ski, relax, and try to find common ground.

• Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.

• What emerged from this meeting was a symbolic Manifesto for Agile Software Development, signed by all participants.

Agile Manifesto

17

Agile is Not New

1943

1950-1960s

1985

1990

1995

1996

1997

1998

2000

2001

USAF & NASAX-15 hypersonic jetIterative Incremental Delivery

Hirotaka Takeuchi & Ikujiro NonakaThe New NewProduct Development Game

1990 - Sutherland & SchwaberScrum Framework

DSDN ConsortiumDynamic SystemDevelopment Method

1996 - Beck, Cunningham, JeffriesExtreme Programming

Jeff de LucaFeature Driven Development

Alistair CockburnCrystal Methodologies

Robert CharetteLean Development

Agile Manifesto

Taiichi OhnoToyota Production SystemKanban

Hardware Software

18

Agile Practices

Lean

Kanban

PMBOK

Agile is an umbrella term for a group of iterative and incremental software development methods.

19

Agile Tools

Process ToolsVersionOneRally SoftwareJIRA + GreenHopperTeam Foundation ServerExcel

KanbanAgileZenLeanKit KanbanKanbanery

Engineering Tools

Continuous Integrationhttp://jenkins-ci.org/http://hudson-ci.org/http://cruisecontrol.sourceforge.net/

Engineering Tools

RubyCucumber for ATDD/BDD: http://cukes.info/RSpec: http://rspec.info/

Javahttp://www.junit.org/http://www.jmock.org/

.Nethttp://www.nunit.org/BDD for .NET: http://www.specflow.org/http://www.nmock.org/

20

Agile Manifesto Values

Individuals & interactions Processes & toolsover

Working softwareComprehensive documentation

over

Customer collaboration Contract negotiationover

Responding to change Following a planover

That is, while there is value in the items on the right, we value the items on the left more.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Source: www.agilemanifesto.org

21

Agile Manifesto Principles

Satisfy the Customer

Welcome Change

Deliver Frequently

Collaborate Daily

Support & Trust Motivated

Teams

Promote Face-to-Face

Conversations

Deliver Working Software

Promote Sustainable

Pace

Promote Technical

Excellence

Maximize Through

Simplicity

Have Self-Organized

Teams

Reflect & Adjust Regularly

Source: www.agilemanifesto.org

Understanding the Basics

28

Flipping the Iron Triangle

Features Cost Date

Cost Date Features

Source: DSDM

Plan-Driven

Value-Driven

$

29

Agile methods support experimentation & adaptation by reducing the cost of change.

This is done by employing many concurrent, rapid feedback loops to surface and address risks early.

Reducing the Cost of Change

Source: Examining the Cost of the Agile Change Curve by Scott Ambler

30

Common Understanding

A document can’t generate the meaning in others that

conversations can.

There is a reason “Individuals and Interactions” is first in the

Agile Manifesto.

? ?!

We don’t need an

accurate document, we

need a shared

understanding- Jeff Patton / Agile 2012

31

DeployDocument

$

Incremental Value Delivery

Agile Concurrent Development• Fund incrementally – opt to extend,

redirect or cancel at a very granular level

• Deliver & realize value steadily

• Validate designs with users & customers

• Continuously adapt to risk and change

• Integrate early & often

Waterfall Serial DevelopmentInvest up front, only realize value at end, assuming value proposition hasn’t changed

TestCode

DesignAnalyze

$$$

Analyze

Design

Code

Test

Deploy

Document

Analyze

Design

Code

Test

Deploy

Document

Analyze

Design

Code

Test

Deploy

Document

$ $$

32

Collaboration and Feedback Loops

Traditional methods only work for so long because…

• No or little feedback before delivery.

• Change not expected.

Why are agile methods being considered?

• Constant feedback loops.

• Change is expected.

33

Process Burden or Lack of Discipline• Historically development teams have

faced a false choice in respect to processo Overly complex and burdensome

o Or, undisciplined with no controls

• Agile Provides a lightweight, but disciplined approach for speeding time to market, improving quality, and increasing predictability

Agile is Discipline w/o Undue Burden

34

Four volunteers, please!Time is set at 2 minutesEstimate throughput

Round 1 (measure first and last delivery time)• First person flips 50 coins• When done with entire batch, pass to next

personRound 2• First person flips one coin of highest value and passes to next person• Keep flipping and passing until doneRound 3• Each table creates their own rules to maximize coin flow/throughput in least

amount of time

Retrospective

Exercise – Batch vs Flow Throughput

35

Key Agile Principles Traditional Waterfall

Focus on Highest Value FirstAlign project, product and team visions by prioritizing by business needs, and using well architected code, to deliver better quality products faster and cheaper.

All or nothingTight coupling & bias toward building out internals in a breadth first fashion means that nothing can be delivered in isolation, even if it’s valuable.

Responding to ChangeAcknowledge uncertainty & adapt to both external (market) and internal changes, by modifying plans & approach. Use engineering principles to make code base easy to modify.

Baseline & Change ControlConstrain or even completely eliminate any significant change other than dropping features. Work to initial plans, even when they are proven to be invalid.

IterativeUse short time boxes to provide a rhythm, continually flow of value to the customer, and refine deliverables over time.

PhasedNo rhythm as project is executed using long phases.

Feedback & Continuous ImprovementUse continual feedback to inform plans and modify approach.

Lessons Learned at the EndFeedback is rarely given in time for it to be applied towards improving processes and project execution.

Small, Integrated TeamsA small team size, and overlap in skills sets, simplifies communications, allows everyone to see the big picture, creates self discipline and provides flexibility.

Silo Teams with HandoffsStaff works in functional oriented groups, throwing documentation and code over the wall.

Technical Excellence / Bake Quality InUse TDD , ATDD, refactoring, and other strong engineering principles to ensure quality.

InspectionAttempt to ensure quality by after the fact inspection.

Agile Principles Compared

36

Agile is Empirical, Not Definitive

Agile assumes that baselines may change significantly during the project.

In such an unpredictable environment, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

37

Rolling Wave Planning, used in Agile processes, embraces the Lean ideal of making decisions at the last responsible moment, when the most possible information is available. This maximizes flexibility and planning accuracy.

Agile Uses Rolling Wave Planning

Level of Planning Planning Approach

Strategic product line goals Strategic Planning

Strategic product goals Product Planning

Specific problems to solve Lean / Six Sigma

Large functional goals Release Planning

Small, defined work items Iteration Planning

Tactical organization & execution Daily Standup

38

Layers of Product Planning

Product / ProjectWhat business objectives will

the product fulfill?

Product Goals

Product Charter

Elevator Pitch

Release

How can we release value incrementally?

What subset of business objectives will each release achieve?

What user constituencies will the release serve?

What general capabilities (big stories) will the release offer?

Release Roadmap

Release Plan

Iteration / Sprint

What specifically will we build? (User Stories)

How will this iteration move us toward release objectives?

Iteration Plan

Development Tasks

Story (Backlog Item)

What user or stakeholder need will the story serve?

How will it specifically look and behave?

How will I determine if it’s completed?

Story Details

Acceptance Tests

39

• Top level goal(s) must be communicated to all levels of the organization

• Members of the organization offer candid information up the management ladder.

• Leaders/Managers offer guidance (why and what ≠ how)

Principle - Self-Organized and Empowered

info

gu

ide

info

gu

ide

info

gu

ide

info

gu

ide

40

Some Basic Terminology

Scrum Extreme Programming (XP) Definition

Sprint Iteration Fixed-length period of time (timebox)

Release Small Release Release to production

Sprint/Release Planning

Planning Game Agile planning meetings

Product Owner Customer Business representative to project

Retrospective Reflection “Lessons learned”-style meeting

ScrumMaster Coach Agile project manager

Development Team

Team Empowered Cross-Functional team

Daily Scrum Daily Standup Brief daily status meeting

41

Some More Agile Terminology

Term Definition

SpikeSomething cannot be estimated until a development team runs a timeboxed investigation. The spike itself is a throw-away.Can include risk, architectural, or any unknown.

Tracer BulletAn experimental solution that cuts through all the "layers" ofthe architecture. It is not necessarily time-boxed. It is not intended to be thrown away.

Kaizen Continual improvement of all areas of a company not just quality.

Value Stream An end-to-end business process which delivers a product or service

More terms… Go to the Community Guide of the PMI-ACP at http://agile.vc.pmi.org/

42

Session Purpose Timing/Duration Attendees

Iteration 0 Orient Team to project’s business value and analytical background, the process, and one another.

Start of projectApproximately 1-3 weeks of 2-4 hr workshops

Team, PO, SM, Key Stakeholders & users

Release Planning

Determine what a Release should include and when it should be delivered.

Start of Release2-4 hours

PO, SM, Key Stakeholders, optionally Team

Daily Standup Facilitate rapid coordination betweenTeam members, and with PO.

Daily10-15 minutes

Team, SM, PO

IterationPlanning

Elaborate, estimate and prioritize highest-value Product Backlog items for anIteration.

Start of each Iteration2-4 hours

Team, SM, PO

IterationRetrospective

Reflect on project & process issues and take action as appropriate.

End of each Iteration30-45 minutes

Team, SM, PO

Iteration Review

Demonstrate completed functionality to interested stakeholders & users to showprogress and gain feedback.

End of each Iteration1-1½ hours

Team, PO, SM, Key Stakeholders & users

Meetings Summarized

43

Small Teams with everything needed to deliver an increment of value

Backlog prioritized by value being delivered incrementally

At scale, the backlog and products for these teams need to be coordinated and technical practices must address the challenges of integration

How does Agile Work?

44

DeployDocument

$

Incremental Value Delivery

Agile Concurrent Development• Fund incrementally – opt to extend,

redirect or cancel at a very granular level

• Deliver & realize value steadily

• Validate designs with users & customers

• Continuously adapt to risk and change

• Integrate early & often

Waterfall Serial DevelopmentInvest up front, only realize value at end, assuming value proposition hasn’t changed

TestCode

DesignAnalyze

$$$

Analyze

Design

Code

Test

Deploy

Document

Analyze

Design

Code

Test

Deploy

Document

Analyze

Design

Code

Test

Deploy

Document

$ $$

45

Incremental and Iterative Delivery

Incrementing is more about delivery.

1 2 3 4 5

1 2 3 4 5

Iterating allows you to move from vague idea to realization. Going from rough to polished

Image Credit: Jeff Patton

46

• Iterations are regularly scheduled, pre-planned, recurring time boxes. Provide a cadence / rhythm that provides predictability and synchronization points for planning. The more mature your process, the shorter the iterations.

• Things we time-box:o Sprints (or Iterations) - length of time in which work is doneo Releases - Production and Maintenanceo Working Sessions - Release Planning, Sprint Planning, Sprint Review,

Retrospective

• Iterations facilitate incremental development (but incremental development doesn’t require iterations).

Iterations

Agile Methods

Lean Kanban

Extreme Programming Scrum

48

“A production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.“

What is Lean?

Source: Wikipedia

49

Kanban (看板) literally meaning "signboard" or "billboard", is a concept related to lean and just-in-time (JIT) production.

Taiichi Ohno is considered to be the father of the Toyota Production System

What is Kanban?

Kanban is a scheduling system that tells you what to produce, when to produce it, and how much to produce.

50

• A software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.

• It advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

What is Extreme Programming?

51

Scrum is an iterative and incremental project delivery framework.

What is “Scrum?”

Source: Wikipedia

52

Iteration 0

Brief orientation to the project’s business value and analytical background, the Agile process, and the Team.

Project Orientation• Business case overview• Business process analysis• Project scope & objectives• Initial Product BacklogProcess Orientation• Agile process training• Sprint/Release cycles• Definition of “Done”Team Orientation• Team room artifacts• Team norms• Technical environments,

design, architecture, etc

Initiating an Agile Project

Release Planning Session

Initial project planning, to review initial Product Backlog and set production Release dates.

Release Schedule

Product Backlog

List of desired functionality prioritized by business value by Product Owner.

Allow a user to create a free account. (Priority 1)

Allow subscribers to purchase music. (Priority 3)

Allow user to personalize store experience. (Priority 9)

53

A useful project charter contains three key elements: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.

Additional elements:Working practices – Planning, estimating, definition of done, tracking progress, TDD

methods

Continuous Integration – integration time limits, breaking the build, code check-in

Code – Paired programming, owning the code, documentation

Iterative and Incremental Development – iteration cycle and deployment cycle

Agile Project Charter

Lean

55

Lean Portfolio Management

• Corporate strategy operates over years with direct line of sight to priorities

• Optimize the whole

• Manage internal and external dependencies

• Focus on quickly delivering minimal marketable features

• Clear feedback mechanism between business and development

• Creates alignment beyond single teams

Year(s): Set corporate goals and strategies

Quarter(s): Discover and create innovative product strategies from corporate goals

Month(s): Update Release Plans, Product Backlogs and Roadmaps

Week(s): Decompose features from Product Backlog into tasks and deliver working code

56

The 7 Principles of Lean1. Eliminate Waste

2. Create Knowledge

3. Build Quality In

4. Defer Commitment

5. Optimize the Whole

6. Deliver Fast

7. Respect People

7 Principles of Lean

Source: Mary and Tom Poppendieck

67

Process Cycle Efficiency is the key measure of Leanness

Process map entire value-stream at a high level, drilling down into more detail only as potential areas of interest are identified

• Value-added: This step in the process adds form, function, and value to the end product and for the customer.

• Non-Value-Added: This step does not add form, function, or assist in the finished goods manufacturing of the product.

• Non-Value-Added-But-Necessary: This step does not add value, but is a necessary step in the final value-added product.

Lean Process Cycle Efficiency

PCE = (sum of time for Value Added process steps)

(sum of time for All process steps)

70

The “Kaizen” Mindset:1. Everything, not just software

development, can and should be improved

2. Improvements should be made day to day

3. The best improvements come from taking the customer’s point of view

4. Move from criticism to suggestion

5. Keep improving, even if things are working

Continuous Improvement

改善

Kanban

74

1. Visualize your Workflow

2. Limit Your Work in Process

Example: Mature Requirements Separately

• Instead of figuring everything out for a user story just in time at Sprint Planning, we can ready them in advance

• The specific process varies, but there is a set of steps to get a requirement ready

Kanban – High Level

New Candidates PO Approved Decomposed

Acceptance Criteria

Testable Example

Dev Review Ready for Sprint

10 cards 6 cards 4 cards 4 cards 4 cards 8 cards 12 cards

Airplane Game

Paper Airplane Game

Team of 5 makes 21 airplanes

1st Run: Fast as you can

2nd Run: Flow, Batch size of one

Consistently better results

– Lead Time: 3X improvement

– Throughput: 10-20% better

– Lower stress

– Easier to manage

76

Everything at once =

many started

few finished

Costs of Over-Utilization

Develop Test

In Process Ready In Process Ready

4 slots 3 slots 4 slots 3 slots

WIP Limits = Fast

“A system of local optimums is not an

optimum system at all” - Eli Goldratt

Extreme Programming (XP)

78

Agile Engineering Practices allow teams to move fast, be flexible and deliver high quality software:

• Automated Builds & Continuous Integration reduce time and effort associated with manual builds, and risk from big-bang integrations

• Simple Design & Refactoring keep incremental development from leading to poor architectures

• Multi-Level/Automated Testing & Test-Driven Development reduce testing time and effort and allow developers to make changes with confidence

• Pair Programming increases software quality without impacting time to deliver.

Agile Engineering Practices

Source: Bill Wake, http://www.xp123.com

79

XP Coach• The XP Coach role helps a team stay on process and helps the team to learn. A

coach brings an outside perspective to help a team see themselves more clearly. The coach will help balance the needs of delivering the project while improving the use of the practices. A coach or team of coaches supports the Customer Team, the Developer Team, and the Organization.

• The decisions that coaches make should always stem from the XP values(communication, simplicity, feedback, and courage) and usually move toward the XP practices. As such, familiarity with the values and practices is a prerequisite. The coach must command the respect required to lead the respective teams. The coach must possess people skills and be effective in influencing the actions of the teams.

• The XP Coach uses many different techniques. The coach is a mentor, working side by side with team members on their tasks. The coach is a facilitator, helping achieve more effective team performance. The coach is a conduit, reinforcing communication within the team and across teams.

XP Roles - Coach

80

XP Customer

• The XP Customer role has the responsibility of defining what is the right product to build, determining the order in which features will be built and making sure the product actually works.

• The XP Customer writes system features in the form of user stories that have business value. Using the planning game, he chooses the order in which the stories will be done by the development team. Defines acceptance tests that will be run against the system to prove that the system is reliable and does what is required.

XP Roles - Customer

81

XP Programmer• The XP Programmer is responsible for implementing the code

to support the user stories.

XP Roles - Programmer

82

XP Tester• The primary responsibility of the XP Tester is to help the

customer define and implement acceptance tests for user stories. The XP Tester is also responsible for running the tests frequently and posting the results for the whole team to see. As the number of tests grow, the XP Tester will likely need to create and maintain some kind of tool to make it easier to define them, run them, and gather the resultsquickly.

XP Roles - Tester

83

1. ______ is responsible for implementing the

code to support the user stories.

2. ______ help the customer define and

implement acceptance tests for user stories

3. ______ Helps a team stay on process and

helps the team to learn. Is a mentor, working

side by side with team members on their

tasks

4. ______ writes system features in the form of

user stories that have business value and

defines acceptance tests.

XP Roles – Quick Quiz

a) XP Coach

b) XP Customer

c) XP Programmer

d) XP Tester

1(c) 2(d) 3(a) 4(b)

86

Simple Design:• Code is always testable, browsable, understandable, and explainable

• Do the simplest thing that could possibly work next. Complex design is replaced with simpler design

• The best architectures, requirements, and designs emerge from self-organizing teams

Refactoring:• Remove redundancy, eliminate unused functionality, and rejuvenate

obsolete designs

• Refactoring throughout the entire project life cycle saves time and increases quality

• Code is kept clean and concise so it is easier to understand, modify, and extend

Simple Design and Refactoring

Risk

94

Create a risk census during the first sprint planning meeting and then update it quickly during subsequent planning meetings as new risks are identified or as the probabilities or sizes of known risks change.

Risk Burndown

As with a regular release burndown chart, we should see a linear drop in risk over the course of the project.

Plot your project risk exposure and display it with other big visible charts in your team area.

Source: Managing Risk on Agile Projects | Mike Cohn - Mountain Goat Software

95

Risk Management

Traditional Risk Management Agile Risk Management

Prepare formal risk management plan Educate the team. Invite them to determine best approach to manage

Formal risk identification meetings and then create Risk Register

Team identifies risks in all meetings and add to information radiators

Conduct qualitative and quantitative analysis. Determine how to respond

Facilitate the team in a qualitative analysis, determine how to respond, post results

Periodically review Risk Register and make updates as needed

Constantly review risk and responses as part of all meetings, reviews and retrospectives

Source: Sliger & Broderick (2008),The Software Project Manager's Bridge to Agility, Addison-Wesley

96

Implicitly managing Risk:

• User stories are prioritized by the Product Ownero Highest value items are attacked first

o Highest risk items are also attacked early

• Iterative delivery ensures that integration and rollout risks are attacked very early in the project lifecycle

• Technical discipline helps keep a tight rein on development risko Automated builds and continuous integration keep code integration and

code quality risk to a minimum

Implicit Risk Management

97

Explicitly managing Risk:• Review the Product Backlog

• Identify and list risks by impact (High/Medium/Low) and probability (High/Medium/Low)

• Provide a mitigation plan with clear responsibility

• Create task cards for risk mitigation items

• Insert into Product Backlog and/or Sprint Backlogs; or track on Risk Board

Explicit Risk Management

Agile Risks, Agile Rewards, Smith and Pichler, Dr. Dobb’s 2005

Agile Requirements

99

User Interface Layer

Business Logic Layer

Persistence Layer

Work in Agile projects is organized by Units of Value, rather than by Architectural Layer.

Work Organized by Value

Feature / User Story 2Feature / User Story 1 Feature / User Story 3

100

Key Characteristics• High-level descriptions of desired

functionality and goals

• Implement “vertical slices” of the system’s functionality

• “Contracts for conversation,” not all-inclusive requirements

• User stories wait in the Product Backlog until pulled into the Sprint Backlog

• Contain Acceptance Criteria to define “Done”

User Stories at a Glance

As a user I can create an account.

Estimate 21 PointsPriority 1 (High)

As a user I can enter a user name.

Estimate 4 pointsPriority 1 (High)

As a user I can enter password.

Estimate 8 pointsPriority 1 (High)

Product Backlog User Story

Sprint Backlog User Stories

101

From User Stories to Tasks

Tasks

As a user I can enter a password.

Estimate 8 pointsPriority 1 (High)

Acceptance Criteria

User Story

On back…

• Design user interface• Develop CSS/HTML• Create database fields• Develop validation criteria• Write test cases• Code test fixtures• Unit testing• Acceptance testing• Usability testing• Write online help text

• Password match validated• Contains special characters• Minimum 10 digits• Cannot be text only

102

As a <type of user>, I can <immediate goal> so that <business outcome>.

User Story Template

User Role (Who?)

Desired Function (What?)

End Result (Why?)

Who, What, Why… what’s not here?

103

Acceptance Criteria help to set scope and define what Done means for a given User Story.

User Story Acceptance Criteria

• Verify that a premium member can cancel the same day without a fee.

• Verify that a non-premium member is charged 10% for a same-day cancellation.

• Verify that an email confirmation is sent.• Verify that the hotel is notified of any cancellation.

As a user, I can cancel a reservation.

104

Circle which attributes make a good story and then discuss as the group

What Makes a Good Story?

Independent

Valuable

Testable

CreativeEstimatable

Small

Negotiable

Source: Bill Wake

105

Pre Release Life of a User Story

• Phone # in US format, contains no alpha characters, minimum 10 digits

• First name, Last name and email address required

• Email specified in standard format• Etc.

Acceptance Criteria Created Prior to Release Planning

As a user I want to create an account

User Stories Created Prior to Release Planning

Sprint Tasks Created at Sprint Planning

• Design UI Mock Up• Write online help text• Develop CSS/HTML• Develop validation criteria• Create database tables• Code test fixtures• Code• Perform testing

Name Phone Email Valid

John Smith 215-555-1212 jsmith@ls.com TRUE

Smith 215-555-1212 jsmith@ls.com FALSE

John 215-555-1212 jsmith@ls.com FALSE

215-555-1212 jsmith@ls.com FALSE

John Smith jsmith@ls.com FALSE

Smith jsmith@ls.com FALSE

John jsmith@ls.com FALSE

Testable Examples (ATDD) Created Prior to Sprint Planning

Estimate 5-PointsPriority 1 -High

(Created at Release Planning)

106

User Stories aren’t the only way to develop, express and elaborate requirements in Agile. Some complementary tools & methods include:

• Essential Use Cases

• Low-fidelity prototyping

• High-fidelity prototyping

The best approach will be determined by your team and the problems at hand.

Beyond User Stories

107

Low-fidelity prototyping is a fast, cheap, easily iterated, collaborative way to test various concepts & approaches.

Low-Fidelity Prototyping in Agile

Tools• Paper sketches and collages• Whiteboard drawings

Applications

• Concept design: to explore different metaphors and design strategies• Interaction design: to organize screen structure & flow• Screen design: for initial screen layout & design• Screen testing: to refine screen layout

Source Adaptive Path for Sketchboard example

108

High-Fidelity prototypes are detailed, interactive and reusable means of simulation.

Tools:• Photoshop, Visio, Powerpoint• Flash, iRise Studio, Serena ProcessView• WPF, XAML, XUL…

Applications:• When stable requirements support reuse• To test complex interaction scenarios• To finalize detailed designs• As inputs to a Sprint

High-Fidelity Prototyping in Agile

Source: iRise Studio, www.irise.com

109

1. In general, we can view the maturation of

a need (expressed as a user story) as

having enough information to prioritize,

__________ and ___________.

2. The user story format has three parts:

“as a”, “I want to” and “_________.”

3. Acceptance criteria is written for team

members and, as such, assumes a level of

existing ___________.

4. Acceptance criteria is incredibly useful

but a ___________ will often provide

significant additional clarity.

Agile Requirements

a) build

b) domain knowledge

c) estimate (test)

d) outsiders

e) so that

f) testable example

1(c) (a) 2(e) 3 (b) 4 (f)

110

5. A ___________ defines how the software will be implemented; it can define the external behavior, ___________ design, or both.

6. As defined in this training, a specification builds on a requirement with additional context, conversations and ___________.

7. A specification should be ___________, defining just enough to help the team build confidently within the sprint.

8. The appropriate level of detail required in a specification will ___________, depending on, among other things, the ___________ of the requirement, the domain knowledge of the team, and the requirements’ similarity to what has already been built.

Agile Requirements

g) complexity

h) designs

i) internal

j) lightweight

k) specification

l) vary

5(k) (i) 6(h) 7 (j) 8 (l) (g)

Agile Estimation

112

High Level – Affinity Story Level – Planning Poker

Story Pointso Purely relative measure of complexity (2 is half as hard as 4)

o Variability averages out across many stories

o Don’t decay over time

Scales with increasing gaps between elements are preferredo Fibonacci: 1, 2, 3, 5, 8, 13

o Doubles: 1/2, 1, 2, 4, 8, 16

o “T-Shirt Sizes:” S, M, L, XL, XXL

Agile Estimation Levels, Units and Sequences

Traditional project estimation approaches may be necessary for initial scoping, but should

rapidly be replaced by empirical observation of Team

output capacity (velocity).

Avoid false precision to avoid false expectations.

113

1. Use more than one person. By engaging the team in the estimation process, we gain the benefits of additional insights and consensus building.

2. Use more than one approach. Use multiple estimation approaches (comparison to similar projects, bottom up, user story points, etc.) and look for convergence between multiple approaches to reinforce likely estimate ranges.

3. Agree on what “It” and “Done” means. Make sure everyone is estimating in the same units, have the same assumptions and are based on standard developer ability/effort.

4. Know when to stop. Balance estimation effort against the diminishing returns and false accuracies of over analysis.

5. Present estimates as a range. Estimates are often poor predictions, and should be noted as such.

6. Defend/explain estimate range probabilities. Educate stakeholders about the relative likelihood of hitting optimistic/pessimistic estimates.

7. Don’t reserve estimating for when you know least about the project. Estimation should not be reserved for only the beginning of projects.

8. Be aware of common estimation omissions. Don’t overlook commonly missed tasks, and use retrospectives to inspect project-specific issues.

9. Embrace reality early. Don’t under-estimate the load of maintaining and refactoring a growing codebase.

10. Review, Revisit, Remove Head from Sand, Repeat. Adjust project forecast based on empirical observation of throughput.

Agile Estimation Essentials

114

Participants: Whole teamMulti-team environment: Work together!

Process: Cards are placed in a stack on the table

• Product Owner explains the top card

• First team member places this card on table by size (left smaller, right larger)

• Next team member either repeats process with next card, or moves an existing card to a new position, with an associated explanation

• Process repeats until all cards are placed and grouped, and no more movement is desired

• Each group is labeled with its estimate

Affinity Estimating

Smaller Larger

115

• Clifford the Big Red Dog

• Marmaduke

• English Bulldog

• Chihuahua

• Pug

• Scooby-Doo

• Great Dane

Exercise – Relative Dog Sizing

Rules Point Estimating:

Team decides scale

Discuss criteria for complexity

Find the reference point

Estimate size for remaining items

Based on Mike Cohn’s dog points

116

“Planning Poker” is based on “Wideband Delphi” convergent estimation techniques.

How to do it:1. Each estimator (someone who could possibly be doing the

work in question) is given a deck of cards, each card has a valid estimate written on it

2. A moderator reads a story and it’s discussed briefly3. Each estimator selects a card to represent her estimate4. Cards are turned over so all can see them5. Discuss differences (especially outliers)6. Re-estimate until estimates converge (or don’t!)

Agile Estimation – Planning poker

117

5

Planning Poker Example

55Bill (Dev)

52Ann (BA)

58Vijay (QA)

33Susan (Dev)

Round 2Round 1Estimator

Scrum

119

Scrum – 50,000 Foot View

Release Planning

SprintPlanning

SprintReview

SprintRetrospective

120

There are only three roles defined in Scrum:

Scrum Roles & Responsibilities

Product Owner

• Owns Product vision

• Defines features, decides on release date and content

• Responsible for market success

• Prioritizes features according to market value

• Can change features and priorities every Sprint

ScrumMaster

• Responsible for facilitating process

• Focuses Team and protects them from external interruption

• Looks for ways to enhance productivity

• Assists Product Owner in leveraging Scrum

The Team

• Small group containing all necessary project skills

• Focuses on steady delivery of high quality features

• Generates options for delivery

• Manages own work within Sprints

121

• Product BacklogPrioritized list of valuable items to deliver during the project.

• Sprint BacklogList of committed items to be addressed within a Sprint.

• Burndown/burn-up Chart Visual aid for tracking team progress and forecasting expected completion dates.

• Velocity ChartTracks rate of feature completion.

Artifacts of Scrum

122

Scrum Milestones

Product Backlog

• ____________• ____________• ____________• ____________• ____________

F3 F6

Release 1F1, F2, F3

Release 2F1, F2, F3F4, F5, F6

Initial Planning

Rel

ease

Pla

nn

ing

Rel

ease

Pla

nn

ing

F1

F2

F2 F1 F4

F5F3

US1

US 2

US 3

US 4

US 5

US 6

US 7

US 8

US 1

US 2

US 3

US 4

US 5

US 6

US 7

US 8

Rel

ease

Pla

nn

ing

SprintBacklog• ______• ______

SprintBacklog• ______• ______

SprintBacklog• ______• ______

SprintBacklog• ______• ______

SprintBacklog• ______• ______

SprintBacklog• ______• ______

Spri

nt

Pla

nn

ing

Spri

nt

Pla

nn

ing

Spri

nt

Pla

nn

ing

Spri

nt

Pla

nn

ing

Spri

nt

Pla

nn

ing

Spri

nt

Pla

nn

ing

123

Scrum Milestones

Features User Stories MMF

124

The Scrum Sprint Cycle

Sprint Planning

Elaboration, estimation and prioritization of highest-value

User Stories.

Sprint Backlog

Allow a user to enter a login & password.

Allow a user to enter personal information.

Allow user to enter billing information.

Spri

nt

Exe

cuti

on

Complete Sprint BacklogTeam works on highest-value functionality until it meets jointly defined Acceptance Criteria.

Sprint ReviewTeam demonstrates completed functionality to

interested stakeholders, gathering feedback.

RetrospectiveTeam reflects on project & process and takes action

as appropriate.

Production Release (Optional)Generally occurs when a useful group of related

functionality has been completed.

Daily Scrum (or Standup)15-minute status and risk management meeting for

Team & Product Owner.

125

Use a cadence of recurring working sessions to synchronize and simplify planning while providing continuity

Cadence & Synchronization

Instead of wasting time coordinating numerous meetings and dates…

126

Instead of cube farm, organized by function…

We collaborate via flexible roles and simple rules to decentralize decision making and get work done.

Small Collaborative Teams

AfterBefore

127

SB Item Priority Hours

User Story High

Task 1 4

Task 2 12

Task 3 6

User Story Med

Task 1 9

Task 3 2

User Story Low

Task 1 5

Task 2 2

Task 3 7

From Product to Sprint Backlog

Product Backlog Sprint BacklogSprint Planning Sprint

Top priority stories are

discussed and decomposed into Tasks for

the Sprint Backlog.

Team pulls and completes Tasks until each User Story is done.

PB Item Priority Points

User Story High 5

User Story High 8

User Story High 3

User Story Med 13

User Story Med 8

User Story Med 5

User Story Med 13

User Story Med 8

User Story Med 5

User Story Low 21

User Story Low 13

128

Cards move left to right, downstream, if there is space.

Tracking Work in a Sprint

Sprint Backlog In Progress Completed

10 cards 6 cards

Sprint Backlog In Progress Completed

10 cards 6 cards

Sprint Backlog In Progress Completed

10 cards 6 cards

Cards move left to right, assuming there is space, then…

From Sprint Backlog to In Progress, if there is space, and…

From In Progress to Completed.

129

1. The ___________ ensures that requests are expressed in user story or other appropriate format and placed in the ___________.

2. The ___________ provides story point estimates for each ___________.

3. Product owners ___________ user stories (PBIs), then, with input from the team and other stakeholders, sequences user stories into ___________.

Scrum Process Review

a) user story

b) product owner

c) product backlog

d) prioritize

e) releases

f) team

1(b) (c) 2(f) (a) 3 (d) (e)

130

4. At the end of each ___________ the team demonstrates _____________ they do this at the ___________.

5. The total story points estimates, for those stories that were completed in a sprint, are added together to provide us with the ___________ for the sprint.

6. The team holds a ___________ to evaluate how well they’ve done and what changes could be made to the process to further improve.

Scrum Process Review

g) sprint

h) sprint review

i) sprint retrospective

j) velocity

k) working software

4(g) (k) (h) 5(j) 6(i)

Roles & Responsibilities

Product Owner

133

Manage the return on investment (ROI)• Establishes baseline target ROI

• Measures project against this baseline

• Prioritizes product backlog to maximize ROI

Guide product development• Establishes, communicates and nurtures the vision

• Knows what to build and in what sequence

• Tunes the vision with the team

Call for releases• Decides when to call for release of a potentially shippable product increment

• Can shift a release forward to maximize ROI based on new knowledge

Product Owner Responsibilities

134

Busy Product Owners need not – and should not – act alone.

Some of the roles that can assist: • Business Analysts help to define business needs and elaborate them for the

rest of the Team

• Developers provide available execution paths and describe their respective costs and benefits

• User Experience experts and marketing resources help to elicit and explain end user needs and desires

• Other Business Stakeholders to get a wider representation of needs from across the organization

An Army of One?

Product Owners represent

many constituents with a single voice.

135

Shared Understanding of Value

The Product Owner helps to spearhead a Shared Vision, but the whole Team should understand it:

• Communicate & elaborate early conceptual & visioning work through Sprint (Iteration) 0.

• Involve Team in translating User Needs into Product Functions

• Involve Team in development of clear Goals

• Directly involve Team in feedback loops

• Provide direct exposure to end users

136

Sarah, the client product manager for your development project, has little interest in being a product owner. “We’ve given you the specification of exactly what we want done,” she declares. “Just do your thing. I know you guys are good!”

What do you do?

Reluctant Product Owner

137

Sprint

What must be in place for your project teams to plan and estimate 2-3 weeks worth of work?(e.g. wireframes, detailed acceptance criteria, key stakeholder approval…)

Defining “Ready”

Ready In Process Done

138

Example of a Definition of Ready

Analyst – User story sufficiently defined and mapped from requirements

Tester – Acceptance criteria developed

Developer – User story is estimated and no known blocking dependencies exist within the sprint

Definition of “Ready”

Vision and Goal

140

A Typical Agile Pipeline

Ideation

Market TrendsPrototypes

Focus GroupsUser ExperienceBasic Workflows

VisionBusiness Outcomes

Release Timing and GoalsProduct ArchitectureEpics and Features

Maturation

User Story DecompositionUser Story Maturation

Acceptance CriteriaTest Cases

DependenciesStory MappingPrioritization

Epic EstimationBacklog Development

Execution

Sprint PlanningTask EstimationDaily Standups

Software DevelopmentTesting

BurndownsDocumentationProduct DemosRetrospectives

Current Sprint~2 Sprints Ahead>4 Sprints Ahead

Marketing/Sales, Product Management, Product Owners, Architects

Product Owners, Architects, Dev Leads, QA Leads, UX/Analysts

Leads, UX/Analysts, Dev Team Members

141

Vision

Goal / Outcome

Epic

Feature Feature

Story Story Story Story Story

Feature

Goal / Outcome

Epic

Feature Feature

Requirements Breakdown Structure

With Scrum, we refine requirements over time, from a high level Vision down to User Stories and tasks that can be executed in a Sprint. • At each level, items can break down further into siblings, so one Epic can become two.

• The exact breakdown is often unclear; is this a Feature or an Epic? In reality, the exact breakdown is not important.

• The names may also vary, so“User Story” or “Story” areoften used interchangeably.

142

1. Estimate relative level of effort for each feature

o Takes into account complexity of work, effort, etc.

o Uses relative units (e.g. A is half as hard as B)

2. Measure “Velocity” to set Team capacity

o Takes into account external interruptions, technical surprises, developer skill level, domain knowledge, etc.

o Work actually completed over time gives accurate data to determine capacity for a Team

Agile Estimation Basics

Velocity requires stability to be accurate.

143

Example of a Definition of Done

• Analyst – Working system reviewed and User Story accepted via Automated Test or Manual Inspection

• Tester – Test cases pass. All critical and high severity bugs fixed and other bugs identified and tracked

• Developer – Deployed to test environment and Code Review complete

Definition of “Done”

144

Story Estimate Status at End of Sprint

As a Prospect, I can submit an application. 2 Pts* Complete

As a Policy Holder, I can update my account information.

5 Pts Complete

As an Account Representative, I can view a Policy Holder’s information.

8 Pts Complete

As an Underwriter, I can approve or reject applications.

5 Pts 1 Pts Remaining

Total Sprint Velocity 15 Pts

Velocity Calculation

* Pts = Story PointsNext Sprint,

15 Pts would be our projected capacity.

145

Metrics fall into two general categories:

Business Valueo ROI, IRR, NPV

o % cycle time reduction

o Customer satisfaction (NPS)

Diagnostico Velocity

o Successful builds per iteration

o Defects across iterations

o Code coverage

Defining Key Metrics in Agile

Tips:• Measure outcome, not output• Measure only a few things• Ensure commonly understood

operational definition and measurement plan

• Target specific questions and audiences

146

Planning Releases

1. Guess a starting velocity (14 in this case)2. Choose which stories must exist to

Release and see how many Sprints are needed, or… Work backwards from the Release date to fit as many high-value stories as possible

3. Adjust the scope within the Release as true Velocity becomes apparent

Velocity = 14 points per Sprint

Sprint 4

Story M 2

Story K 3 Story L 8

Sprint 1

Story A 5 Story B 3

Story C 5 Story G 1

Sprint 3

Sprint 2

Story D 2 Story E 5

Story F 2

Story H 8

Story I 5

Story J 5

Release 1

147

Based on the velocity chart below, in what iteration can the business expect 33 more story points completed?

Estimating Dates with Velocity

Velocity stabilizes as business & technical domain knowledge increase and teams

move from forming & storming to performing.

148

If each sprint costs $20k, what would be the project cost at the end of iteration 15?

Estimating Cost

149

When you are mandated to use EVM

Apply the 0/100 method to measure completion of Stories and Tasks.

It is possible to maintain ANSI/EIA-748 reporting compliance• Replacing velocity with EV metrics

• Creating measures of budgeted cost of work performed (BCWP) using "testable stories"

• Establishing the Budgeted Cost of Work Scheduled (BCWS) baseline at the beginning of each iteration

• Capturing Actual Cost of Work Performed (ACWP) through a time keeping system

• Computing Cost Variance, Schedule Variance from the three base earned value metrics

• Computing Estimate at Completion (EAC) and Estimate to Completion (ETC) from these base metrics as well.

Agile EVM instead of Velocity

1. If you know why you use EVM now, the same applies to AgileEVM2. Use the iteration as the unit for basing calculations

150

• Review velocity and set Sprint capacityIdentify anything unique about the coming sprint (vacation, holidays, etc.)

• Select Sprint Goal (Optional)

• Select top-priority User Stories from Product BacklogSelect slightly more than capacity, aligned with Sprint goal as appropriate

• Discuss User Stories to create Tasks & Acceptance Criteria

• Estimate User StoriesBase on individual task estimates, sticking to about 1-8 hours/task

• Commit to User StoriesSelect until capacity is reached, with some backup stories discussed in case Team finishes early

Sprint Planning Sample Agenda

Identifying & Modeling Users & Customers

152

Prioritization and Socializationo Prioritize user types each release as you

would functionality. Knowing high priority users helps you identify high priority functionality.

o Post them in the area your team works to help team members empathize with target users and make better tactical design decisions.

Focusing Testing & Evaluationo Identify user test subjects.

o Identify alpha/beta test subjects.

o Compare them with your eventual actual users to identify bad assumptions and to add new user constituencies.

Applications of User Models

153

Users interact directly with the systemThey are important to understand, because:• Knowledge of current usage patterns helps to design

better, more usable systems.• Unsatisfied users will work around the system, nullifying

its advantages and eventually eliminating it.

Customers make buying or adoption decisionsThey are also important, because:• They have their own wish lists that may have little to do

with their users’ needs.

• They make the purchasing decisions, so if they aren’t happy, you won’t get in the door.

Users vs. Customers

154

Less detailed descriptions can also work

Succinct User Roles

Nurse Admitting New Patient to Ward

Context

Environment & basic

responsibilities of the role

Busy, noisy hospital.

Characteristics

Patterns of interaction,

behaviors, and attitudes

• Uses the application only several times a week.

• Gets trained at in-service once a year.

• Has access to peers to ask questions.

Criteria

Key objectives of the role

“Get the data entered as quickly as possible

without making any mistakes!”

155

Personas take user roles one step further.

o Represent our current or desired audience.

o Provide a name, a face, and a description to a particular “user role.”

Level of detail

o Some believe in creating a small number of very detailed personas. These often over specify.

o Lightweight personas will suffice for most situations.

One Step Further - Personas

“Extreme Character Personas will lead you to stories, you would be likely to miss otherwise”User Stories Applied by Mike Cohn

156

Here are some example personas

Example Personas

Peter the Programmer“I’d like to get a better handle on test driven development and refactoring.” Peter’s company has just started using agile development. While he’s been a developer for a long time, he’s not used agile practices like TDD.

David the Agile Developer“I've been using TDD, refactoring, and continuous integration for many years now. I want to see what's next.” David is a strong engineer that started with Extreme Programming practices about 2001. He’s proficient at most agile engineering approaches and always on the lookout for new cutting edge techniques. The other engineers in his department look to him for ideas and advice.

Tara the Tester“How do I find time in an Agile process to test effectively?” Although Tara’s been a tester for a long time, she’s been working in an agile team for only a few months. Testing is a real challenge in an agile environment. Tara’s finding she needs to be part programmer to use the automated testing framework her company has adopted for acceptance tests. Some days Tara wishes her company would go back to waterfall development.

Source: Based on “Personas” from Agile 2009

157

A bit more detailed persona give personality to User Roles, helping the Team & Product Owner relate better to them.

Personifying Your Users

Night Nurse

RobinRobin leaves for work at 6pm, after sleeping during the day. She works a 7pm-7am shift in Labor & Delivery, caring for prospective mothers and their babies. It is an uneven shift; sometimes chaotic and busy, sometimes slow. There are 16 other nurses in a given shift, and they coordinate their activities in a central room. Bad IT makes Robin grumpy.

• Needs to be based on study of human behavior

• Usability Testing

• Observation

• Interviews

• Surveys

• Empathy helps to guide design decisions

• Should not be taken too literally

ScrumMaster

159

A ScrumMaster:

• Removes barriers between development

and the customer so the customer drives

development

• Teaches customers how to maximize ROI

and meet their objectives through Scrum

• Enforces the values and practices of Scrum

• Improves productivity in any way possible

• Introduces engineering practices and tools to help ensure

that each increment is potentially shippable

ScrumMaster Responsibilities

160

The ScrumMaster or Agile Project Manager wants one one-hour weekly status meeting instead of daily 15 minute stand-ups because one meeting is “more efficient.”

What do you do?

What do you do?

161

Egoism: When a person acts to create the greatest good for himself or herself.

Utilitarianism: The idea that the moral worth of an action is determined solely by its usefulness in maximizing utility or minimizing negative utility.

Altruism: The opposite of egoism, a person’s primary purpose is to promote the best interests of others.

Ethical Leadership

Source: Based on Domains of Ethical Theories from Leadership Theory and Practice

162

Listening

Empathy

Healing

Awareness

Persuasion

Conceptualization

Foresight

Stewardship

Commitment to the growth of people

Building community

Servant-Leadership

163

ScrumMaster Encourages:• Forthrightness• Blameless observations• Failing & learning fast

ScrumMaster Discourages:• Defensiveness• CYA retrenching• Fear of failure

Failure – End, or Means?

164

• Ensure everyone is doing what they have agreed to do

• Facilitate Scrum sessions

• Look for ways to improve productivity and collaboration

• Assist the Product Owner with the Product Backlog

• Use all of your senses, including common sense, and remember that you have no authority

Typical ScrumMaster Activities

“A dead ScrumMaster is a useless ScrumMaster” - Ken Schwaber

165

• Can a ScrumMaster also be a team member?

• Can a ScrumMaster also be a product owner?

• What potential issues might arise from these scenarios?

Dialogue – Hats of the ScrumMaster

166

What are the key differences between “traditional” PMs and “Agile” PMs or ScrumMasters?

• What project activities does a traditional Project Manager typically handle?

• How are these different from the activities required of a ScrumMaster?

• Are there issues with wearing these two different hats?

Group Discussion – PM vs. SM

167

• Set the standard for the discussion.

• Make the environment a priority.

• Be mindful of timing issues.

• Articulate the purpose of the discussion and its significance to the group.

• Make use of various techniques/tools to keep the discussion moving when tension arises or discussion comes to a halt.

• Try using an Agile game like “speedboat”

• Pay attention to group behaviors.

• Be relaxed and have a sense of humor to make sure discussions are enjoyable as well as educational.

• Seek consensus with methods like dot voting or fist of five

Facilitation Methods

168

The goal is to identify factors that are preventing you from moving forward. In this case the sailboat represents your group or organization. The issues holding it back are symbolized by anchors. Anything propelling you forward is wind in your sails.

Consensus Workshop Method “Sailboat”

Based on Speedboat by Luke Hohmann of Innovation Games

169

1. Build the foundation• Establish ground rules, roles and responsibilities

• Frame the problem, constraints and desired outcome

2. Explore possibilities• Generate options

• Solicit expert opinions

• Storyboard potential solutions

3. Seek agreement• Show of hands

• Roman vote

• Fist of Five

• Multi-voting

Facilitating Group Decision Making

170

Face the speaker

Maintain eye contact

Minimize external distractions

Respond appropriately

Focus solely on what the speaker is saying

Keep an open mind

Avoid letting the speaker know how you handled a similar situation

Wait until they finish to defend yourself

Engage yourself

Active Listening

171

Emotional Intelligence

Unlike your Intelligence Quotient (IQ) which is pretty well fixed at an early age, your measure of Emotional Intelligence, or Emotional Quotient (EQ) can be easily developed throughout your life.

Personal Competencies Social Competencies

SELF-AWARENESSKnowing one's internal states, preferences, resources, and intuitions

EMPATHYAwareness of others' feelings, needs, and concerns.

MANAGING EMOTIONS Managing one's internal states, impulses, and resources.

SOCIAL SKILLS Adeptness at inducing desirable responses in others.

MOTIVATION Emotional tendencies that guide or facilitate reaching goals.

SelfAwareness

Self-Management

SocialAwareness

RelationshipManagement

With Others

Wh

at I

See

Wh

at I

Do

With Me

172

Five Levels of Conflict and ResolutionLevel 1: Problem to Solve

• The normal conflict that occurs when team members have differences of opinions but can work through those for the greater good of the team and project.

• Seek collaboration – Seek a win-win situation

• Consensus. Learning where every team member’s head is with regard to the issue and, in time, arriving at a decision everyone can back.

Level 2: Disagreement

• Personal protection trumps collaboration. Language is guarded and open to interpretation.

• Support – Empowering the other to resolve the problem.

Level 3: Contest

• The goal is to win. It is no longer about resolution but about coming out on top.

• Accommodate – Yielding to the others view when the relationship is more important than the issue. Negotiate and get factual. Gather data to establish the facts.

Level 4: Crusade

• The battle lines have been drawn and each “side” does not believe the other side will change.

• Focus on lowering the level of conflict. Use “shuttle” diplomacy and deescalate. Protecting one’s own group is the focus.

Level 5: World War

• It is not enough that the person wins but that they destroy the other person.

• Do whatever is necessary to prevent people from hurting one another. Source: Lyssa Adkins Coaching Agile Teams

173

• Analyze the situation.

• Differentiate between wants and needs – both theirs and yours.

• Focus on interests and issues rather than on positions.

• Ask high and offer low, but be realistic.

• When you make a concession, make clear you are yielding something of value. And don’t just give in.

• Always make sure both parties feel as if they have won. This is a win-win negotiation. Never let the other party leave feeling as if he or she has been taken advantage of.

• Do a good job of listening and articulating.

Negotiations

Source: PMI PMBOK® Guide 4th Edition Section G.8

174

1. The ScrumMaster (SM) removes __________ between development and the customer.

2. __________would not have been a very good ScrumMaster.

3. __________ are altruists 4. With level 1 conflict, we seek

__________ situation.5. When facilitating a group, a

ScrumMaster should ___________ a foundation, explore the possibilities, and __________ agreement.

6. You need to be __________of others' feelings, needs, and concerns to possess empathy.

ScrumMaster Review

a) Bill Lumburgh

b) barriers

c) build

d) seek

e) servant-leaders

f) win-win

g) aware

1(b) 2(a) 3(e) 4(f) 5(c)(d) 6(g)

The Team

176

Steps1. Intro + Rules

2. 2 minute prep time

3. Get an estimate

4. Create velocity chart

5. 2 minute iteration

6. 1 minute improvement & new estimate

7. Repeat 5 times

8. Retrospective

Collaboration Exercise

Rules:1. Start point = End point (person)

2. Process the most work possible

3. Balls must have air time when being passed

4. Balls may NOT be passed directly to your neighbor on the left or right

5. Balls must be touched by each and every person

6. Balls cannot be processed as one group (the bag/box)

7. Balls left on the floor at the end of an iteration are waste and will be subtracted from your production total

Thank you Scott Dunn, Boris Gloger

177

The inspect and adapt cycle can be used to improve a system of production.

A system has a natural velocity.

Velocity of a team stabilizes because of the team’s system and because the team learns how to work together.

Having a large team makes communication more difficult

If you want to go faster, you have to change the system.

Exercise - What did we learn?

178

Traditional Silos Customer BA Designer DeveloperPM

CoreTeam(EXAMPLE)

BA / Tester

BA

Tester

ProductOwner

Developer

Designer

Developer /BA

SM

ReleaseManager

CapacityPlanner

Prod.

Architect

TechOps

BusinessSponsor

RiskAssessor

Security

Extended Scrum Team

BAAnalystsDeveloperDeveloperDeveloper

Designers TesterTesterTestersDevs

The Core Team ideally consists of

5-9 dedicated members (7 +/- 2)

The Extended Team may contain many additional members, each

playing an important role, but they are typically not dedicated to

the effort.

ProductOwner

179

The analyst on the project wants to work one sprint ahead so that the analysis is ready when the programmers need it.

The tech writers want to work one sprint behind so that they are “more efficient.”

What do you do?

Team of Specialists

180

• Lazy Members – Not all team members will always be equal contributors. Focus on leveraging strengths, and encourage the team to help poor performers.

• Consensus Quagmires – Group decisions can benefit from perspective and suffer from dilution. Use facilitation techniques to foster rapid, inclusive decision making.

• Hero Culture – Teams must have shared goals, not be driven by individual desires. Roving leadership is an ideal state.

Common Team Dysfunctions

What are some other dysfunctions you’ve seen?

181

Provide Feedback You can’t expect your team to operate in a vacuum.

Recognize PerformanceGive constructive feedback so they can meet your expectations. Reinforce what you like so they can continue to meet those expectations or exceed them.

Team Motivation

NegotiateRecognize that some team members will not feel comfortable with some goals set for them. Negotiate realistic outcomes.

Persuade Get to know each of your team members personally and find out what motivates them.

RespectRespect is fundamental in any relationship. You will get the very best from people if you have mutual respect.

182

Discuss answers to the following questions:

• Have you ever been in a high-performance team?

• What characterized that experience?

• Could you replicate it effectively in Agile projects?

Dialogue – High Performance Teams

183

Self-organization refers to a process in which the internal organization of a system, normally an open system, increases automatically without being guided or managed by an outside source.

Self Organization

Source: Wikipedia

184

Self-organizing teams:• Exhibit a high degree of

collaboration

• Operate with a high degree of trust and autonomy

• Work towards high performance

• Produce measurably great results

• Are very fulfilling to work on

Self Organizing Teams

Self-Organizing Teams are Characterized by:

• Small team size

• Dedicated resources

• Customer value orientation

• Individual competence

• Sustainable self-discipline

• Intense collaboration

• Easy information transfer

• Low decision feedback time

• Constant learning &

interaction

185

Team Diversity

We want a broad model of diversity based on style,not just demographics• Change Readiness• Emotional Intelligence• Risk Aversion• Motivation• Work Style

We want diversity as expressed in outer rings

ValuesBeliefs

Risk AversionEmotional Intelligence

MotivationChange Readiness

ReligionCommunications Style

Work ExperienceGeographic Location

Family StatusEducation and Qualifications

AgeGender

RaceSexual Orientation

EthnicityMental AbilitiesPhysical Abilities

186

The Team• Works cross-functionally

(reduce handoffs !)

• Shares roles to get the work done (i.e. generalizing specialist)

Roles of the Team

• A developer may write user documentation• A business analyst may perform testing• A tester may create graphics

• Develops the detailed task list and the estimates

• Volunteers for work (is not tasked)

• Raises issues to the ScrumMaster

• Assesses performance and makes process recommendations

187

Self organizing principles guide a team so they can operate with minimal management controlo As a team member, I will contact the ScrumMaster if I see a tweak

that can be made to a feature, that will maintain it’s business value, while reducing time, cost or risk associated with implementing that feature

o As a team member, when I complete my work, on a task, I will either help another team member, or start a new task, depending on what will most likely allow us to deliver the maximum value in a Sprint

o As a team member, I will provide honest and open feedback to my peers, to the ScrumMaster, to the Project Manager, whenever that feedback will help the performance of the team

Self Organizing Principles

188

This is not a cross-functional team:

Teams are Cross-Functional

This is.

Coding Testing

Analysis Coding Testing

Analysis Coding Testing

Analysis Coding Testing

Sprint 2Sprint 1 Sprint 3 Sprint 4 Sprint 5

Coding

Analysis

Testing

Coding

Analysis

Testing

Coding

Analysis

Testing

Sprint 2Sprint 1 Sprint 3 Sprint 4 Sprint 5

189

• Common area for collaborationo Open flow of information

• Caves for privacyo Intense problem solving

o Creative solitude

o Private phone calls

o Research

o Rocking silently and weeping

Caves and Commons Layout

We all need a place to call home

Whiteboard Covered Wall

Burndown Chart

CubiclesCubicles

Information Radiator

190

• Information transfer maximized through collocation

• Constant face-to-face communication and collaboration

• Allows for Osmotic Communications

• Self-organization & management facilitated by information radiators

Shared Visual Workspace

191

• Project Charter

• Agile Manifesto

• Key Contact Information

• Project Calendar (vacations, etc.)

• Objectives, Outputs & Outcomes

• Success Sliders

• Scope & Objectives Chart

• Values/Rules of Engagement

• Team Norms

• System architecture diagrams

• Information architecture diagrams

• Burn Down Chart

• Other metrics

• Project Backlog and Timeline

• Current Iteration Story Cards & Tasks (Tasks, WIP, To Verify, Done)

• Risks & Issues Log

• External dependencies/groups

• Days left in Sprint/Iteration

• Various team personalization stuff

Information Radiator Examples

Information radiators communicate what’s important for your project; each team has unique needs. Some examples:

192

Team Room Examples

1. Portable easel2. Smart board3. Risks & Issues noted4. Magnetic whiteboard5. Plant needs water6. Task board7. Pair programming station8. Status tracking by color9. Nice chairs

193

Documents

Email & Portals

Phone &Instant Messaging

Video & Teleconferencing

Face-to-face

Communications BandwidthAgile workspaces & information radiators are designed to reduce miscommunications, assumptions and disconnects by maximizing communications bandwidth.

Unidirectional Activities Bidirectional Activities

194

Isolated Scrum TeamsIndependent Daily Scrums.

Distributed Scrum of ScrumsRegular Scrum of Scrums.

Integrated Scrum TeamTeam members split across locations.

Distributed Daily Scrum Models

Daily ScrumDaily Scrum

New York Mumbai

Daily ScrumDaily Scrum

Daily Scrum

Scrum ofScrums

195

• Ensure more frequent feedback with shorter iterations

• Use continuous integration, or at least regular builds

• Send ambassadors, maintain site liaisons

• Put phone/video/messaging communications technology to use

• Use wikis for common project info

• Use test scripts to understand requirements

• Separate teams by functionality, not technical specialty

• Expect more documents

Check out Martin Fowler’s article http://martinfowler.com/articles/agileOffshore.html#UseContinuousIntegrationToAvoidIntegrationHeadaches

Suggestions for Distributed Teams

196

1. The ideal agile team size is ___________ to ___________ people.

2. Agile teams embrace the concept of ___________ instead of specialization.

3. Sharing functional responsibilities may require changes in ___________ policies and compensation.

4. Most of the team members should be ___________ time members of the team.

5. A focus on ___________ typically results in staff members working across teams and projects, which greatly reduces productivity.

Team Review

a) nine

b) full

c) utilization

d) human resource

e) five

f) shared responsibility

1(e) (a) 2(f) 3(d) 4(b) 5(c)

The Scrum ProcessInitial Planning*

Product Backlog

Release Planning

Sprint Planning

Sprint Backlog

Sprint

Sprint Review

Daily Scrum

Sprint Retrospective

Initial Planning

199

DescriptionSeries of facilitated sessions to orient team members to the project’s business value and analytical background, the Agile process, and one another.

DurationAs long as it takes!

AttendeesTeam, Product Owner, ScrumMaster, SMEs

Initial Planning at a Glance

Outputs•Project Orientation•Process Orientation•Team Orientation

Initial Planning

200

Agile Process Training

Product Discoveryo Agile Games with Customers

o Collaborative Modeling Workshop

o User Story Creation and Estimation

o Product Backlog Prioritization

o System Design

o Architecture Spike

Project Discovery o Sponsor Vision

o Business Context, Key Metrics

o Release Planning

o Sprint One Planning

Comprehensive Sprint 0

Process Discovery

o Process Value Stream Map

o Key Metrics

Team Discovery

o Team Norms & Core Hours

o Iteration Structure

o “Ready” Definition

o “Done” Definition

o Business value prioritization scheme

o Team Structure (Core/Extended)

o Stakeholder/Project Interactions

Sample Sprint 0 Session(s) might include:

201

1. Sprint 0 ___________ explicitly part of the scrum framework.

2. The product owner, ScrumMaster, key sponsors, key stakeholders, the ___________ and select subject matter experts participate(s) in the discovery sessions.

3. Business stakeholders and sponsors provide a clearly articulated vision with cascading ___________ so that we can ___________ measure future success.

4. In addition to providing context for the product, discovery provides context around the project, ___________ and team .

5. We avoid BDUF design. Instead we define just enough today to maximize the chance that we can deliver value tomorrow, recognizing that if we get too ___________, too early, we will likely over ___________ the team and get a less valuable product.

Sprint 0 Review

a) goals

b) is not

c) objectively

d) process

e) whole team

f) constrain

g) specific

1(b) 2(e) 3(a) (c) 4(d) 5(g) (f)

Product Backlog

203

DescriptionList of desired functionality for project prioritized by business value by Product Owner.

Key Characteristics• Contains requirements as

“User Stories”

• Near-term stories better defined

Managed byProduct Owner, ScrumMaster

Product Backlog at a Glance

Contains• Prioritized Product Backlog Items or User Stories• Rough estimates• [Optionally] Forecasted iteration boundaries• [Usually] Release Dates

ProductBacklog

204

Adding User Stories

• Anyone can suggest new User Stories

• Product Owner prioritizes them

Estimating & Elaborating

• High-priority items are estimated and described most precisely, since they will be worked on first

• Low-priority items are generally estimated and described coarsely

Prioritizing

• Prioritization is based primarily on Business Value

Product Backlog Essentials

# Backlog Item Estimate

1 Create login screen .5

…

20 Allow user to browserecently viewed items

8

…

60 Add personalization 30 (or so)

High priority items are better defined

Low priority items are often “epics”

205

While business value should be the primary Product Backlog prioritization criterion in most cases, it isn’t the only one to consider. One might also factor in:

o Risk

o Complexity

o Demand

o Integration points from/to related projects or vendors

Backlog Prioritization: A Closer Look

Some Tips: Create a prioritization scheme and Release Schedule that maximize the benefit realized

from incremental releases. Ensure that business needs and technical ones are balanced openly and jointly.

206

1. The product backlog is essentially a ___________ to-do list.

2. A generic term for an item in the product backlog is ___________, a.k.a. PBI.

3. A PBI can be expressed in ___________ or other concise formats.

4. A PBI can be expressed in user story format even if it will take ___________ sprints to complete

5. PBIs can be at varying levels of detail, from an ___________ that can take several releases to finish, all the way down to a user story which can be completed in a single sprint.

6. High priority items are defined in ___________ than are lower priority items.

Product Backlog Review

a) epic or feature

b) never-ending

c) many

d) more detail

e) product backlog item

f) user story

1(b) 2(e) 3(f) 4(c) 5(a) 6(d)

Release Planning

208

DescriptionInitial project planning session, to review initial Product Backlog and define Releases.

Duration2-4 hours

AttendeesTeam, Product Owner, ScrumMaster

Release Planning at a Glance

Outputs• Release Plan• Refined Product Backlog

ReleasePlanning

209

• Present Business Case & Desired FeaturesProduct Owner describes vision for product and initial set of User Stories

• Estimate User StoriesTeam estimates high-level features in terms of story points or ideal delivery days

• Prioritize User StoriesProduct Owner assigns priorities based on business value

• Formulate Release ScheduleGroup User Stories into “minimum marketable feature sets,” set Release dates

Release Planning Sample Agenda

Some Tips: This meeting should revolve primarily around the Release Schedule Product Owners: Come prepared with an initially prioritized Product Backlog Team: Come prepared with initial estimates for Product Backlog items

210

Planning Releases with Story Maps

Time

Pri

ori

ty

• Choose coherent groups of features that consider the span of business functionality and user activities

• Support all necessary activities with the first release

• Improve activity support with subsequent releases

R1 S1 R1 S2

ProvideNurse ID

ProvidePatient ID

FilterRecords

SortRecords

SearchRecords

AddComment

ViewHistory

EnterUpdates

SearchHistory

ReferenceValidation

Notify ofUpdates

R2 S1 R2 S2

AccessRecord

ReviewRecord

UpdateRecord

211

1. The ___________ brings ___________ product backlog items to the release planning session.

2. The ___________ provide(s) estimates in ___________ for the user stories and other product backlog items.

3. Based on story point estimates and velocity projections, the product owner can segment out which user stories will go into which ___________, and, for high priority, near term product backlog items, even which ___________.

Release Planning Review

a) clearly articulated

b) story points

c) sprint

d) product owner

e) whole team

f) release

1(d) (a) 2(e) (b) 3(f) (c)

212

What are some Visual Management Systems?

• Outside of work, describe some visual control systems.

• Are there opportunities to use them at home or work?

Information Radiators - VMS

213

Information Radiators

1-J

un

3-J

un

5-J

un

7-J

un

9-J

un

11

-Ju

n

13

-Ju

n

15

-Ju

n

17

-Ju

n

19

-Ju

n

21

-Ju

n

23

-Ju

n

25

-Ju

n

27

-Ju

n

29

-Ju

n

Cumulative Flow,Burnups,

Burndowns…

are only the beginning

214

Burndowns can provide context to make tough decisions at both the sprint and release level

Burndowns to Provide Context

Product Owner Speaking

To date, we have completed feature 1 through feature 4.

Unfortunately, we lost several key members of our team during iteration 6 and we are unlikely to get all planned features done for this release, unless we execute with perfection, which is unlikely.

We will likely delay feature 9 and 10 until the next release, unless we make some tradeoffs.

We already started discussions with sales and marketing and we may limit our work on feature 5 and 6 in the next Sprint.

To Date

BacklogFeature 1Feature 2Feature 3Feature 4Feature 5Feature 6Feature 7Feature 8Feature 9Feature 10

215

1. Release level burn downs track story points

remaining for a release. Sprint burn downs

have historically tracked ___________

remaining on ___________. Some teams

today now burn down ___________ instead.

2. The primary purpose of the burndown is to

help teams face reality so that they can

make ___________.

3. Variations on a burn down can be used, such

as ___________ or a ___________.

Burndown Review

a) burnup

b) cumulative flow diagram

c) hours

d) story points

e) tasks

f) tradeoffs

1(c) (e) (d) 2(f) 3(b) (a)

Sprint Planning

217

DescriptionMeeting to elaborate, estimate and prioritize highest-value User Stories, creating Sprint Backlog.

Duration2-4 hours

AttendeesTeam, Product Owner, ScrumMaster, SMEs

Sprint Planning at a Glance

Outputs• Estimated & Prioritized User Stories• Acceptance Criteria for User Stories• Sprint Backlog with Tasks

SprintPlanning

218

• Product Owners should arrive prepared to discuss top priority stories and ask any questions regarding alternate development paths

• The Team may prepare estimates and questions about different development scenarios

• Acceptance criteria should be jointly discussed and clarified

• The length of the Sprint Planning session will generally be proportional to the length of the Sprint

Sprint Planning Essentials

219

1. The ScrumMaster should create a ___________ of events, holidays and team member schedules to support capacity planning and coordination

2. The ScrumMaster should evaluate velocity data to spot ___________.

3. At the beginning of sprint planning, team member availability for the sprint is confirmed. This information is combined with the historical velocity data to determine ___________ velocity for the sprint.

4. Team members ___________ for stories and tasks. ___________ are discussed to the extent necessary to allow the team to credibly commit to their completion within the sprint.

5. Some teams detail out all ___________ at Sprint Planning, others detail out just ___________ tasks, others create just a few chunky tasks, and some team don’t detail out tasks at all.

6. The ___________ determines which user stories it will commit to completing within the sprint.

Sprint Planning Review

a) trends

b) target

c) volunteer

d) calendar

e) high priority

f) team

g) tasks

h) user stories

1(d) 2(a) 3(b) 4(c) (h) 5(g) (e) 6(f)

Sprint Backlog

221

DescriptionList of desired functionality for development in the current Sprint.

Key Characteristics

• Contains User Stories estimated at task level

• Acceptance tests defined

Managed byTeam, ScrumMaster

Sprint Backlog at a Glance

Contains• Prioritized User Stories & their tasks• Task-level estimates• Information needed to understand the tasks

SprintBacklog

222

Physical Task Boards

223

1. ___________ user stories are selected

from the product backlog for inclusion in

the ___________.

2. The sprint backlog is essentially a

detailed, short term, ___________

covering items for the ___________.

3. The sprint backlog may be stored in an

electronic tool, a ___________ board, or

both.

4. ___________ may, or may not, be stored

in the sprint backlog.

Sprint Backlog Review

a) high priority

b) physical

c) sprint

d) sprint backlog

e) tasks

f) to do list

1(a) (d) 2(f) (c) 3(b) 4(e)

Sprint

225

DescriptionWhen the work gets done!

Duration1-4 weeks

Key Characteristics

• Isolated from further change

• Requirements elaborated and refined

• Work organized adaptively

InvolvesTeam, ScrumMaster, Product Owner, SMEs

Sprint at a Glance

Outputs• Potentially shippable functionality• Other items, as prioritized by Product Owner

Sprint

226

Effective Agile teams organize their work so that it flows:• Critical activities are never stalled by work on lower-priority activities (which

may or may not arise in a future Sprint)

• Decisions are made at the last responsible moment

• Hand-offs are minimized in favor of synchronized collaboration

Self-Organized Work Patterns

Coding & Refactoring

Business Analysis

Testing

Sprint 1

User Experience

Architecture or Risk “Spikes”

Sprint 2 Sprint 3

227

Do your teams work like Agile teams?

• Does collaboration happen often across roles?

• Are activities assigned explicitly, or pulled based upon skill and capacity?

• Do you have critical person dependencies?

• Is communication between team members open and regular, or formalized and occasional?

Dialogue – Teamwork

228

1. The length of the sprint is ___________.

2. The sprint contains four ceremonies:

___________, ___________, ___________

and ___________.

3. Some teams ___________ their release and

planning cycles. These teams often continue

to use a fixed sprint cycle to provide a

cadence for planning and retrospectives.

4. Backlog grooming (User Story maturity) for

future sprints happens ___________.

Sprint Review

a) daily scrum

b) decouple

c) fixed

d) sprint planning

e) sprint retrospective

f) sprint review

g) during the current sprint

1(c) 2(d) (a) (f) (e) 3(b) 4(g)

Daily Scrum

230

DescriptionBrief, tightly facilitated status and risk management meeting for Team & Product Owner.

Duration10-15 minutes

AttendeesTeam, ScrumMaster, optionally Product Owner and Interested Stakeholders

Daily Scrum at a Glance

Outputs• Risks & Issues• Informal meetings

DailyScrum

231

• Reference specific tasks (at the task board if possible)

• Record and Review Risks and Issues

• Team members should speak to one another; this is an alignment tool, not an exercise to report to the boss

Three Questions in Three Minutes

What will you get done today?2

What did you get done yesterday?1

What’s in your way?3

Each participant answers 3 questions:

232

Quick Quiz:Who maintains the team board?

Parameters

• Daily

• 10-15 minutes

• Everyone stands

• Risks & issues noted

• Not for problem solving!

• Additional meet-ups arranged, often immediately following the Daily Scrum

• Core team talks

• Extended team listens

Daily Scrum Essentials

233

Core / Extended Team

ScrumMaster/ Agile PM

Product Owner

CIO

QA Manager

Tester

Business Analyst

Developer

Daily Scrum – Quick Quiz

Quick QuizWho is allowed to talk at the Daily Scrum (Stand-up)?

234

Some key benefits of the Daily Scrum include:

• Shared language among team members

• Real-time reallocation of resources

Key Benefits of the Daily Scrum

• Focus on value-creating activities

• Clear, prioritized work plan for each day

• Builds team identity and emotional commitment

235

1. The daily scrum is often called a daily ___________.

2. The ScrumMaster can help make the daily standup effective by providing ___________ about schedules, days left in sprint, release date, etc., during the first 45 to 90 seconds.

3. The focus of the daily standup is to convey information so that the team can ___________ their collaboration.

4. The daily standup should last no longer than ___________ minutes.

5. At the daily standup the team members talk to ___________.

6. Detailed discussions and planning should occur ___________ the daily scrum.

Daily Scrum Review

a) 15

b) after

c) co-ordinate

d) context

e) each other

f) standup

1(f) 2(d) 3(c) 4(a) 5(e) 6(b)

Sprint Review

237

DescriptionTeam demonstrates completed functionality to interested stakeholders, gathering feedback.

Duration2-4 hours

AttendeesTeam, Product Owner, ScrumMaster, optionally Users & Interested Stakeholders

Sprint Review at a Glance

Outputs• New Features on Product Backlog• Reprioritized Product Backlog• Revised Team or Project Structure

SprintReview

238

Present Completed User StoriesDemo live functionality completed in prior Sprint; no decks!

Record Customer & User Feedback

Adjust Product Backlog

o Remove completed functionality

o Reprioritize unfinished functionality

o Adjust priorities based on feedback

Adjust Project Structure

o Reformulate or resize the team

o Schedule or reschedule a release

o Decide to stop the project

Sprint Review

239

1. Another name for a sprint review is a sprint ___________ .

2. The sprint review should start with ___________ including a discussion on overall release progress, plans for the just completed sprint and identification of important tradeoffs to discuss.

3. The product owner and team members demonstrate ___________ built during the sprint.

4. The sprint review is a forum for the team and stakeholders to understand what has been done, what is left to be done, and what is likely to be done, so that they can make tradeoffs. These tradeoffs will impact the upcoming ___________ meeting.

Sprint Demo Review

a) context setting

b) demo

c) sprint planning

d) working software

1(b) 2(a) 3(d) 4(c)

Sprint Retrospective

241

DescriptionTeam continuous improvement session to reflect on project & process issues and take action as appropriate.

Duration30 minutes – 1 hour

AttendeesTeam, ScrumMaster, optionally Product Owner

Sprint Retrospective at a Glance

Outputs• Process revisions• Project or Team structure revisions• Other improvement action items

SprintRetrospective

242

The useful way to do “Lessons Learned:”

• Periodically take a look at what is and is not working in your process

• Typically 15–30 minutes

• Done after every sprint

• Whole team participates

• Generates action items to continuously improve project execution

Sprint Retrospective Essentials

Working Well Not Working Well

Automated unit testing

6am Daily Standup

Customers highly satisfied

Testing team availability

Retrospectives have improved process

Build cycle time

Estimates are stabilizing

Product Owner availability

Action Items

Set SLA with QAteam

PO delegates to proxy during Sprints

8am standup

243

Sprint Retrospective

244

Too often, companies focus too much attention on metrics like Team Performance and Team Efficiency, while ignoring metrics like Team Emotion or Happiness

Sprint Retrospective Team Emotion

245

1. The retrospective is often thought of as the

___________ part of the scrum process.

2. Effective retrospectives typically identify a

___________ of items to address.

3. At a minimum, a retrospective should

identify ___________ and ___________.

4. Additional items to cover in a retrospective

can include appreciations and ___________.

5. It is often helpful to collect ___________

feedback prior to the retrospective.

Sprint Retrospective Review

a) anonymous

b) deltas

c) learnings

d) most important

e) pluses

f) small number

1(d) 2(f) 3(b) (e) 4(c) 5(a)

Thank You!

247

Contact Us for Further Information

On the Web:LeadingAgile.com

Facebook: /LeadingAgile

Twitter: @LeadingAgile

Posters with images from presentation

TheCriticalPath.info & Pictofigo.com

Last Updated: 2/27/2015

248

Once this course has been completed:

• If you currently have a PMI credential (PMP or CAPM), you can submit 21 PDUs directly to PMI

• If you are pursuing the PMI-ACP and are applying for 21 Agile Contact Hours, you can submit this class under Agile Education

• If this is a public class, LeadingAgile will send you an email within 24 hours with a link to a PDF version of this deck

• LeadingAgile will send you a letter of completion within two business days

Logistics & Expectations

249

Hope is not a strategy Luck is not a factor

Fear is not an option

• At LeadingAgile, we are dedicated to solving the challenges associated with Agile in larger, more complex enterprises.

• We provide Agile training and coaching, strategic enterprise Agile transformation consulting, and Agile project and portfolio management services.

Specialties• Scrum, XP, AUP, RUP, Project Management, Program Management, Portfolio

Management, Agile Training, Agile Coaching, Agile Consulting, Agile Transformation