Designing a methodology

Cockburn writes:

Designing a methodology is not at all like designing software, hardware, bridges, or factories. Four things, in particular, get in the way:

* Variations in people. People are not the reliable components that designers count on when designing the other systems.
* Variations across projects. The appropriate methodology varies by project, nationality, and local culture.
* Long debug cycles. The test and debug cycle for a methodology is on the order of months and years.
* Changing technologies. By the time the methodology designer debugs one methodology design, the technologies, techniques, and cultures have changed and the design needs updating.

No wonder it is so hard to get this stuff right. It keeps things interesting though.

Amazon Pulls Purchased E-Book Copies of 1984 and Animal Farm (via feedly)

link -> Amazon Pulls Purchased E-Book Copies of 1984 and Animal Farm (via feedly)

Man survives 300 days with knife and pig

link -> Man survives 300 days with knife and pig

Build a DIY Portable Air Conditioner [Beat The Heat]

link -> Build a DIY Portable Air Conditioner [Beat The Heat]

Extreme Hour

Cockburn writes

More recently, Peter Merel invented a one-hour process miniature for Extreme Programming, giving it the nickname Extreme Hour. The purpose of the Extreme Hour is to give people a visceral encounter with XP so that they can discuss its concepts from a base of almost-real experience.

In the Extreme Hour, some people are designated "customers." Within the first 10 minutes of the hour, they present their requests with developers and work through the XP planning session.

In the next 20 minutes, the developers sketch and test their design on overhead transparencies. The total length of time for the first iteration is 30 minutes.

In the next 30 minutes, the entire cycle is repeated so that two cycles of XP are experienced in just 60 minutes.

Usually, the hosts of the Extreme Hour choose a fun assignment, such as designing a fish-catching device that keeps the fish alive until delivering them to the cooking area at the end of the day and also keeps the beer cold during the day. (Yes, they do have to cut scope during the iterations!)

This sounds awesome. I wish we had done an extreme hour on my team before we started XP. I wonder if I could convince people to do one now.

There are so many different pieces to XP. It is hard to see how they fit together by reading a book. I think the Extreme Hour could show people how each part of the process is important without making them invest more than an hour.

VIDEO: Toyota Employees Taped Stealing From, Watching Porn In Customer's Truck [Caught In The Act]

link -> VIDEO: Toyota Employees Taped Stealing From, Watching Porn In Customer's Truck [Caught In The Act]

Daily Commute started on July 1, 2009

link -> Daily Commute started on July 1, 2009

Starting yesterday, I am doing my daily work commute via the Twike. The missing piece was getting a second battery pack working well. I drove yesterday and today to and from work which for me is just under 8 miles. I don't yet have a good feeling for how much power it is taking to do my commute but today it only took 1.2Kw to charge it when I got to work (and that was after it ran the fans for a while to cool the batteries). The NiCads can deliver lots of power but they do heat up in doing so and right now we are having a heat wave in Portland which does not help. I got lots of thumbs up and waves today. One guy was keeping next to me and yelling out his open windows. "hey! really cool. Where did you get it? Did you build it?" that kind of stuff. Kind of hard to drive and answer questions in traffic. Work is cool about letting me charge there (used 12 cents of power today). I'm not sure, but I might have enough charge to go roundtrip without charging at work. Tomorrow I'm going to try a trip to someone's house that is 13 miles away so we will start to test the range a little more. Currently, my longest single trip is the 8 miles to work. Since I brought it home, I bought 3 new tires, had them mounted and balanced, and I installed them on the vehicle. I also did a lot of cleaning up in the battery compartment and on all the removeable panels (bottom and sides). With two reasonable battery packs, the car is pretty snappy on acceleration. I can keep up with traffic no problem and can even hill climb at a reasonable rate (not as fast as a car but at least I *can* accelerate uphill now). I have been taking a less direct route home to minimize the hill climb t

Coordination is important

Cockburn writes:

Coordination is important. The same average people who produce average designs when working alone often produce good designs in collaboration.

Conversely, all the smartest people together still won't produce group success without coordination, cooperation, and communication. Most of us have witnessed or heard of such groups. Team success hinges on cooperation, communication, and coordination.

I like this quote. This is the reason why I am reading this book. I want to learn how to help myself and my team cooperate, communicate, and coordinate better.

Boatman’s bags

link -> Boatman’s bags

Amicability and Conflict

Cockburn writes:

Amicability is the willingness of people to hear the thoughts of another person with goodwill and to speak without malice.

Amicability is the weaker cousin to trust. Trust is wonderful and should be nurtured, but amicability is easier to achieve within a group and still confers advantages. I always watch the amicability level in an organization to learn to what extent information is being revealed versus concealed in conversations.

When people conceal information from their colleagues, they lower the rate of information discovery, which raises the lost-opportunity cost as well as the overall cost per idea developed.

Amicability permits successful conflict to occur when the project goes through a stressful period. The people, knowing that the others are not intending to be hurtful, can look past the current disagreement toward resolving the issues.

One might think that removing all conflict from a project team would be the best, but that turns out not to be the case. People need to be able to disagree, in order to identify design problems!

I think being able to listen and without an agenda is really important but really hard for me to do. I start thinking about how to word my response before the other person is even finished talking. I want to be more patient and not be in such a hurry to steer the conversation in one way or another. I need to trust that eventually both people working together will come to the best conclusion.