3/29/11  

1  

INTRO TO AGILE Presenters:

Bachan Anand

Dave Cornelius, MBA, PMP 1

Copyrigh

t Con

scires 2011

AGENDA

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

2

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

3/29/11  

2  

AGILE 12 PRINCIPLES

  Highest priority is to satisfy the customer through early and continuous delivery of 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

Copyrigh

t Con

scires 2011

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.html 5

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

3/29/11  

3  

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

Copyrigh

t Con

scires 2011

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 team 8

Copyrigh

t Con

scires 2011

SCRUM FRAMEWORK

9

Copyrigh

t Con

scires 2011

3/29/11  

4  

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

3/29/11  

5  

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

Copyrigh

t Con

scires 2011

SCRUM ROLES DETAILS – SCRUM TEAM

 Cross-Functional

 5-8 Members

 Self-Organizing

 Focused on meeting Commitments

14

Copyrigh

t Con

scires 2011

ROLES RELATIONSHIP

15

Copyrigh

t Con

scires 2011

3/29/11  

6  

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 tomorrow

16

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

PRE-SCRUM PLANNING

18

Pre-Portfolio Active Portfolio Post-Portfolio

Projects  Being formulated  Evaluated  Pending approval

Projects  Approved  Pending Kick-off  Executing

Projects  Executed  M & E

Reject

Success or

Failure

Copyrigh

t Con

scires 2011

3/29/11  

7  

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

3/29/11  

8  

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

3/29/11  

9  

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 requirements 25

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

3/29/11  

10  

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

RELEASE BURN-DOWN

30

 Shows progress across Sprints

 X-axis is the number of Sprints

 Y-axis is the total number of stories

Copyrigh

t Con

scires 2011

3/29/11  

11  

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

3/29/11  

12  

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

Copyrigh

t Con

scires 2011

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

Copyrigh

t Con

scires 2011

LET’S DO SCRUM

36

Copyrigh

t Con

scires 2011

3/29/11  

13  

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

37

Copyrigh

t Con

scires 2011

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

38

Copyrigh

t Con

scires 2011

SCRUM MYTHS

  SCRUM:   Exposes issues sooner   Increases visibility, leading to faster issue resolution   Facilitates complete feedback & continuous improvements   Allows people to fail and learn from failure   Moves away from the blame culture   Embraces small incremental changes

39

Copyrigh

t Con

scires 2011

3/29/11  

14  

CLASS WRAP-UP

40

Copyrigh

t Con

scires 2011

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

41

Copyrigh

t Con

scires 2011

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 Commitments 42

Copyrigh

t Con

scires 2011

3/29/11  

15  

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

43

Copyrigh

t Con

scires 2011

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 44

Copyrigh

t Con

scires 2011

KEEP SHARING

45

Copyrigh

t Con

scires 2011