1. Agile Software Development using Scrum
Derek Mathieson Group Leader Advanced Information System
CERN – Geneva, Switzerland

2. FREQUENTLY ASKED QUESTIONS ON W3
Speaker Background
Frequently Asked Questions on WWW
FREQUENTLY ASKED QUESTIONS ON W3
An FAQ list is really a cop-out from managed information. You should be able to find everything you want to know by browsing from the WWW project page, as everything should be arranged in a logical way. Here though are things which maybe didn't fit into the structure, with pointers to the answers which maybe did. Its an experiment, started May 92. The questioners are anonymous.
I am just starting: how do I find out more?[1]
How does www keep track of the available servers?[2]
How does W3 compare with WAIS and Gopher[3] ?
How do I create my own server[4] ?
1-10, Up, <RETURN> for more, Quit, or Help:
Currently:
Group Leader of AIS since January 2010
Previously:
Section Leader EDH (2000)
Software Developer at CERN (1994)
Software Developer at SSC in Texas (1992)
CERN Fellow (1990)
CERN Technical Student (1989)
Software Developer (1986)

3. Agenda Traditional Software Development What is Agile?
The Agile Manifesto
Agile Methods
SCRUM
CERN

4. Traditional Development

5. Waterfall Model Time Requirements Design Implementation Verification
Maintenance
The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, though Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.
For example, in one key study of 1,027 IT projects in the United Kingdom, Thomas [2001] reported that “scope management related to attempting waterfall practices was the single largest contributing factor for failure.” The study’s conclusion:
[T]his suggests that the approach of full requirements definition, followed by a long gap before those requirements are delivered is no
longer appropriate. The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed, and that spending significant time and effort in fighting the to maintain the maximum level is inappropriate.
Time

6. Waterfall in Practice
Safeguard - Ballistic Missile Defence System
The project was delivered according to specifications
Cost: $25 Billion (not adjusted)
, 5407 person years
Operational for 133 days
Project terminated in 1978
‘By the time the 6-year anti-missile system project was completed, the new missiles were faster than the antimissile missiles’

7. Waterfall in Practice Safeguard - Ballistic Missile Defence System
Cost: $25 Billion (not adjusted)
, 5407 person years
Operational for 133 days - Project terminated in 1978
‘By the time the 6-year anti-missile system project was completed, the new missiles were faster than the anti-missile missiles’
‘By the time the 6-year anti-missile system project was completed, the new missiles were faster than the anti-missile missiles’

8. Spiral Model ob j c v s r o l k 3 ve op m T 4 P h x it og 1 . D e t rmn ob j c v s 2 I d f y a nd r o l k 3 ve op m T 4 P h x it og C u R q p ce
Prototype 1
Prototype 2
Operational
Prototype g as V
& w
The spiral model was defined by Barry Boehm in his 1986 article "A Spiral Model of Software Development and Enhancement".
The US military has adopted the spiral model for its Future Combat Systems program. The FCS project was cancelled after six years ( ), it had a 2 year iteration (spiral).

9. Why Software Is Different?
Software is Complex
Technology Changes Rapidly
Requirements are Incomplete
Change is Considered Easy
Software Design is Research
Construction is Actually Design
Change is Inevitable

10. Software is Complex “Computer programs are the most intricate,
delicately balanced and finely interwoven
of all the products of human industry to date”
[James Gleick 1992]

11. Software is Complex

12. Software is Complex

13. Software is Complex

14. Software is Complex

15. Why Software Is Different?
Software is Complex
Technology Changes Rapidly
Requirements are Incomplete
Change is Considered Easy
Software Design is Research
Construction is Actually Design
Change is Inevitable

16. Technology Changes Rapidly

17. Requirements Are Incomplete

18. An Experiment

19. Project Description ‘Personal Transport Device’ Usable outside
Weather proof.
Reasonably Strong
Usable for several years.
Stable, relatively easy to use
Probably 4 wheels?

20. Implementation ?

21. “Many projects fail because their developers fail to build the right thing”
—Grady Booch

22. Why Software Is Different?
Software is Complex
Technology Changes Rapidly
Requirements are Incomplete
Change is Considered Easy
Software Design is Research
Construction is Actually Design
Change is Inevitable

23. Cost of Change Curve

24. Why Software Is Different?
Software is Complex
Technology Changes Rapidly
Requirements are Incomplete
Change is Considered Easy
Software Design is Research
Construction is Actually Design
Change is Inevitable

25. Introducing Agile Development

26. What is Agile?

27. (Oxford English Dictionary)
What is Agile?
Agile:
Having the faculty of quick motion; nimble, active, ready.
Agile software development:
A group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
(Oxford English Dictionary)
(Wikipedia)

28. Why Agile?

29. The Iron Triangle Scope Pick Two Quality Schedule Traditional
Development
Scope
Pick Two
Fred Brooks “The Mythical Man-Month” (1975):
“Adding manpower to a late software project makes it later.” - Brooks's law
The Chaos Report is the first survey made by the Standish Group.
Quality
Schedule

30. The Chaos Report Standish Group (1995)
Software Delivery
31.1% of projects will be canceled before completion.
52.7% of projects will cost over 189% of their original estimates.
16.2% of software projects are completed on-time and on-budget
The Chaos Report Standish Group (1995)

31. The Agile Manifesto (2001)
Early and continuous delivery of valuable software
Welcome Change
Deliver Often
Customers and developers must work together
Best possible people, tools and workplace
Emphasis on face-to-face communication
Working software is the best measure of progress
Constant sustainable progress
Focus on technical excellence and good design
Simplicity
Self-organizing teams
Regular reflection on improvements
In February 2001, 17 software developers met at a ski resort in Snowbird, Utah, to discuss lightweight development methods. They published the "Manifesto for Agile Software Development" to define the approach now known as agile software development. Some of the manifesto's authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto's principles.

32. The 4 Agile Values
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

33. The Iron Triangle Scope Pick Two Quality Schedule Traditional
Development
Scope
Agile
Development
Pick Two
Fred Brooks “The Mythical Man-Month” (1975):
“Adding manpower to a late software project makes it later.” - Brooks's law
The Chaos Report is the first survey made by the Standish Group.
Quality
Schedule

34. Iterative Development
Regular releases to customer
‘Time-boxing’
Normally 2 – 6 weeks
Adjust design as the project progresses
Requirements
Analysis & Design
Implementation
Initial
Planning
Planning
Deployment
Evaluation
Testing

35. Agile Methods Scrum Feature Driven Development (FDD) Lean
Extreme Programming (XP)
RUP
Kanban
In 1995, Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA ’95 in Austin, Texas, its first public appearance. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. In 2001, Schwaber teamed up with Mike Beedle to describe the method in the book "Agile Software Development with Scrum".

36. SCRUM

37. What is SCRUM?

38. What is SCRUM?
Scrum is a framework for iterative, incremental development using cross-functional, self-managing teams. It is built on industry best practices, lean thinking, and empirical process control.
Ken Schwaber, 2006
co-creator of SCRUM

39. Method Comparison Jeff Sutherland, ‘The Scrum Papers’ 2010
Waterfall
Spiral
Iterative
Scrum
Defined processes
Required
Planning & Closure only
Final product
Determined during planning
Fixed during planning
Set during project
Project cost
Partially variable
Completion date
Responsiveness to environment
Planning only
Planning primarily
At end of each iteration
Throughout
Team flexibility,
creativity
Limited - cookbook approach
Unlimited during iterations
Knowledge transfer
Training prior to project
Teamwork during project
Probability of
success
Low
Medium low
Medium
High
Jeff Sutherland, ‘The Scrum Papers’ 2010
co-creator of SCRUM

40. SCRUM in Pictures

41. SCRUM in Practice

42. Distinct Users per month Ratio Signatures/Document
EDH Statistics
14,500 active users
25k Documents/month
60k Signatures/month -
5,000
10,000
15,000
20,000
25,000
Documents per month
Distinct Users per month
0.00
0.50
1.00
1.50
2.00
2.50
3.00 -
10,000
20,000
30,000
40,000
50,000
60,000
Signatures per month
Ratio Signatures/Document

43. EDH Development Team 4 Staff 3 Project Associates 1 Fellows
1 or 2 Students (9 month contract)
1.8 million lines of code
~1000 3rd line support calls/year

44. EDH Development B.C. B. Before SCRUM C.
Constant Developer Interruptions
Low efficiency
Delivery was often late
Poor estimation – many unknowns
Scope Creep
Specification constantly changing
Everything is Free
Some features never used
Before SCRUM C.

45. SCRUM Vocabulary Product Owner Product Backlog Scrum Team
Sprint Planning
Scrum Master
Daily Scrum
Sprint Backlog
Sprint Review Meeting

46. Chickens and Pigs... Involved Committed
A number of roles are defined in Scrum. All roles fall into two distinct groups—pigs and chickens—based on the nature of their involvement in the development process. These groups get their names from a joke about a pig and a chicken opening a restaurant:
A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”
So the “pigs” are committed to building software regularly and frequently, while everyone else is a “chicken”—interested in the project but really indifferent because if it fails they’re not the pigs—that is, they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to get in the way of the actual Scrum project.

47. The Product Owner Typically a Product Manager, Internal Customer, etc.
Responsible for:
Providing and maintain a prioritised “Product Backlog”
Responsive to questions during a sprint

48. The Product Backlog A list of all desired work on the project
Usually a combination of
story-based work:
“let user search and replace”
task-based work:
“improve exception handling”
Prioritised by the Product Owner
Priority should be (ideally) based on “Business Value”
“Cost” assigned by the Scrum Team

49. The Scrum Team Teams are self-organising Cross-functional
QA, Programmers, UI Designers, Technical Writers, etc.
Assign Cost to each Item on the Product Backlog
Commit to the “Sprint Goal”

50. Agile Estimation Planning Poker
Speed up the estimation process by limiting the number of choices (i.e. number of cards).
Avoid a false sense of accuracy for high estimates.
Encourage the team to split large stories into smaller ones.

51. The Scrum Master
Responsible for enacting Scrum values and practices (The Process)
Main job is to remove obstacles which affect the team
Typical obstacles could be:
My ____ broke and I need a new one.
I still haven't got the software I ordered.
I need help debugging a problem with ____.
I'm struggling to learn ____ and would like help.
The GL has asked me to work on something else "for a day or two."

52. The Sprint Planning Meeting
Attended by:
Product Owner, Scrum Master, Scrum Team, and any interested and appropriate management or customer representatives.
Product Owner describes the highest priority features to the team.
Collectively the Scrum Team and the Product Owner define a “Sprint Goal”

53. “Implement Bulk Emailing.”
The Sprint Goal
A short “theme” for the sprint:
The SCRUM Team commit to this goal.
“Create Reports.”
“Create Working Form.”
“Implement Workflow.”
“Implement Bulk ing.”

54. The “Sprint” Fixed “Time-Box” (we chose 2 weeks)
Product is designed, coded, and tested during the sprint
Daily Scrum Meetings
Produce demonstratable, working, new functionality.

55. The Daily Scrum Anyone Invited Led by Scrum Master
15 minutes, every day
Not for problem solving
Three questions:
What did you do yesterday
What will you do today?
What obstacles are in your way?

56. Process repeats...
2 Weeks Pass…

57. The Sprint Review Meeting
Team presents what it accomplished during the sprint
Typically takes the form of a demo of new features or underlying architecture
Participants
Management
Product Owner
Other engineers …

58. Release Sprint Concentrate on preparing for production:
No new features
Last minute bugs, typos, layout issues, etc.
Translation (if not done already)
Desktop Icons
Communication, Bulletin Articles, etc.

59. Scrum– value driven not plan driven
Empower lean teams to deliver more software earlier with higher quality.
Demonstrate working features to the customer early and often so the customer can inspect progress and prioritize change.
Deliver exactly what the client wants by directly involving the customer in the development process.
Provide maximum business value to the customer by responding to changing priorities in real time.
Jeff Sutherland, 2007
co-creator of SCRUM

60. SCRUM in Industry
The most profitable software product ever created (Google Adwords) is powered by Scrum.
The most productive large project with over a million lines of code (SirsiDynix) used a ... Scrum implementation.
Jeff Sutherland, 2010
co-creator of SCRUM

61. SCRUM in Industry Organizations using Agile methods
Agile Adoption Survey, March 2008
State of the IT Union Survey, July 2009

62. Source: Forrester Research, Inc. 2009
SCRUM in Industry
Scrum
10.9%
Agile Modeling
6.0%
Feature-driven development (FDD)
3.8%
Test-driven development (TDD)
3.4%
eXtreme Programming (XP)
2.9%
Lean development
2.1% A
gile, 35%
Microsoft Solutions Framework (MSF) for Agile
1.8%
Agile Data Method
1.6%
Adaptive Software Development (ASD)
1.3%
Six Sigma
0.9%
Crystal
0.3%
Behavior-driven development (BDD)
0.2%
Dynamic Systems Development Method (DSDM)
0.2%
Do not use a formal process methodology
30.6%
Iterative development
16.3%
Rational Unified Process (RUP)
2.7% I
terative, 21%
Spiral
1.6%
Waterfall
8.4%
Capability Maturity Model Integration (CMMI)
2.5% W
aterfall, 13%
ISO 9000
2.5%
Base: 1,298 IT professionals
Source: Forrester Research, Inc. 2009

63. Visible benefits of SCRUM
Time-Boxed:
Maximum investment known up-front
Tackle most valuable features first
Focus on working, tested, documented product features

64. Conclusions Product Owner: Active Participant Can “see” product evolve
Know the cost of each feature
Good Product Owners can be hard to find

65. Conclusions Team: Work closely with Product Owner
Know the “Value” of each Feature
Known Start and End of Project
Efficient, highly focused development
Strong Team Spirit

66. Why SCRUM? What I wanted: What developers wanted:
Manage Product Requirements
Provide Visibility to Clients
Better manage developer time
A more repeatable development process
What developers wanted:
Something ‘light’
Task management
Communication

67. What did we adapt? 2 week Sprint Release Sprint Not everyone ‘SCRUMs’
Full time support staff
Technology
(Almost) Everyone does support too
Some people have several roles

68. Implementation Barriers
Some clients insist all features must be in final product
Daily Sprint meetings = Interruption
Poor Product Owner
Not final decision maker
Doesn’t want to be involved
More than one (that don’t agree!)
Scope
Quality
Schedule
Pick Two

69. Lessons Learned Be careful of the choice of Product Owner
Use tools to simplify admin
Excel, whiteboards, ScrumWorks, JIRA, …

70. Product Backlog Window

71. Sprint Detail Window

72. Web Client

73. JIRA + GreenHopper

74. Jira IDE Integration (IDEA)

75. Does it Increase Productivity?
Probably… 
Did it make development work easier?
Yes…
Communication is better
Estimates are better
Planning is easier
Customers are happier

76. Thank You

77. Yes… but…
“I like writing software, but I don’t like doing the other development stuff which we are not forced to do here.”
SCRUM lets you:
Focus on valuable development
Use tools to minimise admin

78. Yes… but… “It might help, but we have multiple projects per person.”
So do we…
It’s simpler to have only one, but sometime schedules don’t allow…
Time-boxing helps to reduce parallel activities.

79. Yes… but… “Management won’t agree” SCRUM offers: Better Planning
Deadlines met
Minimise unnecessary development
Happy Clients

80. “Our clients won’t agree”
Yes… but…
“Our clients won’t agree”
Tricky one…
SCRUM needs Client commitment
SCRUM exposes the cost of features
SCRUM makes the client choose
In return they get:
Transparency
License to change their minds
Met deadlines

81. Yes… but…
“I like X from Scrum, but not Y, I might try X.”
Do X!

82. Yes… but… “You are trying to get us to work more for less! No way!”
SCRUM lets you:
Focus on useful work

83. Yes… but…
“Our project X is special and not industry so we don’t need a process.”

84. Thank You