Agile Certified Practitioner (ACP) Exam Prep Course …...Agile Principles & Mindset Domain Tasks 1....

Agile Certified Practitioner (ACP) Exam Prep

Course 3a - Agile Principles & Mindset Part 1

Agile Principles & Mindset

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Agile Principles & MindsetDomain Tasks

1. Advocate for agile principles by modeling those principles & discussing agile values in order to develop a shared mindset across the team as well as between the customer & the team.

2. Help ensure that everyone has a common understanding of the values & principles of agile & a common knowledge around the agile practices & terminology being used in order to work effectively.

3. Support change at the system or organization level by educating the organization & influencing processes, behaviors, & people in order to make the organization more effective & efficient.

4. Practice visualization by maintaining highly visible information radiators showing real progress & real team performance in order to enhance transparency & trust.

5. Contribute to a safe & trustful team environment by allowing everyone to experiment & make mistakes so that each can learn & continuously improve the way he or she works.

6. Enhance creativity by experimenting with new techniques & process ideas in order to discover more efficient & effectives ways of working.

7. Encourage team members to share knowledge by collaborating & working together in order to lower risks around knowledge silos & reduce bottlenecks.

8. Encourage emergent leadership within the team by establishing a safe & respectful environment in which new approaches can be tried in order to make improvements & foster self-organization & empowerment.

9. Practice servant leadership by supporting & encouraging others in their endeavors so that they can perform at their highest level & continue to improve.

© Copyright and all rights reserved – Looking Glass Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

PMBOK Guide vs. Agile

• PMBOK® Guide is the umbrella framework.

• Agile represents a family of lifecycles sometimes called methodologies or frameworks.

• Agile methodologies fit within the PMBOK® Guide.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basics of PM


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Two Types of Agile• Iteration-based Agile

– Team works in iterations to deliver features.– Works from most important feature to least.– Team does NOT address even all the features in an

iteration at once.

• Flow-based Agile– Team pulls features from the backlog based on its capacity

to start work rather than on an iteration-based schedule.– Team defines its workflow with columns on a task board

and manages the work in progress for each column.

• Agile life cycles are those that fulfill the principles of the Agile Manifesto.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Four Types of Life Cycles• Predictive life cycle – The “traditional” approach. It is a linear

process with the majority of planning upfront then executed in a single sequential pass. They take advantage of things that are known and proven. The plan drives the work. Value is only delivered at the end.

• Iterative life cycle – An approach that allows feedback for unfinished work to improve and modify future outcomes. Prototypes and proofs are planned, and the outputs are intended to modify the plans at the beginning. When complexity is high or when there are frequent changes or scope is unknown.

• Incremental life cycle – An approach that provides finished deliverables in steps that the customer may use immediately. Here we plan to deliver successive subsets of the overall project. The team may deviate from the original vision. It uncovers hidden or misunderstood requirements.

• Agile life cycle – An approach that is BOTH iterative and incremental to refine work items AND deliver frequently. Here we plan and re-plan as more information becomes available.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Four Types of Life CyclesCharacteristics

Approach Requirements Activities Delivery GoalPredictive Fixed Performed once

for the entire project

Single delivery Manage costs

Iterative Dynamic Repeated until correct

Single delivery Correctness of solution

Incremental Dynamic Performed once for a given increment

Frequent smaller deliveries

speed

Agile Dynamic Repeated until correct

Frequent smaller deliveries

Customer value via frequent delivery and feedback


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basics of PMThe Big 3 Life Cycles


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Four Types of Life cycles


Incremental

Predictive

Agile

Iterative

Degree of Change

Freq

uenc

y of

Del

iver

y

Low

Low

High

High

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Strategies to Implement Agile

• Adopt a formal agile approach. Learn the approach in detail & then tailor it.

• Implement changes to project practices that fits the project context to get progress on a core value or principle.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Agile in Context


Lean

AgileKanbanScrumBan

AUPCrystal

ScrumXP

FDDDSDM

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Agile Methodologies• 16 different frameworks/methodologies are “Agile”• Most common include:

– Scrum– Extreme Programming– Feature-Driven Development (FDD)– Dynamic Systems Development Method (DSDM)– Crystal (Crystal Clear, Crystal Yellow, Crystal Orange…)

• Closely related concepts include:– Lean software development– Kanban

• Exam focuses on Scrum & XP although others might appear.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Agile is Iterative & Incremental• Incremental development – is a staging &

scheduling strategy in which the various parts of the system are developed at different times or rated and integrated as they are completed.

• Iterative development – is a rework scheduling strategy in which time is set aside to revise and improve parts of the system.

Alistair Cockburn

Overview


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Iterative & Incremental Approaches

• Very short feedback loops• Frequent adaptation of process• Reprioritization• Regularly updated plans• Frequent delivery


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Effects of WIP & “Best Resourcing”

Deliverable XOption 1 A AOption 2 A C A

Deliverable YOption 1 B BOption 2 B B C

Deliverable ZOption 1 C COption 2

• In Option 1 the best resource for the deliverable attempts to do each task for the feature and nothing gets delivered.

• In Option 2 resourcing is applied based upon availability and two features are delivered.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________


1960 1966 1972 1978 1984 1990 1996

USAF & NASAX-15 hypersonic jet erative Incremental

Delivery1950s-1960s

Tom GilibAdaptive iterations, fast time to market

1976

Gerald Weinberg Small increments, customer-driven

feedback

1980

Barry BoehnSpiral Model

1985

Hirotaka Takeuchi & IkujiroNonaka

The New New Product Development Game1986

Fred Brooks

Mythical Man Month

1975Fred

BrooksNo Silver Bullet - Essence and

Accident in Software

Engineering

1986

Ken Schwaber & Jeff SutherlandScrum Framework

1990

DSDM Consortium -

Dynamic System Development

Method

1994

Booch, Jacobson & RumbaughRational Unified Process

1995

Beck, Cunningham, & JeffriesExtreme Programming

1996

Jeff de LucaFeature Driven Development

1997

Alistair CockburnCrystal Family

1998

Robert CharetteLean Development

2000

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Beginning of Agile• February, 2001 in Snowbird, Utah

Overview

Kent Beck Mike BeedleArie van Bennekum Alistair CockburnWard Cunningham Martin FowlerJames Grenning Jim HighsmithAndrew Hunt Ron JeffriesJon Kern Brian MarickRobert C. Martin Steve MellorKen Schwaber Jeff SutherlandDave Thomas


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Overview

Agile Development Values…• Individuals & Interactions OVER Processes & Tools

• Customer Collaboration OVER Contract Negotiations

• Responding to Change OVER Following a Plan

• Working Software OVER Comprehensive Documentation


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The 12 Principles of Agile Software1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable

software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the

customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a

preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need,

and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development

team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be

able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its

behavior accordingly.

Overview


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Heartbeat of Agility


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Must, Wants & Needs

Needed Features36%

Rarely Used Features, 19%

Never Used Features

45%

Role of the ProductOwner is to cut offthe project beforewe do what won’tbe used.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Key Terms Pairing – Two developers working together at one workstation. One

writes the code while the other reviews each line as they go. Swarming – The entire team swarms around a single feature or story

e.g. everyone works together on a single story or feature at the same time. It sets a WIP limit of 1.

Mobbing – Combines the concepts of pairing and swarming. The entire team works off of a single keyboard on a single feature.

Mini-waterfalls – team addresses all of the requirements in a given period, then attempts to do all of the design, then moves onto do all of the execution.

Fishbowl window – Long-lived video conference link that allows non-collocated team members to watch each other throughout the day to reduce collaboration lag.

Scrum Basics


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Scrum Basics• Based on industrial process theory

– Self-organization – Emergence

• Defined Process Control vs. Empirical Process Control – Defined Processes - Repeatable processes such as in

manufacturing. Leads to commoditization. In projects often leads to rework.

– Empirical Processes - Complex processes where it is difficult to have consistent processes. Focuses on 3 keys.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Foundation• Visibility – The aspects of the process that affect

the outcome must be visible to those controlling the process & what is seen must be true.

• Inspection – The various aspects of the process must be examined frequently enough that unacceptable variances in the process can be detected.

• Adaptation – If one or more of the processes are determined out of control the processes change.

Scrum Basics


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Scrum Roles• Product Owner – Responsible for representing

interests of all stakeholders, obtaining funding, defining initial requirements, ROI, and objectives (Product Backlog).

• The Development Team – Develops the functionality. Is self-managing, self-organizing, and cross functional.

• Scrum Master – Responsible for the Scrum process, teaching Scrum to everyone, implementing Scrum so it fits with culture, and that everyone follows Scrum rules & practices.

Scrum Basics


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Team Members• C – Committed

• F – Focused

• O – Open

• R – Respected & Respectful

• C – Courageous

• E - Extreme© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Key Scrum Artifacts

• Serves as a Charter or 5 Line

• Required to begin any project.

• Never longer than a single page.

• Includes 5 key pieces of information: Need, justification, success criteria, prioritization, constraints & assumptions.


Schedule Status/Trend: CV: -$21,000 CPI: 0.90 OKBadCost Status/Trend: SV: -$13,000 SPI: 0.93 GoodBad

Actual Costs: $188,000 Cost EAC: $362,852 Sch. EAC: 56.05 WeeksProject Start Date: Project ID: 1234

Project Name: Sample Project Target Dt: 10/21/2011 Project Manager:Project Duration Est.: 52 Weeks Forecast Dt: 11/18/2011 Product Manager:

Project Budget Est.: 326,000$ Executive Sponsor:Development Methodology: Earned Value Reporting: Stage Gate Mgmt:

Fixed Flexible Accept PriorityScope

QualitySchedule

Costs

1 out of 10

Sponsor Approval: Date:

PM Approval: Date:

The Big Boss

Primary Risks

Communication & Reporting Process

Portfolio Fit

Business BenefitIncreased Revenue

Operational EfficiencyReduced Costs

Regulatory / Mandate

Key Constraints / Assumptions

Grow

Project Key Performance Indicators (KPIs)

Project Prioritization (# out of # for org.):

Run

Project Justification

Performance Trends

Project Success Criteria

Joe Smith10/22/2010

Project Datasheet

Change Management Process

Major Project Milestones and/or Phases

Pyramid Management

Project Scope Statement

Primary Stakeholders:

Tranform

$0

$100

$200

$300

$400

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov DecForecast Costs Forecast Results Budget

Waterfall Spiral XP/Scrum Yes No Yes No

In$1,000's

A Product / Project Vision

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Product BacklogKey Scrum Artifacts

• A prioritized list of items to be delivered.

• Each item is “relatively independent” of the others.

• Backlog may bereprioritized at anytime.

• Items = User Stories or PBIs• PBI = Product Backlog Item


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________


• New requirements are prioritized by your project stakeholders and added to the stack in the appropriate place.

• Fundamentally a single person needs to be the final authority when it comes to requirement prioritization (PO).

• The PO is responsible for representing all other stakeholders.• The backlog is initially filled as the result of requirements

envisioning efforts at the beginning of the project called "populating the backlog".

• Each iteration the team pulls an iteration's worth of work off the top of the stack and commits to implementing it by the end of the iteration.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________


• Project stakeholders have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit.

• Stakeholders are responsible for making decisions and providing information in a timely manner. On some projects a business analyst, often in the role of product owner, may take on this responsibility.

• The priorities of non-requirement work items are either negotiated by the team with stakeholders or are addressed as part of slack time within the schedule.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Scrum Basics

Scrum = 3 Roles + 4 Artifacts + 5 Meetings

Sprint Retrospective Not more than 2 hours for a 30 day sprint. Not more

than 1 hour to plan.

2 – 6 Week Sprints

Sprint Tasks Sprint

Backlog

Sprint end date & deliverables do not

change

Daily ScrumEvery 24 Hours


Backlog Ranked Product

Vision

PO, SM & Teamconduct Sprint

Planning Meeting • 1/2 to complete

grooming.

• 1/2 to define tasks & task estimates in ½ or full days. No task longer than 1 day.

Shippable Product

Release Planning

Sprint ReviewNot longer than 4 hours for a 30 day sprint nor

more than 1 hour to plan.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Daily Sprint Schedule


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basics of PMSprint Planning Meeting

PO speak to the sprint goal.Acceptance criteria.Team forecasts number of stories.Team breaks PBIs into tasks.Estimate tasks: 0.5 / 1.Build sprint burndown and task board.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basics of PMThe Daily Scrum

10 to 15 minute meeting for team to answer 3 questions. Stand up means STAND UP! Target 10 minutes, 15 max. Same time every day & don’t miss a day. Stand in front of the visual progress artifact. Everybody is present. No typing during the meeting. Concentrate on the 2nd and 3rd questions. Don’t talk to the Scrum Master. Talk to the team. Don’t solve problems as they become apparent.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basics of PMIteration-Based vs Flow-Based Agile

Iteration-based Agile questionsWhat did I complete yesterday?What am I going to complete today?What impediments do I have?

Flow-based Agile questions:What do we need to do to advance this piece of work? Is anyone working on anything that is not on the board?What do we need to finish as a team?Are there any bottlenecks or blockers to the flow of

work?© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basics of PMSprint Review

Summary of sprint by PO.PO demonstrates every acceptance criteria of

every story delivered.Gather feedback from stakeholders and

incorporate into product backlog.Update release plan and discuss next step.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basics of PMSprint Retrospective

The most important Scrum meeting.Important to change something in every

sprint.Remember: “It’s not a lesson learned until you

do something about.”Work on only the 2 most important lessons.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

PBI To Do In Progress Validate Impeded Done

TaskTaskTaskTaskTaskTask

PBI 1

PBI 2

PBI 3

PBI 4


TaskTask


TaskTaskTask

Tech DebtTech DebtTech DebtTech DebtTech Debt

Tech DebtTech Debt

Tech DebtTech DebtTech DebtTech Debt


TaskTask

TaskTaskTaskTaskTask

Tech Debt

The Basic Team Board or Scrum Board

Technical Debt

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

PBI To Do In Progress Validate Impeded Done


Adding Kanban to Scrum

Technical Debt

5 23TaskTaskTaskTask

TaskTaskTask

TaskTaskTaskTaskTask

TaskTask

TaskTaskTask

PBI

PBI

PBI

PBI

PBI

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Iteration 0• Used by some Scrum teams, but not part of

official process.

• Iteration 0 produces the architecture and feature list

• No useable functionality is produced in Iteration 0

• Iteration or milestone plan is critical to completion

Scrum


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Overview• XP is a methodology that introduces checkpoints

when new requirements can be adopted to improve productivity.

• Iterations of 1 to 2 weeks in length.

• Created by Kent Beck @ Chrysler with Ward Cunningham & Ron Jeffries.

• 12 practices grouped into four (4) areas.

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Basics• XP’s Focus is on:

– Goals– Activities – Values– Principles– Practices

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Basics– Goals – Produce high quality software. XP does this

through short development cycles.– Activities

• Listening - Programmers must listen to customers & understand the business processes.

• Designing – Software must be designed as components without complexity or dependencies between components.

• Coding – Is the meat of the methodology. It is the most important part according to XP advocates.

• Testing

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Core Values• Simplicity – Reduce complexity, extra features & waste. “Find

the simplest thing that could possibly work.”• Communication – All the team members know what is

expected of them & what others are working on.• Feedback – The team must get impressions & suitability

early. It’s about “failing fast”.• Courage – The team has to be willing to put its work out

there for others to see. Use pair programming & share code.• Respect – The team is accountable to each other for results.

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Basics– Principles

• Assume Simplicity – This is about treating every problem as if its solution were extremely simple.

• Embrace Change – Do not work against change, embrace it.

– Practices (4 areas)• Fine Scale Feedback• Continuous Process• Shared Understanding• Programmer Welfare

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Core Practices - Fine Scale Feedback• Paired Programming – Two programmers work together

at one workstation. One programmer writes while the other reviews & thinks strategically. Pairs are not fixed & change often.

• The Planning Game – XP’s main planning process. Occurs once per iteration (typically once per week) Incudes two parts: Release Planning & Iteration Planning.

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Fine Scale Feedback- Release Planning• Focused on determining which requirements are

included in which near-term release & when they should be delivered.

• Customer & developer are part of this.• Includes three (3) phases:

– Exploration Phase – Customer provides a short list of high-value requirements for the system that are written as User Stories.

– Commitment Phase – Business & developers commit to the functionality to include & next release date.

– Steering Phase – Plan can be adjusted, new requirements added, existing requirements changed or removed.

XP Core Practices


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Fine Scale Feedback - Iteration Planning• Focused on planning the tasks & activities of the

developers. • Customer is NOT part of this.• Includes three (3) phases:

– Exploration Phase – The requirements are translated to specific tasks & recorded on task cards.

– Commitment Phase – The tasks are assigned to programmers & the task durations estimated.

– Steering Phase – Tasks are performed & the results then matched with the original User Story.

XP Core Practices


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Core Practices - Fine Scale Feedback• Test Driven Development – Tests are written before code

is written. Tests are automated.– Write unit tests.– Fail tests. Programmers verify the tests fail.– Write code. Programmers write minimal amount of code to

pass tests.– Pass tests. Code is tested to ensure passage.– Refactor. Remove any code smells from the code.

• Whole Team – The customer does not always pay the bill, but always uses the system. Customer must be on hand at all times to answer questions.

XP Core Practices


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

XP Core Practices – Continuous Process• Continuous Integration – XP employs continuous

integration & requires the use of a repository loading it every few hours. Integration tests are run automatically.

• Design Improvement – Only code what is needed today. When problems occur refactor code to make it simpler & more generic.

• Small Releases – Frequent small releases to test are encouraged. Quality is maintained through continuous integration.

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Core Practices – Shared Understanding• Coding Standards – An agreed upon set of rules that the

entire team follows for a consistent style & format. XP advocates self-documenting code that reduces the need for code comments.

• Collective Code Ownership – Any pair of developers can make changes to any code & everyone is responsible for all code.

• Simple Design – “Simplest” is best approach to software design.

• System Metaphor – It is a story that everyone can understand about how the system works. It creates a naming convention that allows customers to guess what class/methods do.

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Core Practices - Programmer Welfare• Sustainable Pace – Programmers should not work more

than 40 hours per week & no two weeks in a row should have overtime.

• A key enabler of this concept is frequent code merges of code that is always executable. This code must constantly be tested to ensure it is of a high quality.

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Extreme Programming Workflow


1. Envision - conversations With the customer.

2. Speculate – StoriesAre generated

3. Explore - Developers use PairedProgramming to develop

code.

SourceControl

LocalIntegrationCh

eck-

In

Test

Code

Refactor

Continuousintegration

5. Close - Customer Acceptance Testing

4. Adapt

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basic Steps• Envision – determine the product vision project

community, and how the team will work together.

• Speculate – develop a feature-based release, milestone, and iteration plan to deliver on the vision.

• Explore - deliver tested features in a short timeframe, constantly seeking to reduce the risk and uncertainty of the project.

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

The Basic Steps• Adapt – review the delivered results, the

current situation, and the team’s performance, and adapt as necessary.

• Close – conclude the project, pass along key learnings and celebrate

Extreme Programming


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

XP vs. Scrum

Scrum• Teams work in sprints of 2

to 6 weeks.• Teams do NOT allow

changes into their sprints.

• Scrum teams control the order of work, but are informed by the PO.

• Scrum doesn’t prescribe any engineering practices

Extreme Programming• Teams work in iterations of

1 to 2 weeks.• So long as work has not

started on a feature it may be changed or replaced.

• XP teams work on a strict priority order as defined by the customer.

• XP prescribes TDD, automated testing, pair programming, simple design


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Feature-Driven Development (FDD)• Created by

– Peter Coad – A leader in the Object Oriented Programming Movement.

– Jeff De Luca – Co-wrote book with P. Coad. IBM Project Manager. Then founder of Nebulon Corp. in Australia.

• Reference books– Java Modeling Color with UML (Last Chapter) 1999– A Practical Guide to Feature-Driven Development 2002

• Origins– Singapore Bank where Peter & Jeff worked together.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Feature-Driven Development (FDD)

Develop an

overall model

Build a feature

list

Plan by feature

Design by

feature

Build by feature


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Feature-Driven Development (FDD)• 1. Develop Overall Model – The team holds a

kickoff and walks through the scope of the system including all of its context. – Detailed domain models are created for each modeling

area by small teams and presented for peer review.– One of the proposed models is selected to become

area domain model.– Domain area models are progressively merged into an

overall model.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Feature-Driven Development (FDD)• 2. Build Feature List – Knowledge from initial

modeling is used to identify the list of features by functionally decomposing the domain into subject areas.– Subject areas each contain business activities.– Steps within each business activity form the basis for a

categorized feature list.– Features in this respect are small pieces of client-valued

functions expressed in the form “<action><result><object>”– Features should not take more than two weeks to complete.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Feature-Driven Development (FDD)• 3. Plan by Feature – In this step, a development plan is

created where ownership of features, or feature sets are assigned as classes to specific programmers.

• 4. Design by Feature – The Chief Programmer selects a small group of features to be developed in the next two weeks.– A Design Package is produced for each feature.– Detailed Sequence Diagrams for each feature are produced.– Class & Method Prologues are written.– The Design Inspection is held.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Feature-Driven Development (FDD)• 5. Build by Feature

– The class owners develop the code for their classes.– Unit tests are conducted on the code.– Code inspection is conducted.– The feature is promoted to the main build.

• Return to step 3 and repeat the process.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Feature-Driven Development (FDD)• Domain Object Modeling – The team explores & explains the domain of

the problem.• Developing by Feature – Break the functions down into two-week or

shorter chunks & calling them features.• Individual Class Ownership – Areas of code have a single owner (different

from XP).• Feature Teams – Small dynamically formed teams that vet designs & allow

multiple designs to be evaluated.• Inspections – Reviews that help ensure good-quality design & code.• Configuration Management – Labeling code, tracking changes, &

managing source code.• Regular Builds – Make sure new code integrates with existing.• Visibility of Progress & Results – Track progress based on completed work.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Feature Driven Development (FDD)

Scrum• No formal process.• No model requirements.

• Product Backlog• Release plan provides initial

view of when PBIs delivered.

• Entire process is iterative

FDD• Five specific steps.• Creates overall model 1st

thing that is not working software.

• Feature List• Plan by feature

• Only the last three (3) steps are iterative.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Review Questions:

1. Which of the following statements BEST describes the relationship between Agile Development and the PMBOK Guide?

A. The PMBOK Guide represents PMI's methodology for executing projects. While Agile Development represents a software development framework.

B. Agile Development represents the newest way to execute a project while the PMBOK Guide represents the old way of executing a project.

C. The PMBOK Guide represents the overall framework for executing projects and Agile Development represents a set of specific methodologies used in project execution.

D. Agile Development represents the overall framework for executing projects and the PMBOK Guide represents a set of specific practices used in large scale projects.

2. Which of the following thought leaders is considered the father of the linear

development methodology know as "Waterfall" A. Alistair Cockburn B. Winston Royce C. Lyssa Adkins D. Ken Schwaber

3. Which of the following terms refers to a staging and scheduling strategy in which the various parts of the system are developed at different times or rated and integrated as they are completed?

A. Iterative development B. Incremental development C. Staged development D. Agile development

4. Which of the following terms represents a scheduling strategy where time is set

aside to revise and improve parts of the system? A. Iterative development B. Incremental development C. Staged development D. Agile development

5. Which comparing traditional linear development to agile, which of the following statements is most likely to be true?

A. Agile development makes extensive use of best resourcing to ensure optimal productivity while traditional development uses WIP.

B. Both traditional development and Agile make use of best resourcing to ensure optimal productivity.

C. Both traditional development and Agile make extensive use of WIP to ensure optimal productivity.

D. Agile development makes extensive use of WIP while traditional development uses best resourcing to ensure optimal productivity.

6. Within the Agile Manifesto, which of the following is valued more than processes and tools?

A. Individuals and interactions B. Customer collaboration C. Responding to change D. Working software

7. Within the Agile Manifesto, which of the following is valued more than contract

negotiations? A. Individuals and interactions B. Customer collaboration C. Responding to change D. Working software

8. Within the Agile Manifesto, which of the following is valued more than following a

plan? A. Individuals and interactions B. Customer collaboration C. Responding to change D. Working software

9. Within the Agile Manifesto, which of the following is valued more than

comprehensive documentation? A. Individuals and interactions B. Customer collaboration C. Responding to change D. Working software

10. Which of the following Agile principles found in the Agile Manifesto is considered MOST important?

A. Welcoming changing requirements, even late in develop. B. Working software is the primary measure of progress. C. Simplicity -- the art of maximizing the amount of work not done. D. Satisfying the customer through early and continuous delivery of valuable

software.

11. Which of the following principles found in the Agile Manifesto focuses the team on the importance of adaptation?

A. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

B. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

C. Business people and developers must work together daily throughout the project.

D. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

12. Within the Agile Manifesto, which of the follow principles focuses the team on the importance of iterations?

A. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

B. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.


D. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

13. Which of the following principles found in the Agile Manifesto focuses the team co-location, osmotic communication, and information radiators?

A. Simplicity - the art of maximizing the amount of work not done - is essential.

B. Agile processes promote sustainable development. Everyone should be able to maintain a constant pace indefinitely.


D. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

14. Which of the following principles found in the Agile Manifesto focuses teams on a pace often referred to as the Heartbeat of Agility?

A. Continuous attention to technical excellence and good design enhances agility.

B. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

C. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

D. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

15. A common term used by agilists to describe the cadence or pace created in Agile Development is__________.

A. The Agile Cadence B. Agile Throughput C. The Heartbeat of Agility D. The Agile Rhythm

16. Which of the following statements concerning the Heartbeat of Agility is NOT

true? A. The notion of a consistent cadence or pace is absolutely critical to Agile

Development. B. The Heartbeat of Agility is all about establishing a rhythm that is

comfortable and sustainable by the team. C. The Heartbeat of Agility establishes a rhythm that often differs from what

the Team experiences in the real world. D. The Heartbeat of Agility establishes a pace with slow periods throughout

most of the project.

17. An Agile Coach is explaining to a new Scrum Master that they believe the Team has NOT been doing Scrum correctly as they are experiencing slow periods of production throughout most of the project only to be forced into a mad dash at the end of each Sprint in hopes of delivering business results. Typically, the team has failed to meet the deadline, is burnt out, and has left their customer frustrated. Which term BEST describes what the team has failed to establish?

A. Clear team expectations B. The Heartbeat of Agility C. Proper Scrum training D. Well defined spike management

18. According to one recent study, what percentage of the average software development project's features are never used?

A. 55% B. 45% C. 35% D. 25%

19. Which of the following represents a way Agile Development helps to prevent the

customer from having to sacrifice quality in order to hit a targeted delivery date? A. Agile methods require the customer to prioritize the project requirements

from most important to least. B. Agile methods iterate the project to prevent mistakes. C. Agile methods require the customer to continue the project until the

backlog is delivered. D. Agile methods force the customer to not require unused features be

delivered.

20. Which of the following statements concerning Agile Development is NOT true? A. Agile Development increases the visibility a customer has on a project. B. Agile Development puts the customer in a position to see constraints

before they cause failure. C. Agile Development ensures the customer receives something of value by

the deadline. D. Agile Development gives the customer their most important features

earlier in the process.

21. In 1986 Hitotaka Takeuchi and Ikujiro Nonaka published an article that appeared in the Harvard Business Review entitled The New Product Development Game which became the basis for which Agile Method?

A. Feature-Driven Development B. Extreme Programming C. Dynamic Systems Method D. Scrum

22. Scrum is based on which of the following aspects of Industrial Process Theory?

A. Self-organization and emergence B. Convergence and self-organization C. Emergence and dynamic evolution D. Dynamic evolution and Convergence

23. Which of the following concepts represents the idea that information, requirements and facts will be seen over time as the project progresses?

A. Convergence B. Emergence C. Self-organization D. Dynamic evolution

24. Which of the following concepts represents the idea that the Development Team

will decide what work needs to be accomplished and who will do the work to deliver the desired business results?

A. Convergence B. Emergence C. Self-organization D. Dynamic evolution

25. According to Jeff Sutherland and Ken Schwaber, traditional project management

is based on the concept of a defined process. This concept is most effective when used in what kind of organization?

A. A projectized organization B. A matrix organization C. A functional organization D. A manufacturing organization

26. Which of the following terms represents a process in which goods that have

economic value and are indistinguishable in terms of attributes (uniqueness or brand) end up becoming simple commodities in the eyes of the market or consumers.

A. Standardization B. Commoditization C. Convergence D. Optimization

27. When describing the various types of processes a project might use which of the following statements is MOST true?

A. Projects have the greatest chance of success when empirical processes are used.

B. Projects have the least chance of success when empirical processes are used.

C. Projects have the greatest chance of success when defined processes are used.

D. Projects have the least chance of success when defined processes are used

28. Which of the following is NOT a key driver for empirical processes? A. Visibility B. Inspection C. Adaption D. Flexibility

29. When describing an empirical process, which of the three major drivers defines

the step where the team brings the process back into conformance once an unacceptable variance is found?

A. Visibility B. Inspection C. Adaptation D. Conformation

30. Which of the following Scrum roles represents the person who is responsible for

representing the interests of all stakeholders, obtaining project funding, defining the initial requirements, defining the project ROI, and the key project objectives?

A. Product owner B. Key stakeholder C. Project sponsor D. Customer

31. Within Scrum, where are the product features maintained and appear in ranked

order from most important to least? A. The product scope statement B. The product backlog C. The project charter D. The requirements matrix

32. Which of the following statements concerning the Product Backlog is NOT true? A. A Product Backlog is never complete. B. The Product Backlog evolves as the product and the environment in which

it will be used evolves. C. The Product Backlog lists all features, functions, requirements,

enhancements, and fixes that constitute the changes to be made to the product.

D. The Product Owner may decide to "lock down" the Product Backlog at any time.

33. Which of the following statements concerning the Product Backlog is NOT true? A. Higher ranked backlog items are usually more clearly and completely

defined than lower ranked items. B. Any backlog item that can be "done" within one sprint is deemed "Ready"

for selection in Sprint Planning. C. The product owner is responsible for all estimates of items appearing on

the product backlog. D. The Scrum Team defines when refinement is done for all backlog items.

34. What primary Scrum role is described as self-managing, self-organizing, and

cross functional? A. The product owner B. The development team C. The Scrum team D. The Scrum master

35. What is the recommended size of the Scrum Development Team?

A. 6 +/- 3 B. 5 +/- 3 C. 3 +/- 4 D. 4 +/- 4

36. Which of the following statements about the Scrum Master is NOT true?

A. The Scrum Master is responsible for the Scrum process. B. The Scrum Master is responsible for implementing Scrum so it fits with

culture. C. The Scrum Master acts as a facilitator. D. The Scrum Master acts as the project manager for the project.

37. Which one of the following represents one of the key expected behaviors of the Development Team represented by the acronym CFORCE?

A. Convicted B. Focused C. Opportunistic D. Courteous

38. Which of the following represents one of the key expected behaviors of the

Development Team NOT represented by the aronym CFORCE? A. Extreme B. Courageous C. Reasoned D. Committed

39. You are acting as a Scrum Master for a new project within your organization.

There currently isn't any documentation for the initiative. Which of the following documents is required before the team can begin work according to the rules of Scrum?

A. A business case B. A needs analysis C. User stories D. A project vision

40. Which of the following items is NOT one of the five core elements found in a

project vision document? A. The business case B. the project justification C. Success criteria D. Constraints and assumptions

41. According to Moore, which of the following is a common way to validate a project

Vision? A. The PDCA Test B. The ROAD Test C. An Elevator Test D. An Ishikawa Test

42. You are asked to explain the project initiation process when using Scrum to a coworker. As part of the discussion you explain two documents are required. What are those two documents?

A. A business case and user stories B. A burndown chart and user story log C. A kanban board and a business case D. A product vision and product backlog

43. Which of the following terms represents a self-contained unit of work agreed

upon by the developers and the stakeholders? A. User Stories B. Themes C. Epics D. Releases

44. Which of the following terms represents a group of related user stories that

contribute to a common goal or are related in some obvious way? A. User Stories B. Themes C. Epics D. Releases

45. Which of the following terms are made up of multiple user stories, but also

sometimes resemble stories in the sense that they may appear as a larger story or complrise a complete workflow for a user and cut across all or some of the three business dimensions?

A. User Stories B. Themes C. Epics D. Releases

46. Which of the following terms represents a grouping of functionality that is most

often seen when teams are implementing SAFe as they are often used to enhance business value of the FULL solution set or bring a range of technologies together?

A. Epics B. Rocks C. Sprints D. Rocks

47. When discussing discussing sprints which of the following statements is NOT true?

A. The original Rules of Scrum stated that each Sprint was 30 days in length. B. The Development Team must decide the length of each sprint during the

Sprint Planning Meeting. C. Over the years, Scrum has adopted the practices from other Agile

methodologies and the common practice is to see sprints of between two and six weeks in length.

D. Each sprint must be the exact same fixed length.

48. Which of the following may explain why releases become necessary: A. The organization that has set specific windows where new code can be

put into the production system. B. It is either impractical or ill advised to put the features completed from a

single sprint into production because the Scrum Master determines it to be so.

C. Releases are never necessary. D. Releases are required on every Scrum project

49. What is the first official meeting defined in the Scrum Guide?

A. The project kickoff B. The release planning meeting C. The sprint planning meeting D. The sprint retrospective

50. What officially signifies the start of each sprint?

A. The product owner announces the sprint initiation. B. It is noted by the calendar. C. The Sprint Planning Meeting D. It varies from one Scrum project to the next.

51. Which of the following is NOT a core purpose of the Release Planning Meeting?

A. The Development Team uses the meeting to examine the backlog items to determine how they need to be grouped together to produce releases.

B. The Development Team uses the meeting to determine how long each sprint will be.

C. The Development Team uses the meeting to determine how the Sprints will be grouped into Releases.

D. The Development Team uses the meeting to create estimates for the significant User Stories.

52. The process of defining Backlog items in greater detail is called __________. A. Grooming B. Defining C. Decomposition D. Consecration

53. When defining a User Story, which of the following rules apply?

A. Each User Story must be completed within one release. B. Each User Story must provide monetary value to the business. C. Each User Story must be completed within one sprint. D. Each User Story represents a single work package.

54. Which of the following is NOT a key question asked during the Daily Scrum?

A. What did they accomplish yesterday? B. What are the User Story durations? C. What are they going to accomplish today? D. What impediments do they have?

55. What is the role of the Product Owner in the Daily Scrum?

A. The PO leads the Daily Scrum. B. The PO does not attend the Daily Scrum. C. The PO answers the key questions. D. The PO acts as an observer in the Daily Scrum.

56. As the Development Team completes the work of a Sprint within the Scrum

framework what is the primary responsibility of the PO? A. Defend the team and secure project funding. B. Groom the backlog and remove impediments. C. Groom the backlog and define the next sprint D. Remove impediments and define the next sprint.

57. You are working on a software development project within your organization serving the the role of Scrum Master. The team is in the middle of its fourth two-week iteration when the Product Owner, who is also the company CEO has just come to you demanding a critical piece of functionality be added to the current Sprint. What should you do?

A. Immediately call the team together to discuss the issue. B. Add the functionality to the sprint backlog C. Remind the PO that in agreeing to use Scrum they committed to not

changing the features the team worked on once a Sprint began. Then ask that they add the feature to the Product Backlog and prioritize it highly.

D. Freeze the project until the issue is resolved.

58. May the Development Team ever alter the features being completed in the current Sprint?

A. Yes, whenever a member of the team believes it is warranted. B. No, changing the work of an in-progress Sprint is never allowed. C. Yes, when new information is learned, or the team finds they have extra

time and the entire team agrees. D. No, only the Product Owner may change the work of an in-progress

Sprint.

59. You are the Scrum Master for a mid-sized project that has just completed its third two-week Sprint. What should the Team do next?

A. Plan and conduct the Sprint Review. B. Plan and conduct the Sprint Retrospective C. Review the Product Backlog before beginning the next Sprint. D. Initiative a Release Planning Meeting.

60. When a team conducts a Sprint Retrospective what is the role of the Product

Owner? A. The Product Owner leads the Sprint Retrospective. B. The Product Owner acts as a team member in the Sprint Retrospective. C. The Product Owner coordinates the objectives of the Sprint Retrospective

with the Scrum Master. D. The Product Owner does not participate in the Sprint Retrospective.

61. A member of the business organization has just returned from a basic Agile training course and wants you and the rest of the Development Team to use an iteration zero in an upcoming Scrum project. Which of the following is NOT a reason for this recommendation?

A. The team believes a more formal architecture plan is needed. B. The team believes the project requires an iteration or milestone plan. C. The team believes the project is extremely complex requiring more

traditional planning. D. The team believes the advanced planning will allow it to move quickly

moves into more standard Scrum sprints.

62. Which of the follow is NOT one areas of focus for Extreme Programming? A. Goals B. Testing C. Activities D. Values

63. Which of the following is NOT a core activity used in Extreme Programming used

to meet its stated goal? A. Listening – Programmers must listen to customers and understand the

business processes. B. Designing – Software must be designed as components without

complexity or dependencies between components. C. Testing – The team must test a functionality. D. Deployment - The team must implement the product or service of the

project.

64. Which of the following is a core value of the Extreme Programming methodology?

A. Guidance B. Commitment C. Simplicity D. Dedication

65. Which of the following is NOT a core value of the Extreme Programming

framework? A. Curious B. Feedback C. Communication D. Respect

66. Which of Extreme Programming practices does NOT belong in the Fine Scale Feedback group?

A. The Planning Game B. Design Improvement C. Test-Driven Development D. Whole Team

67. What Extreme Programming practice calls for a meeting that occurs once per

iteration and likely occurs once per week? This practice is focused on determining which requirements are included in which near-term release and when specifically they should be delivered.

A. Paired Programming B. The Planning Game C. The Whole Team D. Test-Driven Development

68. The team is using Extreme Programming to complete the project, the business

and developers are meeting to commit to the functionality to include within the next release and what the release date will be. In what phase of the Planning Game are you?

A. Exploration B. Planning C. Commitment D. Steering

69. In the XP practice group known as Shared Understanding which of the following

is not a core practice? A. Coding Standards B. Simple Design C. Collective Code Ownership D. Complete Metaphor

70. In discussions with another developer on an XP project team your remind them

of YAGNI. What are you suggesting? A. System designs are usually best when they are kept simple. B. Good design requires a strong overall view of the the project. C. Good architecture is layered in its approach. D. Systems thinking is critical to project success

71. When the creators of Extreme Programming discuss the importance of a sustainable pace to what are they referring?

A. Programmers are not permitted to work more than 40 hours per week on average and no two weeks in a row have over time.

B. Programmers are not permitted to work more than 40 hours per week on average and no more than one week per month has overtime.

C. Programmers are not permitted to work more than 50 hours per week on average and no more than two weeks per month have overtime.

D. Programmers are not permitted to work more than 50 hours per week on average and no more than two weeks in a row have over time.

72. Which of the following is NOT one of the basic steps found the the Extreme Programming process?

A. Envision B. Speculate C. Create D. Adapt

73. Which of the following is NOT one of the basic steps found the the Feature-

Driven Development process? A. Develop Overall Architecture B. Build Feature List C. Plan By Feature D. Build By Feature

74. Feature-Driven Development defines six milestones per feature. During which

activity are the first three milestones completed? A. Build Feature List B. Plan By Feature C. Design By Feature D. Build By Feature

75. FDD is unique because because at the point coding begins a feature is already

____ complete. A. 36% B. 38% C. 42% D. 44%

76. Which of the following statements concerning domain models is NOT true? A. Domain models reflect our understanding of real world entities and their

relationships and responsibilities. B. Domain models help resolve ambiguities in both the requirements and the

design intent. C. Domain models are typically developed by the Product Owner. D. Domain models reflect our understanding of real world entities and their

relationships and responsibilities.

77. In which FDD role does the person work as a member of a three to six member team who designs, codes, tests and documents the features required on the projects?

A. Domain Experts B. Class Owners C. Chief Programmers D. Development Manager

78. In which FDD role are the users, sponsors, and business analysts who have the

specific knowledge relied upon to deliver and correct the system? A. Domain Experts B. Class Owners C. Chief Programmers D. Development Manager

79. Which of the following is NOT a secondary role found in Feature-Driven

Development? A. Toolsmith B. Build Engineer C. Language Guru D. Product Manager

80. Within the process of Domain Object Modeling, which class category color

represents a moment in time or an interval of time usually associated with some business process?

A. Yellow B. Blue C. Green D. Pink

81. Which of the following is a core aspect of Industrial Process Theory used as a basis for Scrum?

A. Divergence B. Capitalization C. Self-organization D. Duality

82. Which of the following terms represents repeatable processes that lead to

commoditization and in projects can cause rework? A. Agile processes B. Manufacturing processes C. Empirical processes D. Defined processes

83. Your organization is using Scrum to manage a software development project

when a number of stakeholders bring to the team’s attention a number of missing requirements. Who is responsible for prioritizing these new requirements?

A. The Team B. The Stakeholders C. The Product Owner D. The ScrumMaster

84. When using Scrum, who is responsible to attend all Scrum meetings on time and

be prepared? A. The Scrum Team B. The Product Owner C. The ScrumMaster D. The ScrumMaster

85. When using Scrum, who is responsible for regularly demonstrating working

product at the Sprint Review. A. The Scrum Team B. The Product Owner C. The ScrumMaster D. The Key Stakeholders

86. When using Scrum, who is responsible to assist the Product Owner with analyzing and decomposing Product Backlog items?

A. The Product Owner B. The Scrum Team C. The Development Team D. The ScrumMaster

87. When using Scrum, what is the difference between the Development Team and

the Scrum Team? A. They are the same thing. B. The Development Team are the people who do the work of the project

while the Scrum Team includes the Development Team, the PO & the ScrumMaster.

C. The Scrum Team are the people who do the work of the project while the Dev Team includes the Scrum Team, the PO & the ScrumMaster.

D. The Scrum Team represents the group of people who manage the organization’s Scrum process and the Development Team does the project work.

88. In Scrum, who provides daily status updates to the Scrum Master at the Daily Scrum?

A. Everyone B. The Development Team C. The Scrum Team D. No One

89. In Scrum, who is responsible for avoiding distracting the Team after the Team

has committed to the Sprint Goal? A. No one B. The Product Owner C. The ScrumMaster D. Everyone

90. In Scrum, who observes end-to-end flow of product delivery and takes action to

maximize the delivery of value? A. No one B. The Product Owner C. The Scrum Master D. Everyone

91. In Scrum, who assigns work to individual team members? A. No one B. The Product Owner C. The ScrumMaster D. Everyone

92. In Scrum, who helps those outside the Development Team understand which of

their interactions with the Team are helpful and which are not, and helps everyone change these interactions to maximize the value created by the team?

A. No one B. The Product Owner C. The Scrum Master D. Everyone

93. In Scrum, who attends Sprint Planning meetings when the Team requests their

expertise? A. Business Stakeholders B. The Product Owner C. The ScrumMaster D. Everyone

94. In Scrum, who is the sole person responsible for managing the Product Backlog?

A. Business Stakeholders B. The Product Owner C. The ScrumMaster D. Everyone

95. What is the desired iteration length for a project using Extreme Programming?

A. One to two weeks B. Two to six weeks C. 30 days D. As short as possible

96. Which of the following is NOT a core activity used in the production of XP’s

goals? A. Listening B. Designing C. Developing D. Testing

97. Which of the following is NOT a core value of Extreme Programming? A. Simplicity B. Speed C. Courage D. Respect

98. Which of the following XP core values represents the Team’s willingness to put

its work out there for others to see? A. Respect B. Feedback C. Communication D. Courage

99. Which of the following is NOT one of the areas of practice for Extreme

Programming? A. Fine Scale Feedback B. Assume Simplicity C. Continuous Process D. Shared Understanding

100. Which of the following is part of XP’s Planning Game?

A. Sprint Planning B. Iteration Grooming C. Release Planning D. Iteration Forecasting

101. In Extreme Programming, which of the following is focused on determining which

requirements are included in which near-term release and when they should be delivered?

A. Sprint Planning B. Release Planning C. Iteration Planning D. Iteration Forecasting

102. Which of the following statements BEST describes XP’s notion of Test Driven

Development? A. Tests are constantly integrating into the development process. B. Tests are written, and applied before any code is written. C. Tests are required for all code. D. Tests are developed with input from all stakeholders.

103. Which of the following statements BEST describes XP’s notion of the Whole Team?

A. Project sponsors must be present for all key meetings. B. The customer must be present for all key meetings. C. The customer must be on hand at all times to answer questions. D. The customer and sponsors must be on hand at all times to answer

questions.

104. Within XP, which of the following is NOT a core practice found in the Continuous Process area?

A. Continuous Integration B. Design Improvement C. Small Releases D. Test Driven Development

105. Within XP, which of the following is NOT a core practice found in the Shared

Understanding area? A. Small Releases B. Coding Standards C. Simple Design D. System Metaphor

106. In which FDD step does the team hold a kickoff and walk through the scope of

the system? A. Develop an overall model B. Build a feature list C. Plan by feature D. Design by feature

107. In FDD, which of the following terms is the process by which the team explores

and explains the domain of the problem? A. Domain Area Modeling B. Designing by Feature C. Domain Object Modeling D. Configuration Management

108. In which FDD step does the team use knowledge from the initial model to identify the list of features by functionally decomposing the domain into subject areas?

A. Domain Area Modeling B. Designing by Feature C. Domain Object Modeling D. Build Feature List

109. Which of the following FDD concepts is used to reference the process of labeling

code, tracking changes, and managing source code? A. Inspections B. Regular builds C. Configuration management D. Domain modeling

110. In FDD who vets designs and allows multiple designs to be evaluated?

A. Feature teams B. The sponsor C. The project manager D. The development team

111. Which of the following principles from the Agile Manifesto calls on the team to

complete an introspection step as part of their process? A. At regular intervals, the team reflects on how to become more effective,

then tunes and adjusts its behavior accordingly. B. Continuous attention to technical excellence and good design enhances

agility. C. Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace indefinitely.

D. Business people and developers must work together daily throughout the project.

112. When comparing Scrum to FDD which of the following statements is true? A. Both Scrum and FDD makes use of a ranked product backlog. B. In Scrum the entire process is iterative. In FDD only the last three steps

are iterative. C. FDD does not have a formal process for development whereas Scrum

does. D. Neither Scrum nor FDD have formal model requirements.

113. When comparing Scrum to XP which of the following statements is true? A. In formal Scrum sprints are 30 days in length and in XP iterations are one-

to-two weeks in length. B. In neither Scrum nor XP does the team allow changes to their iteration. C. Scrum and XP require the Product Owner to define the order of work to be

completed. D. Neither XP nor Scrum prescribe specific engineering practices.

Answer Key:

1. C LGd course manual p. 23 - The relationship between Agile Development and the PMBOK Guide has traditionally been contentious. Many agilists try to argue Agile Development and the PMBOK Guide are at odds. However, nothing could be further from the truth. The PMBOK Guide represents generally accepted principles and practices. It does NOT represent a methodology that can be followed step-by-step. Many agilists also claim that their particular concepts are a framework representing a loose scaffolding. However, most thinkers agree Agile represents an aggregation of methodologies.

2. B LGd course manual p. 25 - Dr. Winston W. Royce is often falsely credited with developing the waterfall methodology based on a he wrote in 1970. However, if one actually reads his paper they find he actually argued there were significant risks in the linear process and proposed an iterative anc incremental approach with at least two loops. He also argued for prototyping.

3. B LGd course manual p.25 - Alistair Cockburn defines Incremental development as a staging and scheduling strategy in which the various parts of the system are developed at different times or rated and integrated as they are completed. This means that the features or requirements do not have to be completed as part of a single release. When a team uses incremental delivery they are able to deliver features or requirement in a wide range of orders defined by the team. This fundamentally changes how projects are executed. Suddenly, it what is delivered at any point in the project. This notion is somewhat similar to the ideas surrounding Object Oriented Programming where features and requirements are delivered as discrete objects independent of others.

4. A LGd course manual p. 26 - Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The concepts of Iterative Development creates loops in the process of executing a project that allow the team to change their process to improve execution and delivery. In a single looped linear process, the team is stuck with the process with which they start the project. This is a key advantage to seasoned, experienced teams. Those teams have completed multiple projects together and hopefully those experiences provide insights on the current effort. Agile projects get lots and lots of chances to deliver because they use lots of short iterations. Each one requires a short cycle of reflection to determine the best way to improve the process and deliver better results.

5. D LGd course manual p. 26 - Agile Development makes extensive use of WIP or Work In Progress. Although there is no rule or requirement to do so, most traditionally managed projects use a concept called Best Resourcing. In Best Resourcing whichever resource possesses the highest skill level is assigned to execute the task. WIP argues that we want to limit the amount of Work In Progress occurring at any single point. The principle can be thought of like a water main. The objective of the Water Department is to ensure the maximum amount of water is constantly available to the end users when they turn on their faucets. Contrary to what you might think, the best way to ensure high water pressure is to ensure the mains are less than 100% full. Remember, the mission is to get each drop to the customer as quickly as possible. If you ask your friendly neighborhood civil engineer, they will confirm that the water will travel the fastest when the pipe is less that 100% full. We do the same thing with our project tasks when using WIP.

6. A LGd course manual p. 28 & the Agile Manifesto at http://agilemanifesto.org. This is perhaps the most important and highlights a common complaint about many Project Managers. According to many involved in Agile Development, traditional Project Managers often lack technical skills dealing with the product or service of the project. This causes them to rely far too much on process and tools to fix problems when they arise. The key is to always remember that projects are about creating business value. The processes, tools and techniques we choose to use to create that value are simply means to an end. Without the end they have no value.

7. B LGd course manual p. 29 -The second value statement is that we value customer collaboration over contract negotiations. This value statement highlights the importance of the Development Team working directly and daily with the Business Stakeholders to deliver value to the business. Rarely does the Development Team understand the business need as well as the customer. Furthermore, the Customer is the final arbiter of whether or not the Team has delivered the right product or service. Therefore, to succeed the team must constantly talk to the stakeholders. In most cases, this means DAILY! Contracts are important, and many project require them. However, when the Team gets caught up in the legalize of what a contract says they often loose site of truly meeting the customer’s needs. At the end of the day, meet the customer’s needs.

8. C LGd course manual p. 29 - The third value statement is we value responding to change over following a plan. This statement often causes an immediately negative knee-jerk reaction from traditionally trained project managers. “Ah ha!” They exclaim. “Here it is. Agile Development leads to chaos because it doesn’t allow for planning or plans. We can’t live this way. We have to be able to tell people what’s coming next.” Unfortunately, this is a complete misunderstanding of what the statement says and how most Agile Methodologies work. Agile projects absolutely have plans and processes. However, these processes and plans are set up in such as way that they can quickly evolve and change as the team learns new information. It is this ability that significantly differentiates Agile Development from other methods for managing projects. Do not misread this value. It is not a license for a no planning free-for-all. Agile requires plans and processes. In many cases, activities are planned to the daily level, a much smaller unit than many traditional projects use.

9. D LGd course manual p. 29 - The final value statement is that the Agilist values working software over comprehensive documentation. This statement takes us back to the importance of delivering real value to the organization as opposed to simply producing a lot of paper to show that people worked hard. People working hard does nothing for the business. It is all about providing value.

10. D LGd course manual p. 29 - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This statement says it all. The highest priority or the most important thing is delivering value to the customer. In the early days of Agile the community was almost entirely software developers so naturally the product was software. Today, Agile has extended to many different industries so it often makes sense to replace “valuable software” with “valuable product, service or result.”

11. A LGd course manual p. 30 - Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. We made all the way to the second principle before things blew up. I hear project managers constantly complain about scope change. It is almost a daily occurrence. “We would have succeeded, if it wasn’t for the customer making all those last minute scope changes.” This statement ignores the fact that it is the customer’s right to demand scope changes so long as they accept the impacts. The problem is that too many team uses processes that make change difficult at best. This is a real key to Agile Development’s success. It make change easy, or at least easier, even late in the process.

12. B LGd course manual p. 30 & the Agile Manifesto at http://agilemanifesto.org. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Remember, Agile Development is focuses on being iterative. This means loops of repeated processes. The large number of loops affords the team the opportunity to learn from the past. As the team executes more and more loops, they are able alter the processes to better deliver. However, the key is that at the end of each iteration the team must deliver working product, service or result. With a timescale of only a few weeks to a few months the team is limited in how much functionality they can produce. This means the team must produce a small amount of functionality that has value to the customer, present it to them, and allow the customer to comment on that functionality. The team then adapts to the feedback, makes changes and moves to the next iteration. A common phase used to highlight this process is, “fail fast.”

13. D LGd course manual p. 31 & the Agile Manifesto at http://agilemanifesto.org. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Here is a news flash. E-mail is a terrible vehicle for most communication needs! Since its inception, Agile Development has understood this and pushed for better ways of sharing information. Broadcasting status reports via email or attempting to collect requirements electronically are examples of using e-mail poorly, but there are many more. Agile Development pushes teams to work closely and be co-located. If you are not familiar with the term CO-LOCATED it is important that you learn it. It means all the members of a group are physically sitting in the same location. This is why you can often quickly pick out and organization that is using Agile Development when the Development Team is all physically located in a single conference room or central area. Being co-located affords the team a number of advantages. First, team members can quickly turn and talk to compatriots when they have issues. Second, information quickly gets dispersed using OSMOTIC COMMUNICATION. This is where information is absorbed by team members simply by being in the room when it is shared. Finally, information moves between parties much more quickly through the use of INFORMATION RADIATORS when the team is in a single location. We will discuss this last term in a later section of the course.

14. B LGd course manual p. 31 -Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Agile Development promotes sustainable development. What the heck is that, and why should you care? First, it is more than just marketing, although there is a bit of that here. The real issue is something many resources have experienced over the years. If you have ever been part of a project that starts out slow where many team members have nothing to do until the end of the project when everything becomes a crisis and a mad dash to the finish line. During these late periods, team members are expected to work significant overtime and often their personal life struggles to deliver the project. This cycle repeats itself time and time again until the resources eventually burn out and leave the organization. Agilists argue that this pace is not only unsustainable, but also unnecessary. A better approach they contend, is to use Agile processes that increase the daily productivity throughout the entire lifecycle of the project thereby reducing or completely eliminating the mad dash crisis at the end. This pace is often referred to as the HEARTBEAT OF AGILITY and will be discussed in a few moments.

15. C

LGd course manual p. 33 - The notion of a cadence is absolutely critical to an Agile team. It is all about establishing a rhythm that is comfortable and sustainable by the Team. This rhythm differs from what many teams experience in the real world where they often experience slow periods of production throughout most of the project only to be forced into a mad dash at the end in hopes of delivering business results. Typically, the team fails to meet the deadline, is burnt out, and has left a frustrated customer. Agile processes attempt to solve this problem by increasing the daily productivity of the team. The goal is to have a higher rate of daily productivity and avoid the massive spikes experienced by the team. This notion does not argue there are not spikes, instead it is about creating much smaller, regular spikes that are within the realm of sustainability. It is called the heartbeat of agility.

16. D LGd course manual p. 33 - The Heartbeat of Agility represents a key aspect of developing an Agile Cadence or pace. The notion of a cadence is absolutely critical to an Agile team. It is all about establishing a rhythm that is comfortable and sustainable by the Team. This rhythm differs from what many teams experience in the real world where they often experience slow periods of production throughout most of the project only to be forced into a mad dash at the end in hopes of delivering business results. Typically, the team fails to meet the deadline, is burnt out, and has left a frustrated customer. Agile processes attempt to solve this problem by increasing the daily productivity of the team. The goal is to have a higher rate of daily productivity and avoid the massive spikes experienced by the team. This notion does not argue there are not spikes, instead it is about creating much smaller, regular spikes that are within the realm of sustainability.

17. B LGd course manual p. 33 - The Heartbeat of Agility represents a key aspect of developing an Agile Cadence or pace. The notion of a cadence is absolutely critical to an Agile team. It is all about establishing a rhythm that is comfortable and sustainable by the Team. This rhythm differs from what many teams experience in the real world where they often experience slow periods of production throughout most of the project only to be forced into a mad dash at the end in hopes of delivering business results. Typically, the team fails to meet the deadline, is burnt out, and has left a frustrated customer. Agile processes attempt to solve this problem by increasing the daily productivity of the team.

The goal is to have a higher rate of daily productivity and avoid the massive spikes experienced by the team. This notion does not argue there are not spikes, instead it is about creating much smaller, regular spikes that are within the realm of sustainability.

18. B LGd course manual p. 34 - Chaos Chronicles, only about 36% of all features are regularly used. Another 19% of a software project’s features are rarely used, and a full 45% of a software applications features are never used. So why does this matter? It matters because far to often project teams force stakeholders to wait for the important, must used features because they are trying to produce features that will never be used.

19. A LGd course manual p. 34 - Most Agile methodologies require the customer or key stakeholders to prioritize the requirements from most important to least. The Team then makes every effort to deliver the features in the defined order. At the end of the project when the Team is at the deadline there will still likely be a number of features or requirements that are incomplete. The difference is that these are the less important ones. This puts the customer in a position of great power. Now the customer can decide whether or not they want the team to continue the project to deliver these minor features. In a linear process, the customer is stuck. They have to continue the project because if they don’t they get nothing of value. In Agile they have the most important items and get to decide how much the lessor items are really worth to them. Secondly, Agile Development gives the customer these most important features earlier in the process. This means they are able to begin using these mission critical features as soon as they are done without waiting for lessor features. Finally, Agile Development forces business stakeholders to make hard decisions like spend more money and time or not. It forces a hard discussion around those never used features in a highly visible way. As a result it becomes far more difficult to sneak a feature or requirement into the process at the end

20. C LGd course manual p. 34 - Be carefule in reading the choices. Although Agile Development does dramatically increase the likelihood the customer will get something of value by the deadline, nothing can ensure this fact.

21. D LGd course manual p. 35 - Scrum was first defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional approach” (read a linear approach such as Waterfall) in January of 1986 by Hitotaka Takeuchi and Ikujiro Nonaka in the New Product Development Game published in the Harvard Business Review. This article described a new approach to commercial product development that they argued would increase both speed and flexibility based upon their examination of numerous case studies in manufacturing, photocopier and the printer industries. They called this the holistic or rugby approach. The idea was to create a single, small cross functional team that possessed all, or at least most, of the skills required to complete the project and this team would work on the project across multiple overlapping phases constantly passing work back and forth until complete.

22. A LGd course manual p.35 - Scrum is based on two aspects of industrial process theory self-organization and emergence. Self-organization is the idea that the Development Team will decide what work needs to be accomplished and who will do the work to deliver the desired business results. Emergence is the idea that information, requirements and facts will emerge as the project progresses. The key is that the team uses processes, tools, and techniques capable of harnessing this new information for the betterment of the organization.

23. B LGd course manual p. 35 - Emergence is the idea that information, requirements and facts will emerge as the project progresses. The key is that the team uses processes, tools, and techniques capable of harnessing new information as it becomes available for the betterment of the project.

24. C LGd course manual p. 35 - Self-organization is the idea that the Development Team will decide what work needs to be accomplished and who will do the work to deliver the desired business results.

25. D LGd course manual p. 35 - The creators of Scrum argue that traditional linear approaches for projects such as Waterfall are based on the concepts of defined processes. Defined processes are repeatable processes such as in manufacturing.

26. B LGd course manual p. 36 - Commoditization is defined as the process in which goods that have economic value and are indistinguishable in terms of attributes (uniqueness or brand) end up becoming simple commodities in the eyes of the market or consumers. This means or widgets become easy to obtains for the consumer because many different organizations have made them uniform, plentiful and affordable.

27. A LGd course manual p. 36 - A defined process is perfectly tailored to operational management because we want people to follow the exact same steps day after day. Projects or new initiatives are a very different animal. They are all about creating something we haven’t had before. They are about creating something new and in some way different. By this definition, the processes we used to execute the last project won’t necessarily work with next. Success relies on flexibility, and flexibility requires a different way of doing things. Projects have the greatest chance of success when empirical processes are used.

28. D LGd course manual p. 36 - Empirical processes focus on creating a situation with the highest using three primary drivers visibility, inspection and adaptation.

29. C LGd course manual p. 36 - If one or more of the processes are determined out of control the processes change. Once you can see the drivers in a process and have taken the time to examine those variables to ensure you know which variables are in control and which ones are not, the only thing left is to fix those processes that are not performing as expected. This step is called adaptation.

30. A LGd course manual p. 37 - The PO is the individual responsible for representing the interests of all stakeholders, obtaining funding, defining the initial requirements, defining the return on investment or ROI, and the project objectives. They are the primary owner of the Product Backload, a document where the User Stories, features or requirements of the project are listed in rank order from most important to least important from the perspective of the business.

31. B The Scrum Guide p. 12 - "The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering."

32. D The Scrum Guide p. 12 - "The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value."

33. C The Scrum Guide p. 13 - The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

34. B LGd course manual p. 37 - The Development Team is self-managing, self-organizing, and cross functional. The team does not have a project manager or functional leader who directs the team’s efforts. The Development Team is also small. According to the rules of Scrum, the team size is six plus or minus three. This puts the optimal team size somewhere between three and nine individuals.

35. A LGd course manual p. 37 - The Development Team is self-managing, self-organizing, and cross functional. The team does not have a project manager or functional leader who directs the team’s efforts. The Development Team is also small. According to the rules of Scrum, the team size is six plus or minus three. This puts the optimal team size somewhere between three and nine individuals.

36. D LGd course manual p. 38 - The Scrum Master is responsible for the Scrum process, teaching Scrum to everyone, implementing Scrum so it fits with culture, and ensuring that everyone follows Scrum’s rules & practices. The closest approximation to in a linear project is the Project Manager, but there are some key differences, at least from the perspective of the Agilist. Most Agilists believe that traditional project managers are only part of hierarchical organizations with the project manager at the top. All the resources report to the PM. Additionally, this person serves as an administrator directing the team, but having no technical skills or knowledge of the project. This is a huge over simplification of the role, but makes for a nice comparison. A Scrum Master serves as a facilitator. Remember, a Scrum Development Team is self-managing. The expectation is that the Scrum Master role is to only help the team, to ask probative questions, to ensure the team knows the Scrum process and follows it. Development Team members report to each other and not the Scrum Master so the Scrum Master has no formal authority to make anyone do anything.

37. B LGd course manual p. 38 - Often Agilists use an acronym to describe the expected behavior of the Development Team. It is CFORCE. The C stands for Committed. An Agile Development Team must be committed to the Team’s goals and to the other members of the Team. F stands for focused. This criteria goes back to an earlier point. A Development Team must be focused on one and only one project. O stands for open. Each member of the team must be open to receive and provide honest criticism intended to improve the project and the team. Team members must always assume positive intend of their compatriots. R stands for respected and respectful. This requirement is also tied to how team members treat each other. It is expected that each team member is a respected part of the organization and that they respect all the other members of the team. Team members must give respect in order to receive it. The C stands for courageous. The team must take risks, find innovative solutions, and focus on finding the best solutions to meet the needs of the business. Finally, we have the E, which stands for extreme. Scrum calls on the Development Team to be zealous in the pursuit of the mission.

38. C LGd course manual p. 38 - Often Agilists use an acronym to describe the expected behavior of the Development Team. It is CFORCE. The C stands for Committed. An Agile Development Team must be committed to the Team’s goals and to the other members of the Team. F stands for focused. This criteria

goes back to an earlier point. A Development Team must be focused on one and only one project. O stands for open. Each member of the team must be open to receive and provide honest criticism intended to improve the project and the team. Team members must always assume positive intend of their compatriots. R stands for respected and respectful. This requirement is also tied to how team members treat each other. It is expected that each team member is a respected part of the organization and that they respect all the other members of the team. Team members must give respect in order to receive it. The C stands for courageous. The team must take risks, find innovative solutions, and focus on finding the best solutions to meet the needs of the business. Finally, we have the E, which stands for extreme. Scrum calls on the Development Team to be zealous in the pursuit of the mission.

39. D LGd course manual p. 38 - Most people are familiar with a project vision by another name, the Project Charter. Many Agilists would contend that the two documents are not the same thing, but this has more to do with many project managers failing to create proper charters than the comparison. The Vision sets the direction of the project and guides the Scrum Team. In 2004, Schwaber described the Vision this way, “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.: (Schwaber 2004, p.68)

40. A LGd course manual p. 39 - A well formed Vision is a single page document that answers a number of questions. These questions cover five major areas: The Business Need, The Project Justification, The Success Criteria, The Project's Prioritization, and any Constraints or Assumptions. A Business Case offers much of the same information as it explains why the business needs the product or service of the project.

41. C LGd course manual p. 40 - A common way to validate your Vision is to answer the elevator test. Can you explain the product, service or result of the project in the time it takes to ride up in an elevator? (Moore 2006 p. 152).

42. D LGd course manual p. 39-40 - The two documents necessary required to implement Scrum. The first of these documents in called the Product or Project

Vision. The Vision sets the direction of the project and guides the Scrum Team. In 2004, Schwaber described the Vision this way, “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.: (Schwaber 2004, p.68). The second document in the list of four is a Ranked Product Backlog. More often than not the literature talks about just the Product Backlog. A Product Backlog is a listing of the User Stories, features or requirements.

43. A LGd course manual p. 40 - A story is a self-contained unit of work agreed upon by the developers and the stakeholders. Stories are the heart of Scrum, and the building blocks of the sprint. Additionally, each story must provide functionality that has real value to the business. A User Story is different from a feature however as a feature represents a distinct element of functionality that provides capability to the business while a User Story is a small aspect of a feature that is used to get feedback from stakeholders and find out if you are doing anything wrong.

44. B LGd course manual p. 40 - Themes may be thought of as groups of related stories. Often the stories all contribute to a common goal or are related in some obvious way, such as focusing on a single customer. Sometimes stories within a theme may be dependent on each other, and then do not necessarily encapsulate a specific work flow or be delivered together.

45. C LGd course manual p. 40 - Epics resemble themes in the sense that they are made up of multiple stories. Sometimes they also resemble stories in the sense that may appear as a big story. Unlike themes, epics often comprise a complete workflow for a user and they typically cut across all or some of the three business dimensions (time, scope and organizations). Another important difference is while the stories that comprise an epic may be completed independently, their business value isn’t realized until the entire epic is complete. This means that it rarely makes sense to deliver an epic until all of the underlying stories are complete.

46. A LGd course manual p. 41 - Epics are most often seen when teams are implementing SAFe as they are often used to enhance business value of the FULL solution set or bring a range of technologies together. They are often key economic drivers for the portfolio,

47. B A short iteration of fixed time where features are produced that have tangible value to the customer. The original Rules of Scrum stated that each Sprint was 30 days in length. However, over the years Scrum has adopted the practices from other Agile methodologies and the common practice is to see sprints of between two and six weeks in length. The key is that each sprint must be the exact same fixed length, and each MUST produce fully tested functionality that has real value to the customer.

48. A LGd course manual p. 41 - A release is a group of related sprints. Releases become necessary for a variety of reasons. The Rules of Scrum require every sprint to provide fully tested, production ready features. However, there are many situations where it is either impractical or ill advised to put the features completed from a single sprint into production. Imagine an organization that has set release windows where new code can be put into the production system. In these situations, the Development Team simply places the results from sprints “on the shelf” until all the releases that are part of the release are complete and then the entire group of features is place into production together.

49. B LGd course manual p. 42 - Every project begins the same way. Just imagine someone in the organization has a problem so they complete a single page document that starts the ball rolling. This document is a Vision. Some type of governance decides the idea has merit so they assign a team to do some initial work. The Development Team conducts an initial kickoff meeting with the Product Owner and key stakeholders to develop an initial Ranked Product Backlog. Once the Development Team has the initial Backlog they enter the Release Planning Meeting. Although the Kickoff Meeting is a common solution for project initiation the Release Planning Meeting is the first official meeting listed in the Scrum Guide.

50. C LGd course manual p. 42 - The Sprint Planning Meeting represents the first step of the process that gets repeated with each sprint. The purpose of the Sprint Planning Meeting is to plan the work of the current Sprint, and it officially kicks off the sprint. The meeting is broken into two parts.

51. D LGd course manual p. 42 - The Release Planning Meeting serves several purposes. The Development Team first uses the meeting to examine the backlog items to determine how they need to be grouped together to produce releases. Additionally, the team needs to determine how long each sprint needs to be. Remember, each User Story must fit into a single sprint. So the Team is tasked with getting a sprint length that is as short as possible, but long enough to deliver fully tested, production ready results that have real value to the business. To do this, the Team must somehow determine estimates for each PBI. There are a number of techniques commonly used for this purpose that are discussed later in this book. The estimates are used by the Development Team to ensure each sprint is approximately the same size. Once the Development Team has determined how long the sprints will be and how the sprints will be grouped into releases, then team is done with the Release Planning Meeting. Approximately once a quarter the team must revisit the Release Planning Meeting.

52. A LGd course manual p. 42 - The process of gaining more detail about a feature or backlog item is called Backlog Grooming. This is process where the Product Backlog Items are defined in enough detail that the Development Team can build the feature.

53. C LGd course manual p. 42 - No User Story could be larger than a single sprint.

54. B LGd course manual p. 44 - Each day begins the same way with a meeting called the Daily Scrum. This is a ten to fifteen minute meeting that provides the Team with basic project status and communication. Each day the Development Team stands around the Scrum or Team Board and answers three questions: What did they accomplish yesterday? What are they going to accomplish today? What impediments do they have?

55. D LGd course manual p. 44 - Each day begins the same way with a meeting called the Daily Scrum. This is a ten to fifteen minute meeting that provides the Team with basic project status and communication. Each day the Development Team stands around the Scrum or Team Board and answers three questions. Each member of the Development Team reports their results to the other members of the Development Team and NOT to the Scrum Master or Product Owner who are also present. The Scrum Master is tasked to act as a facilitator and the PO is only an observer.

56. B LGd course manual p. 44 - While the Development Team works to produce the days results, the Product Owner works on grooming yet undefined User Stories for future sprints while also working with the Scrum Master to remove impediments.

57. C LGd course manual p. 44 - No one from the business may add a feature to a sprint once work has commenced, but may add, delete or change items on the Product Backlog at their discretion. The Development Team occasionally has to take User Stories out of the current sprint as new information is learned and may at their discretion pull up a new item if the situation warrants.

58. C LGd course manual p. 44 - No one from the business may add a feature to a sprint once work has commenced, but may add, delete or change items on the Product Backlog at their discretion. The Development Team occasionally has to take User Stories out of the current sprint as new information is learned and may at their discretion pull up a new item if the situation warrants.

59. A LGd course manual p. 44 - On the last day of each sprint two meetings are conducted. First, the Team conducts a Sprint Review. This one hour to 90 minute meeting allows the Product Owner to present the results of the sprint to the customers. This is all about showing working product to the people who will really use it. The Development Team wants the product owner to take this responsibility because it both provides a connection from them to the users and helps to ensure their engagement throughout the sprint. The Team is allowed a few hours to prepare for this meeting. Once the Sprint Review is complete, the

Development Team conducts a Sprint Retrospective. If the Sprint Review is all about the product of the project, the Sprint Retrospective is all about the process.

60. D LGd course manual p. 44 - Once the Sprint Review is complete, the Development Team conducts a Sprint Retrospective. If the Sprint Review is all about the product of the project, the Sprint Retrospective is all about the process. The Product Owner is not allowed to attend the Retrospective and the Scrum Master is only present as a facilitator. This meeting provides the Development Team the opportunity to review the process and find the best way to improve the process. The team uses a wide range of games and tools to answer the question, “If tomorrow we were 1,000% more efficient what we do to get there?” It is singularly focused on the process the Development Team is using to achieve their results.

61. C LGd course manual p. 45 - Another practice sometimes used by Scrum teams is Iteration 0. This is NOT part of Scrum found in the Scrum Guide. Remember the basic rule we established for Scrum that said every single sprint would be the same length of time and must produce functionality that has real value to the business? Iteration 0 violates both those rules. The goal of Iteration 0 is to produce two items that do not initially have value to the business. These are the core architecture and feature list. It is not unusual for this work to take significantly longer than a single sprint, and as such it violates the Rules of Scrum requiring and out. If a team has decided to use Iteration 0 because they believe the project needs a more formal architectural plan and/or work on its feature list it is important that the team also provides an iteration or milestone plan to ensure the team quickly moves into more standard Scrum sprints.

62. B LGd course manual p. 46-47 - The five areas of focus within Extreme Programming include: Goals, Activities, Values, Principles and Practices.

63. D LGd course manual p. 46 - Extreme Programming defines four core activities necessary to meet its stated goal. These include: Listening – Programmers must listen to customers and understand the business processes. Designing – Software must be designed as components without complexity or dependencies between components.

Coding – Is the meat of the methodology. It is the most important part according to XP advocates. Testing – The team must test a functionality.

64. C LGd course manual p. 46 - Values represent what the team hold highest. When discussing Extreme Programming, here are its core values: Simplicity, Communication, Feedback, Courage, and Respect.

65. A LGd course manual p. 46 - Values represent what the team hold highest. When discussing Extreme Programming, here are its core values: Simplicity, Communication, Feedback, Courage, and Respect.

66. B LGd course manual p. 47 - The first grouping of practices is called Fine Scale Feedback. It is the notion of providing rapid feedback to each individual developer in a fashion they can actually act upon it in a timely manner. The four practices tied to Fine-Scale Feedback include: Paired Programming, The Planning Game, Test-Driven Development, Whole Team.

67. B LGd course manual p. 47 - The Planning Game represents the main planning process used in Extreme Programming. Like the Sprint Planning Meeting in Scrum, The Planning Game is a meeting that occurs once per iteration. In most XP environments, this means once a week. There are two parts to the Game, Release Planning and Iteration Planning. Release planning is focused on determining which requirements are included in which near-term release and when specifically they should be delivered. Both the customer and developer are part of this process. It includes three phases.

68. C LGd course manual p. 48 - The Planning Game represents the main planning process used in Extreme Programming. Like the Sprint Planning Meeting in Scrum, The Planning Game is a meeting that occurs once per iteration. In most XP environments, this means once a week. There are two parts to the Game, Release Planning and Iteration Planning. Release planning is focused on determining which requirements are included in which near-term release and when specifically they should be delivered. Both the customer and developer are part of this process. It includes three phases. In the Commitment Phase, the

business and developers commit to the functionality to include and next release date.

69. D LGd course manual p. 49 - Shared Understanding represents the set of practices that ensure all the members of the team have the same information about the project and its product. It requires more than just access to information though as you will see from its four practices: Coding Standards, Collective Code Ownership, Simple Design, and System Metaphor.

70. A LGd course manual p. 49 - “Simplest” is best approach to software design. Often, software fails because of the layers of complexity that constantly get added until the application collapses under its own weight. XP attempts to peel back the layers of the onion to achieve a design that is more robust and long lasting. A common XP expression used along with Simple Design is the acronym YAGNI which stands for “You Aren’t Gonna Need It.” This expression means that something is not needed, and it will complicate things. Therefore, the best solution is to throw it out.

71. A LGd course manual p. 49 - The last practice found in Extreme Programming is part of a group called Programmer Welfare. It is the practice of a Sustainable Pace where programmers are not required or even allowed to more than 40 hours per week on average and no two weeks in a row have overtime. The idea is based on the concept that programming is highly technical, detailed work and that fresh programmers produce better code. A key enabler of this concept is frequent code merges of code that are always executable. This code must constantly be tested to ensure it is of a high quality.

72. C LGd course manual p. 50 - Like most methodologies, Extreme Programming has a five-step process. These steps include: Envision, speculate, Explore, Adapt, and Close.

73. A LGd course manual p. 51 - FDD is a model-driven, short-iteration methodology that has five basic processes or activities. In FDD the first two activities are used to generate an overall model shape. Then, the final three processes or activities are iterated for each feature. The five processes or activities include: Develop

the Overall Model, Build Feature List, Plan By Feature, Design By Feature and Build By Feature.

74. C LGd course manual p. 52 - Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project it is important to mark the progress made on each feature. Feature-Driven Development therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. At the point that coding begins a feature is already 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%). The code is then worth 45%. Code Inspection provides another 10%, and finally Promoting the Feature to Build adds 1%.

75. D The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. At the point that coding begins a feature is already 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%). The code is then worth 45%. Code Inspection provides another 10%, and finally Promoting the Feature to Build adds 1%.

76. C LGd course manual p. 53 - Domain models reflect our understanding of real world entities and their relationships and responsibilities. Key to remember is that effective Domain Modeling may only occur in the context of the system-level requirements that are often captured as Use Cases or User Stories. Domain Modeling is used to support the analysis of Epics, Backlog refinement at the program and team levels, design workshops at different levels, and the refinement of the Product Vision and Roadmap.

77. B LGd course manual p. 53 - FDD has six primary roles, five support roles and three additional roles. FDD, like all Agile Methodologies argues people are the most important aspect when you consider the key drivers of people, process, and technology. The primary roles include: Project Manager, Chief Architect, Development Manager, Chief Programmer(s), Class Owners, Domain Experts.

The Class Owners are the developers who work as members of those three to six member teams led by the Chief Programmers who design, code, test and document the features required on the project. They are called Class Owners because that is exactly who they are. FDD ensures every single class (defined as a breakout of code) is owned by one and only one person. If anything is wrong with it they are responsible.

78. A LGd course manual p. 53 - FDD has six primary roles, five support roles and three additional roles. FDD, like all Agile Methodologies argues people are the most important aspect when you consider the key drivers of people, process, and technology. The primary roles include: Project Manager, Chief Architect, Development Manager, Chief Programmer(s), Class Owners, Domain Experts. The Domain Experts are users, sponsors, and business analysts who have the specific knowledge the Class Owners rely upon to deliver the correct system.

79. D LGd course manual p. 54 - In addition to the primary roles, Feature Driven Development relies on five supporting roles to succeed. These roles are not considered primary to the team delivering the required features, but they are important roles to the project’s success. These roles include: Release Manager, Language Guru, Build Engineer, Toolsmith, and the System Administrator.

80. D LGd course manual p. 55 - The Domain Object Modeling is the process of building Class Diagrams depicting the significant types of objects within a problem domain and the relationships between them. The first published description of FDD appear as part of a concept called UML in Color. This is the same as plain UML, but the classes are color-encoded. This is done to allow for quick understanding of the dynamics of the problem domain. Each of the class categories are represented by a different color that has specific meaning: Yellow – A role being played by a person or an organization; Blue – A catalogue-like description of an object, but it is not considered the object itself; Green – A party (individual), place, or thing. The green class usually has some identifying attributes, such as a serial number or person’s name associated with it; Pink – A moment in time or an interval of time usually associated with some business process.

81. C LGd course manual p. 35 - Scrum is based on two aspects of industrial process theory self-organization and emergence. Self-organization is the idea that the Development Team will decide what work needs to be accomplished and who will do the work to deliver the desired business results. Emergence is the idea that information, requirements and facts will emerge as the project progresses. The key is that the team uses processes, tools, and techniques capable of harnessing this new information for the betterment of the organization.

82. D LGd course manual p. 35 - The creators of Scrum argue that traditional linear approaches for projects such as Waterfall are based on the concepts of defined processes. Defined processes are repeatable processes such as in manufacturing. Imagine working at the Acme Widget factory. In order to produce widgets of a consistent level of quality it is imperative that our machines stamp and assemble each widget the same way. The more consistently we can stamp the widgets the less variance we see in the finished product. As we move forward we also try to increase the rate of production.

83. C LGd course manual p. 37 - The PO is the individual responsible for representing the interests of all stakeholders, obtaining funding, defining the initial requirements, defining the return on investment or ROI, and the project objectives. They are the primary owner of the Product Backload, a document where the User Stories, features or requirements of the project are listed in rank order from most important to least important from the perspective of the business.

84. A LGd course manual p.37 - Throughout much of the literature and in this book a fourth role is added to the list that is not officially part of Scrum, but often unwittingly included. It is The Team. The Team is different from the Development Team because it includes all three Scrum roles. It is defined as everyone involved in delivering the project. It is the Product Owner, the Scrum Master and the Development Team together. As we go through the rest of this discussion it is important that you can differentiate the Team from the Development Team.

85. A LGd course manual p. 44 - On the last day of each sprint two meetings are conducted. First, the Team conducts a Sprint Review. This one hour to 90 minute meeting allows the Product Owner to present the results of the sprint to the customers. This is all about showing working product to the people who will really use it. The Development Team wants the product owner to take this responsibility because it both provides a connection from them to the users and helps to ensure their engagement throughout the sprint. The Team is allowed a few hours to prepare for this meeting.

86. D LGd course manual p. 38 - The Scrum Master is responsible for the Scrum process, teaching Scrum to everyone, implementing Scrum so it fits with culture, and ensuring that everyone follows Scrum’s rules & practices. The closest approximation to in a linear project is the Project Manager, but there are some key differences, at least from the perspective of the Agilist.

87. B LGd course manual p. 38 - Everyone involved in the project fits into one of these three roles. For many, this is a bit disconcerting. What do you do if you are a business analyst or quality assurance person how do you fit in when there are only three roles and you aren’t one of them? In most situations, these additional roles are included as part of the Development Team. They represent other resources needed to complete the work of the project. However, occasionally they also might fit in to the organization as resources used by the Product Owner to define the requirements of the project.

88. D LGd course manual p. 44 - The focus is supposed to be on the second and third questions as the first is historical and there is no chance to impact it. Each member of the Development Team reports their results to the other members of the Development Team and NOT to the Scrum Master or Product Owner who are also present. The Scrum Master is tasked to act as a facilitator and the PO is only an observer.

89. D LGd course manual p. 47

90. D LGd course manual p. 47 - Although all three Scrum roles are critical to project success, they are not all created equal. Significantly more is offered and expected from the Development Team. Often Agilists use an acronym to describe the expected behavior of the Development Team. It is CFORCE. The C stands for Committed. An Agile Development Team must be committed to the Team’s goals and to the other members of the Team. F stands for focused. This criteria goes back to an earlier point. A Development Team must be focused on one and only one project. O stands for open. Each member of the team must be open to receive and provide honest criticism intended to improve the project and the team. Team members must always assume positive intend of their compatriots. R stands for respected and respectful. This requirement is also tied to how team members treat each other. It is expected that each team member is a respected part of the organization and that they respect all the other members of the team. Team members must give respect in order to receive it. The C stands for courageous. The team must take risks, find innovative solutions, and focus on finding the best solutions to meet the needs of the business. Finally, we have the E, which stands for extreme. Scrum calls on the Development Team to be zealous in the pursuit of the mission.

91. A LGd course manual p. 46

92. C LGd course manual p. 38 - A Scrum Master serves as a facilitator. Remember, a Scrum Development Team is self-managing. The expectation is that the Scrum Master role is to only help the team, to ask probative questions, to ensure the team knows the Scrum process and follows it. Development Team members report to each other and not the Scrum Master so the Scrum Master has no formal authority to make anyone do anything.

93. A LGd course manual p.42 - The next step in the process is the Sprint Planning Meeting represents the first step of the process that gets repeated with each sprint. The purpose of the Sprint Planning Meeting is to plan the work of the current Sprint, and it officially kicks off the sprint. The meeting is broken into two parts. When necessary information is NOT present specific business stakeholders are asked to attend.

94. B LGd course manual p. 40 - A Product Backlog is a listing of the User Stories, features or requirements. These items are often referred to as Product Backlog Items or PBIs. The key is the “ranked” portion. It is a key aspect of using the Product Backlog. Ranking the backlog requires the business to prioritize the items in the Backlog from most important to the business to the least important. Sometimes the Backlog is further defined into groups of User Stories that belong together. The Development Team uses the Backlog to define which features to deliver when. Each of the items on the Backlog items relatively independent of each other. Additionally, the items on the Backlog may be reprioritized at any time.

95. A LGd course manual p. 50 - Scrum teams work in timeboxes called Sprints that are two to six weeks in length. Extreme Programming uses timeboxes called Iterations that are one to two weeks in length. A two week Sprint is the most common in Scrum and a one week Iteration is most common in XP.

96. C LGd course manual p. 46 - Extreme Programming defines four core activities necessary to meet its stated goal. These include: Listening – Programmers must listen to customers and understand the business processes; Designing – Software must be designed as components without complexity or dependencies between components; Coding – Is the meat of the methodology. It is the most important part according to XP advocates; and Testing – The team must test a functionality.

97. B LGd course manual p. 46 - Values represent what the team hold highest. When discussing Extreme Programming, here are its core values: Simplicity, Communication, Feedback, Courage, and Respect.

98. D LGd course manual p. 46 - Courage – The team has to be willing to put its work out there for others to see. It must also use pair programming and shared code. These two principles will be discussed later.

99. B LGd course manual p. 47 - Extreme Programming’s 12 practices are grouped into four practice areas. These practice areas provide the toolset used by teams

implementing XP and the groupings include: Fine Scale Feedback, Continuous Process, Shared Understanding and Programmer Welfare. Most of the rest of this section focuses on these 12 practices. Assuming simplicity is one of two core principles that drive XP and NOT an area of practice.

100. C LGd course manual p. 47 - The Planning Game represents the main planning process used in Extreme Programming. Like the Sprint Planning Meeting in Scrum, The Planning Game is a meeting that occurs once per iteration. In most XP environments, this means once a week. There are two parts to the Game, Release Planning and Iteration Planning. Release planning is focused on determining which requirements are included in which near-term release and when specifically they should be delivered. Both the customer and developer are part of this process.

101. B LGd course manual p. 47 - The Planning Game represents the main planning process used in Extreme Programming. Like the Sprint Planning Meeting in Scrum, The Planning Game is a meeting that occurs once per iteration. In most XP environments, this means once a week. There are two parts to the Game, Release Planning and Iteration Planning. Release planning is focused on determining which requirements are included in which near-term release and when specifically they should be delivered. Both the customer and developer are part of this process.

102. B LGd course manual p. 48 - In TDD, the tests are written before any code is written and those tests are automated. Typically, the TDD process contains five steps: The developer who will eventually write the code writes the unit tests. This is unlike most testing doctrines where someone other than the developer writes the tests often at the same time or after the developer begins writing the code; The developer runs the test to ensure the test fails as not code has been written so a passed test without any code would mean a bad test; The developer writes the minimum amount of code possible that allows the test to be passed; The developer reruns the test to ensure passage; And the developer then refactors the code removing any codes smells from the code. We will talk extensively about what this means later in the course.

103. C LGd course manual p. 48 - The final practice found in Fine-Scale Feedback is the Whole Team. This is a basic requirement seen in many Agile methodologies. The premise is that although the customer does not always pay for the project, they are always the people who use the product, service or result of the project. As a result, the customer must always be on hand to answer questions from the developers.

104. D LGd course manual p. 48 - Test Driven Development is a practice found in the Fine Scaled Feedback area of Extreme Programming.

105. A LGd course manual p. 49 - The four practices found in Shared Understanding include: Coding standards; Collective code ownership; Simple design; And system metaphor.

106. A LGd course manual p. 51 - Develop Overall Model — The team holds a kickoff and high-level walkthrough the scope of the system. This includes all of its context. Next, detailed Domain Models are created for each modeling area by small teams and then presented for peer review. One of the proposed models, or a combination of them, is selected to become the model for each domain area. These Domain Area Models are progressively merged into a single overall model.

107. C LGd course manual p. 52 - Domain Object Modeling – The team explores and explains the domain of the problem. That probably doesn’t mean very much to you at this point so let’s spend a few minutes discussing Domain Modeling. Domain Modeling is a way to describe and model real world things and the relationships between them. This is collectively called the “Problem Domain Space.” Domain Modeling is used by lots of Agile techniques including FDD and SAFe. It is considered one of the key models used in software engineering and there is a saying, “if you only model one thing in Agile, model the domain.”

108. D LGd course manual p. 51 - Build Feature List — Knowledge and information from the initial modeling effort is used to identify the list of features by functionally decomposing the domain into subject areas. Each subject area contains business activities with steps that form the basis for a categorized feature list.

Think of these “features” as small pieces of client-valued functionality expressed in the form “<action><result><object>”. This is a IT specific way of writing features that might have little meaning if you do not come from a software development background. Don’t worry, you do not need to be a software developer to pass the PMI-ACP Exam. These features need to be small enough that they can be completed in not more than two weeks. Once the team has completed this activity they have their overall model and are ready to proceed into the activities used to actually produce the features of the project.

109. C LGd course manual p. 53 - Configuration Management – Labeling code, tracking changes, & managing source code.

110. A LGd course manual p. 54 - The Class Owners are the developers who work as members of those three to six member teams led by the Chief Programmers who design, code, test and document the features required on the project. They are called Class Owners because that is exactly who they are. FDD ensures every single class (defined as a breakout of code) is owned by one and only one person. If anything is wrong with it they are responsible. A Class Owner often cannot do this work alone so must be the leader of a team called a Feature Team.

111. A LGd course manual p. 32 - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Introspection is a key aspect of any Agile team. Unlike linear approaches to project execution where the Team typically does a single release, Agile Development cycles repeatedly. This gives the customer lots and lots of opportunities to comment on the work product. It also provides the Team many opportunities to learn. With every loop, the Team has a chance to execute the basic process. At the end of that process most Agile Methodologies provide some kind of reflection process where the Team is tasked with examining their performance in the cycle and determining the best way to improve before moving on to the next iteration. This reflection period is absolutely critical. It recognizes that the Team is never perfect, and there are always improvements to be made. It move the concept of continuous improvement from some abstract theory we say is important into something we at regular intervals focus on and actually do something about.

112. B LGd course manual p. 56 - Scrum does not require a specific model whereas FDD requires a Domain Model be created first before any software is produced. Secondly, Scrum works from a ranked Product Backlog that is owned by the Product Owner. The Development Team works from the Backlog informed by the PO. FDD works from its Feature List strictly based on the priority list. Next, Scrum uses a Release Plan to provide its initial view of when the Product Backlog Items will be delivered. Feature-Driven Development plans strictly by feature order. Finally, the entire process of Scrum is iterative. In FDD only the last three steps are iterative. The first two steps only occur once.

113. A LGd course manual p. 56 - Scrum does not require a specific model whereas FDD requires a Domain Model be created first before any software is produced. Secondly, Scrum works from a ranked Product Backlog that is owned by the Product Owner. The Development Team works from the Backlog informed by the PO. FDD works from its Feature List strictly based on the priority list. Next, Scrum uses a Release Plan to provide its initial view of when the Product Backlog Items will be delivered. Feature-Driven Development plans strictly by feature order. Finally, the entire process of Scrum is iterative. In FDD only the last three steps are iterative. The first two steps only occur once.

Agile Certified Practitioner (ACP) Exam Prep Course …...Agile Principles & Mindset Domain Tasks 1....

Documents

Transcript of Agile Certified Practitioner (ACP) Exam Prep Course …...Agile Principles & Mindset Domain Tasks 1....