Scrum and Agile Processes - nfq.lt · Scrum and Agile Processes: ... – Process Budgeting and...

34
© 2011 OXID eSales AG Scrum and Agile Processes OXID eSales AG 13. November 2012 Dr.-Ing. Oliver Ciupke

Transcript of Scrum and Agile Processes - nfq.lt · Scrum and Agile Processes: ... – Process Budgeting and...

© 2011 OXID eSales AG

Scrum and Agile Processes

OXID eSales AG

13. November 2012

Dr.-Ing. Oliver Ciupke

© 2011 OXID eSales AG

Scrum and Agile Processes: Outline

� Classical processes and their limitations

� Agile processes

� Scrum

– Overview

– History

– Process

� Budgeting and planning agile projects

� Where does Scrum not fit?

� Advanced questions

� Summary

© 2011 OXID eSales AG

Classical Process Models

� Waterfall: adapted from hardware development by DoD 1960s/70s

� Phases separated by activity:0. Planning

1. Requirements analysis

2. Design

3. Implementation

4. Test

5. Maintenance

� Many refinements, e.g.:

– V-Model

– Boehms spiral model(already predecessor to iterative methods)

� PS: „Maintenance” often 80% of overall effort ...

RequirementsAnalysis

Design

Implemen-tation

Test

Maintenance

© 2011 OXID eSales AG

Where’s the problem?

Problems:

� Errors are made in every phase, including requirements specification

� Specification errors are often not detected before system is running

� Late requirement changes are nowadays more norm than exception

� Processes depending on absence of errors are doomed to fail

Effect:

⇒ Changes to requirements cause all phases to be re-done

⇒ Cost of a change is multiplied by number of phases and/or affected documents!

⇒ Approaches to fix this by increased perfection lead to again more steps and then even higher costs

© 2011 OXID eSales AG

“Proof”

� Research found between 40% and 70% of all SW projects failing

� Governmental SW projects require very formal, typically pre-descriptive SW processes (e.g. V-model in Germany)

� Studies report 90% of large governmental projects to fail …

– (There are of course other reasons as well, to be honest: E.g. large governmental projects tend to be a) complex and b) simply too ambitious.)

© 2011 OXID eSales AG

Non-Trivial Systems Cannot be FullySpecified both in Detail and in Advance

• A robot may not injure a human being or, through inaction, allow a human being to come to harm.

• A robot must obey any orders given to it by human beings, except where such orders would conflict with the First Law.

• A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

• A robot may not injure a human being or, through inaction, allow a human being to come to harm.

• A robot must obey any orders given to it by human beings, except where such orders would conflict with the First Law.

• A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

3-Requirements Example:

(Isaac Asimov, “I, Robot”, 1942)

© 2011 OXID eSales AG

Agile Processes

Agile Manifesto:

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

Numerous variants, e.g.:

� Adaptive Systems Development (ASD)

� Crystal

� Scrum

� Dynamic Systems Development Method (DSDM)

� eXtreme Programming (XP)

� Feature Driven Development (FDD)

In a complex environment, following a plan produces the product you intended, just not the

product you need. (Jim Highsmith)

© 2011 OXID eSales AG

Scrum: Overview

� Agile methods are meanwhile the norm in software industry

� Scrum is by far the most widespread agile method

� Advantages compared to other agile methods (e.g. RUP):

– More a library than a framework with less need for company specific adaptation

– Highly standardized and thus easier to apply and to onboard new team members

� Standard reference: http://www.scrum.org/scrumguides/

� Sure enough, there is no such thing as a silver bullet!

© 2011 OXID eSales AG

Some Terms

� Incremental: iterate development and test

� Iterative: iterate requirements, development and test

� Agile: according to agile manifesto

� Scrum: one out of many, but recently the most successfull, iterative software process, that can be practiced in an agile manner

© 2011 OXID eSales AG

History & References

� 1986: Takeuchi and Nonaka describe a iterative production as a rugby approach, compared to a classical relay race approach("The New New Product Development Game" in Harvard Business Review, Jan/Feb 86)

� 1990/91: Ken Schwaber and Jeff Sutherland with others used such an approach at their companies and referred to it as “Scrum”

� 1995: Sutherland and Schwaber present the “Scrum Development Process” (OOPSLA’95 Business Object Design and Implementation Workshop in Austin, Texas)

� 2001: Schwaber and Sutherland are among 17 first signees of the Agile Manifesto

© 2011 OXID eSales AG

Scrum Process

Three Roles

� Scrum Master

� Product Owner

� Team

Four Ceremonies

� Sprint planning

� Daily scrum meeting

� Sprint demo

� Sprint retrospective

Three Artefacts

� Product backlog

� Sprint backlog

� Burndown chart

(Picture: Lakeworks)

© 2011 OXID eSales AG

The 3 Scrum Roles

Scrum Master

• Responsible for ensuring that the Scrum team adheres to Scrum values, practices, and rules

• Helps the Scrum Team understand and use self-organization and cross-functionality

• Responsible for ensuring that the Scrum team adheres to Scrum values, practices, and rules

• Helps the Scrum Team understand and use self-organization and cross-functionality

Product Owner

• Responsible for managing,prioritizing and maintaining the product backlog

• One person, no committee

• May integrate backlog entries from other persons

• Responsible for managing,prioritizing and maintaining the product backlog

• One person, no committee

• May integrate backlog entries from other persons

Team

• Turns product backlog into increments of potentially shippable functionality every sprint

• Teams are self-organized without external interference

• Optimal size is seven people, plus or minus two

• Turns product backlog into increments of potentially shippable functionality every sprint

• Teams are self-organized without external interference

• Optimal size is seven people, plus or minus two

Scrum Master

always ≠Product Owner

Scrum Team

=

SM + PO + Team

© 2011 OXID eSales AG

Optimize ROI along Business Value

Optimal time of market entry

Business valueof stories

Accumulated business value

?

t

Story

© 2011 OXID eSales AG

Some Principles

� Pull instead of push: Tasks are not assigned to individuals, but are taken on by individuals

� PO is always available for clarifying requirements, but may introduce new ideas only in form of prioritized requirements for the next sprint planning

� The team is self-organizing without external interference

� Time boxing both sprints and meetings: time determines scope, not the other way round

© 2011 OXID eSales AG

Technical Analogy

� A pre-descriptive process corresponds to a open-loop controller (German “Steuerung”)

� An iterative process corresponds to a closed-loop controller(German “Regelung”)

Non-trivial processes require the feedback of aclosed-loop control

© 2011 OXID eSales AG

Planning Poker

� Origins in Scrum

� Accelerates Delphi-method

� “Poker”-cards avoid undesired mutual inducement

� (Roughly) Fibonacci numbers to model progression

� Many web applications available, e.g. for distributed teams

© 2011 OXID eSales AG

Sprint Burndown Chart

© 2011 OXID eSales AG

Definition of Done

While the acceptance criteria are specific to a requirement (e.g. user story), the definition of done contains criteria to be met generic to all requirements. Example:

� Code is implemented according to style guides

� Unit tests or other automated tests are written and run successfully

� Documentation is written

� Code review was performed, if one was planned

� The acceptance criteria are tested (automatically or manually)

� Code is checked into version control

� The check-in is connected to the correct ticket in change tracker (e.g. via uniform check-in comment)

� The ticket in change tracker is updated with applicable information status set to completed

© 2011 OXID eSales AG

Advanced Questions

� Where does Scrum not fit?

� Up-front planning

� Fixed price contracts

� Early phase of a new development

� Trailing efforts

� Cards & walls or tools?

� Scrum role questions

� Scaling scrum

� The tea leaves effect

© 2011 OXID eSales AG

Where does Scrum not fit?

� Support tasks and alike

– Tasks arriving asynchronously at arbitrary times

– Reaction before next sprint

– Priority by urgency rather than business value

– E.g. Kanban:

• Limits work in progress instead of sprint length

� Upfront specification required for contract

– Scrum can then be applied in a more incremental manner for increased transparency

� Small scale fixed price settings

– Scrum has smaller benefits, if only few changes are expected and concepts are well understood by all stakeholders

© 2011 OXID eSales AG

Combine with Up-front Planning

Overall Budgeting

•Rough estimation („Guesstimate“, „Hausnummern“) as before

•Decide on feasibility (ROI sufficient?) as before

•Rough estimation („Guesstimate“, „Hausnummern“) as before

•Decide on feasibility (ROI sufficient?) as before

OptimizeROI

•Sort requirements according to benefit / cost ratio

•Produce detail estimations of requirements filling release resp. budget (plus 10-30%)

•Sort requirements according to benefit / cost ratio

•Produce detail estimations of requirements filling release resp. budget (plus 10-30%)

Adjust

•Per iteration (e.g. during sprint planning):

•Estimate newly added and changed requirements

•Re-Prioritize (update order of requirement)

•Adjust release scope, if needed

•Estimate and commit (Scope) of upcoming iteration (sprint)

•Per iteration (e.g. during sprint planning):

•Estimate newly added and changed requirements

•Re-Prioritize (update order of requirement)

•Adjust release scope, if needed

•Estimate and commit (Scope) of upcoming iteration (sprint)

(Picture: Lakeworks)

© 2011 OXID eSales AG

Fixed Price Contracts

Compare common practices in large waterfall contracts:

� Product and functional specification produced by time & material(typically 30% of overall budget)

� Call for bids after specifications(with advantage for specifier…)

� Reserve for change requests(20 – 30% recommended)

� Many projects stopped after concept phase

Frequent approach with Scrum:

� Initial Backlog for budgeting

� Client can re-prioritize items given effort estimate is kept

− (Already a compromise!)

� Requires mutual trust, but not more than otherwise

� "Requirements-Clarification mode" paid by time & material

− Raises the pressure to state clearly what is required

© 2011 OXID eSales AG

Early Phase of a New Development

Trade-offs:

� Optimizing total effort competes with delivering a potentially shippable product

� Technical foundation and architecture tasks vs. potentially shippable product

� “You ain’t gonna need it …” can compete with avoiding large refactorings

� Lacking velocity vs. information for decisions

� Instable backlog vs. need for scoping

© 2011 OXID eSales AG

Trailing Efforts

Should QA tests be done within the sprint or in the sprint after?

� The larger the team, the more likely the sprint after

� Can be similar for other tasks

� “Potentially releasable” then with pipeline of trailing tasks

Within

current sprint:

Within

current sprint:

During next

sprint:

During next

sprint:

Implementation and developer

tests must finish earlier

Limited time for QA tests

According to process

Fixing this sprint’s errors

Dev

Test

Dev

Test

Dev

Test

Dev Dev Dev

Unit & developer tests as in definition of donealways within sprint!

© 2011 OXID eSales AG

Cards or Tools?

In most teams:

� Product Backlog with tool

– Spreadsheet or (preferably) task tracker

– Nowadays Scrum-plugins for many trackers

� Sprint Backlog:

– Cards on the wall for co-located teams

– Tool for distributed teams

• Tracker, since spreadsheet does not scale

• Must support hierarchical decomposition

� Some trackers can visually simulate a task board

© 2011 OXID eSales AG

Scrum Role Questions

“The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.”

� Good practice to include roles beyond development, such as QA or UI designers, into the team

– But how to deal with fractions of FTE capacity?

� Scrum Master or Product Owner or both may be part of the team

– But they should not be the same person(Similar to separation of power / checks and balances in constitutions)

© 2011 OXID eSales AG

Scaling Scrum

� Scrum recommends team sizes of about 7 people

� Larger projects require more structure

� Common organization is Scrum of Scrums

– Formed by scrum masters of individual teams

– Not necessarily daily

© 2011 OXID eSales AG

Story Maps

� A growing number of epics and stories an be visually organizedusing story maps

Epic EpicEpicEpic

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

Epics

Use

r S

tori

es

Priority

Prio

rity

© 2011 OXID eSales AG

How to Grow?

� How to add people?

� My suggestion: Cell division model

© 2011 OXID eSales AG

Scrum on Higher OrganizationalLevels

� See e.g. Dean Leffingwell:

– Team

– Program

– Portfolio

� Different granularity levels of requirements

– (Tasks)

– User Stories

– (Features)

– Epics

– Themes (may describe high level or cross-cutting requirements)

– Projects / Products

© 2011 OXID eSales AG

Balancing Features, Quality andMaintainability

� All types of requirements to be considered:

– Features

– Fixes

– Refactorings

– Non functional requirements

� Feature implementation includes

– Fixing newly introduced defects

– Refactorings allowing a clean implementation of the feature(but not a big overhaul of the system)

© 2011 OXID eSales AG

The Tea-Leaves-Effect

� Tea leaves swim at the very top in the beginning

� Dwindle down inside the cup until they reach the bottom a bit later

� Similar with product backlog items

– Real business value is re-considered

� This occurs in many if not most projects

– How would a pre-specifying project deal with it?

© 2011 OXID eSales AG

Scrum: Summary of Advantages

� Meanwhile the one standard among software processes

� Easier to introduce than many other processes

� Many open questions, but most issues are shared by other approaches

© 2011 OXID eSales AG

OXID eSales AGBertoldstraße 4879098 Freiburg

www.oxid-esales.comE-Mail: [email protected]: +49 (0)7 61 - 3 68 89 - 0

Freecall: 08 00 - 0 99 94 44

And now:

Your questions please!