Agile or Fragile

Agile or Fragile
Rodrigo Campos
camposr@gmail.com - @xinu

ffffuuuu conference 2010 - http://ffffuuuu.me

Sunday, November 21, 2010 1

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...


Disclaimer #2

I’ll talk about nonteorethical, real life stuff that
happens in real life companies.
Your mileage may vary...


The mythical endless
week
VP
Whatever Inc.

Director
Product R&D

Manager
R&D and Ops

Development Engineering

Operations Infrastructure


week


week
VP
Whatever Inc.

CWTFO
Product R&D

Manager Manager Manager
R&D R&D R&D

R&D R&D R&D

Manager
Operations

Ops


week
VP
Whatever Inc.

CWTFO R&D
Product R&D

R&D
Manager Manager Manager
R&D R&D R&D

R&D R&D R&D R&D R&D R&D

R&D
Manager
Operations

Ops


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...


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


The neverending
project
new story:
now we need to
get back to earth
safe and sound.


The neverending
project
• Continuous development is not an excuse
for short sighted deﬁnitions
• 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 !


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


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


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


Possible Solutions

• QA needs time to accurately test software
• Every new feature should have a on/off
switch (feature ﬂags)
• Plan and do dark deploys


Pair Programming


Pair Programming

• Besides unemployment rates, what problem
are you trying to solve ?


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


The Quality Assurance
Panacea


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


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

The meeting addiction

“Meetings are indispensable when you don't want
to do anything.”
John Kenneth Galbraith


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


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 ﬁx (or get rid of)
the problem


The risk homeostasis
syndrome
The hypothesis of risk homeostasis holds
that everyone has his or her own ﬁxed 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


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 signiﬁcant stories being deployed every
cycle

• More than one deploy for each cycle - see the
mythical endless week


Possible Solutions

• If the company missed the time to market
window, launching a poorly developed
product won’t ﬁx it
• Remember Brook’s Law: "adding manpower
to a late software project makes it later"
• Trust your team’s effort estimations


Now this one is for the
managers
I know you’re out there !


If you expect this...


Don’t treat your team
like this


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


You can’t ﬁt a square
peg in a round hole.


It’s Q&A time !


Agile or Fragile

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (9)

Similaire à Agile or Fragile

Similaire à Agile or Fragile (20)

Plus de Rodrigo Campos

Plus de Rodrigo Campos (20)

Dernier

Dernier (20)

Agile or Fragile