Intro to Agile Software Development - DMH Distribution

DMarkHaynes Consulting
5/12/2016dmarkhaynesconsulting@gmail.com (734) 474-3303 1
Copyright © 2016 [Donald Mark Haynes]. All Rights Reserved.
 Project
Management
 Quality
Assurance
 Software
Estimation
 Process
Improvement
s
Providing IT Services for:
Agile/Scrum
Rational
Unified Process
(RUP)
Waterfall
Methodologies
Logistics
Health-care
Insurance
Automotive
Telecom
Marketing
Financial

Introduction to Agile/Scrum
Presented by D. Mark Haynes – Project Manager, Scrum
Master, QA Manager

Introduction
Scrum
Agile Requirements
Agile Estimation
Release Planning
A Few Agile Metrics
Why Use Agile?
Closing Thoughts
Appendix
Agenda
Copyright © 2016 [Donald Mark Haynes]. All Rights Reserved. 5/12/2016dmarkhaynesconsulting@gmail.com (734) 474-3303
3

1940s - Edward Deming - Plan-Do Study-Act cycle
1950s – X-15 hypersonic jet applied Iterative,
Incremental Development (IID)
1970 - Royce initiates Waterfall but recommends IID
1985 – Boehm publishes A Spiral Model of Software
Development
1986 – Scrum developed by Schwaber & Sutherland
1996 – Rational Unified Process created
1999 – Extreme Programming Explained published
2001 – Agile Alliance group formed
Introduction
A Brief History of Agile
Copyright © 2016 [Donald Mark Haynes]. All Rights Reserved. 5/12/2016dmarkhaynesconsulting@gmail.com (734) 474-3303
4

Agile Manifesto

Agile Defined
Group of software development methodologies
Promotes self-organizing, & cross-functional
teams
Development is cyclic and incremental
Testing is performed continuously
Early delivery of product
Processes & solutions are continuously evolving
Rapid & flexible response to changes

What’s the Difference?
Encourages tightly integrated teams
Requires greater user interaction with teams
Focus is flexibility, over economies of scale
Teams embrace the unknown, not the fear
Team’s focus on delivering functionality which
benefits the business

Scrum Defined
Focus is on:
Meeting business needs,
Incrementally & iteratively delivers working software,
Encourages positive team dynamics & collaboration
Simple yet powerful framework for:
Management & control process,
Reduces complexity,
Provides high degree of clarity & transparency

Scrum Defined

Product Owner (PO) Role
Customer representative, responsible for
project’s success
Understands Management & Stakeholder’s
needs
Conveys their vision & business case to the
team
Prioritizes the product backlog
Maintains relationship & reports progress to
management & Stakeholders
Obtains necessary resources

Stakeholder Role
Anyone who has a interest (stake) in the
project
Clarify the specifications for the product
Authority to represent a community that
intends to use the product
Works with PO on the product backlog
Provides feedback: Sprint planning & reviews
Removes roadblocks & impediments
Supports the Scrum Framework

Traditional Scrum Master (SM) Role
As Process Owner
Communicates value of Scrum
Remove impediments to progress
Facilitates Scrum activities and team’s focus
Helps groom product backlog
Creates & maintains Scrum tools
Produces Scrum metrics

Additional Scrum Master Roles
As Facilitator:
Intervenes to increase productivity & efficiency,
Provides a focus towards project success,
Team champion negotiating on their behalf
As Mentor:
Demonstrates solutions & techniques

Additional Scrum Master Roles
(cont.)
 Coach:
• Asks probing questions, provides constant guidance,
• Acts as Cheerleader, celebrates accomplishments,
• Points out anti-patterns (counter-productive
behavior)
 Trainer:
• Provides classroom training, seminars and
workshops,
• Helps the team understand important concepts

Scrum Roles in the Balance

Scrum Activities:
Maintain Product Backlog
Create User
Story
Delete User
Story
Groom/Update
User Story
Decompose
User Story
Delete User
Story

Time-Box Scrum Traditions

Scrum Activities:
Sprint Planning
• Identify user stories
• Identify non-functional items
• Estimate user stories (story points & effort
hours)
• Assign user stories
• Prioritize user stories

Scrum Activities:
Daily Stand-up
• What did you accomplish?
• What do you plan on accomplishing?
• What’s impeding your progress?

Scrum Activities (cont.)
 Sprint Review
 Sprint retrospective:
• What went well?
• What didn’t go well?
• Identify potential improvements?
• Prioritize action items for improvements?

Questions & Answers
Take a 10 minute break

Agile Requirements
Organization
Feature

User Story Definition
The user story is the basic agile requirement
Captures the end-users perspective of a
feature
Simplest statement a requirement may take
Describes:
The type of user,
What they want,
Why they want it

User Story Definition (cont.)
Format "role-feature-reason“ template
As a <role>, I want <some business
requirement>, So that <provide some value to
business>

Three C’s of a User Story
Card – user stories are traditionally written on
cards, can be annotated with extra details
Conversation – details behind the story come
from conversations with the Product Owner
Confirmation – acceptance tests confirm the
story is working as intended

Acceptance Criteria
Confirms the User story is working as
intended
Identifies user conditions that the user story
is acceptable
Granularity – at the level of User Acceptance
Tests
Format: Given/When/Then

Acceptance Criteria (cont.)
Acceptance Criteria must be:
Unambiguous,
Language of the customer,
A set of statements, with a clear pass/fail result,
Must be actionable (cause/effect) and testable

User Story - Example
User Story: As a Registration Clerk, I want to be able to Create
Student’s registration data, so that instructors will have an accurate
list of class attendees.
Description: Registration for the upcoming semester may be
performed on-line via the students account or at the registration
office. When a request for a course is submitted the student is
prompted for a payment. Payment can either be made by credit
card or check. An updated class list is sent to the instructor.
Acceptance Criteria:
• Given a student in good standing, when registering for a course,
then their name appears on the instructors list.
• Given a student in good standing, when they enroll for a course,
Then they are billed for the credits they enrolled for.

Team Foundation Server (TFS)
Role some business requirement provide value to business
Name
Clarification & Conversations of User
Story

Estimating with Scrum Poker
 SME provides a short overview of the user story
 Team asks questions, clarifying assumptions & risks
 Everyone plays one card from the Scrum Poker deck
 Scrum Poker deck contains hands with Story Points
 Story Points are a modified Fibonacci sequence: 0, 1, 2,
3, 5, 8, 13, 21, 34, 55, 89

Agile Estimation
Definition of Story Points
 Story Point are a relative measure of
complexity
• 1 (small): simple, smallest unit of work performed,
• 3 (medium): moderately complex,
• 5 (large): complex,
• 13 (very large): high degree of complexity,
• 100 (much too large): requires re-estimation

Estimating with Scrum Poker (cont.)
 Outliers are discussed: High & low #’s are
explained
 Repeat the estimate until a consensus is
reached
 User story estimates which are too large are
kicked for further evaluation
 Keep the discussion brief – only clarify
complexity issues

Release Planning Cycle

Release Planning Process
 Conduct a release planning session to establish
the overall release schedule and features to be
delivered
 Estimate the items on the list using a modified
Scrum Poker session
 Identify dependencies – modify the schedule

Release Planning Process (cont.)
 Create a discrete set of prioritize software
features to implement
 Develop an initial feature list - larger than a
User Story but smaller than a project
 Keep planning interval short – two to six
sprints

Release Planning Process (cont.)
 Create a release plan – a modified Kanban
board
 Use the previous Releases velocity for the
current velocity
 The Release plan feeds directly into individual
Sprint backlog

Release Planning - Features

A Few Agile Metrics
 Keep your metrics simple at first
 Delivered Story Point per Feature is a good
measure of “Earned Value”
 Velocity - measures throughput of a scrum
team per iteration. This is rate of delivered
story points
 Burn-down/ Burn-up chart tracks the
completion of work

Delivered Story Point per Feature

Sprint Velocity

Burn Down Chart

Why Use Agile?
 Highly responsive to changing customer requests
 Adaptive at discovering poorly defined requirements
 Permits innovative solutions
 Encourages greater collaboration with the client
 Speeds up team building & establishing relationships
 Story Points improve the estimating process

Closing Thoughts
 Identify the theme for the release and the
sprint
 Identify and remove impediments
 Obtain frequent stakeholder input & feedback
 Demonstrate value at the end of each Sprint
 Write thinner User stories, with Story Point’s at
1 or 3

Closing Thoughts (cont.)
 Track daily progress visually with tools &
metrics
 Continuously improve the Agile processes
 Do not blend Waterfall & Agile methodologies
 All user stories need an acceptance test
 Empower small, cross-functional teams
 Always work on communication issues
 Encourage small break-out sessions

Questions & Answers

Appendix
A Few Flavors of Agile
 Scrum
 Test Driven Development
 Feature Driven Development
 Design Driven Development
 Acceptance Test Driven Development
 Extreme Programming (XP)
 Dynamic System Development Model (DSDM)
 Lean Development (LD)

Test Driven Design
Developer writes an
automated test that
defines a desired
improvement
Produced the
minimum amount
of code to pass the
test.
Refactors the new
code to acceptable
standards

Test Driven Design
 Add a test - new features begins with writing a test
 Clearly understand each new feature requirement
 Write Use cases or User Stories
 Run all tests – validate the test harness
 Write some code - in order to pass the test
 Run tests
 Refactor code – clean up the growing code base
 Repeat

Feature Driven Development
 A client-centric, architecture-centric methodology
 Short, iterative, feature driven life cycles
 Five processes:
 Develop an overall model,
 Build a features list,
 Plan by features,
 Design by feature,
 Build by feature

Acceptance Test-Driven
Development
 Based on communication between the business
customers, the developers, and the testers
 Processes aid developers and testers understand the
customer’s needs prior to implementation
 Related to Test-Driven Development. Emphasis on
developer-tester-business customer collaboration
 Highlights writing acceptance tests before developers
begin coding

Extreme Programming
 Small releases – two week sprints
 Simple Design – only code necessary to achieve
desired results
 Testing – done consistently throughout process
 Refactoring – Improve design at every stage of
development
 Pair Programming – code written by a pair of
programmers

Lean Development
 Eliminate Waste
 Amplify Learning
 Decide as Late as Possible
 Empower the Team
 Build Integrity In
 See the Whole

Visualize the workflow
Lead using a team approach
Reduce the Batch Size of your Efforts
Learn and improve continuously
Kanban

Intro to Agile Software Development - DMH Distribution

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Similar to Intro to Agile Software Development - DMH Distribution

Similar to Intro to Agile Software Development - DMH Distribution (20)

Intro to Agile Software Development - DMH Distribution