The Extreme Decade: Progress, Pain, Paradox
Upcoming SlideShare
Loading in...5
×
 

The Extreme Decade: Progress, Pain, Paradox

on

  • 525 views

I have had the privilege of observing and participating in the agile software community for ten years, and in that time have witnessed much success, much failure, much consternation and much ...

I have had the privilege of observing and participating in the agile software community for ten years, and in that time have witnessed much success, much failure, much consternation and much confusion. I will take a random walk through the Extreme decade, during which the community has pushed the limits of what it means to do less and achieve more.

I won’t try to answer the question of whether we’ve advanced the start of the art, but I’ll share with you what I’ve seen, what I’ve done, what I’d like to see next, and perhaps how you can make your mark. I hope that you’ll leave with tougher questions than you had when you came in.

Statistics

Views

Total Views
525
Views on SlideShare
494
Embed Views
31

Actions

Likes
1
Downloads
1
Comments
0

2 Embeds 31

http://www.linkedin.com 26
https://www.linkedin.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Extreme Decade: Progress, Pain, Paradox The Extreme Decade: Progress, Pain, Paradox Presentation Transcript

  • The Extreme DecadeProgress, Pain, Paradox
  • Ron Jeffries Chet Hendrickson
  • Knowing all the tasks...
  • Hes Canadian,you know...
  • Chris Matts
  • Mary Poppendieck
  • Estimating work...
  • Watch the video athttp://link.jbrains.ca/pVURX3
  • Knowing how quickly we go...
  • Hes Canadian,you know...
  • Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience Arlo Belshee Architect Silver Platter Software Pasadena, CA 91103 (503) 265-1263 a_xp@arlim.org the paramount concerns. Performance was second, and Abstract features were a distant third. The company was a startup, so we were tight on both Many traditional software practices stress the cash and time. The company was typically operating withimportance of programming in Flow. XP directly between -30 and 180 Days ‘Till Broke. Our contracts allchallenges the assertion that Flow is critical and had lead times of 3-5 years. This meant that sales had toproclaims Pair Flow. start at the same time as engineering. Thus, engineering Both Flow states are fragile. They are easily disrupted had to produce many sales demos and to frequently alterby outside distraction or task rotation. Both take a long the product to more closely fit the needs of a particulartime to enter. Furthermore, it takes days for a given pair customer.to be comfortable enough with each other to be able to Due to these influences, we chose a software processachieve Pair Flow at all. with rapid feedback and change. We ran the shortest My team at Silver Platter discovered that there is a third iterations we could (1 week) to get the most data possible.option to achieve high-efficiency programming. Our team We tracked our metrics closely, and we ran severalspent the majority of its time in Beginner’s Mind. experiments each iteration. We used the metrics to decideWhereas Flow depends on stability, Beginner’s Mind what worked and to what degree. We then adopted thosedepends on instability, yet provides similar efficiency things that worked and started the next set of experiments.gains to a constant state of Flow. Chief among these experiments were variations on
  • Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience Arlo Belshee Architect Silver Platter Software Pasadena, CA 91103 (503) 265-1263 a_xp@arlim.org the paramount concerns. Performance was second, and Abstract features were a distant third. The company was a startup, so we were tight on both Many traditional software practices stress the cash and time. The company was typically operating withimportance of programming in Flow. XP directly between -30 and 180 Days ‘Till Broke. Our contracts allchallenges the assertion that Flow is critical and had lead times of 3-5 years. This meant that sales had toproclaims Pair Flow. start at the same time as engineering. Thus, engineering Both Flow states are fragile. They are easily disrupted had to produce many sales demos and to frequently alterby outside distraction or task rotation. Both take a long the product to more closely fit the needs of a particulartime to enter. Furthermore, it takes days for a given pair customer.to be comfortable enough with each other to be able to Due to these influences, we chose a software processachieve Pair Flow at all. with rapid feedback and change. We ran the shortest My team at Silver Platter discovered that there is a third iterations we could (1 week) to get the most data possible.option to achieve high-efficiency programming. Our team We tracked our metrics closely, and we ran severalspent the majority of its time in Beginner’s Mind. experiments each iteration. We used the metrics to decideWhereas Flow depends on stability, Beginner’s Mind what worked and to what degree. We then adopted thosedepends on instability, yet provides similar efficiency things that worked and started the next set of experiments.gains to a constant state of Flow. Chief among these experiments were variations on
  • Eliyahu Moshe Goldratt31.03.1947–11.06.2011
  • I promised you a paradox...
  • Agile
  • agile
  • Ron Jeffries Chet Hendrickson
  • Corey Haines J. B. Rainsberger
  • XP
  • Bill CaputoFOR ME, XP AIN’T OUT THERE, IT’S IN HERE.
  • Watch the video athttp://link.jbrains.ca/ojPnyd
  • ME@JBRAINS.CA europeantour2011.comThe Extreme DecadeProgress, Pain, Paradox