Agile or Fragile

Agile or FragileRodrigo Campos

[email protected] - @xinu

ffffuuuu conference 2010 - http://ffffuuuu.me

1Sunday, November 21, 2010

mailto:[email protected]

mailto:[email protected]

http://ffffuuuu.me

http://ffffuuuu.me

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

VPWhatever Inc.

DirectorProduct R&D

ManagerR&D and Ops

Development Engineering

Operations Infrastructure



VPWhatever Inc.

CWTFOProduct R&D

ManagerR&D

ManagerOperations

ManagerR&D

ManagerR&D

R&D R&D R&D

Ops



VPWhatever Inc.

CWTFOProduct R&D

ManagerR&D

ManagerOperations

ManagerR&D

ManagerR&D

R&D R&D R&D

Ops

R&D

R&D

R&D

R&D

R&D R&D


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.



• 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 !



• 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 flags)

• 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


http://thinkexist.com/quotation/meetings_are_indispensable_when_you_don-t_want_to/212559.html




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


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


http://en.wikipedia.org/wiki/Homeostasis

http://en.wikipedia.org/wiki/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 significant 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 fix 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 InGarbage 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 fit a square peg in a round hole.


It’s Q&A time !


Agile or Fragile

Technology

Transcript of Agile or Fragile