1. Agile or Fragile
Rodrigo Campos
camposr@gmail.com - @xinu
ffffuuuu conference 2010 - http://ffffuuuu.me
Sunday, November 21, 2010 1
2. Disclaimer #1
Agile methods can improve a company’s ability to
deliver production ready systems in less time than
the so called traditional development methods.
Now that said...
Sunday, November 21, 2010 2
3. Disclaimer #2
I’ll talk about nonteorethical, real life stuff that
happens in real life companies.
Your mileage may vary...
Sunday, November 21, 2010 3
4. The mythical endless
week
VP
Whatever Inc.
Director
Product R&D
Manager
R&D and Ops
Development Engineering
Operations Infrastructure
Sunday, November 21, 2010 4
9. Operations will be
overwhelmed and will
provide poor service
If you can live with that, that’s OK !
Just don’t go bitch and moan at the ops team...
Sunday, November 21, 2010 9
10. Possible solutions
• If you need operational throughput and quality of
service you need a vertical organizational
structure
• Schedule production deploys every 2 or 3 cycles
• Focus on quality assurance so you’ll have less
bugs in production
• Automation is not an option !
• Don’t be an asshole
Sunday, November 21, 2010 10
11. The neverending
project
new story:
now we need to
get back to earth
safe and sound.
Sunday, November 21, 2010 11
12. The neverending
project
• Continuous development is not an excuse
for short sighted definitions
• You can be damn sure that Leonardo da
Vinci was not trying to draw a horse when
he started painting La Gioconda
• If you need to change your data model and
build new architecture components every
other cycle, something is wrong !
Sunday, November 21, 2010 12
13. The neverending
project
• Goal != Requirements
• Goal: “... achieving the goal, before the decade is out,
of landing a man on the moon and returning him
safely to the earth.” (JFK, 1961)
• Requirements (Saturn V):
• Payload to LEO: 119.000 Kg
• Main Engines: 5 Rocketdyne F-1
• Thrust: 34.020.000 N
• Burn time: 150 seconds
Sunday, November 21, 2010 13
14. Possible Solutions
• The PO has to fully understand and evaluate end
customer needs as well as market dynamics
• She can’t be clueless about the product !
• You may not need a “project statement” but every
team needs a goal
• The goal has to be:
• Measurable
• Valuable
• Tangible
Sunday, November 21, 2010 14
15. The bugless fallacy
• There’s no such thing as bugless
applications
• Business will take precedence over quality
• By that I mean time to market issues as
well as QA budget
• You’ll need to handle emergency rollouts
Sunday, November 21, 2010 15
16. Possible Solutions
• QA needs time to accurately test software
• Every new feature should have a on/off
switch (feature flags)
• Plan and do dark deploys
Sunday, November 21, 2010 16
18. Pair Programming
• Besides unemployment rates, what problem
are you trying to solve ?
Sunday, November 21, 2010 18
19. Pair Programming
• Two wrongs don’t make a right !
• A seminal book on Agile methods suggests
that it is a good idea to have one
programmer controlling the keyboard while
the other controls the mouse
• No, I’m not kidding
Sunday, November 21, 2010 19
21. The Quality Assurance
Panacea
• “But it passed QA”
• This is the new “Met the requirements” !
• QA oriented development is a predictable
train crash
• Having a QA process doesn’t mean you can
hire subpar programmers
Sunday, November 21, 2010 21
22. Possible Solutions
• Avoid QA oriented development, what you
need is user oriented development
• Make it clear that development should care
about the end user experience and
expectations
• Be sure that the whole team actually knows
the user expectations
• QA needs leverage to halt a deploy
Sunday, November 21, 2010 22
23. The meeting addiction
“Meetings are indispensable when you don't want
to do anything.”
John Kenneth Galbraith
Sunday, November 21, 2010 23
24. The meeting addiction
• Actually, daily meetings can be a good thing!
• You need to control the Drama Queens
• Constant whining is a sign of trouble
• More communication doesn’t mean good
communication
Sunday, November 21, 2010 24
25. Possible Solutions
• Focus on planning instead of eternal
debates over what went wrong
• “Inspect and adapt” can lead to a
dangerous road
• Sometimes you need to fix (or get rid of)
the problem
Sunday, November 21, 2010 25
26. The risk homeostasis
syndrome
The hypothesis of risk homeostasis holds
that everyone has his or her own fixed level
of acceptable risk. When the level of risk in
one part of the individual's life changes, there
will be a corresponding rise or fall in risk
elsewhere to bring the overall risk back to
that individual's equilibrium.
Source: http://en.wikipedia.org/wiki/Risk_homeostasis
Sunday, November 21, 2010 26
27. The risk homeostasis
syndrome
• Symptoms may include:
• Multiple development teams working on a project
at the same time
• Scrum master arguing about the number of stories
and/or effort estimations
• Too many significant stories being deployed every
cycle
• More than one deploy for each cycle - see the
mythical endless week
Sunday, November 21, 2010 27
28. Possible Solutions
• If the company missed the time to market
window, launching a poorly developed
product won’t fix it
• Remember Brook’s Law: "adding manpower
to a late software project makes it later"
• Trust your team’s effort estimations
Sunday, November 21, 2010 28
29. Now this one is for the
managers
I know you’re out there !
Sunday, November 21, 2010 29
32. Garbage In
Garbage Out
• In the end it’s all about people
• Cheap programmer’s code will be...
cheap
• No development process will harness
the power of ignorance
Sunday, November 21, 2010 32
33. You can’t fit a square
peg in a round hole.
Sunday, November 21, 2010 33