Date post: | 14-Jul-2015 |
Category: |
Software |
Upload: | wjperez0629 |
View: | 889 times |
Download: | 12 times |
PMI-Agile Certified PractitionerPMI-ACP Prep Workshop
LeadingAgile Atlanta2180 Satellite Blvd Suite 400
Duluth, Georgia 30097(678) 935 -4664
Rick Austin– Enterprise Agile Coach
PMI-ACP: Support Team LeadPMI Agile Community of Practice: Volunteer
About me…experience applying agile to small teamslarge distributed teamschange management
Agile Project ManagementVolunteer and Leader
Expert in Financial Services Industry
Georgia State Grad
Agile TransitionDirector, Program
Manager
Applications DevelopmentManager
SolutionsDirector of Development
Information TechnologyDirector
3
Let’s introduce ourselves, find out why we’re all at this session
• What is your name?
• Why are you here?
• What is your level of expertise with Agile?
Introductions
4
Write your questions on Sticky notes as they occur to you & affix them to our Learning Backlog.
Learning Backlog
Backlog
5
Participation is a Key to Success
• We will move quickly, but spend appropriate time on material you find especially useful
• I should be asking a lot of questions
• The key to success for our session is participationo Share your ideas and learning
o Tell me when to move on
o Tell me when to go into more detail
Approach
6
Course AgendaRiskBurndownsQualitative vs. QuantitativeImplicit vs. Explicit
ScrumBasic UnderstandingScrum Process OverviewPlanningRequirementsEstimation
Roles & ResponsibilitiesProduct OwnerScrumMasterThe Team
The Scrum ProcessInitial PlanningProduct BacklogRelease PlanningSprint PlanningSprint BacklogSprintSprint ReviewDaily ScrumSprint Retrospective
Simulations and ExercisesCommand-and-Control ExerciseSelf-Organization ExerciseBatch and Flow ExerciseTeam Collaboration ExerciseTheory of Constraints Exercise
User Story WritingPlanning PokerAffinity EstimatingIteration 0/Release PlanningSprint PlanningDaily StandupReview and DemoRetrospective
Exam Content OverviewWhat is the PMI-ACPDomains and TasksContent DistributionTools & TechniquesKnowledge & SkillsCommunity Guide of the PMI-ACP
Agile HistoryLeaders over timeWaterfallAgile Manifesto
Why Agile?Understanding the basics
Agile MethodsLeanKanbanExtreme ProgrammingScrum
What is the PMI-ACP?
8
PMI-ACP is not:• A replacement for the PMP®• PMI’s own flavor of Agile• Without support from the Agile community• Going to make you an Agile expert
Agile is not:• Something New• A silver bullet• An excuse for little or no planning • An excuse for little or no documentation• An excuse for poor quality• Undisciplined • Unproven
What the PMI-ACP and Agile are Not
≠
9
Based on Geoffrey Moore’s Technology Adoption Life Cycle Curve
PMI-ACP and Adoption CurveThe
chasm
PMPACP
We are here!
10
Knowledge & Skills (50% of exam)Percentage of Knowledge and Skill Content / % of Exam
Level 1 (66% / 33%)(18 knowledge/skills)
Level 2 (24% / 12%)(12 knowledge/skills)
Level 3 (10% / 5%)(13 knowledge/skills)
Active listening Agile frameworks and terminology Agile contracting methods
Agile Manifesto values & principles Building high-performance teams Agile project accounting principles
Assessing and incorporating community and stakeholder values
Business case development Applying new Agile practices
Brainstorming techniques Colocation (geographic proximity)/distributed teams
Compliance (organization)
Building empowered teams Continuous improvement processes Control limits for Agile projects
Coaching and mentoring within teams Elements of a project charter for an Agile project Failure modes and alternatives
Communications management Facilitation methods Globalization, culture, and team diversity
Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations)
Participatory decision models (e.g., input based, shared collaboration, command)
Innovation games
Incremental delivery PMI's Code of Ethics and Professional Conduct Principles of systems thinking (e.g., complex adaptive, chaos)
Knowledge sharing Process analysis techniques Regulatory compliance
Leadership tools and techniques Self assessment Variance and trend analysis
Prioritization Value-base analysis Variations in Agile methods and approaches
Problem-solving strategies, tools, and techniques Vendor management
Project and quality standards for Agile projects
Stakeholder management
Team motivation
Time, budget, and cost estimation
Value-based decomposition and prioritization
11
Tools & Techniques (50% of exam)Communications
• information radiator, team space, agile tooling, osmotic communications for colocated and/or distributed teams, daily stand-ups
Planning, monitoring, and adapting
• retrospectives, task/Kanban boards, timeboxing, iteration and release planning, WIP limits, burn down/up charts, cumulative flow diagrams, process tailoring
Agile estimation
• relative sizing/story points, wide band Delphi/planning poker, affinity estimating, ideal time
Agile analysis and design
• product roadmap, user stories/backlog, story maps, progressive elaboration, wireframes, chartering, personas, agile modeling
Product quality
• frequent verification and validation, test-driven development/test first development, acceptance test-driven development, definition of done, continuous integration
Soft skills negotiation
• emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership
Value-based prioritization
• return on investment (ROI)/net present value (NPV)/internal rate of return (IRR), compliance, customer-valued prioritization, minimally marketable feature (MMF), relative prioritization/ranking
Risk management Metrics
• risk- adjusted backlog, risk burn down graphs, risk-based spike MetricsIncluding but not limited to: velocity, cycle time, earned value management (EVM) for agile projects, escaped defects
Value stream analysis
• value stream mapping
13
Community Guide of the PMI-ACP
Source: PMI.org/Agile
Agile History
16
• On February 11-13, 2001, at Snowbird ski resort, seventeen people met to talk, ski, relax, and try to find common ground.
• Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.
• What emerged from this meeting was a symbolic Manifesto for Agile Software Development, signed by all participants.
Agile Manifesto
17
Agile is Not New
1943
1950-1960s
1985
1990
1995
1996
1997
1998
2000
2001
USAF & NASAX-15 hypersonic jetIterative Incremental Delivery
Hirotaka Takeuchi & Ikujiro NonakaThe New NewProduct Development Game
1990 - Sutherland & SchwaberScrum Framework
DSDN ConsortiumDynamic SystemDevelopment Method
1996 - Beck, Cunningham, JeffriesExtreme Programming
Jeff de LucaFeature Driven Development
Alistair CockburnCrystal Methodologies
Robert CharetteLean Development
Agile Manifesto
Taiichi OhnoToyota Production SystemKanban
Hardware Software
18
Agile Practices
Lean
Kanban
PMBOK
Agile is an umbrella term for a group of iterative and incremental software development methods.
19
Agile Tools
Process ToolsVersionOneRally SoftwareJIRA + GreenHopperTeam Foundation ServerExcel
KanbanAgileZenLeanKit KanbanKanbanery
Engineering Tools
Continuous Integrationhttp://jenkins-ci.org/http://hudson-ci.org/http://cruisecontrol.sourceforge.net/
Engineering Tools
RubyCucumber for ATDD/BDD: http://cukes.info/RSpec: http://rspec.info/
Javahttp://www.junit.org/http://www.jmock.org/
.Nethttp://www.nunit.org/BDD for .NET: http://www.specflow.org/http://www.nmock.org/
20
Agile Manifesto Values
Individuals & interactions Processes & toolsover
Working softwareComprehensive documentation
over
Customer collaboration Contract negotiationover
Responding to change Following a planover
That is, while there is value in the items on the right, we value the items on the left more.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Source: www.agilemanifesto.org
21
Agile Manifesto Principles
Satisfy the Customer
Welcome Change
Deliver Frequently
Collaborate Daily
Support & Trust Motivated
Teams
Promote Face-to-Face
Conversations
Deliver Working Software
Promote Sustainable
Pace
Promote Technical
Excellence
Maximize Through
Simplicity
Have Self-Organized
Teams
Reflect & Adjust Regularly
Source: www.agilemanifesto.org
Understanding the Basics
28
Flipping the Iron Triangle
Features Cost Date
Cost Date Features
Source: DSDM
Plan-Driven
Value-Driven
$
29
Agile methods support experimentation & adaptation by reducing the cost of change.
This is done by employing many concurrent, rapid feedback loops to surface and address risks early.
Reducing the Cost of Change
Source: Examining the Cost of the Agile Change Curve by Scott Ambler
30
Common Understanding
A document can’t generate the meaning in others that
conversations can.
There is a reason “Individuals and Interactions” is first in the
Agile Manifesto.
? ?!
We don’t need an
accurate document, we
need a shared
understanding- Jeff Patton / Agile 2012
31
DeployDocument
$
Incremental Value Delivery
Agile Concurrent Development• Fund incrementally – opt to extend,
redirect or cancel at a very granular level
• Deliver & realize value steadily
• Validate designs with users & customers
• Continuously adapt to risk and change
• Integrate early & often
Waterfall Serial DevelopmentInvest up front, only realize value at end, assuming value proposition hasn’t changed
TestCode
DesignAnalyze
$$$
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
$ $$
32
Collaboration and Feedback Loops
Traditional methods only work for so long because…
• No or little feedback before delivery.
• Change not expected.
Why are agile methods being considered?
• Constant feedback loops.
• Change is expected.
33
Process Burden or Lack of Discipline• Historically development teams have
faced a false choice in respect to processo Overly complex and burdensome
o Or, undisciplined with no controls
• Agile Provides a lightweight, but disciplined approach for speeding time to market, improving quality, and increasing predictability
Agile is Discipline w/o Undue Burden
34
Four volunteers, please!Time is set at 2 minutesEstimate throughput
Round 1 (measure first and last delivery time)• First person flips 50 coins• When done with entire batch, pass to next
personRound 2• First person flips one coin of highest value and passes to next person• Keep flipping and passing until doneRound 3• Each table creates their own rules to maximize coin flow/throughput in least
amount of time
Retrospective
Exercise – Batch vs Flow Throughput
35
Key Agile Principles Traditional Waterfall
Focus on Highest Value FirstAlign project, product and team visions by prioritizing by business needs, and using well architected code, to deliver better quality products faster and cheaper.
All or nothingTight coupling & bias toward building out internals in a breadth first fashion means that nothing can be delivered in isolation, even if it’s valuable.
Responding to ChangeAcknowledge uncertainty & adapt to both external (market) and internal changes, by modifying plans & approach. Use engineering principles to make code base easy to modify.
Baseline & Change ControlConstrain or even completely eliminate any significant change other than dropping features. Work to initial plans, even when they are proven to be invalid.
IterativeUse short time boxes to provide a rhythm, continually flow of value to the customer, and refine deliverables over time.
PhasedNo rhythm as project is executed using long phases.
Feedback & Continuous ImprovementUse continual feedback to inform plans and modify approach.
Lessons Learned at the EndFeedback is rarely given in time for it to be applied towards improving processes and project execution.
Small, Integrated TeamsA small team size, and overlap in skills sets, simplifies communications, allows everyone to see the big picture, creates self discipline and provides flexibility.
Silo Teams with HandoffsStaff works in functional oriented groups, throwing documentation and code over the wall.
Technical Excellence / Bake Quality InUse TDD , ATDD, refactoring, and other strong engineering principles to ensure quality.
InspectionAttempt to ensure quality by after the fact inspection.
Agile Principles Compared
36
Agile is Empirical, Not Definitive
Agile assumes that baselines may change significantly during the project.
In such an unpredictable environment, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.
37
Rolling Wave Planning, used in Agile processes, embraces the Lean ideal of making decisions at the last responsible moment, when the most possible information is available. This maximizes flexibility and planning accuracy.
Agile Uses Rolling Wave Planning
Level of Planning Planning Approach
Strategic product line goals Strategic Planning
Strategic product goals Product Planning
Specific problems to solve Lean / Six Sigma
Large functional goals Release Planning
Small, defined work items Iteration Planning
Tactical organization & execution Daily Standup
38
Layers of Product Planning
Product / ProjectWhat business objectives will
the product fulfill?
Product Goals
Product Charter
Elevator Pitch
Release
How can we release value incrementally?
What subset of business objectives will each release achieve?
What user constituencies will the release serve?
What general capabilities (big stories) will the release offer?
Release Roadmap
Release Plan
Iteration / Sprint
What specifically will we build? (User Stories)
How will this iteration move us toward release objectives?
Iteration Plan
Development Tasks
Story (Backlog Item)
What user or stakeholder need will the story serve?
How will it specifically look and behave?
How will I determine if it’s completed?
Story Details
Acceptance Tests
39
• Top level goal(s) must be communicated to all levels of the organization
• Members of the organization offer candid information up the management ladder.
• Leaders/Managers offer guidance (why and what ≠ how)
Principle - Self-Organized and Empowered
info
gu
ide
info
gu
ide
info
gu
ide
info
gu
ide
40
Some Basic Terminology
Scrum Extreme Programming (XP) Definition
Sprint Iteration Fixed-length period of time (timebox)
Release Small Release Release to production
Sprint/Release Planning
Planning Game Agile planning meetings
Product Owner Customer Business representative to project
Retrospective Reflection “Lessons learned”-style meeting
ScrumMaster Coach Agile project manager
Development Team
Team Empowered Cross-Functional team
Daily Scrum Daily Standup Brief daily status meeting
41
Some More Agile Terminology
Term Definition
SpikeSomething cannot be estimated until a development team runs a timeboxed investigation. The spike itself is a throw-away.Can include risk, architectural, or any unknown.
Tracer BulletAn experimental solution that cuts through all the "layers" ofthe architecture. It is not necessarily time-boxed. It is not intended to be thrown away.
Kaizen Continual improvement of all areas of a company not just quality.
Value Stream An end-to-end business process which delivers a product or service
More terms… Go to the Community Guide of the PMI-ACP at http://agile.vc.pmi.org/
42
Session Purpose Timing/Duration Attendees
Iteration 0 Orient Team to project’s business value and analytical background, the process, and one another.
Start of projectApproximately 1-3 weeks of 2-4 hr workshops
Team, PO, SM, Key Stakeholders & users
Release Planning
Determine what a Release should include and when it should be delivered.
Start of Release2-4 hours
PO, SM, Key Stakeholders, optionally Team
Daily Standup Facilitate rapid coordination betweenTeam members, and with PO.
Daily10-15 minutes
Team, SM, PO
IterationPlanning
Elaborate, estimate and prioritize highest-value Product Backlog items for anIteration.
Start of each Iteration2-4 hours
Team, SM, PO
IterationRetrospective
Reflect on project & process issues and take action as appropriate.
End of each Iteration30-45 minutes
Team, SM, PO
Iteration Review
Demonstrate completed functionality to interested stakeholders & users to showprogress and gain feedback.
End of each Iteration1-1½ hours
Team, PO, SM, Key Stakeholders & users
Meetings Summarized
43
Small Teams with everything needed to deliver an increment of value
Backlog prioritized by value being delivered incrementally
At scale, the backlog and products for these teams need to be coordinated and technical practices must address the challenges of integration
How does Agile Work?
44
DeployDocument
$
Incremental Value Delivery
Agile Concurrent Development• Fund incrementally – opt to extend,
redirect or cancel at a very granular level
• Deliver & realize value steadily
• Validate designs with users & customers
• Continuously adapt to risk and change
• Integrate early & often
Waterfall Serial DevelopmentInvest up front, only realize value at end, assuming value proposition hasn’t changed
TestCode
DesignAnalyze
$$$
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
$ $$
45
Incremental and Iterative Delivery
Incrementing is more about delivery.
1 2 3 4 5
1 2 3 4 5
Iterating allows you to move from vague idea to realization. Going from rough to polished
Image Credit: Jeff Patton
46
• Iterations are regularly scheduled, pre-planned, recurring time boxes. Provide a cadence / rhythm that provides predictability and synchronization points for planning. The more mature your process, the shorter the iterations.
• Things we time-box:o Sprints (or Iterations) - length of time in which work is doneo Releases - Production and Maintenanceo Working Sessions - Release Planning, Sprint Planning, Sprint Review,
Retrospective
• Iterations facilitate incremental development (but incremental development doesn’t require iterations).
Iterations
Agile Methods
Lean Kanban
Extreme Programming Scrum
48
“A production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.“
What is Lean?
Source: Wikipedia
49
Kanban (看板) literally meaning "signboard" or "billboard", is a concept related to lean and just-in-time (JIT) production.
Taiichi Ohno is considered to be the father of the Toyota Production System
What is Kanban?
Kanban is a scheduling system that tells you what to produce, when to produce it, and how much to produce.
50
• A software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.
• It advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.
What is Extreme Programming?
51
Scrum is an iterative and incremental project delivery framework.
What is “Scrum?”
Source: Wikipedia
52
Iteration 0
Brief orientation to the project’s business value and analytical background, the Agile process, and the Team.
Project Orientation• Business case overview• Business process analysis• Project scope & objectives• Initial Product BacklogProcess Orientation• Agile process training• Sprint/Release cycles• Definition of “Done”Team Orientation• Team room artifacts• Team norms• Technical environments,
design, architecture, etc
Initiating an Agile Project
Release Planning Session
Initial project planning, to review initial Product Backlog and set production Release dates.
Release Schedule
Product Backlog
List of desired functionality prioritized by business value by Product Owner.
Allow a user to create a free account. (Priority 1)
Allow subscribers to purchase music. (Priority 3)
Allow user to personalize store experience. (Priority 9)
53
A useful project charter contains three key elements:1. Vision: The vision defines the “Why” of the project. This is the higher purpose, or the reason for the project’s existence.2. Mission: This is the “What” of the project and it states what will be done in the project to achieve its higher purpose.3. Success Criteria: The success criteria are management tests that describe effects
outside of the solution itself.
Additional elements:Working practices – Planning, estimating, definition of done, tracking progress, TDD
methods
Continuous Integration – integration time limits, breaking the build, code check-in
Code – Paired programming, owning the code, documentation
Iterative and Incremental Development – iteration cycle and deployment cycle
Agile Project Charter
Lean
55
Lean Portfolio Management
• Corporate strategy operates over years with direct line of sight to priorities
• Optimize the whole
• Manage internal and external dependencies
• Focus on quickly delivering minimal marketable features
• Clear feedback mechanism between business and development
• Creates alignment beyond single teams
Year(s): Set corporate goals and strategies
Quarter(s): Discover and create innovative product strategies from corporate goals
Month(s): Update Release Plans, Product Backlogs and Roadmaps
Week(s): Decompose features from Product Backlog into tasks and deliver working code
56
The 7 Principles of Lean1. Eliminate Waste
2. Create Knowledge
3. Build Quality In
4. Defer Commitment
5. Optimize the Whole
6. Deliver Fast
7. Respect People
7 Principles of Lean
Source: Mary and Tom Poppendieck
67
Process Cycle Efficiency is the key measure of Leanness
Process map entire value-stream at a high level, drilling down into more detail only as potential areas of interest are identified
• Value-added: This step in the process adds form, function, and value to the end product and for the customer.
• Non-Value-Added: This step does not add form, function, or assist in the finished goods manufacturing of the product.
• Non-Value-Added-But-Necessary: This step does not add value, but is a necessary step in the final value-added product.
Lean Process Cycle Efficiency
PCE = (sum of time for Value Added process steps)
(sum of time for All process steps)
70
The “Kaizen” Mindset:1. Everything, not just software
development, can and should be improved
2. Improvements should be made day to day
3. The best improvements come from taking the customer’s point of view
4. Move from criticism to suggestion
5. Keep improving, even if things are working
Continuous Improvement
改善
Kanban
74
1. Visualize your Workflow
2. Limit Your Work in Process
Example: Mature Requirements Separately
• Instead of figuring everything out for a user story just in time at Sprint Planning, we can ready them in advance
• The specific process varies, but there is a set of steps to get a requirement ready
Kanban – High Level
New Candidates PO Approved Decomposed
Acceptance Criteria
Testable Example
Dev Review Ready for Sprint
10 cards 6 cards 4 cards 4 cards 4 cards 8 cards 12 cards
Airplane Game
Paper Airplane Game
Team of 5 makes 21 airplanes
1st Run: Fast as you can
2nd Run: Flow, Batch size of one
Consistently better results
– Lead Time: 3X improvement
– Throughput: 10-20% better
– Lower stress
– Easier to manage
76
Everything at once =
many started
few finished
Costs of Over-Utilization
Develop Test
In Process Ready In Process Ready
4 slots 3 slots 4 slots 3 slots
WIP Limits = Fast
“A system of local optimums is not an
optimum system at all” - Eli Goldratt
Extreme Programming (XP)
78
Agile Engineering Practices allow teams to move fast, be flexible and deliver high quality software:
• Automated Builds & Continuous Integration reduce time and effort associated with manual builds, and risk from big-bang integrations
• Simple Design & Refactoring keep incremental development from leading to poor architectures
• Multi-Level/Automated Testing & Test-Driven Development reduce testing time and effort and allow developers to make changes with confidence
• Pair Programming increases software quality without impacting time to deliver.
Agile Engineering Practices
Source: Bill Wake, http://www.xp123.com
79
XP Coach• The XP Coach role helps a team stay on process and helps the team to learn. A
coach brings an outside perspective to help a team see themselves more clearly. The coach will help balance the needs of delivering the project while improving the use of the practices. A coach or team of coaches supports the Customer Team, the Developer Team, and the Organization.
• The decisions that coaches make should always stem from the XP values(communication, simplicity, feedback, and courage) and usually move toward the XP practices. As such, familiarity with the values and practices is a prerequisite. The coach must command the respect required to lead the respective teams. The coach must possess people skills and be effective in influencing the actions of the teams.
• The XP Coach uses many different techniques. The coach is a mentor, working side by side with team members on their tasks. The coach is a facilitator, helping achieve more effective team performance. The coach is a conduit, reinforcing communication within the team and across teams.
XP Roles - Coach
80
XP Customer
• The XP Customer role has the responsibility of defining what is the right product to build, determining the order in which features will be built and making sure the product actually works.
• The XP Customer writes system features in the form of user stories that have business value. Using the planning game, he chooses the order in which the stories will be done by the development team. Defines acceptance tests that will be run against the system to prove that the system is reliable and does what is required.
XP Roles - Customer
81
XP Programmer• The XP Programmer is responsible for implementing the code
to support the user stories.
XP Roles - Programmer
82
XP Tester• The primary responsibility of the XP Tester is to help the
customer define and implement acceptance tests for user stories. The XP Tester is also responsible for running the tests frequently and posting the results for the whole team to see. As the number of tests grow, the XP Tester will likely need to create and maintain some kind of tool to make it easier to define them, run them, and gather the resultsquickly.
XP Roles - Tester
83
1. ______ is responsible for implementing the
code to support the user stories.
2. ______ help the customer define and
implement acceptance tests for user stories
3. ______ Helps a team stay on process and
helps the team to learn. Is a mentor, working
side by side with team members on their
tasks
4. ______ writes system features in the form of
user stories that have business value and
defines acceptance tests.
XP Roles – Quick Quiz
a) XP Coach
b) XP Customer
c) XP Programmer
d) XP Tester
1(c) 2(d) 3(a) 4(b)
86
Simple Design:• Code is always testable, browsable, understandable, and explainable
• Do the simplest thing that could possibly work next. Complex design is replaced with simpler design
• The best architectures, requirements, and designs emerge from self-organizing teams
Refactoring:• Remove redundancy, eliminate unused functionality, and rejuvenate
obsolete designs
• Refactoring throughout the entire project life cycle saves time and increases quality
• Code is kept clean and concise so it is easier to understand, modify, and extend
Simple Design and Refactoring
Risk
94
Create a risk census during the first sprint planning meeting and then update it quickly during subsequent planning meetings as new risks are identified or as the probabilities or sizes of known risks change.
Risk Burndown
As with a regular release burndown chart, we should see a linear drop in risk over the course of the project.
Plot your project risk exposure and display it with other big visible charts in your team area.
Source: Managing Risk on Agile Projects | Mike Cohn - Mountain Goat Software
95
Risk Management
Traditional Risk Management Agile Risk Management
Prepare formal risk management plan Educate the team. Invite them to determine best approach to manage
Formal risk identification meetings and then create Risk Register
Team identifies risks in all meetings and add to information radiators
Conduct qualitative and quantitative analysis. Determine how to respond
Facilitate the team in a qualitative analysis, determine how to respond, post results
Periodically review Risk Register and make updates as needed
Constantly review risk and responses as part of all meetings, reviews and retrospectives
Source: Sliger & Broderick (2008),The Software Project Manager's Bridge to Agility, Addison-Wesley
96
Implicitly managing Risk:
• User stories are prioritized by the Product Ownero Highest value items are attacked first
o Highest risk items are also attacked early
• Iterative delivery ensures that integration and rollout risks are attacked very early in the project lifecycle
• Technical discipline helps keep a tight rein on development risko Automated builds and continuous integration keep code integration and
code quality risk to a minimum
Implicit Risk Management
97
Explicitly managing Risk:• Review the Product Backlog
• Identify and list risks by impact (High/Medium/Low) and probability (High/Medium/Low)
• Provide a mitigation plan with clear responsibility
• Create task cards for risk mitigation items
• Insert into Product Backlog and/or Sprint Backlogs; or track on Risk Board
Explicit Risk Management
Agile Risks, Agile Rewards, Smith and Pichler, Dr. Dobb’s 2005
Agile Requirements
99
User Interface Layer
Business Logic Layer
Persistence Layer
Work in Agile projects is organized by Units of Value, rather than by Architectural Layer.
Work Organized by Value
Feature / User Story 2Feature / User Story 1 Feature / User Story 3
100
Key Characteristics• High-level descriptions of desired
functionality and goals
• Implement “vertical slices” of the system’s functionality
• “Contracts for conversation,” not all-inclusive requirements
• User stories wait in the Product Backlog until pulled into the Sprint Backlog
• Contain Acceptance Criteria to define “Done”
User Stories at a Glance
As a user I can create an account.
Estimate 21 PointsPriority 1 (High)
As a user I can enter a user name.
Estimate 4 pointsPriority 1 (High)
As a user I can enter password.
Estimate 8 pointsPriority 1 (High)
Product Backlog User Story
Sprint Backlog User Stories
101
From User Stories to Tasks
Tasks
As a user I can enter a password.
Estimate 8 pointsPriority 1 (High)
Acceptance Criteria
User Story
On back…
• Design user interface• Develop CSS/HTML• Create database fields• Develop validation criteria• Write test cases• Code test fixtures• Unit testing• Acceptance testing• Usability testing• Write online help text
• Password match validated• Contains special characters• Minimum 10 digits• Cannot be text only
102
As a <type of user>, I can <immediate goal> so that <business outcome>.
User Story Template
User Role (Who?)
Desired Function (What?)
End Result (Why?)
Who, What, Why… what’s not here?
103
Acceptance Criteria help to set scope and define what Done means for a given User Story.
User Story Acceptance Criteria
• Verify that a premium member can cancel the same day without a fee.
• Verify that a non-premium member is charged 10% for a same-day cancellation.
• Verify that an email confirmation is sent.• Verify that the hotel is notified of any cancellation.
As a user, I can cancel a reservation.
104
Circle which attributes make a good story and then discuss as the group
What Makes a Good Story?
Independent
Valuable
Testable
CreativeEstimatable
Small
Negotiable
Source: Bill Wake
105
Pre Release Life of a User Story
• Phone # in US format, contains no alpha characters, minimum 10 digits
• First name, Last name and email address required
• Email specified in standard format• Etc.
Acceptance Criteria Created Prior to Release Planning
As a user I want to create an account
User Stories Created Prior to Release Planning
Sprint Tasks Created at Sprint Planning
• Design UI Mock Up• Write online help text• Develop CSS/HTML• Develop validation criteria• Create database tables• Code test fixtures• Code• Perform testing
Name Phone Email Valid
John Smith 215-555-1212 [email protected] TRUE
Smith 215-555-1212 [email protected] FALSE
John 215-555-1212 [email protected] FALSE
215-555-1212 [email protected] FALSE
John Smith [email protected] FALSE
Smith [email protected] FALSE
John [email protected] FALSE
Testable Examples (ATDD) Created Prior to Sprint Planning
Estimate 5-PointsPriority 1 -High
(Created at Release Planning)
106
User Stories aren’t the only way to develop, express and elaborate requirements in Agile. Some complementary tools & methods include:
• Essential Use Cases
• Low-fidelity prototyping
• High-fidelity prototyping
The best approach will be determined by your team and the problems at hand.
Beyond User Stories
107
Low-fidelity prototyping is a fast, cheap, easily iterated, collaborative way to test various concepts & approaches.
Low-Fidelity Prototyping in Agile
Tools• Paper sketches and collages• Whiteboard drawings
Applications
• Concept design: to explore different metaphors and design strategies• Interaction design: to organize screen structure & flow• Screen design: for initial screen layout & design• Screen testing: to refine screen layout
Source Adaptive Path for Sketchboard example
108
High-Fidelity prototypes are detailed, interactive and reusable means of simulation.
Tools:• Photoshop, Visio, Powerpoint• Flash, iRise Studio, Serena ProcessView• WPF, XAML, XUL…
Applications:• When stable requirements support reuse• To test complex interaction scenarios• To finalize detailed designs• As inputs to a Sprint
High-Fidelity Prototyping in Agile
Source: iRise Studio, www.irise.com
109
1. In general, we can view the maturation of
a need (expressed as a user story) as
having enough information to prioritize,
__________ and ___________.
2. The user story format has three parts:
“as a”, “I want to” and “_________.”
3. Acceptance criteria is written for team
members and, as such, assumes a level of
existing ___________.
4. Acceptance criteria is incredibly useful
but a ___________ will often provide
significant additional clarity.
Agile Requirements
a) build
b) domain knowledge
c) estimate (test)
d) outsiders
e) so that
f) testable example
1(c) (a) 2(e) 3 (b) 4 (f)
110
5. A ___________ defines how the software will be implemented; it can define the external behavior, ___________ design, or both.
6. As defined in this training, a specification builds on a requirement with additional context, conversations and ___________.
7. A specification should be ___________, defining just enough to help the team build confidently within the sprint.
8. The appropriate level of detail required in a specification will ___________, depending on, among other things, the ___________ of the requirement, the domain knowledge of the team, and the requirements’ similarity to what has already been built.
Agile Requirements
g) complexity
h) designs
i) internal
j) lightweight
k) specification
l) vary
5(k) (i) 6(h) 7 (j) 8 (l) (g)
Agile Estimation
112
High Level – Affinity Story Level – Planning Poker
Story Pointso Purely relative measure of complexity (2 is half as hard as 4)
o Variability averages out across many stories
o Don’t decay over time
Scales with increasing gaps between elements are preferredo Fibonacci: 1, 2, 3, 5, 8, 13
o Doubles: 1/2, 1, 2, 4, 8, 16
o “T-Shirt Sizes:” S, M, L, XL, XXL
Agile Estimation Levels, Units and Sequences
Traditional project estimation approaches may be necessary for initial scoping, but should
rapidly be replaced by empirical observation of Team
output capacity (velocity).
Avoid false precision to avoid false expectations.
113
1. Use more than one person. By engaging the team in the estimation process, we gain the benefits of additional insights and consensus building.
2. Use more than one approach. Use multiple estimation approaches (comparison to similar projects, bottom up, user story points, etc.) and look for convergence between multiple approaches to reinforce likely estimate ranges.
3. Agree on what “It” and “Done” means. Make sure everyone is estimating in the same units, have the same assumptions and are based on standard developer ability/effort.
4. Know when to stop. Balance estimation effort against the diminishing returns and false accuracies of over analysis.
5. Present estimates as a range. Estimates are often poor predictions, and should be noted as such.
6. Defend/explain estimate range probabilities. Educate stakeholders about the relative likelihood of hitting optimistic/pessimistic estimates.
7. Don’t reserve estimating for when you know least about the project. Estimation should not be reserved for only the beginning of projects.
8. Be aware of common estimation omissions. Don’t overlook commonly missed tasks, and use retrospectives to inspect project-specific issues.
9. Embrace reality early. Don’t under-estimate the load of maintaining and refactoring a growing codebase.
10. Review, Revisit, Remove Head from Sand, Repeat. Adjust project forecast based on empirical observation of throughput.
Agile Estimation Essentials
114
Participants: Whole teamMulti-team environment: Work together!
Process: Cards are placed in a stack on the table
• Product Owner explains the top card
• First team member places this card on table by size (left smaller, right larger)
• Next team member either repeats process with next card, or moves an existing card to a new position, with an associated explanation
• Process repeats until all cards are placed and grouped, and no more movement is desired
• Each group is labeled with its estimate
Affinity Estimating
Smaller Larger
115
• Clifford the Big Red Dog
• Marmaduke
• English Bulldog
• Chihuahua
• Pug
• Scooby-Doo
• Great Dane
Exercise – Relative Dog Sizing
Rules Point Estimating:
Team decides scale
Discuss criteria for complexity
Find the reference point
Estimate size for remaining items
Based on Mike Cohn’s dog points
116
“Planning Poker” is based on “Wideband Delphi” convergent estimation techniques.
How to do it:1. Each estimator (someone who could possibly be doing the
work in question) is given a deck of cards, each card has a valid estimate written on it
2. A moderator reads a story and it’s discussed briefly3. Each estimator selects a card to represent her estimate4. Cards are turned over so all can see them5. Discuss differences (especially outliers)6. Re-estimate until estimates converge (or don’t!)
Agile Estimation – Planning poker
117
5
Planning Poker Example
55Bill (Dev)
52Ann (BA)
58Vijay (QA)
33Susan (Dev)
Round 2Round 1Estimator
Scrum
119
Scrum – 50,000 Foot View
Release Planning
SprintPlanning
SprintReview
SprintRetrospective
120
There are only three roles defined in Scrum:
Scrum Roles & Responsibilities
Product Owner
• Owns Product vision
• Defines features, decides on release date and content
• Responsible for market success
• Prioritizes features according to market value
• Can change features and priorities every Sprint
ScrumMaster
• Responsible for facilitating process
• Focuses Team and protects them from external interruption
• Looks for ways to enhance productivity
• Assists Product Owner in leveraging Scrum
The Team
• Small group containing all necessary project skills
• Focuses on steady delivery of high quality features
• Generates options for delivery
• Manages own work within Sprints
121
• Product BacklogPrioritized list of valuable items to deliver during the project.
• Sprint BacklogList of committed items to be addressed within a Sprint.
• Burndown/burn-up Chart Visual aid for tracking team progress and forecasting expected completion dates.
• Velocity ChartTracks rate of feature completion.
Artifacts of Scrum
122
Scrum Milestones
Product Backlog
• ____________• ____________• ____________• ____________• ____________
F3 F6
Release 1F1, F2, F3
Release 2F1, F2, F3F4, F5, F6
Initial Planning
Rel
ease
Pla
nn
ing
Rel
ease
Pla
nn
ing
F1
F2
F2 F1 F4
F5F3
US1
US 2
US 3
US 4
US 5
US 6
US 7
US 8
US 1
US 2
US 3
US 4
US 5
US 6
US 7
US 8
Rel
ease
Pla
nn
ing
SprintBacklog• ______• ______
SprintBacklog• ______• ______
SprintBacklog• ______• ______
SprintBacklog• ______• ______
SprintBacklog• ______• ______
SprintBacklog• ______• ______
Spri
nt
Pla
nn
ing
Spri
nt
Pla
nn
ing
Spri
nt
Pla
nn
ing
Spri
nt
Pla
nn
ing
Spri
nt
Pla
nn
ing
Spri
nt
Pla
nn
ing
123
Scrum Milestones
Features User Stories MMF
124
The Scrum Sprint Cycle
Sprint Planning
Elaboration, estimation and prioritization of highest-value
User Stories.
Sprint Backlog
Allow a user to enter a login & password.
Allow a user to enter personal information.
Allow user to enter billing information.
Spri
nt
Exe
cuti
on
Complete Sprint BacklogTeam works on highest-value functionality until it meets jointly defined Acceptance Criteria.
Sprint ReviewTeam demonstrates completed functionality to
interested stakeholders, gathering feedback.
RetrospectiveTeam reflects on project & process and takes action
as appropriate.
Production Release (Optional)Generally occurs when a useful group of related
functionality has been completed.
Daily Scrum (or Standup)15-minute status and risk management meeting for
Team & Product Owner.
125
Use a cadence of recurring working sessions to synchronize and simplify planning while providing continuity
Cadence & Synchronization
Instead of wasting time coordinating numerous meetings and dates…
126
Instead of cube farm, organized by function…
We collaborate via flexible roles and simple rules to decentralize decision making and get work done.
Small Collaborative Teams
AfterBefore
127
SB Item Priority Hours
User Story High
Task 1 4
Task 2 12
Task 3 6
User Story Med
Task 1 9
Task 3 2
User Story Low
Task 1 5
Task 2 2
Task 3 7
From Product to Sprint Backlog
Product Backlog Sprint BacklogSprint Planning Sprint
Top priority stories are
discussed and decomposed into Tasks for
the Sprint Backlog.
Team pulls and completes Tasks until each User Story is done.
PB Item Priority Points
User Story High 5
User Story High 8
User Story High 3
User Story Med 13
User Story Med 8
User Story Med 5
User Story Med 13
User Story Med 8
User Story Med 5
User Story Low 21
User Story Low 13
128
Cards move left to right, downstream, if there is space.
Tracking Work in a Sprint
Sprint Backlog In Progress Completed
10 cards 6 cards
Sprint Backlog In Progress Completed
10 cards 6 cards
Sprint Backlog In Progress Completed
10 cards 6 cards
Cards move left to right, assuming there is space, then…
From Sprint Backlog to In Progress, if there is space, and…
From In Progress to Completed.
129
1. The ___________ ensures that requests are expressed in user story or other appropriate format and placed in the ___________.
2. The ___________ provides story point estimates for each ___________.
3. Product owners ___________ user stories (PBIs), then, with input from the team and other stakeholders, sequences user stories into ___________.
Scrum Process Review
a) user story
b) product owner
c) product backlog
d) prioritize
e) releases
f) team
1(b) (c) 2(f) (a) 3 (d) (e)
130
4. At the end of each ___________ the team demonstrates _____________ they do this at the ___________.
5. The total story points estimates, for those stories that were completed in a sprint, are added together to provide us with the ___________ for the sprint.
6. The team holds a ___________ to evaluate how well they’ve done and what changes could be made to the process to further improve.
Scrum Process Review
g) sprint
h) sprint review
i) sprint retrospective
j) velocity
k) working software
4(g) (k) (h) 5(j) 6(i)
Roles & Responsibilities
Product Owner
133
Manage the return on investment (ROI)• Establishes baseline target ROI
• Measures project against this baseline
• Prioritizes product backlog to maximize ROI
Guide product development• Establishes, communicates and nurtures the vision
• Knows what to build and in what sequence
• Tunes the vision with the team
Call for releases• Decides when to call for release of a potentially shippable product increment
• Can shift a release forward to maximize ROI based on new knowledge
Product Owner Responsibilities
134
Busy Product Owners need not – and should not – act alone.
Some of the roles that can assist: • Business Analysts help to define business needs and elaborate them for the
rest of the Team
• Developers provide available execution paths and describe their respective costs and benefits
• User Experience experts and marketing resources help to elicit and explain end user needs and desires
• Other Business Stakeholders to get a wider representation of needs from across the organization
An Army of One?
Product Owners represent
many constituents with a single voice.
135
Shared Understanding of Value
The Product Owner helps to spearhead a Shared Vision, but the whole Team should understand it:
• Communicate & elaborate early conceptual & visioning work through Sprint (Iteration) 0.
• Involve Team in translating User Needs into Product Functions
• Involve Team in development of clear Goals
• Directly involve Team in feedback loops
• Provide direct exposure to end users
136
Sarah, the client product manager for your development project, has little interest in being a product owner. “We’ve given you the specification of exactly what we want done,” she declares. “Just do your thing. I know you guys are good!”
What do you do?
Reluctant Product Owner
137
Sprint
What must be in place for your project teams to plan and estimate 2-3 weeks worth of work?(e.g. wireframes, detailed acceptance criteria, key stakeholder approval…)
Defining “Ready”
Ready In Process Done
138
Example of a Definition of Ready
Analyst – User story sufficiently defined and mapped from requirements
Tester – Acceptance criteria developed
Developer – User story is estimated and no known blocking dependencies exist within the sprint
Definition of “Ready”
Vision and Goal
140
A Typical Agile Pipeline
Ideation
Market TrendsPrototypes
Focus GroupsUser ExperienceBasic Workflows
VisionBusiness Outcomes
Release Timing and GoalsProduct ArchitectureEpics and Features
Maturation
User Story DecompositionUser Story Maturation
Acceptance CriteriaTest Cases
DependenciesStory MappingPrioritization
Epic EstimationBacklog Development
Execution
Sprint PlanningTask EstimationDaily Standups
Software DevelopmentTesting
BurndownsDocumentationProduct DemosRetrospectives
Current Sprint~2 Sprints Ahead>4 Sprints Ahead
Marketing/Sales, Product Management, Product Owners, Architects
Product Owners, Architects, Dev Leads, QA Leads, UX/Analysts
Leads, UX/Analysts, Dev Team Members
141
Vision
Goal / Outcome
Epic
Feature Feature
Story Story Story Story Story
Feature
Goal / Outcome
Epic
Feature Feature
Requirements Breakdown Structure
With Scrum, we refine requirements over time, from a high level Vision down to User Stories and tasks that can be executed in a Sprint. • At each level, items can break down further into siblings, so one Epic can become two.
• The exact breakdown is often unclear; is this a Feature or an Epic? In reality, the exact breakdown is not important.
• The names may also vary, so“User Story” or “Story” areoften used interchangeably.
142
1. Estimate relative level of effort for each feature
o Takes into account complexity of work, effort, etc.
o Uses relative units (e.g. A is half as hard as B)
2. Measure “Velocity” to set Team capacity
o Takes into account external interruptions, technical surprises, developer skill level, domain knowledge, etc.
o Work actually completed over time gives accurate data to determine capacity for a Team
Agile Estimation Basics
Velocity requires stability to be accurate.
143
Example of a Definition of Done
• Analyst – Working system reviewed and User Story accepted via Automated Test or Manual Inspection
• Tester – Test cases pass. All critical and high severity bugs fixed and other bugs identified and tracked
• Developer – Deployed to test environment and Code Review complete
Definition of “Done”
144
Story Estimate Status at End of Sprint
As a Prospect, I can submit an application. 2 Pts* Complete
As a Policy Holder, I can update my account information.
5 Pts Complete
As an Account Representative, I can view a Policy Holder’s information.
8 Pts Complete
As an Underwriter, I can approve or reject applications.
5 Pts 1 Pts Remaining
Total Sprint Velocity 15 Pts
Velocity Calculation
* Pts = Story PointsNext Sprint,
15 Pts would be our projected capacity.
145
Metrics fall into two general categories:
Business Valueo ROI, IRR, NPV
o % cycle time reduction
o Customer satisfaction (NPS)
Diagnostico Velocity
o Successful builds per iteration
o Defects across iterations
o Code coverage
Defining Key Metrics in Agile
Tips:• Measure outcome, not output• Measure only a few things• Ensure commonly understood
operational definition and measurement plan
• Target specific questions and audiences
146
Planning Releases
1. Guess a starting velocity (14 in this case)2. Choose which stories must exist to
Release and see how many Sprints are needed, or… Work backwards from the Release date to fit as many high-value stories as possible
3. Adjust the scope within the Release as true Velocity becomes apparent
Velocity = 14 points per Sprint
Sprint 4
Story M 2
Story K 3 Story L 8
Sprint 1
Story A 5 Story B 3
Story C 5 Story G 1
Sprint 3
Sprint 2
Story D 2 Story E 5
Story F 2
Story H 8
Story I 5
Story J 5
Release 1
147
Based on the velocity chart below, in what iteration can the business expect 33 more story points completed?
Estimating Dates with Velocity
Velocity stabilizes as business & technical domain knowledge increase and teams
move from forming & storming to performing.
148
If each sprint costs $20k, what would be the project cost at the end of iteration 15?
Estimating Cost
149
When you are mandated to use EVM
Apply the 0/100 method to measure completion of Stories and Tasks.
It is possible to maintain ANSI/EIA-748 reporting compliance• Replacing velocity with EV metrics
• Creating measures of budgeted cost of work performed (BCWP) using "testable stories"
• Establishing the Budgeted Cost of Work Scheduled (BCWS) baseline at the beginning of each iteration
• Capturing Actual Cost of Work Performed (ACWP) through a time keeping system
• Computing Cost Variance, Schedule Variance from the three base earned value metrics
• Computing Estimate at Completion (EAC) and Estimate to Completion (ETC) from these base metrics as well.
Agile EVM instead of Velocity
1. If you know why you use EVM now, the same applies to AgileEVM2. Use the iteration as the unit for basing calculations
150
• Review velocity and set Sprint capacityIdentify anything unique about the coming sprint (vacation, holidays, etc.)
• Select Sprint Goal (Optional)
• Select top-priority User Stories from Product BacklogSelect slightly more than capacity, aligned with Sprint goal as appropriate
• Discuss User Stories to create Tasks & Acceptance Criteria
• Estimate User StoriesBase on individual task estimates, sticking to about 1-8 hours/task
• Commit to User StoriesSelect until capacity is reached, with some backup stories discussed in case Team finishes early
Sprint Planning Sample Agenda
Identifying & Modeling Users & Customers
152
Prioritization and Socializationo Prioritize user types each release as you
would functionality. Knowing high priority users helps you identify high priority functionality.
o Post them in the area your team works to help team members empathize with target users and make better tactical design decisions.
Focusing Testing & Evaluationo Identify user test subjects.
o Identify alpha/beta test subjects.
o Compare them with your eventual actual users to identify bad assumptions and to add new user constituencies.
Applications of User Models
153
Users interact directly with the systemThey are important to understand, because:• Knowledge of current usage patterns helps to design
better, more usable systems.• Unsatisfied users will work around the system, nullifying
its advantages and eventually eliminating it.
Customers make buying or adoption decisionsThey are also important, because:• They have their own wish lists that may have little to do
with their users’ needs.
• They make the purchasing decisions, so if they aren’t happy, you won’t get in the door.
Users vs. Customers
154
Less detailed descriptions can also work
Succinct User Roles
Nurse Admitting New Patient to Ward
Context
Environment & basic
responsibilities of the role
Busy, noisy hospital.
Characteristics
Patterns of interaction,
behaviors, and attitudes
• Uses the application only several times a week.
• Gets trained at in-service once a year.
• Has access to peers to ask questions.
Criteria
Key objectives of the role
“Get the data entered as quickly as possible
without making any mistakes!”
155
Personas take user roles one step further.
o Represent our current or desired audience.
o Provide a name, a face, and a description to a particular “user role.”
Level of detail
o Some believe in creating a small number of very detailed personas. These often over specify.
o Lightweight personas will suffice for most situations.
One Step Further - Personas
“Extreme Character Personas will lead you to stories, you would be likely to miss otherwise”User Stories Applied by Mike Cohn
156
Here are some example personas
Example Personas
Peter the Programmer“I’d like to get a better handle on test driven development and refactoring.” Peter’s company has just started using agile development. While he’s been a developer for a long time, he’s not used agile practices like TDD.
David the Agile Developer“I've been using TDD, refactoring, and continuous integration for many years now. I want to see what's next.” David is a strong engineer that started with Extreme Programming practices about 2001. He’s proficient at most agile engineering approaches and always on the lookout for new cutting edge techniques. The other engineers in his department look to him for ideas and advice.
Tara the Tester“How do I find time in an Agile process to test effectively?” Although Tara’s been a tester for a long time, she’s been working in an agile team for only a few months. Testing is a real challenge in an agile environment. Tara’s finding she needs to be part programmer to use the automated testing framework her company has adopted for acceptance tests. Some days Tara wishes her company would go back to waterfall development.
Source: Based on “Personas” from Agile 2009
157
A bit more detailed persona give personality to User Roles, helping the Team & Product Owner relate better to them.
Personifying Your Users
Night Nurse
RobinRobin leaves for work at 6pm, after sleeping during the day. She works a 7pm-7am shift in Labor & Delivery, caring for prospective mothers and their babies. It is an uneven shift; sometimes chaotic and busy, sometimes slow. There are 16 other nurses in a given shift, and they coordinate their activities in a central room. Bad IT makes Robin grumpy.
• Needs to be based on study of human behavior
• Usability Testing
• Observation
• Interviews
• Surveys
• Empathy helps to guide design decisions
• Should not be taken too literally
ScrumMaster
159
A ScrumMaster:
• Removes barriers between development
and the customer so the customer drives
development
• Teaches customers how to maximize ROI
and meet their objectives through Scrum
• Enforces the values and practices of Scrum
• Improves productivity in any way possible
• Introduces engineering practices and tools to help ensure
that each increment is potentially shippable
ScrumMaster Responsibilities
160
The ScrumMaster or Agile Project Manager wants one one-hour weekly status meeting instead of daily 15 minute stand-ups because one meeting is “more efficient.”
What do you do?
What do you do?
161
Egoism: When a person acts to create the greatest good for himself or herself.
Utilitarianism: The idea that the moral worth of an action is determined solely by its usefulness in maximizing utility or minimizing negative utility.
Altruism: The opposite of egoism, a person’s primary purpose is to promote the best interests of others.
Ethical Leadership
Source: Based on Domains of Ethical Theories from Leadership Theory and Practice
162
Listening
Empathy
Healing
Awareness
Persuasion
Conceptualization
Foresight
Stewardship
Commitment to the growth of people
Building community
Servant-Leadership
163
ScrumMaster Encourages:• Forthrightness• Blameless observations• Failing & learning fast
ScrumMaster Discourages:• Defensiveness• CYA retrenching• Fear of failure
Failure – End, or Means?
164
• Ensure everyone is doing what they have agreed to do
• Facilitate Scrum sessions
• Look for ways to improve productivity and collaboration
• Assist the Product Owner with the Product Backlog
• Use all of your senses, including common sense, and remember that you have no authority
Typical ScrumMaster Activities
“A dead ScrumMaster is a useless ScrumMaster” - Ken Schwaber
165
• Can a ScrumMaster also be a team member?
• Can a ScrumMaster also be a product owner?
• What potential issues might arise from these scenarios?
Dialogue – Hats of the ScrumMaster
166
What are the key differences between “traditional” PMs and “Agile” PMs or ScrumMasters?
• What project activities does a traditional Project Manager typically handle?
• How are these different from the activities required of a ScrumMaster?
• Are there issues with wearing these two different hats?
Group Discussion – PM vs. SM
167
• Set the standard for the discussion.
• Make the environment a priority.
• Be mindful of timing issues.
• Articulate the purpose of the discussion and its significance to the group.
• Make use of various techniques/tools to keep the discussion moving when tension arises or discussion comes to a halt.
• Try using an Agile game like “speedboat”
• Pay attention to group behaviors.
• Be relaxed and have a sense of humor to make sure discussions are enjoyable as well as educational.
• Seek consensus with methods like dot voting or fist of five
Facilitation Methods
168
The goal is to identify factors that are preventing you from moving forward. In this case the sailboat represents your group or organization. The issues holding it back are symbolized by anchors. Anything propelling you forward is wind in your sails.
Consensus Workshop Method “Sailboat”
Based on Speedboat by Luke Hohmann of Innovation Games
169
1. Build the foundation• Establish ground rules, roles and responsibilities
• Frame the problem, constraints and desired outcome
2. Explore possibilities• Generate options
• Solicit expert opinions
• Storyboard potential solutions
3. Seek agreement• Show of hands
• Roman vote
• Fist of Five
• Multi-voting
Facilitating Group Decision Making
170
Face the speaker
Maintain eye contact
Minimize external distractions
Respond appropriately
Focus solely on what the speaker is saying
Keep an open mind
Avoid letting the speaker know how you handled a similar situation
Wait until they finish to defend yourself
Engage yourself
Active Listening
171
Emotional Intelligence
Unlike your Intelligence Quotient (IQ) which is pretty well fixed at an early age, your measure of Emotional Intelligence, or Emotional Quotient (EQ) can be easily developed throughout your life.
Personal Competencies Social Competencies
SELF-AWARENESSKnowing one's internal states, preferences, resources, and intuitions
EMPATHYAwareness of others' feelings, needs, and concerns.
MANAGING EMOTIONS Managing one's internal states, impulses, and resources.
SOCIAL SKILLS Adeptness at inducing desirable responses in others.
MOTIVATION Emotional tendencies that guide or facilitate reaching goals.
SelfAwareness
Self-Management
SocialAwareness
RelationshipManagement
With Others
Wh
at I
See
Wh
at I
Do
With Me
172
Five Levels of Conflict and ResolutionLevel 1: Problem to Solve
• The normal conflict that occurs when team members have differences of opinions but can work through those for the greater good of the team and project.
• Seek collaboration – Seek a win-win situation
• Consensus. Learning where every team member’s head is with regard to the issue and, in time, arriving at a decision everyone can back.
Level 2: Disagreement
• Personal protection trumps collaboration. Language is guarded and open to interpretation.
• Support – Empowering the other to resolve the problem.
Level 3: Contest
• The goal is to win. It is no longer about resolution but about coming out on top.
• Accommodate – Yielding to the others view when the relationship is more important than the issue. Negotiate and get factual. Gather data to establish the facts.
Level 4: Crusade
• The battle lines have been drawn and each “side” does not believe the other side will change.
• Focus on lowering the level of conflict. Use “shuttle” diplomacy and deescalate. Protecting one’s own group is the focus.
Level 5: World War
• It is not enough that the person wins but that they destroy the other person.
• Do whatever is necessary to prevent people from hurting one another. Source: Lyssa Adkins Coaching Agile Teams
173
• Analyze the situation.
• Differentiate between wants and needs – both theirs and yours.
• Focus on interests and issues rather than on positions.
• Ask high and offer low, but be realistic.
• When you make a concession, make clear you are yielding something of value. And don’t just give in.
• Always make sure both parties feel as if they have won. This is a win-win negotiation. Never let the other party leave feeling as if he or she has been taken advantage of.
• Do a good job of listening and articulating.
Negotiations
Source: PMI PMBOK® Guide 4th Edition Section G.8
174
1. The ScrumMaster (SM) removes __________ between development and the customer.
2. __________would not have been a very good ScrumMaster.
3. __________ are altruists 4. With level 1 conflict, we seek
__________ situation.5. When facilitating a group, a
ScrumMaster should ___________ a foundation, explore the possibilities, and __________ agreement.
6. You need to be __________of others' feelings, needs, and concerns to possess empathy.
ScrumMaster Review
a) Bill Lumburgh
b) barriers
c) build
d) seek
e) servant-leaders
f) win-win
g) aware
1(b) 2(a) 3(e) 4(f) 5(c)(d) 6(g)
The Team
176
Steps1. Intro + Rules
2. 2 minute prep time
3. Get an estimate
4. Create velocity chart
5. 2 minute iteration
6. 1 minute improvement & new estimate
7. Repeat 5 times
8. Retrospective
Collaboration Exercise
Rules:1. Start point = End point (person)
2. Process the most work possible
3. Balls must have air time when being passed
4. Balls may NOT be passed directly to your neighbor on the left or right
5. Balls must be touched by each and every person
6. Balls cannot be processed as one group (the bag/box)
7. Balls left on the floor at the end of an iteration are waste and will be subtracted from your production total
Thank you Scott Dunn, Boris Gloger
177
The inspect and adapt cycle can be used to improve a system of production.
A system has a natural velocity.
Velocity of a team stabilizes because of the team’s system and because the team learns how to work together.
Having a large team makes communication more difficult
If you want to go faster, you have to change the system.
Exercise - What did we learn?
178
Traditional Silos Customer BA Designer DeveloperPM
CoreTeam(EXAMPLE)
BA / Tester
BA
Tester
ProductOwner
Developer
Designer
Developer /BA
SM
ReleaseManager
CapacityPlanner
Prod.
Architect
TechOps
BusinessSponsor
RiskAssessor
Security
Extended Scrum Team
BAAnalystsDeveloperDeveloperDeveloper
Designers TesterTesterTestersDevs
The Core Team ideally consists of
5-9 dedicated members (7 +/- 2)
The Extended Team may contain many additional members, each
playing an important role, but they are typically not dedicated to
the effort.
ProductOwner
179
The analyst on the project wants to work one sprint ahead so that the analysis is ready when the programmers need it.
The tech writers want to work one sprint behind so that they are “more efficient.”
What do you do?
Team of Specialists
180
• Lazy Members – Not all team members will always be equal contributors. Focus on leveraging strengths, and encourage the team to help poor performers.
• Consensus Quagmires – Group decisions can benefit from perspective and suffer from dilution. Use facilitation techniques to foster rapid, inclusive decision making.
• Hero Culture – Teams must have shared goals, not be driven by individual desires. Roving leadership is an ideal state.
Common Team Dysfunctions
What are some other dysfunctions you’ve seen?
181
Provide Feedback You can’t expect your team to operate in a vacuum.
Recognize PerformanceGive constructive feedback so they can meet your expectations. Reinforce what you like so they can continue to meet those expectations or exceed them.
Team Motivation
NegotiateRecognize that some team members will not feel comfortable with some goals set for them. Negotiate realistic outcomes.
Persuade Get to know each of your team members personally and find out what motivates them.
RespectRespect is fundamental in any relationship. You will get the very best from people if you have mutual respect.
182
Discuss answers to the following questions:
• Have you ever been in a high-performance team?
• What characterized that experience?
• Could you replicate it effectively in Agile projects?
Dialogue – High Performance Teams
183
Self-organization refers to a process in which the internal organization of a system, normally an open system, increases automatically without being guided or managed by an outside source.
Self Organization
Source: Wikipedia
184
Self-organizing teams:• Exhibit a high degree of
collaboration
• Operate with a high degree of trust and autonomy
• Work towards high performance
• Produce measurably great results
• Are very fulfilling to work on
Self Organizing Teams
Self-Organizing Teams are Characterized by:
• Small team size
• Dedicated resources
• Customer value orientation
• Individual competence
• Sustainable self-discipline
• Intense collaboration
• Easy information transfer
• Low decision feedback time
• Constant learning &
interaction
185
Team Diversity
We want a broad model of diversity based on style,not just demographics• Change Readiness• Emotional Intelligence• Risk Aversion• Motivation• Work Style
We want diversity as expressed in outer rings
ValuesBeliefs
Risk AversionEmotional Intelligence
MotivationChange Readiness
ReligionCommunications Style
Work ExperienceGeographic Location
Family StatusEducation and Qualifications
AgeGender
RaceSexual Orientation
EthnicityMental AbilitiesPhysical Abilities
186
The Team• Works cross-functionally
(reduce handoffs !)
• Shares roles to get the work done (i.e. generalizing specialist)
Roles of the Team
• A developer may write user documentation• A business analyst may perform testing• A tester may create graphics
• Develops the detailed task list and the estimates
• Volunteers for work (is not tasked)
• Raises issues to the ScrumMaster
• Assesses performance and makes process recommendations
187
Self organizing principles guide a team so they can operate with minimal management controlo As a team member, I will contact the ScrumMaster if I see a tweak
that can be made to a feature, that will maintain it’s business value, while reducing time, cost or risk associated with implementing that feature
o As a team member, when I complete my work, on a task, I will either help another team member, or start a new task, depending on what will most likely allow us to deliver the maximum value in a Sprint
o As a team member, I will provide honest and open feedback to my peers, to the ScrumMaster, to the Project Manager, whenever that feedback will help the performance of the team
Self Organizing Principles
188
This is not a cross-functional team:
Teams are Cross-Functional
This is.
Coding Testing
Analysis Coding Testing
Analysis Coding Testing
Analysis Coding Testing
Sprint 2Sprint 1 Sprint 3 Sprint 4 Sprint 5
Coding
Analysis
Testing
Coding
Analysis
Testing
Coding
Analysis
Testing
Sprint 2Sprint 1 Sprint 3 Sprint 4 Sprint 5
189
• Common area for collaborationo Open flow of information
• Caves for privacyo Intense problem solving
o Creative solitude
o Private phone calls
o Research
o Rocking silently and weeping
Caves and Commons Layout
We all need a place to call home
Whiteboard Covered Wall
Burndown Chart
CubiclesCubicles
Information Radiator
190
• Information transfer maximized through collocation
• Constant face-to-face communication and collaboration
• Allows for Osmotic Communications
• Self-organization & management facilitated by information radiators
Shared Visual Workspace
191
• Project Charter
• Agile Manifesto
• Key Contact Information
• Project Calendar (vacations, etc.)
• Objectives, Outputs & Outcomes
• Success Sliders
• Scope & Objectives Chart
• Values/Rules of Engagement
• Team Norms
• System architecture diagrams
• Information architecture diagrams
• Burn Down Chart
• Other metrics
• Project Backlog and Timeline
• Current Iteration Story Cards & Tasks (Tasks, WIP, To Verify, Done)
• Risks & Issues Log
• External dependencies/groups
• Days left in Sprint/Iteration
• Various team personalization stuff
Information Radiator Examples
Information radiators communicate what’s important for your project; each team has unique needs. Some examples:
192
Team Room Examples
1. Portable easel2. Smart board3. Risks & Issues noted4. Magnetic whiteboard5. Plant needs water6. Task board7. Pair programming station8. Status tracking by color9. Nice chairs
193
Documents
Email & Portals
Phone &Instant Messaging
Video & Teleconferencing
Face-to-face
Communications BandwidthAgile workspaces & information radiators are designed to reduce miscommunications, assumptions and disconnects by maximizing communications bandwidth.
Unidirectional Activities Bidirectional Activities
194
Isolated Scrum TeamsIndependent Daily Scrums.
Distributed Scrum of ScrumsRegular Scrum of Scrums.
Integrated Scrum TeamTeam members split across locations.
Distributed Daily Scrum Models
Daily ScrumDaily Scrum
New York Mumbai
Daily ScrumDaily Scrum
Daily Scrum
Scrum ofScrums
195
• Ensure more frequent feedback with shorter iterations
• Use continuous integration, or at least regular builds
• Send ambassadors, maintain site liaisons
• Put phone/video/messaging communications technology to use
• Use wikis for common project info
• Use test scripts to understand requirements
• Separate teams by functionality, not technical specialty
• Expect more documents
Check out Martin Fowler’s article http://martinfowler.com/articles/agileOffshore.html#UseContinuousIntegrationToAvoidIntegrationHeadaches
Suggestions for Distributed Teams
196
1. The ideal agile team size is ___________ to ___________ people.
2. Agile teams embrace the concept of ___________ instead of specialization.
3. Sharing functional responsibilities may require changes in ___________ policies and compensation.
4. Most of the team members should be ___________ time members of the team.
5. A focus on ___________ typically results in staff members working across teams and projects, which greatly reduces productivity.
Team Review
a) nine
b) full
c) utilization
d) human resource
e) five
f) shared responsibility
1(e) (a) 2(f) 3(d) 4(b) 5(c)
The Scrum ProcessInitial Planning*
Product Backlog
Release Planning
Sprint Planning
Sprint Backlog
Sprint
Sprint Review
Daily Scrum
Sprint Retrospective
Initial Planning
199
DescriptionSeries of facilitated sessions to orient team members to the project’s business value and analytical background, the Agile process, and one another.
DurationAs long as it takes!
AttendeesTeam, Product Owner, ScrumMaster, SMEs
Initial Planning at a Glance
Outputs•Project Orientation•Process Orientation•Team Orientation
Initial Planning
200
Agile Process Training
Product Discoveryo Agile Games with Customers
o Collaborative Modeling Workshop
o User Story Creation and Estimation
o Product Backlog Prioritization
o System Design
o Architecture Spike
Project Discovery o Sponsor Vision
o Business Context, Key Metrics
o Release Planning
o Sprint One Planning
Comprehensive Sprint 0
Process Discovery
o Process Value Stream Map
o Key Metrics
Team Discovery
o Team Norms & Core Hours
o Iteration Structure
o “Ready” Definition
o “Done” Definition
o Business value prioritization scheme
o Team Structure (Core/Extended)
o Stakeholder/Project Interactions
Sample Sprint 0 Session(s) might include:
201
1. Sprint 0 ___________ explicitly part of the scrum framework.
2. The product owner, ScrumMaster, key sponsors, key stakeholders, the ___________ and select subject matter experts participate(s) in the discovery sessions.
3. Business stakeholders and sponsors provide a clearly articulated vision with cascading ___________ so that we can ___________ measure future success.
4. In addition to providing context for the product, discovery provides context around the project, ___________ and team .
5. We avoid BDUF design. Instead we define just enough today to maximize the chance that we can deliver value tomorrow, recognizing that if we get too ___________, too early, we will likely over ___________ the team and get a less valuable product.
Sprint 0 Review
a) goals
b) is not
c) objectively
d) process
e) whole team
f) constrain
g) specific
1(b) 2(e) 3(a) (c) 4(d) 5(g) (f)
Product Backlog
203
DescriptionList of desired functionality for project prioritized by business value by Product Owner.
Key Characteristics• Contains requirements as
“User Stories”
• Near-term stories better defined
Managed byProduct Owner, ScrumMaster
Product Backlog at a Glance
Contains• Prioritized Product Backlog Items or User Stories• Rough estimates• [Optionally] Forecasted iteration boundaries• [Usually] Release Dates
ProductBacklog
204
Adding User Stories
• Anyone can suggest new User Stories
• Product Owner prioritizes them
Estimating & Elaborating
• High-priority items are estimated and described most precisely, since they will be worked on first
• Low-priority items are generally estimated and described coarsely
Prioritizing
• Prioritization is based primarily on Business Value
Product Backlog Essentials
# Backlog Item Estimate
1 Create login screen .5
…
20 Allow user to browserecently viewed items
8
…
60 Add personalization 30 (or so)
High priority items are better defined
Low priority items are often “epics”
205
While business value should be the primary Product Backlog prioritization criterion in most cases, it isn’t the only one to consider. One might also factor in:
o Risk
o Complexity
o Demand
o Integration points from/to related projects or vendors
Backlog Prioritization: A Closer Look
Some Tips: Create a prioritization scheme and Release Schedule that maximize the benefit realized
from incremental releases. Ensure that business needs and technical ones are balanced openly and jointly.
206
1. The product backlog is essentially a ___________ to-do list.
2. A generic term for an item in the product backlog is ___________, a.k.a. PBI.
3. A PBI can be expressed in ___________ or other concise formats.
4. A PBI can be expressed in user story format even if it will take ___________ sprints to complete
5. PBIs can be at varying levels of detail, from an ___________ that can take several releases to finish, all the way down to a user story which can be completed in a single sprint.
6. High priority items are defined in ___________ than are lower priority items.
Product Backlog Review
a) epic or feature
b) never-ending
c) many
d) more detail
e) product backlog item
f) user story
1(b) 2(e) 3(f) 4(c) 5(a) 6(d)
Release Planning
208
DescriptionInitial project planning session, to review initial Product Backlog and define Releases.
Duration2-4 hours
AttendeesTeam, Product Owner, ScrumMaster
Release Planning at a Glance
Outputs• Release Plan• Refined Product Backlog
ReleasePlanning
209
• Present Business Case & Desired FeaturesProduct Owner describes vision for product and initial set of User Stories
• Estimate User StoriesTeam estimates high-level features in terms of story points or ideal delivery days
• Prioritize User StoriesProduct Owner assigns priorities based on business value
• Formulate Release ScheduleGroup User Stories into “minimum marketable feature sets,” set Release dates
Release Planning Sample Agenda
Some Tips: This meeting should revolve primarily around the Release Schedule Product Owners: Come prepared with an initially prioritized Product Backlog Team: Come prepared with initial estimates for Product Backlog items
210
Planning Releases with Story Maps
Time
Pri
ori
ty
• Choose coherent groups of features that consider the span of business functionality and user activities
• Support all necessary activities with the first release
• Improve activity support with subsequent releases
R1 S1 R1 S2
ProvideNurse ID
ProvidePatient ID
FilterRecords
SortRecords
SearchRecords
AddComment
ViewHistory
EnterUpdates
SearchHistory
ReferenceValidation
Notify ofUpdates
R2 S1 R2 S2
AccessRecord
ReviewRecord
UpdateRecord
211
1. The ___________ brings ___________ product backlog items to the release planning session.
2. The ___________ provide(s) estimates in ___________ for the user stories and other product backlog items.
3. Based on story point estimates and velocity projections, the product owner can segment out which user stories will go into which ___________, and, for high priority, near term product backlog items, even which ___________.
Release Planning Review
a) clearly articulated
b) story points
c) sprint
d) product owner
e) whole team
f) release
1(d) (a) 2(e) (b) 3(f) (c)
212
What are some Visual Management Systems?
• Outside of work, describe some visual control systems.
• Are there opportunities to use them at home or work?
Information Radiators - VMS
213
Information Radiators
1-J
un
3-J
un
5-J
un
7-J
un
9-J
un
11
-Ju
n
13
-Ju
n
15
-Ju
n
17
-Ju
n
19
-Ju
n
21
-Ju
n
23
-Ju
n
25
-Ju
n
27
-Ju
n
29
-Ju
n
Cumulative Flow,Burnups,
Burndowns…
are only the beginning
214
Burndowns can provide context to make tough decisions at both the sprint and release level
Burndowns to Provide Context
Product Owner Speaking
To date, we have completed feature 1 through feature 4.
Unfortunately, we lost several key members of our team during iteration 6 and we are unlikely to get all planned features done for this release, unless we execute with perfection, which is unlikely.
We will likely delay feature 9 and 10 until the next release, unless we make some tradeoffs.
We already started discussions with sales and marketing and we may limit our work on feature 5 and 6 in the next Sprint.
To Date
BacklogFeature 1Feature 2Feature 3Feature 4Feature 5Feature 6Feature 7Feature 8Feature 9Feature 10
215
1. Release level burn downs track story points
remaining for a release. Sprint burn downs
have historically tracked ___________
remaining on ___________. Some teams
today now burn down ___________ instead.
2. The primary purpose of the burndown is to
help teams face reality so that they can
make ___________.
3. Variations on a burn down can be used, such
as ___________ or a ___________.
Burndown Review
a) burnup
b) cumulative flow diagram
c) hours
d) story points
e) tasks
f) tradeoffs
1(c) (e) (d) 2(f) 3(b) (a)
Sprint Planning
217
DescriptionMeeting to elaborate, estimate and prioritize highest-value User Stories, creating Sprint Backlog.
Duration2-4 hours
AttendeesTeam, Product Owner, ScrumMaster, SMEs
Sprint Planning at a Glance
Outputs• Estimated & Prioritized User Stories• Acceptance Criteria for User Stories• Sprint Backlog with Tasks
SprintPlanning
218
• Product Owners should arrive prepared to discuss top priority stories and ask any questions regarding alternate development paths
• The Team may prepare estimates and questions about different development scenarios
• Acceptance criteria should be jointly discussed and clarified
• The length of the Sprint Planning session will generally be proportional to the length of the Sprint
Sprint Planning Essentials
219
1. The ScrumMaster should create a ___________ of events, holidays and team member schedules to support capacity planning and coordination
2. The ScrumMaster should evaluate velocity data to spot ___________.
3. At the beginning of sprint planning, team member availability for the sprint is confirmed. This information is combined with the historical velocity data to determine ___________ velocity for the sprint.
4. Team members ___________ for stories and tasks. ___________ are discussed to the extent necessary to allow the team to credibly commit to their completion within the sprint.
5. Some teams detail out all ___________ at Sprint Planning, others detail out just ___________ tasks, others create just a few chunky tasks, and some team don’t detail out tasks at all.
6. The ___________ determines which user stories it will commit to completing within the sprint.
Sprint Planning Review
a) trends
b) target
c) volunteer
d) calendar
e) high priority
f) team
g) tasks
h) user stories
1(d) 2(a) 3(b) 4(c) (h) 5(g) (e) 6(f)
Sprint Backlog
221
DescriptionList of desired functionality for development in the current Sprint.
Key Characteristics
• Contains User Stories estimated at task level
• Acceptance tests defined
Managed byTeam, ScrumMaster
Sprint Backlog at a Glance
Contains• Prioritized User Stories & their tasks• Task-level estimates• Information needed to understand the tasks
SprintBacklog
222
Physical Task Boards
223
1. ___________ user stories are selected
from the product backlog for inclusion in
the ___________.
2. The sprint backlog is essentially a
detailed, short term, ___________
covering items for the ___________.
3. The sprint backlog may be stored in an
electronic tool, a ___________ board, or
both.
4. ___________ may, or may not, be stored
in the sprint backlog.
Sprint Backlog Review
a) high priority
b) physical
c) sprint
d) sprint backlog
e) tasks
f) to do list
1(a) (d) 2(f) (c) 3(b) 4(e)
Sprint
225
DescriptionWhen the work gets done!
Duration1-4 weeks
Key Characteristics
• Isolated from further change
• Requirements elaborated and refined
• Work organized adaptively
InvolvesTeam, ScrumMaster, Product Owner, SMEs
Sprint at a Glance
Outputs• Potentially shippable functionality• Other items, as prioritized by Product Owner
Sprint
226
Effective Agile teams organize their work so that it flows:• Critical activities are never stalled by work on lower-priority activities (which
may or may not arise in a future Sprint)
• Decisions are made at the last responsible moment
• Hand-offs are minimized in favor of synchronized collaboration
Self-Organized Work Patterns
Coding & Refactoring
Business Analysis
Testing
Sprint 1
User Experience
Architecture or Risk “Spikes”
Sprint 2 Sprint 3
227
Do your teams work like Agile teams?
• Does collaboration happen often across roles?
• Are activities assigned explicitly, or pulled based upon skill and capacity?
• Do you have critical person dependencies?
• Is communication between team members open and regular, or formalized and occasional?
Dialogue – Teamwork
228
1. The length of the sprint is ___________.
2. The sprint contains four ceremonies:
___________, ___________, ___________
and ___________.
3. Some teams ___________ their release and
planning cycles. These teams often continue
to use a fixed sprint cycle to provide a
cadence for planning and retrospectives.
4. Backlog grooming (User Story maturity) for
future sprints happens ___________.
Sprint Review
a) daily scrum
b) decouple
c) fixed
d) sprint planning
e) sprint retrospective
f) sprint review
g) during the current sprint
1(c) 2(d) (a) (f) (e) 3(b) 4(g)
Daily Scrum
230
DescriptionBrief, tightly facilitated status and risk management meeting for Team & Product Owner.
Duration10-15 minutes
AttendeesTeam, ScrumMaster, optionally Product Owner and Interested Stakeholders
Daily Scrum at a Glance
Outputs• Risks & Issues• Informal meetings
DailyScrum
231
• Reference specific tasks (at the task board if possible)
• Record and Review Risks and Issues
• Team members should speak to one another; this is an alignment tool, not an exercise to report to the boss
Three Questions in Three Minutes
What will you get done today?2
What did you get done yesterday?1
What’s in your way?3
Each participant answers 3 questions:
232
Quick Quiz:Who maintains the team board?
Parameters
• Daily
• 10-15 minutes
• Everyone stands
• Risks & issues noted
• Not for problem solving!
• Additional meet-ups arranged, often immediately following the Daily Scrum
• Core team talks
• Extended team listens
Daily Scrum Essentials
233
Core / Extended Team
ScrumMaster/ Agile PM
Product Owner
CIO
QA Manager
Tester
Business Analyst
Developer
Daily Scrum – Quick Quiz
Quick QuizWho is allowed to talk at the Daily Scrum (Stand-up)?
234
Some key benefits of the Daily Scrum include:
• Shared language among team members
• Real-time reallocation of resources
Key Benefits of the Daily Scrum
• Focus on value-creating activities
• Clear, prioritized work plan for each day
• Builds team identity and emotional commitment
235
1. The daily scrum is often called a daily ___________.
2. The ScrumMaster can help make the daily standup effective by providing ___________ about schedules, days left in sprint, release date, etc., during the first 45 to 90 seconds.
3. The focus of the daily standup is to convey information so that the team can ___________ their collaboration.
4. The daily standup should last no longer than ___________ minutes.
5. At the daily standup the team members talk to ___________.
6. Detailed discussions and planning should occur ___________ the daily scrum.
Daily Scrum Review
a) 15
b) after
c) co-ordinate
d) context
e) each other
f) standup
1(f) 2(d) 3(c) 4(a) 5(e) 6(b)
Sprint Review
237
DescriptionTeam demonstrates completed functionality to interested stakeholders, gathering feedback.
Duration2-4 hours
AttendeesTeam, Product Owner, ScrumMaster, optionally Users & Interested Stakeholders
Sprint Review at a Glance
Outputs• New Features on Product Backlog• Reprioritized Product Backlog• Revised Team or Project Structure
SprintReview
238
Present Completed User StoriesDemo live functionality completed in prior Sprint; no decks!
Record Customer & User Feedback
Adjust Product Backlog
o Remove completed functionality
o Reprioritize unfinished functionality
o Adjust priorities based on feedback
Adjust Project Structure
o Reformulate or resize the team
o Schedule or reschedule a release
o Decide to stop the project
Sprint Review
239
1. Another name for a sprint review is a sprint ___________ .
2. The sprint review should start with ___________ including a discussion on overall release progress, plans for the just completed sprint and identification of important tradeoffs to discuss.
3. The product owner and team members demonstrate ___________ built during the sprint.
4. The sprint review is a forum for the team and stakeholders to understand what has been done, what is left to be done, and what is likely to be done, so that they can make tradeoffs. These tradeoffs will impact the upcoming ___________ meeting.
Sprint Demo Review
a) context setting
b) demo
c) sprint planning
d) working software
1(b) 2(a) 3(d) 4(c)
Sprint Retrospective
241
DescriptionTeam continuous improvement session to reflect on project & process issues and take action as appropriate.
Duration30 minutes – 1 hour
AttendeesTeam, ScrumMaster, optionally Product Owner
Sprint Retrospective at a Glance
Outputs• Process revisions• Project or Team structure revisions• Other improvement action items
SprintRetrospective
242
The useful way to do “Lessons Learned:”
• Periodically take a look at what is and is not working in your process
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• Generates action items to continuously improve project execution
Sprint Retrospective Essentials
Working Well Not Working Well
Automated unit testing
6am Daily Standup
Customers highly satisfied
Testing team availability
Retrospectives have improved process
Build cycle time
Estimates are stabilizing
Product Owner availability
Action Items
Set SLA with QAteam
PO delegates to proxy during Sprints
8am standup
243
Sprint Retrospective
244
Too often, companies focus too much attention on metrics like Team Performance and Team Efficiency, while ignoring metrics like Team Emotion or Happiness
Sprint Retrospective Team Emotion
245
1. The retrospective is often thought of as the
___________ part of the scrum process.
2. Effective retrospectives typically identify a
___________ of items to address.
3. At a minimum, a retrospective should
identify ___________ and ___________.
4. Additional items to cover in a retrospective
can include appreciations and ___________.
5. It is often helpful to collect ___________
feedback prior to the retrospective.
Sprint Retrospective Review
a) anonymous
b) deltas
c) learnings
d) most important
e) pluses
f) small number
1(d) 2(f) 3(b) (e) 4(c) 5(a)
Thank You!
247
Contact Us for Further Information
On the Web:LeadingAgile.com
Facebook: /LeadingAgile
Twitter: @LeadingAgile
Posters with images from presentation
TheCriticalPath.info & Pictofigo.com
Last Updated: 2/27/2015
248
Once this course has been completed:
• If you currently have a PMI credential (PMP or CAPM), you can submit 21 PDUs directly to PMI
• If you are pursuing the PMI-ACP and are applying for 21 Agile Contact Hours, you can submit this class under Agile Education
• If this is a public class, LeadingAgile will send you an email within 24 hours with a link to a PDF version of this deck
• LeadingAgile will send you a letter of completion within two business days
Logistics & Expectations
249
Hope is not a strategy Luck is not a factor
Fear is not an option
• At LeadingAgile, we are dedicated to solving the challenges associated with Agile in larger, more complex enterprises.
• We provide Agile training and coaching, strategic enterprise Agile transformation consulting, and Agile project and portfolio management services.
Specialties• Scrum, XP, AUP, RUP, Project Management, Program Management, Portfolio
Management, Agile Training, Agile Coaching, Agile Consulting, Agile Transformation