The document provides an overview of agile software development practices compared to traditional waterfall approaches. It summarizes the author's experience transitioning from waterfall to agile development and embracing eXtreme Programming (XP) practices like test-driven development, pair programming, and continuous integration. The author then integrated XP with Scrum, the most popular agile framework. The document compares different agile methodologies and emphasizes that agile is about values and principles over prescriptive rules.
1. @agilesensei
After reading this,
introduce yourself
to a person you
don’t know yet.
Tell this person
why you are here
and what you hope
to learn.
written, illustrated and
performed by
Claudio Perrone
2. “
Pair Customer Development
with Agile Development
Customer development is useless unless the
product development organization can
iterate the product with speed and agility.
--- Steve Blank & Bob Dorf
4. … Only 3 people in this room will Create
successful companies*
“(*) The only statistics you can
trust are those you falsified
yourself
--(often falsely attributed to) Winston Churchill
11. Until then, I was mostly familiar with
the traditional “waterfall” approach
Weeks
12. …which was fundamentally inadequate
in my domain
Fixed-Price/ New
Sequential
Fixed Scope opportunities/
process Release
Contracts + Change
(waterfall)
BDUF requests
- Stringent - Big handoffs - Late changes are - Late Releases,
contracts (transaction unwelcomed - poor quality
- Fixed scope costs) - Scope creep - poor staff morale
- Fixed date based - Last phases - Unbalanced demand - low customer
on early estimate compressed - -no time for process satisfaction
or cost of delay - lots of Work In improvement
⇒ All features are Process (WIP) - - quality suffers
equally - -Unknown
important, integration phase
⇒ Big cushion to length
contain risk - - poor progress
(contingency) visibility
⇒ All or nothing
13. A business strategy lesson confirmed
what I had realized
“build cheap, fail fast
(i.e. the faster you find your
flaws, the faster you move on to
what works)
17. “How do you see the world?”
from predictive...
...to adaptive
18. Manifesto
for
Agile
So2ware
Development
We
are
uncovering
be;er
ways
of
developing
so2ware
by
doing
it
and
helping
others
do
it.
Through
this
work
we
have
come
to
value:
Individuals
and
interacCons
over
processes
and
tools
Working
so2ware
over
comprehensive
documentaCon
Customer
collaboraCon
over
contract
negoCaCon
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
le2
more.
h;p://agilemanifesto.org/iso/it/
19. Under the umbrella of agile (values & principles),
THERE ARE several methodologies (implementations)
Crystal
Clear
Scrum
…
eXtreme
Programming
DSDM
Lean
Feature
Driven
So2ware
Development
20. I’ve embraced XP’s technical practices
since 2001
Whole
team
Coding
standard
Test-‐Driven
Development
(TDD)
CollecCve
ownership
Customer
tests
Pair
programming
Refactoring
Planning
game
ConCnuous
integraCon
Simple
design
Sustainable
pace
Metaphor
Small
releases
21. I then integrated XP with Scrum, the most
popular agile framework to date
22. Compare for understanding, not judgment
More prescriptive More adaptive
RUP XP Scrum Kanban Do Whatever
(120+) (13) (9) (5) (0)
• Architecture
Reviewer
• Business
use
case
realizaCon
• Business
Designer
• Business
use-‐case
model
• Business-‐Model
Reviewer
• Business
vision
• Whole
team
• Scrum
Master
• Visualize
the
• Business-‐Process
Analyst
• Change
request
• Coding
• Product
• Capsule
Designer
• ConfiguraCon
audit
findings
workflow
•
•
Change
Control
Manager
Code
Reviewer
•
•
ConfiguraCon
management
plan
Data
model
standard
Owner
•
•
ConfiguraCon
Manager
Course
Developer
•
•
Deployment
model
Deployment
plan
• TDD
• Team
• Limit
WIP
•
•
Database
Designer
Deployment
Manager
•
•
Design
guidelines
Design
model
• CollecCve
• Sprint
• Measure
and
• Design
Reviewer
• Development
case
• Designer
• Development-‐organizaCon
assessment
ownership
planning
opCmize
flow
• Graphic
ArCst
• End-‐user
support
mateirla
• Customer
meeCng
• Implementer
• Glossary
• Write
explict
•
•
Integrator
Process
Engineer
•
•
ImplementaCon
model
InstallaCon
arCfacts
tests
• Daily
Scrum
•
•
Project
Manager
Project
Reviewer
•
•
IntegraCon
build
plan
Issues
list
• Pair
• Sprint
review
policies
•
•
Requirements
Reviewer
Requirements
Specifier
•
•
IteraCon
assessment
IteraCon
plan
programming
• Product
• Improve
•
•
So2ware
Architect
Stakeholder
•
•
Manual
styleguide
Programming
guidelines
• Refactoring
backlogt
collaboraCvely
•
•
System
Administrator
System
Analyst
•
•
Quality
assurance
plan
Reference
architecture
• Planning
• Sprint
backlog
•
•
Technical
Writer
Test
Analyst
•
•
Release
notes
Requirements
a;ributes
game
• BUrndown
•
•
Test
Designer
Test
Manager
• Requirements
management
plan
• ConCnuous
chart
•
•
Tester
Tool
Specialist
•
•
Review
record
Risk
list
integraCon
• User-‐Interface
Designer
• Risk
management
plan
• Architectural
analysis
• So2ware
architecture
• Simple
design
• Assess
Viability
of
architectural
proof-‐
of-‐concept
•
document
So2ware
development
• Sustainable
•
•
Capsule
design
Class
design
•
plan
So2ware
requirements
specificaCon
pace
• Construct
architectural
proof-‐of-‐
concept
•
•
Stakeholder
requests
Status
assessment
• Metaphor
•
•
Database
design
Describe
distribuCon
•
•
Supplementary
business
specificaCon
Supplementary
specificaCon
• Small
releases
• Describe
the
run-‐Cme
architecture
• Target
organizaCon
assessment
• Design
test
packages
and
classes
• Test
automaCon
architecture
• Develop
design
guidelines
• Test
cases
• Develop
programming
guidelines
• Test
environment
configuraCon
• IdenCfy
design
elements
• Test
evaluaCon
summary
• IdenCfy
design
mechanisms
• Test
guidelines
• Incorporate
design
elements
• Test
ideas
list
• PrioriCze
use
cases
• Test
interface
specificaCon
• Review
the
architecture
• Test
plan
• Review
the
design
• Test
suite
• Structure
the
implementaCon
model
• Tool
guidelines
• Subsystem
design
• Training
materials
• Use-‐case
analysis
• Use
case
model
• Use-‐case
design
• Use
case
package
• Analysis
model
• Use-‐case
modeling
guidelines
• Architectural
proof-‐of-‐concept
• Use-‐case
realizaCon
•
•
Bill
of
materials
Business
architecture
document
•
•
Use-‐case
storyboard
User-‐interface
guidelines
Henrik Kniberg
• Business
case
• User-‐interface
prototype
• Business
glossary
• Vision
• Business
modeling
guidelines
• Work
order
• Business
object
model
• Workload
analysis
model
• Business
rules
• Business
use
case
Henrik
Kniberg
24. User stories were our “placeholders
for conversations”
Customer withdraws cash
As a customer,
I want to withdraw cash
from an ATM,
so that I don’t have to
wait in line at the bank.
Ref:
h;p://dannorth.net/introducing-‐bdd
25. Every day, we held a quick standup
meeting to synchronize our efforts
To DO Doing Done Burndown
Family 1
Work Left
Days
Unplanned Next
26. Every 2 weeks, we demonstrated what
we built and held a team retrospective
Good Bad Next
Do more Do Less
Start Stop
Doing Doing
Keep
Doing
27. Product owners, scrum masters, teams
and management worked together to
create value & remove impediments
28. what can you expect from an agile team/
organization?
Visibility Adaptability
Business
Value Risk
Agile
Development Traditional
Development
29. We crafted opinionated software
“The best software
has a vision.
The best software
takes sides.
…
Decide what
your vision is and run with it.”
-- 37 signals
41. I became increasingly intrigued by the rise
of Lean and its influence in the agile circles
42. There are 7 principles of lean thinking which
are most relevant to software development
Eliminate Waste
Build quality in
Create knowledge
Defer commitment
Deliver fast
Respect for people
Optimize the whole
43. Lean is heavily inspired by Toyota’s
breakthroughs in operational excellence
44. “ All we are doing is looking at the timeline from
the moment the customer gives us an order to
the point we can collect the cash.
And we are reducing that timeline by removing
the non-value-added wastes.
--- Taiichi Ohno, Founder of TPS
54. One
day
in
Kanban
land
(5/6)
Courtesy
of
Henrik
Kniberg
(www.crisp.se)
Ref:
h;p://is.gd/3gAIO
55. One
day
in
Kanban
land
(6/6)
Courtesy
of
Henrik
Kniberg
(www.crisp.se)
Ref:
h;p://is.gd/3gAIO
56. Kanban is a great enabler, but it represents
only the tip of the iceberg…
57. As a consequence, there are many possible
definitions of Lean, all somewhat limited
1. What Toyota does
2. Identifying and removing waste
3. A problem-identifying and problem-
solving system
58. During my extensive work on “a3 thinking”*,
a Toyota management process to systematically
solve problems, improve and mentor…
(*) I’m writing a book about it!
59. I discovered that a3 thinking = Lean thinking, a
vivid expression of the scientific method!
60. “Hence, I offer you my own definition”
“Lean is a business strategy
to make money*
THROUGH
the development of people
(*) replace with “create customer value” or “reach
results”, if you prefer
61. Using Lean and agile, I brought success to
many clients, from large enterprises to
fast-growing companies around Europe
75. Evaluate your own learning!
Write down…
What did you learn?
How will you apply it?
How will it benefit your venture?
Suggestions or questions you
still have?
claudio@agilesensei.com
www.agilesensei.com
www.twitter.com/agilesensei
Editor's Notes
Research (anarchy)Simple (maintenance)Scrum is appropriate for problems in the complex space
Scrum didn't really become a development concept until 1995, when Jeff Sutherland and Ken Schwaber teamed up to codify the method (and the term) that is so ably documented in the book Schwaber wrote with Mike Beedle in 2001, entitled Agile Software Development with SCRUM (Prentice Hall, ISBN: 0130576349).
In Scrum and Kanban you are supposed to add stuff.In RUP, you are supposed to remove stuff.Scrum + XPKanban + daily standupScrum team using use cases or limiting WIPDon’t call it Scrum if it isn’t.
Research (anarchy)Simple (maintenance)Scrum is appropriate for problems in the complex space
Role, feature, benefit
IT IS MORE IMPORTANT TO DO THE RIGHT THING THAN IT IS TO DO THINGS RIGHT!