Archive for the ‘Musings’ Category

Cash for Clunker PCs

Sunday, August 23rd, 2009

Hmmm. I’m already an Apple user but this new ad campaign of “Cash for Clunker PCs” makes me want to trade in the old PC in the basement:

www.CashForClunkerPCs.com

A Requirements Challenge

Friday, January 23rd, 2009

I have always done highly iterative development and have always worked in short iterations. Initially this was because the domains I worked in early in my career gave me no choice but to work that way. Later I discovered the philosophical reasons for working this way. I also soon learned that keeping the software close to bug free was best. This was all back in the 1980s and early 1990s. In 1992 I started Mountain Goat Software to do outsourced, contract development projects and needed a name for the new company. I found the name in Tom Gilb’s wonderful Principles of Software Engineering book. Every page or two has a gray sidebar highlight some key principle. On page 99 is the Mountain Goat Principle:

Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step.

I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out.
Although I’d named the company after one of Tom’s principles, I had never met him in person. Well, last month I finally had the honor of meeting Tom and his son, Kai Gilb, who is a top-notch software consultant in his own right. (See Kai’s book on the Evo process.

At dinner, Tom and Kai posed a challenge to me that I haven’t been able to figure out yet. We talked about how adding a new feature to a product is not an issue of adding new capabilities as much as it is about changing how well something can be done. I other words, it is about changing the quality of the implementation.

For example, imagine a simple word processor back in 1982 without an integrated spell-checker. Spell checking was still possible. You could have looked up each word on the screen in a physical dictionary and determined which were misspelled. Adding the integrated spell-checker was more about improving the quality of an implementation than about adding a new capability.

The challenge that Tom and Kai posed me was to think of a function in MS Word (any word processor will do), that is a new function, and not just a change in the quality of those functions. To think about this, compare Word of today with the tools of a century ago—paper, pen or pencil, the post office, and so on.

Surely, they were nuts, I thought. So I tossed off a few answers:

“Undo.”

“No,” they replied. “That could have been done in the old days with an eraser.”

“Printing.”

“No,” they replied. “That could be done by monks in a monastery making copies by hand.”

I tried a few more but came up empty. So, how about it? Can you help me by coming up with a feature in a word processor, like Microsoft Word, that is new functionality and not just a change in how well something could have been done with pencil, paper, and similar tools.

The US-Russian War of 1981

Friday, January 25th, 2008

Nothing very profound in this comment but something I wanted to post because I’ve been thinking about it all day…

I started reading a new book called Made to Stick by Chip and Dan Heath. It’s about why some ideas are “sticky” and spread while other ideas die out. They start with the classic urban legend of the guy who is drugged and wakes up in a bathtub full of ice and discovers his kidney has been stolen. That’s a sticky idea. Many of us have heard it, and we remember it after hearing it. Sticky ideas and stories aren’t necessarily bad; they are just things that change our attention at just the right time and that are so intriguing/compelling/interesting that they spread like wildfire.

This got me thinking about sticky stories from my past and how perhaps stickiness has changed given the rapid communication of today, including and especially the Internet. One real story from my life is from back in January 1981. I was in college and living in the dorm. Ronald Reagan was newly sworn-in as President. A common joke at the time was that Reagan would start a nuclear war and blow up the whole world. The previous summer the US had boycotted the Olympics because of the Russian invasion of Afghanistan. It was a bit of frightening time.

That’s why I remember how scary it was one Sunday morning when our whole dorm woke to rumors that the US and the USSR had declared war on one another. We couldn’t confirm this, though. Not a single person in our dorm had a TV. None of the radio stations were saying anything about it. This was before Al Gore had invented the Internet. This rumor of US-USSR war was *sticky.* It spread around the whole dorm building within minutes. People were waking others, pounding on their doors saying, “Wake up, we’ve declared war on Russia!” Still, we couldn’t get any real confirmation of this.

I finally called my parents who lived two timezones away and were still asleep. I sheepishly asked, “Mom, did we declare war on Russia this morning?” She thought I was crazy so I explained. While I did that she turned on her television and confirmed nothing was being reported. That was good enough for us. All of us college students went back to sleep.

Two thoughts strike me form this: First, Communication has changed that much in 27 years. It was possible back then to be unable to verify something like a war. If that happened today I’d browse the web on my phone and know in seconds. Second, that was a very first-hand example of how quickly a sticky idea could spread.

It seems that agile might be a sticky idea.

Looking Forward to the Next Twelve Months

Sunday, August 26th, 2007

One of my favorite singers/songwriters is Jimmy Buffett. If the name isn’t familiar, you’ve almost certainly heard at least his song Margaritaville. There’s an even better song on that same album (yes, it was originally an album and I am old enough to have owned it on vinyl). The song is Changes in Latitudes, Changes in Attitudes. On this song, Jimmy sings,

I took off for a weekend last month
Just to try and recall the whole year.
All of the faces and all of the places,
wonderin’ where they all disappeared.
I didn’t ponder the question too long;
I was hungry and went out for a bite.
Ran into a chum with a bottle of rum,
and we wound up drinkin’ all night.

Although no one showed up with a bottle of rum last night (where are friends when you need them?), I did take some time off this weekend to “try and recall the whole year.” I had a birthday this weekend (as did my wife; we were born one day apart) so I felt entitled to a little nostalgic recollection over the year.

Wow—what a year it’s been. We’ve definitely seen agile cross over and become of interest to mainstream organizations. Even better, agile is definitely viewed as a viable alternative to heavier weight processes. Three years ago I used to get a lot of calls for consulting work that started with, “Can you help assess whether agile would be a good fit for us? We’re considering using it on a small pilot project.” In trying to recall the whole year, I didn’t get a single call like this. Instead, this year the calls I got were more like the one from Steve and Chris at salesforce.com in which they asked if I could help them transition 200+ people overnight to Scrum.

Jimmy continues in Changes in Latitudes, Changes in Attitudes:
Reading departure signs in some big airport
Reminds me of the places I’ve been.
Visions of good times that brought so much pleasure
Makes me want to go back again.

Good times that brought so much pleasure, indeed. I have the most wonderful job in the world. I get to work with people and organizations who are making positive changes. They’re changing their jobs, their companies, and our entire profession. I cannot thank my many clients enough for allowing me the opportunity to help you, learn from you, and be part of your successes.

I want to also thank anyone who reads my books and articles, attends conference sessions, or whom I meet other ways. It is such an honor that you look to me for insights and advice. I take that responsibility very seriously and always try to respond with the best advice I can.

Jimmy again:
I think about Paris when I’m high on red wine,
I wish I could jump on a plane.
And so many nights I just dream of the ocean.
God, I wish I was sailin’ again.

I did make it to Paris for a trip last fall. What a beautiful city—just like all the other great places I had the opportunity to travel this past year: Atlanta, Austin, Boston, Columbus, Dallas, Denver,Helsinki, London, Minneapolis, Orange County, Orlando, Oslo, Phoenix, Portland, Rockville, St. Louis, San Diego, San Francisco, San Jose, Seattle/Tacoma, and Washington. On the other hand, Jimmy’s right and at nights I do dream of the ocean. I grew up in Huntington Beach, California. I don’t know what someone who loves the ocean is doing living in Denver, but I really do like it here.

Jimmy wraps up with:
Yesterdays are over my shoulder,
So I can’t look back for too long.
There’s just too much to see waiting in front of me,
and I know that I just can’t go wrong

It’s exciting to think about what the coming year holds for agile software development and for those doing it. While the changes agile has made have been tremendous, there so much room for more. Think of all the projects and companies that haven’t yet started and that could benefit from a shift toward agile. The last year has been wonderful and busy. The next will be even better. Hopefully I find time to do more than dream of the ocean and do take time off for sailing.

Miscommunicating with the written word

Tuesday, May 22nd, 2007

What a wonderfully poor medium it is to communicate with written words. I’m sometimes amazed that we’re able to communicate meaning at all. Here are two good examples of how hard it is to communicate with written words.
A few weeks ago I was traveling and decided it was time to schedule another Certified ScrumMaster class. I emailed my assistant, Tonya, and said, “Please book the Hyatt in Denver for July 31-August 2.” A day or two later she emailed back saying, “The hotel is booked.” With that crossed off my mental to-do list I moved on to the next thing.

About two weeks later I’m again on the road and Tonya emails me saying, “Did you want me to find a different hotel in Denver or are you just not going to do that class?” I’m very confused because she’s told me the “hotel is booked.” Since that’s the case why is she asking me about booking a different hotel? We exchange a few more emails until I finally realize that her reply to me (“The hotel is booked”) did not mean “I’ve finished with that task; the hotel is booked.” It instead meant “The hotel is already booked by someone else; now what should I do?”

What’s interesting is to look back over the communication–nothing is wrong with what either of us typed into our emails except that we were each coming out the question from a completely different context.

Here’s a second example of how easy it is to miscommunicate: I’m in London this week teaching some classes for my good friends at Conchango. Since I can’t watch the basketball playoffs as I normally would this time of year I’ve been taking the opportunity to try to learn the rules to cricket. To someone with absolutely no prior exposure to the game it’s quite confusing especially as it seems to go on forever. I mentioned to my class today that I’m trying to figure the game out. One of the participants in the class shared with me the following instructions. These are apparently marketed as “Cricket Rules for Foreigners” throughout the UK:

You have two sides, one out in the field and one in. Each man that’s in the side that’s in goes out, and when he’s out he comes in and the next man goes in until he’s out. When they are all out, the side that’s out comes in and the side thats been in goes out and tries to get those coming in, out. Sometimes you get men still in and not out.

When a man goes out to go in, the men who are out try to get him out, and when he is out he goes in and the next man in goes out and goes in. There are two men called umpires who stay all out all the time and they decide when the men who are in are out. When both sides have been in and all the men have been out, and both sides have been out twice after all the men have been in, including those who are not out, that is the end of the game!

These rules are obviously intentionally obtuse. Notice how they are (probably) perfectly correct yet they say nothing about how to really play cricket. What strikes me is how similar these rules are to many requirements documents I’ve seen in the past–they may be accurate and perhaps clear to someone who already knows what is being said but they sure don’t convey any true understanding to the reader.

About

Sunday, October 22nd, 2006

The Succeeding With Agile blog is written by Mike Cohn, the founder of Mountain Goat Software, an agile training and consulting firm. He is the author of Agile Estimating and Planning, User Stories Applied for Agile Software Development, Succeeding with Agile, and books on Java and C++.

With over 20 years of experience, Mike has been a technology executive in companies of various sizes, from startup to Fortune 40. Mike is a founding member of both the Agile Alliance and the Scrum Alliance.

Mike is a Certified Scrum Trainer and offers training courses on a variety of Scrum and agile topics. A complete schedule of upcoming training is available or classes can be presented at your site.