Injustice - Developers Among Us (SciFiDevCon 2024)
Â
Agile and Scrum Workshop
1. 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
2. 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)
4. 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
5. 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)
6. Waterfall Model
Traditional Process
Agile and Scrum Workshop
âŠ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
7. 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
8. 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
9. 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?
10. 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?
11. Staceyâs Agreement and Certainty Matrix
Plan-driven
Approach
Agile and Scrum Workshop
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
12. Targetting Economy of Scope
Software Factory
Custom Code
Project A
Custom Code
Project B
Base Class Library
13. Targetting Economy of Scope
Software Factory
Custom Code
Project A
Custom Code
Project B
Base Class Library
Common Components
14. Targetting Economy of Scope
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
15. 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
16. 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
17. Manifesto for Agile Software Development
Basic Ideas
Agile and Scrum Workshop
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
18. Iterative Approach in Agile Development
Incremental
Development
Agile and Scrum Workshop
Source: MSDN
Adaptive Planning
Time-boxed iterations
E.g. Sprints in Scrum,
Iterations in XP
Regular interactions
E.g. Business and development,
team members
19. 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
20. 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!
21. Agile Principles
ï” Regularly reflect on how to become more effective
Truth in every communication
Facilitate positive conflicts
Read more at agilemanifesto.org
22. Adaptive vs. Predictive Process
Release Planning
Agile and Scrum Workshop
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
23. Lean/Agile Methods
ï” Lean software development
ï” Extreme Programming (XP)
ï” Kanban
ï” Scrum (more about this later)
ï” âŠ
24. XP vs. Scrum
Scrum XP
Product owner Customer
Scrum master XP coach
Team Team
Sprint Iteration
Sprint planning meeting Planning game
25. Kanban
Kanban Core Values
Agile and Scrum Workshop
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
26. 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
27. Reduce âWasteâ with Lean
ï” 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
28. Reduce âWasteâ with Lean
ï” 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)
29. Video: Lucy Candy Factory
Remember The
Agile Values?
Agile and Scrum Workshop
Source: YouTube
Self-organizing, cross-
functional team
Sustainable pace avoiding
crunch-time
Truth in every communication
30. Reduce âWasteâ with Lean
ï” Defects
Reduce the need for rework by e.g. TDD
Detect architectural issues by doing depth-first development
31. 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
32. 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
33. 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
34. 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.
35. Misconceptions and Realities
Agile Myths
Agile and Scrum Workshop
Source: Boehm B., Turner R.: Balancing Agility and Discipline, Figure 2-3
YAGNI = You ainât gonna
need it
36. Dimensions Affecting Method
Agile Myths
Agile and Scrum Workshop
Source: Boehm B., Turner R.: Balancing Agility and Discipline, Figure 2-2
37. Saves the day.
Agile and Scrum Workshop
Q&A
Rainer Stropek
software architects gmbh
rainer@timecockpit.com
http://www.timecockpit.com
@rstropek
Thank your for coming!
Mail
Web
Twitter
38. 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)
39. 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)
40. 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
41. 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
42. 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
43. Sprint Planning Tools
Tools
Agile and Scrum Workshop
Whiteboard or software?
Whiteboard
Software support for
backlog management
Easier to use if not collocated
44. Agile and Scrum Workshop
Work item management integrated with source control, build, and test
Team Foundation Server/Services
47. 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
48. 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?
49. 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
50. 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?
51. 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
53. Definition of âDoneâ
âDoneâ Checklist
Agile and Scrum Workshop
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
54. Saves the day.
Agile and Scrum Workshop
Q&A
Rainer Stropek
software architects gmbh
rainer@timecockpit.com
http://www.timecockpit.com
@rstropek
Thank your for coming!
Mail
Web
Twitter
55. 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)
56. 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
57. Engineering Practices
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
(e.g. Team Foundation Server)
Enhance Quality Gated check-in
(e.g. Team Foundation Server)
58. Engineering Practices
ï” 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
59. Effort Estimation and Scrum
Principles
Agile and Scrum Workshop
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
60. Burndown Chart
Monitor Progress
Agile and Scrum Workshop
Source: Lacey M.: The Scrum Field Guide
Burndown chart not a
mandatory artifact in
Scrum
Still popular in many Scrum
teams
61. Story Decomposition
Whatâs a Story?
Agile and Scrum Workshop
Source: Lacey M.: The Scrum Field Guide
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
62. How large is an elephant?
Fermi Method
Agile and Scrum Workshop
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)
63. Calculate circumference of the earth
What to measure
and/or plan?
Agile and Scrum Workshop
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
64. Release planning
Planning the
Unknown
Agile and Scrum Workshop
Source: Lacey M.: The Scrum Field Guide
Inputs
An estimated, ordered, and
prioritized product backlog
The team velocity
A sprint timeline
65. 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
66. 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
67. Estimation
How good are you?
Agile and Scrum Workshop
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
68. A house as high as an
Airbus A380 is a
âHochhausâ in Germany
Source: Airbus
69. 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
70. 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ÂČ
71. A 90% confidence interval is more a 30% interval
Cognitive Bias
Agile and Scrum Workshop
Source: McConnell et al: AufwandsschÀtzung bei Softwareprojekten
You have to train your
ability to estimate
72. Estimating Costs
Hubbardâs Rule of
Five
Agile and Scrum Workshop
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
73. Estimating Costs
Statistics
Agile and Scrum Workshop
How to estimate when agile?
Statistics can be dangerous
OperationalCosts/RGU[âŹ]
Natural minimum
Endless potential for e.g.
unforeseen problems
76. Black Swan
Black Swan
Agile and Scrum Workshop
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
77. Saves the day.
Agile and Scrum Workshop
Q&A
Rainer Stropek
software architects gmbh
rainer@timecockpit.com
http://www.timecockpit.com
@rstropek
Thank your for coming!
Mail
Web
Twitter
78. 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)
79. Saves the day.
Agile and Scrum Workshop
Q&A
Rainer Stropek
software architects gmbh
rainer@timecockpit.com
http://www.timecockpit.com
@rstropek
Thank your for coming!
Mail
Web
Twitter
Hinweis der Redaktion
Lösung: Bis zu vier Metern erreichen. Das gröĂte bekannte Exemplar war ein am 4. April 1978 im Damaraland (Namibia) erlegter Bulle, der 4,21 Meter groĂ und 10,39 Meter lang warQuelle: Wikipedia, http://de.wikipedia.org/wiki/Elefanten
Bildquellen:
http://www.flickr.com/photos/moe/1981942682
http://www.flickr.com/photos/travel_aficionado/2200003879/