AGILE &SCRUMIn a Nutshell

Why Agile?

Traditional (Waterfall) Development

Requirements

Design

Implementation

Verification

Maintenance

Agile / Agile Methodology

Agile: able to move quickly and easily

In Development: An umbrella term for any of a number of iterative, incremental development processes or frameworks

Iterative development: incremental development of smaller features with frequent revisions. Encourages rapid and flexible response to change.

Agile Manifesto

Individuals and interactions over Process and tools

Working software over Comprehensive documentation

Customer Collaboration over Contract negotiation

Responding to change over Following a plan

While there is value on the right, we value the items on the left more

Agile

Scrum KanbanXP FDD

Agile vs. Waterfall

Build a House: Waterfall Style

Imagine: • Meet Client. Discuss full house requirements • Design entire house • Lay foundation for fully designed house • Build frame • Put in plumbing • Wire electrical • Complete exterior • Complete interior

Build a House: Agile Style

Imagine: • Meet Client. Discuss immediate need (shelter to sleep in) • Design, build & test a bedroom (1 door to get in and out) • Meet Client. Discuss next need (bathroom) • Design, build & test a bathroom (attached to bedroom) • Meet Client. Discuss next need (kitchen) • Design, build & test a kitchen (attached to bathroom) • Meet Client. Discuss next need (bedroom on 2nd floor) • Ooops, need to teardown and rebuild - originally

designed for one level

Build a House: Notes

• Last slide poked fun at Agile, but that wasn’t the point • Both Waterfall & Agile methodologies can result in waste

• Waterfall: May build the wrong thing, wrong time, not fulfill a need

• Agile: May need to redo work due to lack of plan/foresight. Can “spin wheels” doing work to get it right.

• With Agile, still helps to have a vision; helps to have some idea where you are going to help further reduce waste

Benefits of Agile

• Greater ability to respond to change • Greater transparency • Greater predictability • Reduced risk • Constant Product and Process

Improvement

Scrum

Scrum

• First described by Hirotaka Takeuchi & Ikujiro Nonaka in 1986 in the New Product Development Game

• Based on case studies from automotive, photocopier and print manufacturing

• Formalized as Scrum in 1995 by Ken Schwaber & Jeff Sutherland

Product Owner

Product Owner: The one who decides what gets built. Represents the stakeholders and is the voice of the customer. Responsible for maximizing value.

Product Owner

Backlog Item: Has attributes of description, order, estimate and value.

User Story:A description that captures the user’s need (‘who’, ‘what’, and ‘why’) in a simple, concise way.

Written in the form of:“As a {role}, I want a {goal/desire} so that I can {benefit}.”

Example:“As a car driver, I want a means to turn the car, so that I can go around a bend in the road.”

Backlog Item

Item 2Item 3Item 4 Item 5Item 6 Item 1Product Owner

ProductBacklog

Product Backlog: Prioritized list of user stories and “technical debt”.

Technical Debt is technical work to be completed but which the user is not likely to notice. For example, better organizing code for maintainability.

Item 1Item 2Item 3Item 4 Item 5Item 6

Product Owner

Development Team: Cross-functional team with all the skills necessary to create product features (complete backlog items). Responsible for delivering potentially shippable increments of the product.

Sprint: One development cycle. Typically 2 to 4 weeks in length. The development team commits to completing select backlog items each sprint.

Some Quick Definitions

ProductBacklog

Item 1Item 2Item 3Item 4 Item 5Item 6

Sprint Planning

Product Owner

ProductBacklog

Sprint Backlog

Item 1Item 2Item 3

Item 4 Item 5Item 6

Product Owner

Scrum Master: Servant leader for the team. Ensures the team uses agreed-upon scrum processes. Removes impediments to Development Team progress.

Similar to Project/Program Manager

Sprint

24 hr

ProductBacklog

Sprint Backlog

Item 1Item 2Item 3

Item 4 Item 5Item 6

Daily Stand-up

Product Owner Daily Stand-up:

Meeting in which each team member gives a brief status update of what they did, what they will do, and what is blocking them.

Sprint

24 hr

ProductBacklog

Sprint Backlog

Item 1Item 2Item 3

Item 4 Item 5Item 6

Product Owner

Definition of Done (DoD): Team defined criteria by which a backlog item is considered complete. Can include things such as having automated tests in place and features passing all automated tests.

Sprint

24 hr

Working Increment

ProductBacklog

Sprint Backlog

Item 4 Item 5Item 6

Product Owner

Working Increment

Feedback

Sprint

Item 7

Item 8

24 hr

ProductBacklog

Sprint Backlog

Recap of Scrum Roles

Product Owner: Decides what is to be built. The voice of the stakeholders. Responsible for maximizing product and Development Team value. Similar to a Product Manager.

Development Team: Cross-functional team with all the skills necessary to create product features. Responsible for delivering potentially shippable increments of product every sprint.

Scrum Master: Meeting facilitator and coach. Ensures the team uses agreed-upon scrum processes. Removes impediments to Development Team progress.

Scrum Meetings

Sprint Planning: Meeting in which the team figures out which backlog items it can commit to completing for the coming sprint.

Daily Stand-up: Short meeting held every day during a sprint. Each team member briefly describes what (s)he worked on, what (s)he will work on, and any thing that is blocking them from working.

Sprint Review & Retrospective: Meetings in which the team demonstrates completed work to stakeholders. The team also discusses what went well, not so well and what they want to work on improving in the next sprint (much like a post mortem).

Backlog Grooming: A meeting used to make sure the backlog is still properly prioritized, break down larger stories, or get clarification on stories.

Other Common Terms

Story Points: An estimated measure given to a user story to judge how much work the story is.

Velocity: The capacity of a team to handle story points in a sprint. Over time an average can be determined of how many story points a team typically completes in a sprint.

Burn-down chart: Chart that is updated every day to show the “burn down” of the amount of work left in a sprint, plotted against the ideal, linear burn-down rate.

Spike: A time boxed period in a sprint used to perform research or create a prototype. A spike is complete when the time period ends. The goal may or may not have been achieved in a spike.

Resources

• “Scrum: The Art of Doing Twice the Work in Half the Time” by Ken Schwaber and Jeff Sutherland

• http://agilemanifesto.org

• http://scrumtrainingseries.com

• http://www.scrumguides.org

• http://www.scrum.org

• http://www.scrumalliance.org

• “Kanban: Successful Evolutionary Change for Your Technology Business” by David J. Anderson

Kanban

• Developed by Taiichi Ohno of Toyota in the 1950’s.

• Adapted for software by David J. Anderson

• Based on the Theory of Constraints introduced in 1984 in the book The Goal by Eliyahu M. Goldratt

Kanban Key Principles

• Start with existing process

• Agree to pursue incremental, evolutionary change

• Respect current process, roles, responsibilities and titles

• Leadership at all levels

Kanban

Backlog Analysis Develop Test Deploy3 5 3 5

Doing DoingDone Done

Kanban places upper limit on WIP inventory

Scrum vs. Kanban

Scrum KanbanCadence Fixed length Continuous flow

RolesProduct Owner, Scrum Master

Development TeamNo prescribed roles

Key Metrics Velocity Cycle time

Change Philosophy Change only between sprints Change at any time

Level of Structure More structured Less structured

Thank You!