Agile or Fragile

7,645 views

Published on

Musings on agile methods and other fairy tales, as presented in ffffuuuu conf 2010.

Published in: Technology
1 Comment
10 Likes
Statistics
Notes
No Downloads
Views
Total views
7,645
On SlideShare
0
From Embeds
0
Number of Embeds
2,165
Actions
Shares
0
Downloads
55
Comments
1
Likes
10
Embeds 0
No embeds

No notes for slide

Agile or Fragile

  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
  5. The mythical endless week Sunday, November 21, 2010 5
  6. The mythical endless week Sunday, November 21, 2010 6
  7. The mythical endless 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 Sunday, November 21, 2010 7
  8. The mythical endless 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 Sunday, November 21, 2010 8
  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
  17. Pair Programming Sunday, November 21, 2010 17
  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
  20. The Quality Assurance Panacea Sunday, November 21, 2010 20
  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
  30. If you expect this... Sunday, November 21, 2010 30
  31. Don’t treat your team like this Sunday, November 21, 2010 31
  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
  34. It’s Q&A time ! Sunday, November 21, 2010 34

×