Agile & Scrum Training Slides

Copyright Conscires 2011

INTRO TO AGILE & SCRUMPresenter:Bachan Anand


AGENDA SCRUM Framework SCRUM Roles Planning & Estimation Team Engagement SCRUM Simulations SCRUM Myths Class Retrospective

2


AGILE MANIFESTO

Individuals and interactions over processes and tools Working software/product over comprehensive

documentation Customer collaboration over contract negotiation Responding to change over following a plan

3


AGILE 12 PRINCIPLES

Highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software

Welcome changing requirements Deliver working software (Product) frequently Business people and developers must work

together daily throughout the project Build projects around motivated individuals Most efficient and effective method of

conveying information is face-to-face conversation

4


AGILE 12 PRINCIPLES

Working software (product) is the primary measure of progress

Agile processes promote sustainable development (maintain a constant pace indefinitely)

Continuous attention to technical excellence and good design enhances agility

Simplicity (art of maximizing amount of work not done) is essential

Best architectures, requirements, and designs emerge from self-organizing teams

At regular intervals, team reflects on how to become more effective, then tunes and adjusts

http://agilemanifesto.org/principles.html5


AGILE LEAN ROOTS

Eliminate Waste – Anything that does not add value Build Quality In – Quality if a primary focus Deliver fast – Just as it’s defined Defer Commitment – Learning before commitment Respect People – Give space for others to grow Improve the System – The system is the entire process Create Knowledge – Sharable and Usable Focus on the customer - Needs Continuous improvement - Daily Kaizen - Change for better processes, led by the people

6


SCRUM FOUNDATION VALUES

Empiricism Detailed up-front planning and defined processes are

replaced by just-in-time Inspect and Adapt cycles Self-Organization

Small teams manage their own workload and organize themselves around clear goals and constraints

Prioritization Do the next right thing

Rhythm Allows teams to avoid daily noise and focus on

delivery Collaboration

Leaders and customers work with the Team, rather than directing them 7


SCRUM VALUES

Transparency Everything about a project is visible to everyone

Commitment Be willing to commit to a goal

Courage Have the courage to commit, to act, to be open and to

expect respect Focus

Focus all of your efforts and skills on doing the work that you have committed to doing

Respect Respect and trust the different people who comprise a

team8


SCRUM FRAMEWORK

9


SCRUM AND WATERFALL DIFFERENCES

SCRUM Traditional (Waterfall)

Plan what you expect to happen with detail appropriate to the horizon

Plan what you expect to happen

Control happens through inspection and adaption

•Reviews and Retrospectives•Self-organizing Teams

Enforce what happens is the same as what is planned

•Directive management•Control

Use Agile Practices to manage change•Continuous feedback loop•Iterative and incremental development•Prioritized backlogs

Use change control to manage change•Change Control Board•Defect Management

10


SCRUM ROLES DETAILS

Product Owner Maximize the value of the work done by prioritizing

the features by market value SCRUM Master

Manages the SCRUM framework Team

Self-organizing empowered individuals motivated by business goals

Other Stakeholders Anyone who needs something from the team or the

team something from

11


SCRUM ROLES DETAILS – PRODUCT OWNER

Thought Leader and Visionary Drives the Product Vision (for example, with Story

Mapping) Prioritizes the User Stories Maintains the Product Backlog with the team Accepts the Working Product (on behalf of the customer)

12


SCRUM ROLES DETAILS – SCRUM MASTER

Servant Leader Facilitates the Process Supports the Team Removes Organizational Impediments Socializes Scrum to Management Enable close collaboration across all roles and functions

13


SCRUM ROLES DETAILS – SCRUM TEAM

Cross-Functional 5-8 Members Self-Organizing Focused on meeting Commitments

14


ROLES RELATIONSHIP

15


MANAGEMENT ROLES (SERVANT LEADERSHIP) Is a servant first and ensures other people – i.e. followers

or stakeholders – highest priority needs are being served Empowers others and supports an environment of trust Has empathy and sensitivity to the needs and interest of

all stakeholders Is open to the voice of others by supporting discussions

that includes those without a voice Accept risks; takes the risk of failure along with the

chance of success, while trusting others My cup is always full – my focus is now; I’ve learned

from yesterday and I’m planning for tomorrow16


PRE-SCRUM PLANNING

Pre-SCRUM is where projects are approved, budgets and resources assigned

Project Portfolio’s are expensive They are risky

Do we have the right people with the right experience and skills?

Can we afford the project? What are the objectives of the project? Clear goals. Lack of commitment Can we verify the promise was met?

The business want value and a return on investment

17


PRE-SCRUM PLANNING

18

Pre-Portfolio

Active Portfolio

Post-Portfolio

Projects Being formulatedEvaluated Pending approval

Projects ApprovedPending Kick-off Executing

Projects ExecutedM & E

Reject

Success or

Failure


PRODUCT VISION & ROLE ENGAGEMENT

A goal to aspire to Can be summarized in a short statement of intent Communicate it to the team Common format:

For: (Our Target Customer) Who: (Statement of need) The: (Product/Product name) is a (Product/Product category) That: (Product/Product key benefit, compelling reason to buy

and/or use) Unlike: (Primary competitive alternative) Our Product: (Final statement of primary differentiation)

19


RELATIVE ESTIMATION

Humans are better at relative estimates than absolute estimates

Many heads are better than one Estimates are made by those who perform the work Estimate size/complexity – Derive duration The goal is to get useful estimates with minimal effort Estimates are not commitments Planning Poker is the common method for estimation

20


RELATIVE ESTIMATION

Story Points: Commonly used in Agile estimation No real-world dimensions Compare one story to another Based on effort, complexity, risk Precision is not critical

21


PRODUCT BACKLOG

A living list of requirements captured in the form of User Stories

Represents the WHAT of the system Prioritization with respect to business value is essential! Each story has estimated Story Points, which represent

relative size, and is determined by those actually doing the work

Higher priority items are decomposed and lower priority items are left as larger stories (epics)

22


USER STORIES

Product requirements formulated as one or more sentences in the everyday or business language of the user As a <user>, I would like <function> so that I get

<value> Each User Story has an associated Acceptance Criteria

that is used to determine if the Story is completed

23


SPRINT BACKLOG

List of stories, broken down into tasks, that is committed for any particular Sprint

Owned and managed by the Team Any team member can add, delete or change the sprint

backlog with additional tasks

24


USER STORIES

Independent Not overlap in concept and be able to schedule and

implement them in any order Negotiable

Not an explicit contract for features; rather, details will be co-created by Product Owner and Team

Valuable Add business value

Estimated Just enough to help the Product Owner rank and

schedule the story's implementation Sized Appropriately

Need to be small, such as a few person-days Testable

A characteristic of good requirements25


SPRINT PLANNING

Sprint Planning meeting held at beginning of each Sprint Time and Resources are fixed in any given Sprint Goal is to have prioritized Sprint Backlog, broken down

into tasks, that the Team can commit to During planning, Team commits to scope that can be

completed in the Sprint, taking into account the definition of Done

Story points may be refined

26


TASK BOARD Active visual indicator of flow

of work Should be visible to team

members at all times Should be kept current Encourages self-organization,

and collaboration

27


DOD - (DEFINITION OF DONE) Team creates its own definition of Done in the interest of

creating quality software Definition can evolve over sprints Example checklist (not exhaustive):

Unit tests pass (ideally automated) Customer Acceptance tests pass User docs written UI design approved by PO Integrated into existing system Regression test/s pass (ideally automated) Deployed on staging server Performance tests pass

28


SPRINT BURN-DOWN

29

Shows daily progress in the Sprint

X-axis is the number of days in the Sprint

Y-axis is the number of remaining stories


RELEASE BURN-DOWN

30

Shows progress across Sprints

X-axis is the number of Sprints

Y-axis is the total number of stories


DAILY STANDUP MEETINGS

Meetings held in same location, same time, every day Time-boxed at 15 minutes Encourages self-organization, rhythm, and collaboration Not a status meeting Each Team member speaks to:

What did I accomplish in the last 24 hours What do I plan to accomplish in the next 24 hours Any impediments getting in the way of my work

31


SPRINT REVIEW

Occurs at the end of each Sprint Inspect and Adapt the product (Empiricism) The team meets with the Product Owner (and

Stakeholders) to demonstrate the working software from the Sprint

This is a hands-on software demo (not a PowerPoint) that usually requires some prep beforehand

32


RETROSPECTIVES

Occurs at the end of each Sprint Inspect and Adapt the process (Empiricism) Team and ScrumMaster meet to reflect on what went well

and what can be improved Tone of the meeting is that everyone did their best and

now look to how can we improve Retrospectives must conclude with team commitments to

action

33


SCRUM RELEASE - VELOCITY

Total number of story points completed by a team in a Sprint

Can be used by the team as a reference during Sprint Planning

Used by Product Owner to plan out the releases

34


SCRUM RELEASE PLANNING

Product Owner, in conjunction with the team, formulates Release Plans by applying the team Velocity to the Product Backlog

Release Plans are revisited after every Sprint Two ways to approach

Fix scope and determine how many sprints are needed Fix time and determine how much scope can be

completed

35


SCRUM MYTHS

SCRUM Myths: No quality/no testing People burnout because of short and frequent delivery

cycles (sprints) No culture change is needed Will make a better team SCRUM is the only Agile method Solution to all

36


SCRUM MYTHS

SCRUM Myths: A silver bullet Management believes it will solve all problems Easy to implement Will replace waterfall method Cowboy coding No documentation Simple but not easy

37


SCRUM MYTHS

SCRUM:Exposes issues soonerIncreases visibility, leading to faster issue resolutionFacilitates complete feedback & continuous

improvementsAllows people to fail and learn from failureMoves away from the blame cultureEmbraces small incremental changes

38


TAKE AWAY

Scrum is a lightweight framework with a simple set of rules, built on foundations and values

Scrum enables teams to discover their true potential and deliver quality software that adds business value

39


APPENDIX - ROLES

Product Owner Thought Leader and Visionary, who drives the Product

Vision, maintains the Product Backlog, prioritizes the User Stories, and accepts the Working Software (on behalf of the customer)

ScrumMaster Servant Leader, who facilitates the process, supports

the Team, removes organizational impediments, and socializes Scrum to Management

Team Cross-Functional group of 5-8 Members that is self-

organizing and focused on meeting Commitments40


APPENDIX – ARTIFACTS

Product Backlog A living list of requirements captured in the form of

User Stories, prioritized according to business value Sprint Backlog

List of stories, broken down into tasks, that is committed for any particular Sprint; owned and managed by the Team

Taskboard Active visual indicator of flow of work

Sprint Burndown Chart Shows daily progress in the Sprint

Release Burndown Chart Shows progress across Sprints

41


APPENDIX - CEREMONIES

Sprint Planning Held at beginning of each Sprint, with the goal to have

prioritized Sprint Backlog, broken down into tasks, that the Team can commit to

Daily Standup Meetings held in same location, same time, every day,

with the goal of ensuring that team members are in synch (not a status meeting)

Sprint Review Occurs at the end of each Sprint, with the goal of

inspecting and adapting the Product Retrospective

Occurs at the end of each Sprint, with the goal of inspecting and adapting the process 42

Technology

Agile & Scrum Training Slides