Agile Conference 2009 - Day Two
"I Come to Bury Agile, Not to Praise It" -- Keynote by Dr. Alistair Cockburn
So this is one of those classic keynotes where the title has little to do with the content of the talk. I did enjoy the keynote, very much so, but only the first 10 minutes were devoted to Agile's 'Death.'
Alistair came out following a bagpiper playing "Amazing Grace" -- like a funeral. I gotta admit that it was a pretty nice entrance. Then he gave a modified version of "I came to bury Caesar, not to praise him" speech from Shakespeare's Julius Caesar (full text here: http://alistair.cockburn.us/I+come+to+bury+Agile%2c+not+to+praise+it). His point was that Agile started out as something for small, co-located, groups and was pretty rare. It is now very prominent and used in quite large organizations. So it has gone through a bunch of changes despite the fact that we call it by the same name. Not quite a 'death' but "Isn't it weird how we still call Agile the same thing even though it's changed a lot since 2000?" isn't a catchy title for a keynote.
Then he spent the next 70 minutes talking about the 4 pillars of Agile:
1. The finite co-operative game
Goals of the game:
2. Craft
Pay attention to skills and to the medium
People learn in 3 stages:
3. Lean processes
Aim for continuous flow
Watch your queues (where the bottlenecks are)
4. Knowledge Acquisition
If you integrate all the time (or release) you can have knowledge lead cost (spending on the project) then you can trim the tail of the project to deliver on time or extend to get a little bit better value. If you integrate late the options are: Deliver late or work overtime.
At one point he claimed that there are studies that show how expensive distance is to a company. 12 people not pairing costs 100,000 per year and goes up to $300,000 if they are on different floors. Taking a look at his slides, I think this fact was taken from the book "Managing the Flow of Technology," but I'm not sure.
Link to the slides.
Idea Factory - Brian Marick, David Carlton
This was an attempt to relate 3 ideas of how scientific ideas are adopted to Agile.
The "Trading Zones" idea is from a book by Peter Galison titled "Image and Logic: A Material Culture of Microphysics." The idea is to setup local areas where separate groups working on the same project, but do drastically different things, can get together and possibly form a common language.
Packages are a way of, well, packaging your ideas so that they are easy to assimilate and adopt.
Example: JUnit made it easy to do TDD. (That's kind of what I'm trying to do with metric_fu and code metrics).
Actor/Network theory is a study of "how does a fact become a fact?" A successful idea will, over time, go from:
Something that is cited conditional in publications. Ex. "Watson and Crick propose that DNA has a double helix structure"
to
Being cited without question. Ex. "Watson and Crick proved that DNA has a double helix structure"
to
Being assumed. "Given the double helix nature of DNA..."
XP: My Greatest Misses 2000-2009 - J. B. Rainsberger
This was another interesting talk by Rainsberger. He discussed his greatest failures as an XP/Agile coach/trainer. Almost all of his problems were caused by his failure to consider the people part of software. His ideas, processes, and plans may have been spot on in his own mind but they were often interpreted by others as challenges or insults or worse.
The breakthrough for him was when he finally started reading the works of Gerald M. Weinberg and Virginia Satir and learned about the human side of consulting. When J.B. speaks he thinks about how what he said will be interpreted. And when he hears something jarring or offensive he tries to figure out what an alternate and generous interpretation might be for the comment.
He wrote up an article about miscommunication entitled: Don't Let Miscommunication Spiral Out Of Control
Improving Obama Campaign Software by Learning from Users -- Paul Baker, Billy Belchev, and Zack Exley
Every 4 years the election software budget goes from 0 to 800 million. Which can be hard on the software. Paul Baker and Billy Belchev were hired to evaluate a bunch of software used by Obama volunteers during the campaign to track canvassing and phone banking efforts.
They did this in 3 ways:
1. Contextual inquires (interviews)
1-5 users per task
30-45 min per interview
2. Lightweight usability testing
1-3 user per task
15-25 min per session
3. Collecting artifacts
Taking pictures and video of the environment, people, and software interacting (or, in some cases, failing to interact)
Basically they went out into the field and talked to people as they used the software. Amazing how this simple strategy quickly (they spent 9 days in the field) finds huge problems with the software.
Example quote: "The way I would really do it? I'd write her name down and call her later." Instead of use the cumbersome tracking software.
Lots of offices used Google Docs to store information because an overly restrictive permission system wouldn't let key members see data and to store specific fields the software couldn't hold.
All the sticky notes on the wall, computer, and stuff on the whiteboards will tell you what the software isn't doing (or doing well)
They used a lot of video clips with people talking about how they worked around the bad parts of the software.
Pretty good day, all in all. Tomorrow I'll be attending the Software Craftsmanship Conference sponsored by my own company Obitva. Then I have rush back to Agile to give my talk "What's the Right Level of Testing?" at 4:45. Seeing the caliber of talks here I'm pretty proud and excited to be a presenter.
So this is one of those classic keynotes where the title has little to do with the content of the talk. I did enjoy the keynote, very much so, but only the first 10 minutes were devoted to Agile's 'Death.'
Alistair came out following a bagpiper playing "Amazing Grace" -- like a funeral. I gotta admit that it was a pretty nice entrance. Then he gave a modified version of "I came to bury Caesar, not to praise him" speech from Shakespeare's Julius Caesar (full text here: http://alistair.cockburn.us/I+come+to+bury+Agile%2c+not+to+praise+it). His point was that Agile started out as something for small, co-located, groups and was pretty rare. It is now very prominent and used in quite large organizations. So it has gone through a bunch of changes despite the fact that we call it by the same name. Not quite a 'death' but "Isn't it weird how we still call Agile the same thing even though it's changed a lot since 2000?" isn't a catchy title for a keynote.
Then he spent the next 70 minutes talking about the 4 pillars of Agile:
1. The finite co-operative game
Goals of the game:
- Deliver the software
- Setup the next game
- Invent
- Decide
- Communicate
2. Craft
Pay attention to skills and to the medium
People learn in 3 stages:
- Shu: learn a technique
- Ha: Collect techniques
- Ri: Invent/blend techniques
3. Lean processes
Aim for continuous flow
Watch your queues (where the bottlenecks are)
4. Knowledge Acquisition
If you integrate all the time (or release) you can have knowledge lead cost (spending on the project) then you can trim the tail of the project to deliver on time or extend to get a little bit better value. If you integrate late the options are: Deliver late or work overtime.
At one point he claimed that there are studies that show how expensive distance is to a company. 12 people not pairing costs 100,000 per year and goes up to $300,000 if they are on different floors. Taking a look at his slides, I think this fact was taken from the book "Managing the Flow of Technology," but I'm not sure.
Link to the slides.
Idea Factory - Brian Marick, David Carlton
This was an attempt to relate 3 ideas of how scientific ideas are adopted to Agile.
The "Trading Zones" idea is from a book by Peter Galison titled "Image and Logic: A Material Culture of Microphysics." The idea is to setup local areas where separate groups working on the same project, but do drastically different things, can get together and possibly form a common language.
Packages are a way of, well, packaging your ideas so that they are easy to assimilate and adopt.
Example: JUnit made it easy to do TDD. (That's kind of what I'm trying to do with metric_fu and code metrics).
Actor/Network theory is a study of "how does a fact become a fact?" A successful idea will, over time, go from:
Something that is cited conditional in publications. Ex. "Watson and Crick propose that DNA has a double helix structure"
to
Being cited without question. Ex. "Watson and Crick proved that DNA has a double helix structure"
to
Being assumed. "Given the double helix nature of DNA..."
XP: My Greatest Misses 2000-2009 - J. B. Rainsberger
This was another interesting talk by Rainsberger. He discussed his greatest failures as an XP/Agile coach/trainer. Almost all of his problems were caused by his failure to consider the people part of software. His ideas, processes, and plans may have been spot on in his own mind but they were often interpreted by others as challenges or insults or worse.
The breakthrough for him was when he finally started reading the works of Gerald M. Weinberg and Virginia Satir and learned about the human side of consulting. When J.B. speaks he thinks about how what he said will be interpreted. And when he hears something jarring or offensive he tries to figure out what an alternate and generous interpretation might be for the comment.
He wrote up an article about miscommunication entitled: Don't Let Miscommunication Spiral Out Of Control
Improving Obama Campaign Software by Learning from Users -- Paul Baker, Billy Belchev, and Zack Exley
Every 4 years the election software budget goes from 0 to 800 million. Which can be hard on the software. Paul Baker and Billy Belchev were hired to evaluate a bunch of software used by Obama volunteers during the campaign to track canvassing and phone banking efforts.
They did this in 3 ways:
1. Contextual inquires (interviews)
1-5 users per task
30-45 min per interview
2. Lightweight usability testing
1-3 user per task
15-25 min per session
3. Collecting artifacts
Taking pictures and video of the environment, people, and software interacting (or, in some cases, failing to interact)
Basically they went out into the field and talked to people as they used the software. Amazing how this simple strategy quickly (they spent 9 days in the field) finds huge problems with the software.
Example quote: "The way I would really do it? I'd write her name down and call her later." Instead of use the cumbersome tracking software.
Lots of offices used Google Docs to store information because an overly restrictive permission system wouldn't let key members see data and to store specific fields the software couldn't hold.
All the sticky notes on the wall, computer, and stuff on the whiteboards will tell you what the software isn't doing (or doing well)
They used a lot of video clips with people talking about how they worked around the bad parts of the software.
Pretty good day, all in all. Tomorrow I'll be attending the Software Craftsmanship Conference sponsored by my own company Obitva. Then I have rush back to Agile to give my talk "What's the Right Level of Testing?" at 4:45. Seeing the caliber of talks here I'm pretty proud and excited to be a presenter.
Comments