Fundamentals of Agile Methodologies - Part I

Fundamentals of
Agile Methodologies - I
Compiled By:
Dr. Gopinath Ramakrishnan
Agile Coach & Process Transformation Specialist
Contact Information:
e-mail: gopi@rgopinath.com
LinkedIn: www.linkedin.com/in/gopinathr
Twitter: @gpnth
Website: www.rgopinath.com

Note
The contents of the following slides are
compiled from public domain works of
several persons/ organizations.
Their contribution is gratefully acknowledged
their copyrights and trademarks are
duly recognized.

Acknowledgements
• Agile 42: www.agile42.com
• Agile Alliance: www.agilealliance.org
• Agile Transformation Inc: www.agiletransformation.com
• Dzone: www.dzone.com
• Gear Stream: www.gearstream.com
• Henrik Kniberg: www.crisp.se/henrik.kniberg
• Jeff Sutherland : scrum.jeffsutherland.com
• Ken Schwaber: kenschwaber.wordpress.com/
• Kent Beck: www.threeriversinstitute.org
• Mike Cohn: www.mountaingoatsoftware.com
• Pete Deemer: www.goodagile,com
• Roman Pichler: www.romanpichler.com
• Ron Jeffries: xprogramming.com
• Scrum Alliance: www.scrumalliance.org
• Scrum.org: www.scrum.org
• Wikipedia: www.wikipedia.org

Contents
1. Overview of Agile
 Limitations of Traditional Software Development
 Origin of Agile Methodologies
 Agile Manifesto, Principles & Practices
 Agile Vs Traditional Methods
 So What is Agile ?
2. Overview of Scrum
 Empirical Process Control
 Scrum Lifecycle & Framework
 Scrum Roles
 3 Pillars of Scrum
 Transparency , Inspection and Adaptation
3. Product Vision and Product Roadmap
 Five Levels of Planning
 Product Vision – Example & Template
 Product Roadmap – Example & Template

Contents (contd..)
4. Release Planning
 Product Backlog – Examples and Attributes
 Product Backlog Creation Steps
 User Stories – Writing, INVEST criteria, Splitting
Techniques
 User Story Estimation – Story Points, Planning Poker
 Product Backlog Prioritization and Ordering
 Release Plan Creation

1: Overview of Agile
Limitations of Traditional Software Development
Origin of Agile Methodologies
Agile Manifesto, Principles & Practices
Agile Vs Traditional Methods
So What is Agile ?

Software Development - 1970s
• Cowboy Coding (Adhoc Code & Fix approach)
 Project Failures
• Computing Time Costly
 Failure Not an Option
• Birth of Software Engineering Discipline
(c) Dr. Gopinath Ramakrishnan, 2015

Software Engineering Discipline
• Software Development Lifecycle (SDLC)
models
– Waterfall, V-Model, Spiral, Incremental, Iterative
• Standards & Process Frameworks
– DOD Standards, CMM, ISO, SPICE

Traditional SDLC– Waterfall Model
Source : http://commons.wikimedia.org/wiki/File:Waterfall_model.svg
SDLC – Software Development Life Cycle

Traditional SDLC - Limitations
• Change Management difficult
• Heavy Documentation not read and
understood
• Big Upfront Planning cannot predict
uncertainties
• Hand-offs foster adversarial relationship
• Late Availability of Working Software leads to
delayed customer feedback

Business Scenario – 1990s onwards
S ource : http://www.stratabridge.com/wp-content/uploads/2012/02/VUCA-Definition.jpg

Standish Group – CHAOS Report 1994
• 84 % Projects Challenged or Failures
– Only 16 % Projects Successful
• Top Reasons for Failure
– Incomplete Requirements
– Lack of User Involvement
– Lack of Resources
– Unrealistic Expectations
– Lack of Executive Support

Emergence of Lightweight
Methodologies
• 1992 – Crystal Methods
• 1994 – DSDM (Dynamic Systems Development
Method)
• 1995 – Scrum
• 1997 – FDD (Feature Driven Development)
• 1999 – ASD (Adaptive Software Development),
XP (Extreme Programming)

Feb 11-13, 2001 - 17 Thought Leaders
@ Snowbird Ski Resort, Utah
http://setandbma.wordpress.com/2012/03/23/agile-history

Agile Manifesto –
Values & Principles

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

Source :http://cdn.dzone.com/static/images/mails/agileposter-v3a.jpg

Source:
http://www.lynnecazaly.com.au/the-visual-agile-manifesto/

12 Agile Principles
1. Customer Satisfaction
2. Welcome Changing Requirements
3. Deliver Working Software Frequently
4. Business People and Developers to Work Together
5. Motivated Individuals
6. Face-to-Face Conversations
7. Working Software is the Primary Measure of Progress
8. Sustained Pace of Development
9. Technical Excellence and Good Design
10. Simplicity is Essential
11. Self-organizing Team
12. Regular Tunings and Adjustments of Team Behavior

Agile Vs Traditional Methods
Traditional Method Agile Method
Changes Resisted and Controlled Welcomed and
Adapted to
Contracts Binding Flexible
Customer Interaction During selected
milestones
Continuous
Delivery One-time Iterative and
Incremental
Orientation Process People
Process Heavyweight Lightweight
Requirements
Architecture & Design
Defined Upfront Evolves
Roles More Less
Success Criteria Conformance to the
Requirements
Business value delivered
to the customer

Waterfall Projects Vs Agile Projects

Project Success Scenario in 2009
• Standish Group - CHAOS Report 1994
– Only 16 % Projects Successful
• Standish Group - CHAOS Report 2009
– 32 % Projects Succeeded
• Project Success Rate doubled in 15 years
• Coincides with the Agile emergence
• Still a long way to go !

Agile projects -
3 times more successful
Source : http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-
more-often-than-waterfall

Agile Methodologies - Characteristics
• Business Value Focus
• Iterative
• Incremental
• Time-boxed
• Feedback

Agile Methodologies
Source: http://www.slideshare.net/RichardPDoerer/what-isagile-henrik-kniberg-august-20-2013

Agile is….
• A set of Engineering Practices that
– enable rapid delivery
• Project Management that
– encourages frequent inspection and adaptation
• A Business Approach that
– aligns development with customer needs and company
goals
• Leadership that encourages
– teamwork, self-organization and accountability
• A set of Values and Principles that should be
– internalized by every Agile Practitioner

2: Overview of Scrum
Empirical Process Control
Scrum Lifecycle & Framework
Scrum Roles
3 Pillars of Scrum
Transparency , Inspection and Adaptation

Source: http://www.slideshare.net/gamsjo/empirical-processcontrol
Assembly Line Manufacturing Research and Development

ource: http://www.slideshare.net/gamsjo/empirical-processcontrol

Empirical Process Control
• Knowledge comes from experience
• Making decisions based on what is known.
• Iterative & Incremental approach
– to optimize predictability and control risk.
• Empirical Process Control Theory is the
foundation of Scrum

Scrum
Cancel
Gift wrap
Return
Sprint
2-4 weeks
Return
Sprint goal
Sprint
backlog
Potentially shippable
product increment
Product
backlog
CouponsGift wrap
Coupons
Cancel
24 hours

Putting it all together
Image available at
www.mountaingoatsoftware.com/scrum

Sequential vs. overlapping
development
Source: “The New New Product Development Game” by Takeuchi and
Nonaka. Harvard Business Review, January 1986.
Rather than doing all of
one thing at a time...
...Scrum teams do a little of
everything all the time
Requirements Design Code Test

No changes during a sprint
• Plan sprint durations around how long you can
commit to keeping change out of the sprint
Change

Scrum framework
•Product owner
•ScrumMaster
• Development Team
Roles
•Sprint planning
•Daily Scrum
•Sprint review
•Sprint retrospective
Ceremonies
•Product backlog
•Sprint backlog
•Increment
Artifacts

Scrum framework
•Sprint planning
•Daily scrum meeting
•Sprint review
•Sprint retrospective
Ceremonies
•Product backlog
•Sprint backlog
•Increment
Artifacts
•Product owner
•ScrumMaster
• Development Team
Roles

Product owner
• Define the features of the product
• Make scope vs schedule decisions
• Be responsible for the profitability of the
product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as
needed
• Accept or reject work results

The ScrumMaster
• Responsible for enacting Scrum values and practices
• Removes impediments
• Coaches the team to their best possible performance
• Ensure that the team is fully functional and
productive
• Enable close cooperation across all roles and
functions
• Shield the team from external interferences

The Development Team
• Typically 5-9 people
• Cross-functional:
– Programmers, testers, user experience designers, etc.
• Members should be full-time
– May be exceptions (e.g., database administrator)
• Teams are self-organizing
– Ideally, no titles but rarely a possibility
• Membership should change only between sprints

Source: http://www.adventureswithagile.com/empiricism-and-complexity-in-software-development/

Transparency
• Significant aspects of the process visible
– to those responsible for the outcome
• Aspects be defined by a common standard
– to share a common understanding
• For e.g.
– A common language referring to the process
– A common definition of “Done”1

Inspection
• Frequently inspect to detect undesirable
variances
– Not so frequent to get in the way of the work
– Most beneficial when diligently performed by
skilled inspectors at the point of work.

Adaptation
• Adjustment of the process or the material being
processed if
– one or more aspects of a process deviate outside
acceptable limits, and
– that the resulting product will be unacceptable
• Made as soon as possible
– to minimize further deviation.
• Four formal opportunities in Scrum for inspection
and adaptation
– Sprint Planning Meeting , Daily Scrum , Sprint Review
Meeting , Sprint Retrospective

Scrum - Summary
© 2010 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde
http://www.goodagile.com/scrumprimer/scrumprimer.pdf

3: Product Vision and Roadmap
Five Levels of Planning
Product Vision – Example & Template
Product Roadmap – Example & Template

Product Vision and Product Roadmap

Product Vision
• Visualizes the Released Product
• Guides Product Development
• Overarching Goal that Everyone Shares

Product Vision (contd..)
• Who is the target customer?
• What customer needs will it solve?
• What are its critical attributes?
• What are its unique selling points?

Example- Silicon Graphics
Workstations
For movie producers and others
who depend heavily on post-production special effects
the Silicon Graphics is a range of workstations
That have capabilities to integrate digital fantasies with
actual film footage.
Unlike other general purpose computer workstations,
Our products are a no-compromise commitment to
meeting film makers' post-production needs
[Adapted from Geoffery Moore’s example in the book Crossing the Chasm]

Product Vision - Template
For <target customer>
Who <statement of the need or opportunity>
The <product name> is a <product category>
That <key benefit, compelling reason to buy>
Unlike <primary competitive alternative>
Our product <statement of primary
differentiation>
[Geoffery Moore’s in the book Crossing the Chasm]

Product Roadmap
• High-level strategic plan providing longer-
term outlook
• Helps to secure funds
• Sets expectations
• Aligns stakeholders
• Facilitates prioritization & coordination
• Provides Reassurance to the Customers

Product Roadmap (contd..)
• Names of the releases planned
• Dates/ timeframes of releases
• Goals of each release
• Key features of each release
• Release Success Criteria

Example – Product Roadmap of a
Dance Game
• A dance game for girls aged eight to 12 years.
• Fun and educational
• Allows the players to
– modify the characters
– change the music
– dance with remote players
– choreograph new dances.

http://www.romanpichler.com/tools/product-
roadmap/

Example – Product Roadmap of a Dance Game (contd..)
http://www.slideshare.net/romanpichler/agile-product-roadmap-tutorial

4: Release Planning
Product Backlog – Examples and Attributes
Product Backlog Creation Steps
User Stories – Writing, INVEST criteria, Splitting Techniques
User Story Estimation – Story Points, Planning Poker
Product Backlog Prioritization and Ordering
Release Plan Creation

Product Backlog
• A Single, Transparent and Official List of
Requirements or Pending Activities
• Maintained by Product Owner
• Continuously Evolves throughout the product
lifecycle
– depending on changes in business requirements,
market conditions, or technology

Product Backlog Items (PBIs)
• Customer-centric Features
– Epics and User Stories
• Technical Improvements
– Refactoring, Performance improvements
• Research Work (aka Spikes)
– the ones needed for implementing features
• Known Defects
– only if they are few in numbers

PBIs - Examples
Source : http://www.goodagile.com/scrumprimer/scrumprimer.pdf

Product Backlog – Attributes
Detailed Appropriately
Estimated
Emergent
Prioritized
Source:
Agile Product Management, Roman Pichler

Product Backlog Creation Steps
• Write User Stories and other PBIs
• Prioritize/Order based on business value
• Split/Slice the Epics (Big PBI)
• Estimate PBI size (relative estimation)
• Evaluate risks and dependencies
• Determine the order of development

Product Backlog Creation -
User Story Writing

Epic
• Large Feature/Functionality in the Product
Roadmap
• Too big to be DONE in one sprint
• To be broken down into smaller
features/functionalities (User Stories)

User Story
• A smallest piece of Functionality from the User
Perspective that can be DONE in one sprint
– DONE means potentially releasable condition
• Has Business Value
• Description has 3 Parts
– User (Who ?)
– Functionality (What?)
– Business Justification (Why ?)
• Must be accompanied by an Acceptance Criteria

User Story Acceptance Criteria
• Conditions that a story must satisfy to be
accepted by PO
• A set of statements, each with a clear pass/fail
result, that specify both functional and non-
functional requirements

User Roles
• Recognize and Explicitly Identify Multiple User Roles
• Avoid the word “User” in the Stories
• Don’t Write Stories from a single User Role Perspective

User story format
As a <User>
I can <Functionality>
so that <Business Justification>

User Stories – Acceptance Criteria
• An Example

User Story – Review Criteria
Source: www.gearstream.com

User Stories - INVEST
• Independent
– Should be possible to implement in any order
– Should not overlap each other
– Example
Image Source: www.gearstream.com

User Stories – INVEST (contd..)
• Negotiable
– Should be descriptive, not prescriptive
– Not exhaustive
– Should stimulate conversation between the team
and the Product Owner or Customer
– Example
• As a book-lover, I want to download a new book so that
I can save time going to a bookshop

• Valuable to Users or Customers
– Should have clear external value
Does not describe the value to the customer
Written from developer perspective
Image Source: www.gearstream.com

• Estimatable
– Should be descriptive enough to be estimated
• Small
– Should require no more than 4 days and no less
than ½ day of work to implement
• Testable
– Should be able to prove that it is truly DONE
– Acceptance Criteria is defined

INVEST - Summary
Source: http://www.slideshare.net/thomasjeffreyandersontwin/lean-agile-stack-training-kanban-scrum-user-stories

Good Acceptance Criteria
• State an intent not a solution
– e.g. “The user can choose an account” rather than
“The user can select the account from a drop-down”
• Are independent of implementation
– discuss WHAT is expected, and not HOW the
functionality will be implemented
• Are relatively high level
– more details (if needed) are captured in team
member’s internal notes or in automated acceptance
tests

Product Backlog Creation -
User Story Splitting/Slicing

Why Split User Stories ?
• To create smaller stories that are
potentially shippable by the end of a sprint
• More focus
• Flexibility to reconfigure and adapt to new
discoveries and changes
• More feedback opportunities

User Story Splitting - Horizontal
http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake

User Story Splitting - Vertical
http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake

User Story – Basis of Various Splitting
Techniques
• Requirements Options
– Ellen Gottesdiener & Mary Gorman
• Incremental build up of quality
– Gerard Mezzaros and Jeff Patton
• Nine Patterns of Functional Complexity
– Richard Lawrence
• Twenty Ways based on Big Picture, User Experience, “illities”, and
Features
– Bill Wake
The above techniques have overlaps and are not mutually exclusive

User Story Splitting –
Requirements Options
Source: “Slicing Requirements for Agile Success”, Ellen Gottesdiener and Mary Gorman , Better Software , July/August 2010

© Jeff Patton, all rights reserved, www.AgileProductDesign.com
User Story Splitting – Incremental build
up of quality
• Bare Necessity
– For the feature to be minimally demonstrable – but not releasable, what is the minimal
functionality
– Example: A form with only necessary fields and no validation
• Capability & Flexibility
– What would add the ability to perform the user task in different ways? Adding in sub tasks
that are optionally performed?
– Example: a form with optional fields, date lookup tools, input translation on dates
• Safety
– What would make this feature safer for me to use? For both the user, and for the business
paying for the software?
– Example: input validation, enforcement of business rules such as credit card validation
• Usability, Performance, Jazziness
– What would make this feature easier to use? More desirable to use? Faster to use?
– Example: auto-completion, jazzy visual design, speed keys
•Adapted from Gerard Meszaros’ “Storyotypes” in
http://www.agileproductdesign.com/downloads/patton_user_story_mapping.ppt(c) Dr. Gopinath Ramakrishnan, 2015

User Story Splitting –
Functional Complexity Patterns
• Workflow steps
• Business rule variations
• Major effort
• Simple/complex
• Variations in data
• Data display /entry methods
• Defer performance
• Operations (e.g. CRUD)
• ‘Spike’ it
Source:
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-
user-stories

User Story Splitting – Twenty Ways
Source :Bill Wake, http://xp123.com/articles/twenty-ways-to-split-stories

Product Backlog Creation - User
Story Estimation

User Story Estimation
• Estimation Unit – Story Point (SP)
• Basis of Estimation
– Size,
– Complexity
– Uncertainty
– Effort
• Estimation Scale
– 1, 2, 3, 5, 8, 13, 20 ,40, 100
• Relative Estimation
• Collaborative & Consensus Based

Estimation Techniques
• Planning Poker
• Affinity Sizing
• Complexity Buckets

Planning Poker
• Estimation from Multiple Perspectives
• Discussion Oriented
• Fun
Image Source : https://www.crisp.se/bocker-och-produkter/planning-poker

Affinity Sizing/Triangulation of
Estimates
For e.g. An User Story of 2 SPs must be roughly twice as big/complex as an User Story
of 1 SP and less than half as big/complex as an User Story of 5 SP
Source: Agile Estimation and Planning by Mike Cohn

Story Point Estimates - Benefits
• A pure measure of size
– Easier to provide relative estimates
• Estimates do not change
– when team’s understanding of the technology
and the domain improves
• Estimating process help in driving cross-
functional behavior
– During estimation all specialists discuss and arrive
at a single story point estimate

Product Backlog Creation –
Prioritization / Ordering

Product Backlog –
Prioritization/Development Order Criteria
• Business Value
• Risks
• Size/Complexity
• Infrastructure needs
• Dependencies
• Return on Investment
• Grouping based on ease of development

Release Plan
• Maps Major Features to Specific Releases
• More Detailed than Product Roadmap, Less
Detailed than Sprint (Iteration) Plan
• Continuously updated based on rate of
progress

Velocity
• Measure of Rate of Progress
• Sum of Story Points of the Stories DONE in an
iteration
• Story Points of the Work-in-Progress Stories
not counted
• Useful for Forecasting
– Final Delivery Dates for a Fixed Scope of Features
– Features that can be delivered on a Fixed Date

Estimating Velocity
• Use Past Data
• Run an Iteration and Use the Velocity of that
Iteration
• Take a Guess

Release Planning Steps
• Select Iteration Length : 2-4 weeks
• Estimate Iteration Velocity
• Allocate Stories to Iterations as per Priority
and Velocity

Release Plan – An Example
Source: www.gearstream.com

Fundamentals of Agile Methodologies - Part I

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Fundamentals of Agile Methodologies - Part I

Similaire à Fundamentals of Agile Methodologies - Part I (20)

Dernier

Dernier (20)

Fundamentals of Agile Methodologies - Part I