© Freddie Mac 2010 1
Our Expertise and Commitment – Driving your Success
Agile 101 Training
February 2014
By: Jean Ballard and Kurt Rasmussen
2
Agile 101 Training Agenda
Part I: Agile Overview» Agile– What it is?
» Agile vs. Waterfall
» Why Agile
» Who - Agile teams
» Key terms
» Assessment
Part II: Project Management with Agile» Project lifecycle
» Planning
» Requirements
» Key milestones
What is an Agile Process?
3
In principle: Any process that adheres to the principles of the Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over Processes and toolsWorking software over Comprehensive documentationCustomer collaboration over Contract negotiationResponding 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.”
Manifesto for Agile Software Development, www.agilemanifesto.org
Agile principles
4
The Agile Manifesto is based on twelve principles:
1. Customer satisfaction by rapid delivery of useful software2. Welcome changing requirements, even late in development3. Working software is delivered frequently (weeks rather than months)4. Close, daily cooperation between business people and developers5. Projects are built around motivated individuals, who should be trusted6. Face-to-face conversation is the best form of communication (co-location)7. Working software is the principal measure of progress8. Sustainable development, able to maintain a constant pace9. Continuous attention to technical excellence and good design10. Simplicity—the art of maximizing the amount of work not done—is
essential11. Self-organizing teams12. Regular adaptation to changing circumstances
5
What is Agile Software Development?
Process that allows focus on delivering the highest business value in the shortest time.
It allows rapid and repeated inspection of actual working software (every 2 weeks to 1 month).
The business sets the priorities. Teams self-organize to determine the best way to deliver
the highest priority features. Can see real working software and decide to release it ‘as
is’ or continue to enhance it for another sprint.
Mountain Goat Software LLC
6
What is Agile? (continued)
What is it: Provides complete project transparency Facilitates continuous communication Maintains team continuity and team focus Pro-active mitigation of project risks Appropriately aligns expectations
What Agile is NOT: Not a panacea for perfect Project Management Not just a management reporting tool Not one size fits all Not just for application development
7
Agile vs. Waterfall
Command and control
Detailed planning up front
Sign-offs
Protect project scope
Show results at end
Weekly project meetings
Working together
Communication frequency
Getting things done
Planning
Scope
Getting feedback
Leadership, facilitation, communication
Commitments
Detailed planningIn chunks
Project Sprint scope
Show results at endof every sprint
Daily Scrum meetings
Waterfall Agile
8
Earlier delivery of value to the customer
Faster time to market; higher priority functionality deployed first
Reduced waste and costs; increased quality
Improved predictability of delivery
Increased productivity from self-organizing, collaborative, adaptive, and cohesive teams
Increased project team satisfaction
Lower project risk through higher visibility
Improved stakeholder satisfaction!!!
Why Agile?
9
Agile Team Composition
Composition of an Effective Agile Team
A. Select domain experts that cover the spectrum aligned with project delivery
B. Ensure that all team members are willing and able to accept multiple roles
C. Make sure that appropriate knowledge is spread across the team
D. Establish core team principles (e.g. team will be self organizing) and a shared vision that is clearly defined
E. Promote effective communication (e.g. face-to-face), mutual trust, and collaboration
F. Set up an environment that rewards constant improvement
G. Ensure that the Product Owner / Business Customer is hands on - They are Team Members too.
10
Agile Key Terms
Term Definition
Backlog also known as product backlog. A prioritized features list, containing short descriptions of all functionality desired in the product.
Epic states the theme of a group of features. A user story which describes a large amount of customer value and must be broken down into smaller user storied.
User Story states the functionality of a feature as told from the point of view of the Business User. Describes the Who, What, Why in simple-to-understand language.
Release An increment of potentially shippable product from the development team into routine use by customers.
Iteration A period of time in which software development activities take place and result in delivery of working software. Similar in nature and definition as a sprint.
Sprint a “time-boxed” period of work, with a closely defined and agreed output - generally 2-4 weeks.
Scrum Agile development project management framework based around sprints and generally comprised of the scrum team.
Velocity how much product backlog effort a team can handle in one sprint
Task a unit of work generally between 4 and16 hours.
14
Agile Planning
Planning Level Planning Description
A. Product vision What, who, why, when, assumptions constraints determined by Product Owner
B. Product roadmap Releases – dates, feature sets, objective, product backlog
C. Release planning Sprint / Iteration, team capacity, user stories, priority, size, estimates, definition of done
D. Sprint planning User Stories – tasks, level of effort, commitment, sprint backlog
E. Daily planning What did I do yesterday?, What am I going to do today? What are my obstacles?
15
Release Planning
Product
Owner
Introduce
s Goal
• Allows team to understand motivation behind release goal• Positions team to identify the scope that can be completed by the release date
Estimate
Team Veloc
ity
• Best used if team hasn’t changed• For Fixed Release Date: Velocity = # of Sprints in Release X Velocity of Last Iteration
Review
User Stories
• Product Owner presents User Stories to Development Team• Developers ask questions about User Stories• User Story are described at a high level (Avoid getting into the weeds!)
Estimate
User Stori
es
• Developers produce estimates based on predetermined scaling schema• Each User Story is discussed for 2-minutes MAX
Assess
Technical Risk
• Development team assesses technical risk for each User Story• Risk is classified as High, Med, Low
Select User Stories for Relea
se
• Prioritize User Stories based on value, estimates, and technical risk• Consensus needs to be reached on the release plan with everyone present stating their commitment
verbally
16
Sprint Planning
• Team selects items from the product backlog they can commit to completing
• The team commits to completing what they select• It’s a team commitment, not a set of individual commitments
• Sprint backlog is created– Tasks are identified and each is estimated (1-16 hours)
– Collaboratively, not done alone by the ScrumMaster
• High-level design is considered
As a Claims Reviewer, I’m able see what claims are assigned to me, so I don’t miss reviewing a claim.
As a Claims Reviewer, I’m able see what claims are assigned to me, so I don’t miss reviewing a claim.
Code the middle tier (8 hours)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)
17
Sprint Management: Daily Scrum
• Parameters
– Daily, 15-minutes, Stand-up
• Not for problem solving
– Whole world is invited
– Only team members, ScrumMaster, product owner, can talk
• Helps avoid other unnecessary meetings
Three questions answered by all participants:
1. What did you do yesterday?
2. What will you do today?
3. Is there anything preventing you from completing your tasks?
18
Documenting Requirements
The requirements (user stories)
A list of all desired work on the project for a product
Ideally expressed such that each item has value to the users or customers of the product
Prioritized by the product owner
Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
Product backlog
19
Documenting Requirements
Backlog item
User Story #1399: As a Manager, I'm able to view all the claims in the workflow (Management View), so I know what claims need to be paid.
User Story #1403: As an Assignee, I'm able to receive an alert email with a link to my To Do View, at certain time increments and if status is Red, so I can easily access the claims in my queue.
User Story #1452: As an Insurance Ops Associate, I'm able to BATCH separately LAE & Commutations in CPMS, so Cash Mgmt & Finance can review the Batch Report for each. (One-to-One)
User Story #1467: As a Cash Management User, I'm able to upload a document confirming that US Bank received wire from MBIA, so I can confirm that the wire was sent and the task is approved.
User Story #1477: As a Claims Reviewer, I'm able to Terminate a claim, so it will be removed from the CPMS and will not get paid.
...
A sample product backlog:
20
Post-Sprint: Sprint Demo
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world