Agile Truths and Misconceptions Exposed

excella.com | @excellaco
Agile Truths
and
Misconceptions
Richard Cheng
Proprietary Material Provided for
Training Purposes Only
© 2018 Excella Consulting, Inc.

 Agile trainer & coach
 Director of Training
 CST, CSM, CSPO, CSP, PMI-ACP,
PMP, SAFe SPC, Certified LeSS
Practitioner, CAL 1, Certified Enterprise
Scrum Trainer, Training from the Back
for the Room Certified Instructor
 Background in Federal, commercial,
and non-profit Agile transformations
 richard.cheng@excella.com
Richard Cheng
@RichardKCheng

Agile is just a high level concept.
TRUTH!
Truth or Misconception

Process and tools
Comprehensive documentation
Contract negotiations
Following a plan
Designed to minimize risk and control change
“Traditional” IT Project Management

We are uncovering better ways of developing software by
doing it and helping others do it.
Through this work we have come to value:
Agile Manifesto
Individuals and interactions over Process and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the
left more.
http://agilemanifesto.org/

1. "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."
Principles Behind The Agile Manifesto:

Agile and Scrum are the same
thing
MISCONCEPTION!

Scrum – Iterative method used by most
teams
Kanban – A method derived from the Kanban
mechanism in Lean; often used in operations
XP – The software engineering practices
Agile Umbrella
Agile

Scrum Framework

Scrum is just mini-waterfall
MISCONCEPTION!

Scrum Overview
Product Vision
Roadmap
Day
Sprint…
…
…
Day
Day
Daily Scrum
Sprint
Idea
Initiation Release Release Release
Time

Building Microsoft Word

Scrum is always the best
approach
MISCONCEPTION!

Waterfall is based on Predictability
• Feedback is usually not attained
until late in the project
• Works best when all details are
known up front
• Change is expensive
Scrum is based on Adaptability
• Constant feedback
• Allows for discovery throughout the
lifecycle
• Provides infrastructure to support
and implement change
Scrum and Waterfall

• Simple projects don’t need Scrum
• The Complicated projects
benefits from Scrum to increase
certainty and agreement
• Scrum returns the biggest
process gains in the Complex
space
• In the Anarchy space, there is
high risk regardless of method
The Stacey Diagram
Ralph Stacey, Strategic Management and Organizational Dynamics
Technology
Requirements

The Certified ScrumMaster
(CSM) is the entry level Agile
and Scrum certification
TRUTH!

Scrum Alliance Certifications*
*From http://www.scrumalliance.org/certifications

1. Complete CSM course
2. Pass CSM test
1. Correctly answer 24 out of 35 questions
2. 60 minutes to complete
3. Combination of true/false and multiple choice questions
4. Two free attempts within 90 days of course completion
5. $25 for each additional attempt after the free period
3. Accept the license agreement
CSM Requirements

As a Certified Scrum Trainer, you’ll help others
understand the principles and values that form the
foundation of Scrum. You'll grow as an individual and
professional as you find creative ways to help
organizations, and your peers adopt this Agile
framework and capitalize on its benefits.
Scrum Alliance Certified Enterprise Coaches℠
(CECs) are Scrum experts in both theory and practice
that have an in-depth understanding of the practices
and principles of Scrum and real-world experience in
actual Scrum organizations. As a CEC, you will help
companies navigate the difficult process of becoming
an Agile organization.
A Certified Team Coach works with Scrum teams,
stakeholders, and management to improve
performance and outcomes. Unlike a ScrumMaster®,
a Certified Team Coach works across multiple teams.
And unlike a Certified Enterprise Coach, a Certified
Team Coach focuses on a subset of an organization
in a project or program, or across multiple teams.
Scrum Alliance Certifications*
*From http://www.scrumalliance.org/certifications

Scrum doesn’t work for Fixed
Date / Fixed Scope
MISCONCEPTION!
Truth or Misconception #5

Outcomes of Fixed Date / Fixed Scope projects:
• Waterfall
1. Delivered _____ and working ________
2. “Delivered” _____ … with ______
3. Cannot deliver on time, ______
• Scrum
1. Delivered _____ and working ________
2. The _____ items are _______ by the
requested date and working _______
Fixed Date / Fixed Scope

Outcomes of Fixed Date / Fixed Scope projects:
• Waterfall
1. Delivered on time and working as expected
2. “Delivered” on time … with issues
3. Cannot deliver on time, have to extend
• Scrum
1. Delivered on time and working as expected
2. The highest value items are delivered by the
requested date and working as expected
Be cautious of sacrificing quality to meet dates
Fixed Date / Fixed Scope

Delivery
0%
20%
40%
60%
80%
100%
1/1/2010
2/1/2010
3/1/2010
4/1/2010
5/1/2010
6/1/2010
7/1/2010
8/1/2010
9/1/2010
10/1/2010
11/1/2010
12/1/2010
1/1/2011
Work Completed
Work Remaining
Project Due Date

Agile Truths and
Misconceptions
Open Q&A

Excella Training
Training Courses
– Certified ScrumMaster (CSM)
– Certified Scrum Product Owner (CSPO)
– Advanced Certified ScrumMaster (A-CSM)
– Certified Scrum Developer (CSD)
– Certified Kanban Management Professional (KMP I and KMP II)
– Requirements Management - User Story workshop
– Certified Agile Testing and Automation
– DevOps Workshop
– Certified Agile Leadership 1 (CAL1)
See http://www.excella.com/training for more information

Certified Scrum Product Owner (CSPO)
• November 7 – 8, Blacksburg, VA
Advanced Certified ScrumMaster (A-CSM)
• November 19 – 20, Arlington, VA
Certified ScrumMaster (CSM)
• December 6-7, Blacksburg, VA
Certified Agile Leadership 1 (CAL1)
• December 17-18, Arlington, VA
See http://www.excella.com/training for full listings
Email training@excella.com for discount codes and more information
Upcoming Classes

Richard K Cheng
richard.cheng@excella.com
703-967-8620
http://www.linkedin.com/in/richardcheng
Twitter: @RichardKCheng
http://www.excella.com/training
Contact Information

Agile Truths and
Misconceptions
Supplemental

Exercise – Learning Objective
As a <your role / who>
I want <learning objective / what>
so that <value / why>

 Agile trainer & coach
 Agile Training, lead
 Member of PMI, Scrum Alliance, Agile
Alliance, Agile Leadership Network
 CST, CSM, CSPO, CSP, PMI-ACP,
PMP, SAFe SPC, LeSS Certified
Practitioner
 Founder & executive committee
member of Agile Delivery for Agencies,
Programs, and Teams (ADAPT)
 Background in Federal and commercial
Agile transformations
 richard.cheng@excella.com
Richard Cheng
@RichardKCheng

• 15+ years of experience in
software development
• Focused on Agile since 2006
• Agile readiness & maturity
assessments
• Agile coaching & mentoring
• Agile principles & software
engineering training
• Founder of the DC Software
Craftsmanship User Group
• Organizer of the DC Scrum User
Group
Fadi Stephan

 Class start time
 Lunch
 Class end time
 Breaks throughout
the day
 Tangents
 Words
Housekeeping
 Restrooms
 Parking lot
 Tabletop toys
 Name tags
 Opting out /
accessibility issues
 Skipping slides

 Parking validation
 Charging station
 Kitchen
Housekeeping at Excella’s ATX
 Wi-Fi
 Coat racks
 Office area and
conference rooms

1. Introduction
2. A Case for Agile
3. Agile Overview
4. Iterative & Incremental
5. Defined vs. Empirical
6. Scrum Framework
7. Scrum Roles
8. Scrum Teams
9. Product Backlog & Backlog Refinement
10.Product Backlog Items (PBI)
11. Product Increment and
Table of Contents
11. Definition of Done
12. Estimation
13. Sprint Planning
14. Task Board & Daily Scrum
15. Sprint Review & Retrospective
16. Burndown Charts
17. Scrum Review
18. Continuous Improvement
19. Closing Thoughts
20. Supplemental Material

20. References
21. Agile and EVM
22. Agile Engineering
23. Agile Dashboard
24. Kanban
25. More Metrics
Table of Contents – Supplemental
Material

Waterfall Development
Requirements
Design
Develop
Test
Deploy

IT Industry average success rate
Success rate ~___%
From 2010 report by The Standish Group
Industry Success Rate

Problems with Waterfall
Requirements
Design
Develop
Test
Deploy
“I believe in this concept, but the
implementation described above is risky
and invites failure”
- Dr. Winston Royce
Managing the Development of Large Software Systems, Winston Royce (1970)

Feature Usage in Software
• 20% of features always
or often used
• 60% of features never or
rarely used
Metrics based on Industry Studies
Never
45%
Often
13%
Sometimes
16%
Always 7%
Rarely
19%

• Project development is performed in 2 to 4 week sprints
• Product Owner creates an ordered backlog of Product
Backlog Items
• Highest priority items delivered first
• The team meets each day to assess progress
• At the end of the sprint, the deliverables are reviewed by
the business customers
• The team reflects on the process
• This is repeated until the project is completed
Scrum Overview

• Product Owner
• Responsible for drawing out the most valuable possible
product by the desired date
• Development Team
• Responsible for delivering the Product Increment
• Self-organize to accomplish the work
• Dedicated and cross-functional
• ScrumMaster
• “Servant Leader”
• Helps in resolving impediments
• Fosters self-organization
Scrum Roles Overview
http://agileatlas.org

• Product Backlog
• Ordered list of ideas, kept in order we expect to do them
• Single source from which all requirements flow
• Sprint Backlog
• List of refined Product Backlog Items chosen for development
in the current Sprint
• The team’s plan for the Sprint
• Reflects the team’s forecast of what work can be
accomplished
• Product Increment
• Meets team’s Definition of Done
• Accepted by Product Owner
• High enough quality to be given to users
Scrum Artifacts Overview

• Sprint Planning
• Determine what will be completed in the Sprint
• Determine how the work will be accomplished
• Daily Scrum
• Team uses Daily Scrum to ensure they are on track for attaining the Sprint goal
• Sprint Review
• Scrum team and stakeholders review the output of the Sprint (Product
Increment demo)
• Sprint Retrospective
• Review how things went with respect to the process, the relationships among
people, and the tools
• Product Backlog Refinement
• Refining the product backlog by adding, removing, re-ordering, splitting, or
merging product backlog items
Scrum Ceremonies Overview

Scrum Overview
Product Vision
Roadmap
Idea
Day
Sprint…
…
…
Plan
Day
Day
Daily
Scrum
Review
Retro
Sprint
Plan
Review
Retro
Initiation Release
Plan
Release Release
Plan
Plan
Time

Scrum Roles

• Organize yourselves into 3 teams
• Each team selects one Scrum role
(ScrumMaster, Product Owner, or Scrum
Development Team)
• For your role:
1. Write down 6 statements about the role you
selected
• At least 2 truths/facts
• At least 2 misconceptions/myths
2. Get ready to play Myth or Fact with the other teams
Exercise – Scrum Roles Myth or Fact

The Scrum Development Team
Function “The Implementers”
Responsible For “How are we going to deliver”
Artifact Sprint Backlog & Burndown
End product / result
Traits Cross functional & self-organizing
Know how best to accomplish their work
Have all skills needed to deliver business value
Responsibilities Tasking and estimation
Delivery of potentially shippable value

The Scrum Team

The Peripheral Team

• Cross Functional / Goal Oriented
• Well Defined Goals
• Clearly Defined Roles
• Fully Dedicated
• Co-Located
• Empowered & Authorized
• Self-Organizing
Performance Amplifiers

The Product Owner
Function “The Decider”
Responsible For “What are we delivering”
Artifact Product Backlog
Traits Single Person
Value focused
Voice of the business
Responsibilities Manage and order the backlog
ROI
Releases
Product development
Product vision

Product Owner needs to have
• Bandwidth
• Power
• Knowledge
• Interest
• Direction
Qualities of a Good Product Owner

An effective Product Owner has a strong
relationship with the Scrum Master and the
Scrum Development Team
“A good product owner should ensure your
questions are answered within 5 minutes 85%
of the time”
- Jim York
Qualities of a Good Product Owner

The ScrumMaster
Function “Servant Leader”
Responsible For “Are we getting better?”
Artifact None…and all
Traits Collaborative
Teaches and coaches, but does NOT manage
Responsibilities Enforces Scrum values, practices, and rules
Empowers the team
Removes impediments
Blocks distractions
Enables close cooperation across all roles and functions

• Mediation
• Communication
• Facilitation
• Negotiation
• Collaboration
• Servant Leadership
“A good Scrum Master is always on the verge of
being fired…..”
- Ken Schwaber
ScrumMaster Traits

1. How is the Product Owner doing?
2. How is the Team doing?
3. How are the Engineering Practices going?
4. How is the Organization doing?
ScrumMaster Checklist

• Is the Product Backlog prioritized according to his/her latest thinking?
• Are all the requirements from all stakeholders for the product captured in the emergent
backlog?
• Is the Product Backlog a manageable size?
• Could any requirements better implement the INVEST principle?
• Have you educated your Product Owner about technical debt and how to avoid it?
• Is the backlog an information radiator highly visible to all stakeholders?
• If you’re using an automated tool for backlog management, does everyone know how to
use it easily?
• Are you working with the tool supplier to use it to its fullest capacity, or to change it to
serve you better?
• Can you help radiate by showing everyone printouts?
• Can you help radiate by creating big visible charts?
• Have you helped your Product Owner organize backlog items into appropriate releases?
• Do all stakeholders (including the team) know whether the release plan still matches
reality?
• Did your Product Owner adjust the release plan after the last Sprint Review Meeting?
How is the Product Owner doing?
from ScrumMasterChecklist.org

• Are team members spending time in a “state of flow”?
• Do team members seem to like each other, goof off together, and celebrate each other’s success?
• Do team members hold each other accountable to high standards, and challenge each other to grow?
• Are there issues/opportunities the team isn’t discussing because they’re too uncomfortable?
• Have you tried a variety of formats and locations for Sprint Retrospective Meetings?
• Has the team kept focus on acceptance criteria?
• Does the Sprint Task list reflect what the team is actually doing?
• Are your team’s task estimates and/or your taskboard up to date?
• Are the team self-management artifacts (taskboard, Sprint Burndown Chart, etc.) visible to the team,
convenient for the team to use?
• Are these artifacts adequately protected from micromanagers?
• Do team members volunteer for tasks?
• Are technical debt repayment items (sapping your team’s velocity) captured in the backlog, or
otherwise communicated with the Product Owner?
• Are team members checking their job titles at the door of the team room?
• Does the entire team consider itself collectively responsible for testing, user documentation, etc.?
• Is management measuring the team by collective success?
How is the Team doing?

• Does your system in development have a “push to test” button so that anyone (same team or
different team) can conveniently detect when they’ve broken it?
• Do you have an appropriate balance between automated end-to-end system tests (a.k.a.
“functional tests”) and automated unit tests?
• Is the team writing both system “functional” tests and unit tests in the same language as the system
they’re developing?
• Has your team discovered the useful gray area between system tests and unit tests?
• Does a continuous integration server automatically sound an alarm within an hour (or minutes) of
someone causing a regression failure?
• Do all tests roll up into the continuous integration server result?
• Have team members discovered the joy of continuous design and constant refactoring, as an
alternative to Big Up Front Design?
• Does your definition of “done” (acceptance criteria) for each functional Product Backlog Item
include full automated test coverage and refactoring?
• Are team members pair programming most of the time?
How are the Engineering Practices
going?

• Is the appropriate amount of inter-team communication happening?
• Are your ScrumMasters meeting with each other, working the organizational impediments list?
• When appropriate, are the organizational impediments pasted to the wall of the development
director’s office? Can the cost be quantified in dollars, lost time to market, lost quality, or lost
customer opportunities?
• Is your organization one of the few with career paths compatible with the collective goals of your
teams? Answer “no” if there’s a career incentive to do programming or architecture work at the
expense of testing, test automation, or user documentation.
• Has your organization been recognized by the trade press or other independent sources as one of
the best places to work or a leader in your industry?
• Are you helping to create a learning organization?
How is the Organization doing?

Variations (don’t do these)
Team Members
ScrumMaster
Product Owner
Team Members
ScrumMaster
Product Owner
Team Members
ScrumMaster
Product Owner
Team Members
ScrumMaster
Product Owner
These make you slower
and increases risk

Product Backlog &
Backlog Refinement

Progressive Elaboration
Now
Later
Much
Later

• Single source of requirements
• Ordered list of features, functions,
requirements, enhancements, and fixes
• Backlog is emergent - is never complete
• Dynamic
• Constantly changes to identify product needs
• Frequently re-ordered
Product Backlog*
*from Scrum Guide

• Business value
• Risk
• Time sensitivity
• External dependency
• Necessity
Ordered

Product Backlog Refinement is an ongoing activity
throughout a Scrum project
• keeping the Product Backlog ordered
• removing or demoting items that no longer seem important
• adding or promoting items that arise or become more
important
• splitting items into smaller items
• merging items into larger items
• estimating items
Product Backlog Refinement*
*http://agileatlas.org/atlas/scrum#backlog-refinement

Product Backlog Refinement
PBI
PBI
PBI
PBI
Add
Split
Reorder
Remove
High priority
to
next Sprint
Granularity
Fine
Coarse
Product Backlog
Reorder

Product Backlog Items
(PBI)

• User Stories – a format for describing a
Product Backlog Item
• Simple, clear, short description of customer
valued functionality
• 3 parts*1:
• Written description used for planning
• Conversation to flesh out details
• Tests to determine completeness
• 3Cs*2 - Card, conversation, confirmation
User Stories
1- From Mike Cohn
2- From Ron Jeffries

New Hardwood Floor
As a homeowner,
I want a new hardwood
floor
so that my floors will look
like they did the day that I
bought the house
User Stories
As a [role],
I want [feature]
so that [business value]

Help define Done
Manage expectations
Lead to new requirements
Attributes:
• Objective
• Measurable
• Tangible
Acceptance Criteria
• Floor has a shine
• Minimal scratches
• Deep color

Help define Done
Manage expectations
Lead to new requirements
Attributes:
• Objective
• Measurable
• Tangible
Acceptance Criteria
• Brown
• Maple Rio Grande – 5in
• No scratches larger than 1in
• No more than 1 scratch per
sq foot

• Design document
• Detailed design document
• Specifications document
• Requirements Traceability Matrix
• Test plan document
• Wireframes
• Use cases
Spikes
Optional Additional Documentation

• Who?
• What?
• Why?
• Acceptance Criteria?
• How?
Who owns this?
As a [role/who],
I want [feature/what]
so that [value/why]
In the items below:
• One is owned by the Scrum Development Team
• Two are owned and from the Product Owner perspective
• Two, while technically owned by the PO, often is a collaboration
between the PO and the Scrum Dev Team

Vertical Slicing
User Story 1 User Story 2 User Story 3
Database
Business Logic
Web Interface
Client application

Roadmap/Epics/PBIs
Project Vision
Roadmap (w/ one or more Themes)
Epic
PBI PBI PBI
Epic
PBI PBI
Epic
Roadmap
Epic Epic
Roadmap

Theme/Epic/User Story/PBI
Theme
Epic
PBI
PBI
Epic PBI
Task
Task
Task
Task

Example

Product Increment &
Definition of Done

• Product of every Sprint
• Produced iteratively and incrementally
• Includes functionality of all previous increments
• Is fully tested
• Is of high enough quality to be “potentially
shippable”
• Acceptable by the Product Owner
• Meets the team’s current Definition of Done
Product Increment

• Project understanding
• Team agreements
• Definition of Done
When the Product Increment is delivered, it needs to
be "done" according to a shared understanding of
what "done" means.*
Team Charter
*from the Agile Atlas, http://agileatlas.org/atlas/scrum#product-increment

• DoD is a checklist of valuable activities
required to produce software.
• DoD is the primary reporting mechanism for
team members.
• DoD is informed by reality.
• DoD is not static.
• DoD is an auditable checklist.
Definition of Done*
*from Dhaval Panchal, http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod

Continuously Improve DoD
All Code
Checked-in
Unit Tests
Passing
Help Text
Updated
Acceptance
Criteria
Passing
Integration
Test
Passing
Performance
Test Passing
With a PBI
With a Sprint
With a Release
Security
Audit
Passing
Regression
Test
Passing
ContinuousImprovement

Definition of Done
Definition of Done for the PBI
Security
Testing
Browser
Tested
Stress
Testing
Acceptance
Criteria
Definition of Done for the Sprint
Definition of Done for the Release
Unit Tested
Stakeholder
Review

Definition of Done
Definition of Done for the PBI
Definition of Done for the Sprint
Definition of Done for the Release
Security
Testing
Browser
Tested
Stress
Testing
Acceptance
Criteria
Unit Tested
Stakeholder
Review

Estimation

• Who provides your estimates?
• Who commits to the estimates?
• What units do you use for your estimation?
Estimation

Exercise – The Estimation Game

• Confirm estimates by comparing the story to
multiple other stories.
• Group like-sized stories together
Affinity Based Estimating
Story A
L
M
S
Story C Story
D
Story
F
Story
B
Story
E

• Story Points represent the relative effort needed to
complete a story
• This should factor in volume of work, complexity,
and risk of unknown
• Story Points use a rough order of magnitude scale:
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, inf.
• Story size should be relative to each other.
Story Points

• A Wide Band Delphi based approach to group
estimation
• Each team member concurrently and
independently provides an estimate on a story
• Outlier are discussed until consensus is
reached
• Helps team reach common understanding of
the work
Planning Poker

• Fast techniques
• Increases accuracy
• Builds understanding
• Drives commitment
• Provides data points
Story Points and Planning Poker

Sprint Planning

• Meeting to flesh-out and estimate highest
business value stories from product backlog
• Generate Sprint backlog
• Determine
• What will be delivered
• How will it be achieved
• Two hours or less per week of Sprint
duration
Sprint Planning

• Part 1
• Determine sprint goal
• Discuss and elaborate high priority stories
• Finalize acceptance criteria
• Provide high level estimate
• Part 2
• Task out each story
• Provide a more detailed estimate
• Ask for further clarification
• Commit to achieving sprint goal
Sprint Planning

• Refined Product Backlog items
• Team’s plan to accomplish the work
• PBIs broken into tasks
• Reflects team’s forecast of what can be
accomplished
Sprint Backlog

Task Board
Story Task In Progress To Verify Done
User
Story
User
Story
User
Story
Task Task Task
Task Task
Task Task Task
Task Task

Task Board &
Daily Scrum

Task Board
Story Task In Progress To Verify Done
User
Story
User
Story
User
Story
Task Task
Task Task
Task Task Task
Task Task
Task

Exercise – Task Board

• Three questions:
1. What did I do yesterday that helped the Development Team
meet the Sprint Goal?
2. What will I do today to help the Development Team meet the
Sprint Goal?
3. Do I see any impediment that prevents me or the Development
Team from meeting the Sprint Goal?
• The daily scrum is held by the team for the team
• Product Owner optional (based on team needs)
• Time after Daily Scrum is great for ad-hoc meetings
• 15 minutes or less
Daily Scrum

Exercise – Dysfunctional Scrum

Sprint Review &
Retrospective

• Development team presents the Product
Increment
• Product Owner, stakeholders, and SMEs reviews
the product
• Feedback gathered from PO, stakeholders, and
SMEs
• Feedback is later processed by PO
• Product backlog and release plans updated
• One hour or less per week of Sprint duration
Sprint Review

• Goal – improve the process
• What went well?
• What could be better?
• Scrum Development Team, ScrumMaster,
Product Owner (optional, but recommended)
• Facilitated by the ScrumMaster
• Actionable outcomes
• Follow-up on previous retrospectives
• 45 minutes or less per week of Sprint duration
Retrospective

Agile Truths and Misconceptions Exposed

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agile Truths and Misconceptions Exposed

Similar to Agile Truths and Misconceptions Exposed (20)

More from Richard Cheng

More from Richard Cheng (20)

Recently uploaded

Recently uploaded (20)

Agile Truths and Misconceptions Exposed

Editor's Notes