Lessons Learned from Practical Application

Presented to NM Women In Technology

June 28, 2012

Ana Lopez, Certified Scrum Master Lisa Milmine, Certified Scrum Master

Software Application Engineering

Sandia National Laboratories

Agile Implementation

Presentation Overview

• Agile Development

• The Scrum Framework

• Lessons Learned and Recommendations (So what)

What is Agile?

Frequently delivering business value while adapting to change

Agile is a philosophy

Agile is applied through a method (like XP or Scrum)

See: Shore, James and Shane Warden. The Art of Agile Development, Sabastopol, CA: O’Reilly Media, Inc. , 2008. Print.

How Agile Evolved

See: What is Agile Software Development: http://www.agilealliance.org/the-alliance/what-is-agile/ Agile Software Development: http://en.wikipedia.org/wiki/Agile_software_development

1990s – common methodologies emerged Face to face communication

Frequent delivery of business value

Self managing teams

Adaptable coding practices

In 2001 - Agile Summit

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

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.” See: Manifesto for Agile Software Development: http://agilemanifesto.org/

12 Principles

Satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Welcome changing requirements, even late in development.

Regular adaptation to changing circumstances

See: Manifesto for Agile Software Development: http://agilemanifesto.org/principles.html

12 Principles (Cont.)

Build projects around motivated individuals.

Self-organizing teams

Continuous attention to technical excellence and good design

Working software is the primary measure of progress.

See: Manifesto for Agile Software Development: http://agilemanifesto.org/principles.html

12 Principles (Cont.)

Business people and developers must work together daily throughout the project.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Simplicity- The art of maximizing the amount of work not done - is essential

Agile processes promote sustainable development.

See: Manifesto for Agile Software Development: http://agilemanifesto.org/principles.html

Why everyone likes agile

• Executives and Senior Management − Return on investment − Software longevity

• Users and Stakeholders − Influence the direction of software development − Teams focus on delivering useful and valuable software − Increased delivery frequency

• Project Managers − Change direction as business needs change, − Make and meet commitments − Improved stakeholder satisfaction

• Developers − Increased technical quality − Greater influence over estimates and schedules and team autonomy

• Testers − Part of the team − Influence quality at all stages of the project

See: Shore, James and Shane Warden. The Art of Agile Development, Sabastopol, CA: O’Reilly Media, Inc. , 2008. Print.

What is Scrum?

An agile framework focused on delivering business value in short incremental periods (sprints)

Created in the early 1993 at Easel Corporation

Specifically suited for complex problems

Defined in The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game

- Developed and Sustained by Ken Schwaber and Jeff Sutherland

Term “scrum” inspired by a Rugby formation for players used to restart the play of a game usually after an infraction. A team approach.

Origins: http://scrum.jeffsutherland.com

• Software development is - Complex

- Always Broken

• A proven method for meeting customer needs is to use the ideas of Agile, including empirical process control.

• Empirical Process Control: • Inspection

• Adaptation

• Transparency

Scrum Philosophy

Empirical Process: http://en.wikipedia.org/wiki/Empirical_process_(process_control_model)

The Process

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

Process: http://www.scrumalliance.org/learn_about_scrum

The Product Backlog

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

The Sprint Planning

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

The Sprint Planning Tasks

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

The Sprint

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

The Daily Standup

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

The Sprint Objective – Working Software

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

The Review

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

The Retrospective

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

The Iterative Process

User Story

Two Questions

Three Questions

Sprint Backlog Tasks

Scrum Roles

• Product Owner (PO) Responsible for the success/business value of project

Empathetically represents customers

Uses insight to prioritize essential/incidental requirements

• Scrum Master (SM) A process facilitator, NOT a project/people manager

Resolves impediments, helps team focus on value

• Team Self managed, self organizing to get the work done

Owns/takes responsibility for process

Scrum recommends 7 +/- 2 team members at most

Scrum Artifacts

• Product backlog Prioritized list of desired project requirements Founded from product Vision

• Sprint backlog/Task backlog Set of work from the product backlog that the team agrees to complete in a sprint, broken into tasks

Follow a clearly defined Definition of Done

• Burn-down or Burn-up chart At-a-glance look at the work remaining

• Release set Minimally marketable release

Ceremonies (aka meetings)

• Sprint planning The team and product owner estimate and negotiate a set of work to deliver during a sprint

• Daily scrum The team meets each day to report progress, next steps, and impediments Facilitated by SM – team reports to each other

• Sprint reviews The team demonstrates to the product owner and stakeholders what it has completed during the sprint (working software)

• Sprint retrospectives The team looks for ways to improve the process. Facilitated by SM

User Stories

• Describes functionality that is valuable to a user/stakeholder

The “what” not the “how”

• Written from the customers perspective

• Represents customer priorities

• Reminders to have a conversation

• A user story is NOT a contract or agreement Everything can go in the backlog

Backlog Grooming

• A regular meeting to manage the backlog of stories Grooming activities include: • Creating /Removing stories in response to newly discovered

needs

• Re-assessing the relative priority of stories

• Assigning estimates to stories which have yet to receive one

• Correcting estimates in light of newly discovered information

• Splitting large user stories into multiple sprint sized stories

• Development of acceptance criteria

Project Status/Information Radiators

• Level of Effort Story Points, T-shirt sizes, etc.

• Rate of Production Velocity (velocity = story pts completed per sprint)

Basis for planning/projecting

• Sprint Burn-Down Chart Daily display of work remaining in a sprint

Pitfall: fails to show effect of changing

• Release Burn-Up Chart Tracks how much work is done wrt product backlog

Projections give insight for release planning goals

Team Velocity w.r.t. Sprints

Team Velocity w.r.t. Sprints

Cumulative Story Points

Sprint Burn-Down Chart

Day of Sprint

Uni

ts o

f Wor

k

Release Burn-Up Chart

So…

What have we learned in practice? What wont the textbooks tell you?

People

• Development Team Members − Elicit team-oriented characteristics − Comfortable with not knowing all details up front − Appropriately sized

− Trained on agile method

• ScrumMaster − Posses or acquire good facilitation skills

− Focus on facilitating and not managing the process

− Try to develop good coaching skills

− Should be independent of development and customer responsibilities

People (Cont.)

• Project Manager − Responsible for managing process areas not called out by Scrum

(risk management, communications, etc.)

− Empower self management of your team

− Report frequently to build management confidence

• Product Owner

− Fully committed to project

− Product owner trained/certified

− Empowered by management to have decision authority

− Understands that they have ultimate authority

People (Cont.)

• Management − Knowledgeable of process at a high level

− Supportive of team’s empowerment to manage

• Customers and Stakeholders

− Flexible on scope

− Committed and engaged through the duration of the project

Practices

• Definition of Done − Do it for task, story, and sprint

− Revisit Often

− Adapt as necessary

• Backlog Grooming − Conduct regularly throughout project

− Project owner representation is required

• Reporting (progress/status) − Use the Scrum terminology/measurements

− Familiarize Management ahead of time

Structure

• Sprint Tasks − Allow the team to develop a method that adds value to them

− Preserve differentiation of stories and tasks

− Maintain goal of transparency of work at hand

• Execution of Development within Process

− Remember: Failed acceptance tests or unfinished work equal additional backlog or defect work

− Plan for adequate testing/acceptance within sprint

− Prevent scope creep! Only work on planned work

Structure

• Planning − Come prepared!

− Conduct sufficient discussion of stories with dev team

− Obtain verbal commitment to sprint backlog

• Review − Maintain consistent forum for demonstrating work/obtaining

feedback

− Keep reviews efficient

− Plan for review “demo” preparation time

• Retrospective − Revisit previous retro notes

− Ensure all team members have opportunity to contribute

Tips for Getting Started

• Select an agile method that suits your team

• Get management’s commitment/trust

• Ensure PO is empowered and can respond rapidly

• Get your team and customers trained and motivated

• Clearly define roles and responsibility

• Obtain acceptance from all team members

• Establish your sprint schedule & logistics

• Establish communication lines for distance separated teams

• Set up your team room/workspace

• Create a vision for your product

• Spend just enough time on architecture & design to avoid disjointed components

• Have a kickoff

Have Fun and Explore – Be Agile!

Questions and Discussion

Contact Information: Lisa Milmine, (505) 284-4103, ldmilmi@sandia.gov Ana Lopez, (505) 284-1873, avlopez@sandia.gov

Backup Slides

Velocity Statistics

|Velocity Min| 19.00 |Velocity Max| 49.00 |Velocity Avg| 30.18 |Velocity Std Dev| 7.29 |Cum. SP Slope| 31.55 |SP/Story| 3.88 |Vel Avg Last 3| 31.00

Sprint Backlog Task Board

As a <who: insert role or persona> I want <what: insert functionality> So that <why: for what business value>

Acceptance Criteria: ◦ verifies the story works as the customer expected ◦ Specifies tests

General Story Format

Agile References

Shore, James and Shane Warden. The Art of Agile Development, Sabastopol, CA: O’Reilly Media, Inc. , 2008. Print.

What is Agile Software Development?. 2012. Agile Alliance. 27 June 2012. < http://www.agilealliance.org/the-alliance/what-is-agile/>

Agile Software Development. 2012. Wikipedia. 27 June 2012. <http://en.wikipedia.org/wiki/Agile_software_development >

Manifesto for Agile Software Development. 2001. Ward Cunningham. 27 June 2012. <http://agilemanifesto.org/>

Additional Scrum References

Schwaber and Sutherland, The Scrum Guide (“The official Scrum Body Of Knowledge” – scrum.org, “Canonical Scrum” - Dan Mezick)

http://www.scrum.org/scrumguides/

Schwaber, Agile Project Management with Scrum, 2004, ISBN-13: 978-0735619937 (The “Scrum Bible”)

Amazon link

Scrum In 5 Minutes

http://www.infoq.com/news/2006/11/scrum-in-five-minutes

WikiPedia Scrum Page

http://en.wikipedia.org/wiki/Scrum_(development)

Shalloway and Trott, Lean-Agile Pocket Guide for Scrum Teams

Amazon Link

Scrum For Team System’s web page FAQ

http://www.scrumforteamsystem.com/ProcessGuidanceOld/v2/FAQ/FAQ.aspx

Scrum Alliance web page

http://www.scrumalliance.org/