What is Scrum? Michael Bourque Director of Development PTC

What is Agile Scrum? Michael Bourque Director of Development PTC

Why I love PHP? Michael Bourque Director of Development PTC

Building software is fun again? Michael Bourque Director of Development PTC

About me CNC Machinist Manufacturing Engineer QA Manager Product Designer Manager of Product Design Director of Development Developer at Heart

CNC Machinist

Manufacturing Engineer

QA Manager

Product Designer

Manager of Product Design

Director of Development

Developer at Heart

Languages Basic Assembly Fortran Visual Basic C Perl PHP Ruby on Rails

Basic

Assembly

Fortran

Visual Basic

C

Perl

PHP

Ruby on Rails

Development Methodologies Waterfall Agile

Waterfall

Agile

Waterfall The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. Requirements Gathering Design (Specs, UI, Etc) Development Testing (UAT, Reg) Integration L10N Freeze Freeze Freeze Freeze - Wikipedia

The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.

Not my job!

Agile Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. 2-4 Weeks Designed, Developed, Documented, Tested, Integrated, Released - Wikipedia Iteration 1 Authentication Iteration 2 Authentication Iteration 3 Course Viewer Iteration 4 Assessment Viewer Iteration 25 Browse Content Iteration 26 Search

Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.

Agile Methods Scrum More…

Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan by “The Agile Alliance” http:// www.agilemanifesto.org /

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

by “The Agile Alliance”

http:// www.agilemanifesto.org /

Waterfall vs. Agile Requirements Fixed PLAN driven Resources Time Estimated Features The requirements drive the cost/schedule estimates FEATURE driven Resources Time Waterfall Agile Budget and time select the requirements that can be delivered

What is Scrum? In rugby, a scrum is a way of restarting the game, either after an accidental infringement or when the ball has gone out of play. - agilethinking.net

In rugby, a scrum is a way of restarting the game, either after an accidental infringement or when the ball has gone out of play.

Who’s using Scrum? Microsoft Sun IBM Yahoo Google Show of hands?

Microsoft

Sun

IBM

Yahoo

Google

Show of hands?

Framework 2 Weeks 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Standup Meeting Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Vision

Terminology Epic Sprint User Story Backlog Task boarding Story points T-shirt sizing Daily standup meeting Burndown chart Team velocity Self-Organizing team Retrospective Roles Customer / Sponsor Product Owner Scrum Master Developer QA

Epic

Sprint

User Story

Backlog

Task boarding

Story points

T-shirt sizing

Daily standup meeting

Burndown chart

Team velocity

Self-Organizing team

Retrospective

Roles

Customer / Sponsor

Product Owner

Scrum Master

Developer

QA

Product Vision & Roadmap

User Stories & Backlog Requirements Small pieces of functionality. Written as though they were from a customer. Not every detail is needed. Follows the INVEST model Independent Negotiable Valuable Estimatable Small Testable Prioritize according to business value. Stored in a system of record. Product Backlog As prioritized by Product Owner

Requirements

Small pieces of functionality.

Written as though they were from a customer.

Not every detail is needed.

Follows the INVEST model

Independent

Negotiable

Valuable

Estimatable

Small

Testable

Prioritize according to business value.

Stored in a system of record.

Estimating Story points Rough guess (t) Plan estimate (t) Task Estimate (h) ToDo (h)

Story points

Rough guess (t)

Plan estimate (t)

Task Estimate (h)

ToDo (h)

Definition of Done The described functionality has been implemented. The functionality is integrated into the main application on the development/integration server. It is not sufficient, if the implementation exists only on the developer's personal work station. Sufficient coverage of automated unit tests has been implemented. All united test cases have been executed on development/integration server. Peer code review has been conducted. The code adheres to the defined coding standards and technology being used. Functional test cases have been created Functional test cases have been peer reviewed. All functional test cases have been executed. No major bugs are associated with the story. It is up to the product owner's discretion to decide whether open bugs are prohibiting acceptance of the story. The implemented story has been demoed to the team on the development/integration server - in particular, to the product owners. All business acceptance criteria are met. If the product owners conclude, that the implementation of the story does not satisfy their business needs, new stories may be created to address any changes necessary as well as marking the original story as done. All technical acceptance criteria are met. For now, those will be checked during code review.

The described functionality has been implemented.

The functionality is integrated into the main application on the development/integration server. It is not sufficient, if the implementation exists only on the developer's personal work station.

Sufficient coverage of automated unit tests has been implemented.

All united test cases have been executed on development/integration server.

Peer code review has been conducted. The code adheres to the defined coding standards and technology being used.

Functional test cases have been created

Functional test cases have been peer reviewed.

All functional test cases have been executed.

No major bugs are associated with the story. It is up to the product owner's discretion to decide whether open bugs are prohibiting acceptance of the story.

The implemented story has been demoed to the team on the development/integration server - in particular, to the product owners.

All business acceptance criteria are met. If the product owners conclude, that the implementation of the story does not satisfy their business needs, new stories may be created to address any changes necessary as well as marking the original story as done.

All technical acceptance criteria are met. For now, those will be checked during code review.

Sprint planning meeting Product owner proposes users stories from backlog based on priority and team velocity. Visual prototypes Entire team is involved. Plan estimates are given in story points (t-shirt). Team produces a Sprint Backlog Very collaborative Sprint Backlog

Product owner proposes users stories from backlog based on priority and team velocity.

Visual prototypes

Entire team is involved.

Plan estimates are given in story points (t-shirt).

Team produces a Sprint Backlog

Very collaborative

Task boarding Team breaks down the user stories into tasks on a whiteboard. Developers estimate the effort on each task. Developers choose their own tasks. Resource planning, availability (Vacation, PTO) Team produces a backlog of tasks with owners. Very collaborative Backlog tasks expanded by team

Team breaks down the user stories into tasks on a whiteboard.

Developers estimate the effort on each task.

Developers choose their own tasks.

Resource planning, availability (Vacation, PTO)

Team produces a backlog of tasks with owners.

Very collaborative

Sprint Entire team works together (PO, DEV, QA, INT, Etc) User stories are elaborated as they are needed. Goal of team is to finish the work Features are designed, coded, tested, documented and accepted during the Sprint Self organization No scope creep allowed in during sprint 2 Weeks

Entire team works together (PO, DEV, QA, INT, Etc)

User stories are elaborated as they are needed.

Goal of team is to finish the work

Features are designed, coded, tested, documented and accepted during the Sprint

Self organization

No scope creep allowed in during sprint

Daily Standup meeting 15-30 Minutes daily Led by Scrum Master Three questions What did I do yesterday? What will I do today? Is there anything stopping me from finishing my tasks? Discussions are taken offline. 2 Weeks 24 hours

15-30 Minutes daily

Led by Scrum Master

Three questions

What did I do yesterday?

What will I do today?

Is there anything stopping me from finishing my tasks?

Discussions are taken offline.

Team Velocity (burndown)

Demo meeting At the end of the sprint Only stories completely done are allowed. Developers give the demo to product owner and customer. Feedback is encouraged. Problems, ideas, enhancements are captured by product owner and scheduled in the product backlog. Real product – no Powerpoint Potentially Shippable Product Increment

At the end of the sprint

Only stories completely done are allowed.

Developers give the demo to product owner and customer.

Feedback is encouraged.

Problems, ideas, enhancements are captured by product owner and scheduled in the product backlog.

Real product – no Powerpoint

Repeat

Retrospective meeting Special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. What went well, what needs to be improved? Improvements can be made in the following sprint.

Special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork.

What went well, what needs to be improved?

Improvements can be made in the following sprint.

Benefits I have seen Rapid development - get started right away. Product owner manages the backlog and is responsible for driving business value. No more guarding of development resources. See the product evolve over time. Embraces change. Fully transparent. It’s fun!

Rapid development - get started right away.

Product owner manages the backlog and is responsible for driving business value.

No more guarding of development resources.

See the product evolve over time.

Embraces change.

Fully transparent.

It’s fun!

Q & A

Release Burnup chart

QA Testing – V to I