Agile and Scrum Workshop

Saves the day.
Agile and Scrum Workshop
Agile & Scrum
Rainer Stropek
software architects gmbh
http://www.timecockpit.com
rainer@timecockpit.com
@rstropek
Workshop
Web
Mail
Twitter

Agile
development – what’s
different?
Agenda
Scrum
basics – how does it
work?
Operational
excellence – how to
get the most our of
Scrum?
Discussion
Open Space, interview
Source: Flickr (Common Creative)Source: MSDN
Source:Wikipedia
Source: Flickr (Common Creative)

Agenda
 Session 1: Basics of Agile Development
08:00-09:15
Coffee break 09:15-09:30
 Session 2: Scrum
09:30-11:00
Coffee break 11:00-11:15
 Session 3: Operational Excellence With Scrum
11:15-12:30
Lunch 12:30-13:30
 Session 4: Discussion, Interview
13:30-15:00

Workshop
 Please mute your phones and close mail apps
We will pay attention to time management  breaks for phone calls and/or mails
 Stay open for new approaches
Scrum might be different to what you are used to
 Make it interactive
Ask questions, provide feedback
Participate in the Open Space discussion in session 4

Waterfall Model
Traditional Process
…or variants of it (e.g. V-Model); read more in Wikipedia
Big Design Up Front
Detailed Product Planning
Requirements elicitation
Software Design
Carefully think through and design the
end product.
Testing
Make sure that implemented product
works how it was designed in
product planning stage
Documentation
Reduce dependencies on certain
people/teams
Requirements Specification
Design Design Document
Implementation Product & Doc
Testing Acceptance
Maintenance
Documentation

Traditional Process
 It is simple, logical, and easy to understand
Before you build something, you have to know what to build
 Save money by emphasizing up-font planning phase
„Show me how you started your project and I can tell you how it will end“
Bugs found in early project stages are less costly to fix
Goal: Predictable, repeatable process

Traditional Process
 Reduce risk by taking enough time to plan
Predict features, quality, milestones, costs, etc.
Well researched techniques for requirements elicitation and management including
prototypes
 Documentation is very important
Specification might be part of a contract
Get independent of people/teams
Goal: Predictable, repeatable process

Traditional Process
 All good ideas must come at the beginning
A great idea in a late process cycle becomes a threat
 Written documentation only makes us feel safe
It proves that we have worked hard, it preserves knowledge even if people change
Will it be read? Is it complete?
“It feels that we are spending more time writing documents than producing software”
 “Aha” effect
Best ideas often appear during first hands-on experiences
Deliver what has been asked for (“written in stone”), not what is needed
It seams logical - what’s wrong?

Traditional Process
 Times are changing
Planning (or guessing) what the future will bring is hard, if not impossible
Requirements often already change during (extensive) planning phase
There is a cost in being able to repeat in a world that changes fast
 It is not much fun for a team
A rigid, change-resistant process destroys team work
 “If it does not work, we just have to do it better!”
It seams logical - what’s wrong?

Stacey’s Agreement and Certainty Matrix
Plan-driven
Approach
Read more…
Needed for highly structured
physical environments
E.g. manufacturing, construction
industries
Might work for simple projects
Predictive
Fails for complicated projects
Adaptive needed
Prototyping might help
Completely unsuitable for
complex projects
Research projects
Experimental development
Technology
Close to
certainty
Far from
certainty
Requirements
Far from
agreement
Close to
agreement

Targetting Economy of Scope
Software Factory
Custom Code
Project A
Custom Code
Project B
Base Class Library

Software Factory
Custom Code
Project A
Custom Code
Project B
Base Class Library
Common Components

Software Factory
Custom
Component
Project A Project B
Base Class Library
Common Components
Custom
Component
Custom
Component
Custom
Component
Model, Extensions, Configuration, Scripts Model, Extensions, Configuration, Scripts
Patterns, Practices, Guidelines

Software Factories
Multiple implementations (=Copies) of
the same design/product
 Cost per unit of output generally
decreasing with increasing scale as
fixed costs are spread out over more
units of output
 Examples
Manufacturing
Software (e.g. shipping versions on DVDs)
Economy of Scale
Production of multiple designs and their
initial implementations
 Similar designs based on common
techniques and technologies
 Examples
Construction industry (e.g. bridges, sky scrapers)
Custom software in a specific domain
Economy of Scope

Traditional Process
"There are two approaches, evolutionary and single step [waterfall], to full capability.
An evolutionary approach is preferred. … [In this] approach, the ultimate capability
delivered to the user is divided into two or more blocks, with increasing increments
of capability...
software development shall follow an iterative spiral development process in which
continually expanding software versions are based on learning from earlier
development.“ US Department of Defense, Acquisition Strategy Considerations, Source: Wikipedia
Many organizations are turning away from waterfall

Manifesto for Agile Software Development
Basic Ideas
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to 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
That is, while there is value in the items on the right, we value the items
on the left more.
Source: agilemanifesto.org (2001)
Welcome changes
Response flexible and fast
Lightweight development
methods
Iterative and incremental
development
Self-organizing, cross-
functional teams

Iterative Approach in Agile Development
Incremental
Development
Source: MSDN
Adaptive Planning
Time-boxed iterations
E.g. Sprints in Scrum,
Iterations in XP
Regular interactions
E.g. Business and development,
team members

Agile Principles
 Early and continuous delivery of valuable software
Frequent software delivery (weeks to a couple of months; the shorter the better)
Working software is the primary measure of progress
 Welcome changing requirements
Changes are welcome for the customer's competitive advantage
 Business people and developers work together daily
Convey information preferably by face-to-face conversation
Co-location is preferred

Agile Principles
 Build projects around motivated individuals
Cross-functional, self-organizing team of typically 5-9 people
Sustainable pace avoiding crunch-time and “death marches”
 Technical excellence and good design enhance agility
The best architectures, requirements, and designs emerge from self-organizing teams
 Simplicity is essential
Maximize the amount of work that is not done
This is what lean development is all about!

Agile Principles
 Regularly reflect on how to become more effective
Truth in every communication
Facilitate positive conflicts
Read more at agilemanifesto.org

Adaptive vs. Predictive Process
Release Planning
Iterative approach instead of big up front planning
Very detailed plan about
short-term work
Shared across entire team
Mid-term: Committed
stories/features
Regularly shared/revised with business
Long-term: Strategic level,
range of functionality
Continuously revised throughout the
project
Time
We know exactly
what we are going
to do next week
We have an idea of
where we are going
to invest time in the
following month
We have a mission
statement for the
release in six months

Lean/Agile Methods
 Lean software development
 Extreme Programming (XP)
 Kanban
 Scrum (more about this later)
 …

XP vs. Scrum
Scrum XP
Product owner Customer
Scrum master XP coach
Team Team
Sprint Iteration
Sprint planning meeting Planning game

Kanban
Kanban Core Values
Source: E. Brechner: Too much of a good thing? Enter Kanban
Visualize your work
Immediately identify work that is
waiting and will likely never be
finished
Limit Work in Progress
Constrain work in progress to
reduce cycle times

Reduce „Waste“ with Lean
 Overproduction
Don‘t produce more than you need
Too complex, too general, too extensible, …
Solution: Frequently reprioritize work based on business value
Image Source: Lacey M.: The Scrum Field Guide

 Depth first instead of breadth first
Spec, design, code, and test limited number of features completely before moving on
Stay focused on producing value instead of infrastructure
Fail early
 Transportation
Reduce waiting time between team members and teams
E.g. build times, branching, incompatible office hours
 Motion
Know how you spend your time and reduce time used to find stuff
E.g. bug tracking system instead of emails, source code repository

 Over-processing
Over-engineering, e.g. optimize code that is performing adequately
TDD, SDD
 Inventory
Undelivered work, typical for breadth-first development
You can’t deliver value, you can’t get feedback
 Waiting
Optimize the flow of features by having the right amount of PMs, Devs, and Testers
E.g. Drum-Buffer-Rope concept of Theory of Constraints (TOC)

Video: Lucy Candy Factory
Remember The
Agile Values?
Source: YouTube
Self-organizing, cross-
functional team
Sustainable pace avoiding
crunch-time
Truth in every communication

 Defects
Reduce the need for rework by e.g. TDD
Detect architectural issues by doing depth-first development

Limits/Problems of Agile
 Primary Goal: Predictability,
stability, and high assurance
Can be based on a contract
 Scales better to large projects
with many participants
 Covers a broad spectrum
Used in contracted software development,
addresses product line, organizational, and
enterprise concerns that span multiple projects
Plan-Driven Approach
 Primary Goal: Rapid value and
responsiveness to change
Needs a dedicated, collocated customer
 Works best for small to medium
sized teams
 Concentrates on a specific project
Still need for high-level planning, syncing
milestones across teams, cross-team scenario-
focused engineering, …
Agile Approach

Limits/Problems of Agile
 One-way, explicitly documented
knowledge
 Formally complete, consistent,
traceable, and testable
specifications
 Architecture-based design
Take advantage of software reuse e.g. across
product lines
Plan-Driven Approach
 Frequent, person-to-person
interaction
 Adjustable, informal stories with
frequent reprioritization and
iterative refinement
 Simple design
Risk of costly “architecture breakers”
Agile Approach

Agile Myths
 Myth #1: Agile = Scrum
There are many agile methods, Scrum is one of them
 Myth #2: In agile projects there is no planning
„What XP teams find valuable is the collaboration, elicitation, and balancing of priorities in the planning
act itself. The plans that result have a short half-life, not because they are bad plans, but because their
underlying assumptions have a short half-life.”
(Kent Beck, co-creator of XP)
 Myth #3: Agile means no documentation
Remember the agile manifesto: “while there is value in the items on the right, we value the items on the
left more”. Essential documentation is still valuable for customers, partners, and cross-team
dependencies

Agile Myths
 Myth #4: Agile means no up-front design
Technical excellence and good design are key. However, value responding to change more than sticking
to your original plan.

Misconceptions and Realities
Agile Myths
Source: Boehm B., Turner R.: Balancing Agility and Discipline, Figure 2-3
YAGNI = You ain‘t gonna
need it

Dimensions Affecting Method
Agile Myths
Source: Boehm B., Turner R.: Balancing Agility and Discipline, Figure 2-2

Saves the day.
Q&A
Rainer Stropek
software architects gmbh
rainer@timecockpit.com
http://www.timecockpit.com
@rstropek
Thank your for coming!
Mail
Web
Twitter

What is Scrum?
 Scrum is a framework for developing
and sustaining complex products
Including, but not limited to, software
Read the Scrum Guide
 Transparency
Process must be visible to those responsible for the outcome
Common understanding of what is being seen (e.g. what means “done”?)
 Inspection
Frequently inspect Scrum artifacts and progress
 Adaption
Process or the material being processed might need adjustment
Source: Flickr (Common Creative)

The Team
 Product Owner
Customer or customer representative
Responsible for maximizing the value of the product and the work of the team
Manages the Product Backlog
 Development Team
Self-organizing, cross-functional, without hierarchy
Typically three to nine people
 Scrum Master
Responsible for ensuring Scrum is understood and enacted
Servant-leader for the Scrum Team
Building a team of people
instead of using a pool of
resources

The Team
 A dedicated person
Can represent a committee
 The only one who manages the
product backlog
Based on the company’s vision or roadmap
Can delegate the work, but is still accountable
 Clarifies the requirements for the
development team
 This is a very demanding job!
Product Owner
 A dedicated person
If possible, don’t mix roles for a single person
 Builds and maintains the team
Like a coach
 Coordination, collecting status
E.g. manage daily standup meeting
 Provide balance against the Product
Owner
Support and protection of the team
Scrum Master

The Events – Sprint
 Time-box
(One month or less) during which a “Done”, useable, and
potentially releasable product increment is created
 Constant sprint goal
Quality goals also must not be changed
 Scope may be clarified and re-
negotiated
 In extreme cases cancel the entire
sprint

Sprint Planning Tools
Tools
Whiteboard or software?
Whiteboard
Software support for
backlog management
Easier to use if not collocated

Work item management integrated with source control, build, and test
Team Foundation Server/Services

Project management
Atlassian Jira

Project management
Rally

The Events – Sprint Planning
 Time-boxed
Typically eight hours for a one-month sprint
 Two parts
What will be done in the sprint?
How will it be done?
 Input: Ordered Product Backlog
Derive Sprint Backlog based on the team’s velocity
 Output: Sprint Backlog
User Stories
Task for short-term stories

The Events – Daily Scrum
 15 Minutes, Time-box
Synchronize, plan next 24 hours
 Goals
Improve communications
Identify and remove impediments
Highlight and promote quick decision-making
Improve the Dev’s level of project knowledge
 Questions to ask
What did you do yesterday?
What will you do today?
What blocking issues do you have?
What is your confidence (1-10) that the team will
accomplish the goal of this sprint?

The Events – Sprint Review
 Time-boxed
Typically four hours for a one-month sprint
 Demo the work in an environment as
close to production as possible
Build trust by constantly showing a high-quality product
 Review Product Backlog

The Events – Retrospective
 Time-boxed
Typically three hours for a one-month sprint
 Opportunity for process
improvement
How do we work together?
What works? What does not work?

Product Backlog
 The single source of requirements for any changes to the product
Remember YAGNI?
 Constantly evolves as the product and the environment in which it will
be used evolves
 Ordered by value, risk, priority, and necessity
Higher ordered Product Backlog items are clearer and more detailed
The lower the order, the less detailed
 Product Backlog grooming
Product Owner and the Development Team collaborate on the details of Product Backlog items
Can consume up to 10% of the Development Team’s time

Source: http://www.mitchlacey.com
Scrum Framework Flow Diagram

Definition of „Done“
„Done“ Checklist
Source: Lacey M., How Do We Know When We Are Done?
Shared understanding of
what it means for work to
be complete
Definition of “Done” will
expand to include more
stringent criteria for
higher quality over time

Engineering Practices
Goal Tool
Shared Code Ownership Static Code Analysis
(e.g. Style Cop, Code Analysis)
Framework Design Guidelines
Documentation
(e.g. Sandcastle)
Automated Tests Test Driven Development
Automated Unit Tests
(e.g. MS Test, MS Fakes)
Automated Integration and
Acceptance Tests

Goal Tool
Pair Programming, Code Review Automated Code Review Process
(e.g. Team Foundation Server)
Refactoring Editor Tools in the IDE
(e.g. Visual Studio, Re-Sharper)
Continuous Integration
Frequent Check-Ins
Automated build, branching strategy
Enhance Quality Gated check-in

 Build Engineering into Product Backlog
Product owner must understand and be willing to make the long-term investment
 Work on your “Done” checklist
E.g. code must be checked-in on main branch (gated check-in)
 If necessary, care for appropriate training

Effort Estimation and Scrum
Principles
How long does it take to build something more-or-less unknown?
Use story points to express
relative complexity
Try to learn about the team‘s
velocity
„Done“ story points per sprint
If necessary use a small
reference story for velocity
prediction
Constantly track project‘s
progress
User Stories
„As a […]
I want to […]
so that […]“
Estimation
Remaining
work in
hours
Story Points
„T-Shirt Sizing“
Use a XS story
as a reference

Burndown Chart
Monitor Progress
Source: Lacey M.: The Scrum Field Guide
Burndown chart not a
mandatory artifact in
Scrum
Still popular in many Scrum
teams

Story Decomposition
What‘s a Story?
Epics
Importance of grooming
Describes the smallest
action that a user would
typically want to do, or it
is the smallest piece of
functionality with
business value
Tasks should be completed
in no more than two days

How large is an elephant?
Fermi Method
Estimation
Making justified guesses
about quantities that
seem impossible to
compute given limited
available information
“How many piano tuners
are there in Chicago?”
3-4m, largest one was
4.21m large and 10.39m
long (Source: Wikipedia)

Calculate circumference of the earth
What to measure
and/or plan?
Eratosthenes (ca. 276-194 B.C.), read more in Wikipedia
Plan/measure what‘s
import instead of what‘s
easy
Constantly monitor and
update your plan

Release planning
Planning the
Unknown
Inputs
An estimated, ordered, and
prioritized product backlog
The team velocity
A sprint timeline

Add a Degree of Confidence
 „We estimate that we will finish the project within two
months“
 “Management wants to launch the product before
Christmas. We estimate that we can finish the project until
then.
Our goal is to
are committed to finishing

Add a Degree of Confidence
 Our estimation is that the project…
…will be finished in <= two months (75%)
…will take us between two and three months (15%)
…will take us more than three months (10%)
 Use story points, velocity, sprint schedule, and confidence
intervals for release planning and risk management

Estimation
How good are you?
How good do you estimate?
Estimate width (“between …
and …”) of an Airbus
A380 with a confidence
interval of 90%
Estimate the height
(“between … and …”)Width of an Airbus
A380?
Wheel of fortune
where 9 of 10 fields
win

A house as high as an
Airbus A380 is a
„Hochhaus“ in Germany
Source: Airbus

Frage Kleinste
Schätzung
Größte
Schätzung
Richtig?
1938 hat eine Englische Dampflokomotive einen Geschwindigkeitsrekord
aufgestellt. Wie schnell war sie (in km/h)?
In welchem Jahr hat Newton seine Gravitationsgesetze („Mathematische
Prinzipien der Naturphilosophie“) veröffentlicht?
Wie breit (inch) ist eine typische Visitenkarte in den USA?
In welchem Jahr wurde das Internet als militärische
Kommunikationsinfrastruktur eingeführt (damals als „Arpanet“ bezeichnet)?
In welchem Jahr kam Wiliam Shakespeare zur Welt?
Wieviele KM Luftlinie liegen zwischen New York und Los Angeles?
Wieviel Prozent eines Rechtecks werden durch einen Kreis mit gleicher Breite
abgedeckt?
Wie alt war Charlie Chaplin als er starb?
Wie hoch ist die Oberflächentemperator der Sonne (in Grad Celsius)?
Wie groß ist die Fläche des Kontinents Asien (in km²)?
Summe der erreichten Punkte

Frage Antwort
1938 hat eine Englische Dampflokomotive einen Geschwindigkeitsrekord
aufgestellt. Wie schnell war sie (in km/h)?
202 km/h
In welchem Jahr hat Newton seine Gravitationsgesetze („Mathematische
Prinzipien der Naturphilosophie“) veröffentlicht?
1685
Wie breit (inch) ist eine typische Visitenkarte in den USA? 3.5
In welchem Jahr wurde das Internet als militärische Kommunikationsinfrastruktur
eingeführt (damals als „Arpanet“ bezeichnet)?
1969
In welchem Jahr kam Wiliam Shakespeare zur Welt? 1564
Wieviele KM Luftlinie liegen zwischen New York und Los Angeles? 2.451
Wieviel Prozent eines Rechtecks werden durch einen Kreis mit gleicher Breite
abgedeckt?
78,5%
Wie alt war Charlie Chaplin als er starb? 88
Wie hoch ist die Oberflächentemperator der Sonne (in Grad Celsius)? 6.000°C
Wie groß ist die Fläche des Kontinents Asien (in km²)? 44,39 Mio. km²

A 90% confidence interval is more a 30% interval
Cognitive Bias
Source: McConnell et al: Aufwandsschätzung bei Softwareprojekten
You have to train your
ability to estimate

Estimating Costs
Hubbard’s Rule of
Five
How to estimate when agile?
There is about 93% probability
that the median (and mean)
of the entire population is
between the highest and the
lowest values of a sample of
five
Prerequisite: Gaussian
distribution
Source: Hubbard D.: How To Measure Anything
Average
Probability of an
estimation being on this
side of the bell curve?
Probability that a
second estimation is
also on this side of the
bell curve?
Probability that five
estimations in a row are
on this side of the bell
curve?
50%
50% * 50% = 25%
50% * 50% * 50% * 50% * 50% = 3,125%
Estimation

Estimating Costs
Statistics
How to estimate when agile?
Statistics can be dangerous
OperationalCosts/RGU[€]
Natural minimum
Endless potential for e.g.
unforeseen problems

Mediokristan
Extremistan
Sources:http://www.flickr.com/photos/akc77/3370167184/,
http://www.flickr.com/photos/thomashawk/337323578/
UnderCreativeCommonsLicense

Black Swan
Black Swan
http://www.flickr.com/photos/essjay/224318029/
Under Creative Commons License
You cannot predict the future
exactly
Small: Heisenberg
Big: Complexity
We do not live in the
asymptote, we live in the real
life
We tend to believe in statistics
Look for positive black swans
Source: Taleb N.: The Black Swan

Agile and Scrum Workshop

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Agile and Scrum Workshop

Similaire à Agile and Scrum Workshop (20)

Dernier

Dernier (20)

Agile and Scrum Workshop

Notes de l'éditeur