Archive for August, 2007

31
Aug

Natural Capitalism

I usually don’t rave about books until after I finish reading them. I’m going to make an exception because I just completed reading two great chapters that are already worth telling everyone that this is shaping up to be a wonderful read.

The book I’m referring to is an older book (1999) called Natural Capitalism. I’ve only spent two evenings with this book and I’m already a huge fan.

The book is big and dense, but it has a ton of thought and supporting evidence behind it. Simply put, this book kicks ass.

I’ve heard this book mentioned a few times by a few different people, but I decided to buy it after seeing it referenced by Ryan Martens during a presentation at Agile 2007. Ryan pleaded his case for the “greening of software” and made a few interesting references to the book.

My mind is swirling with ideas and thoughts after flipping through the introductory chapters.

You can find the book on Amazon or you can download it (chapter by chapter) on the Natural Capitalism website.

30
Aug

Data Visualizations

The quality of data visualizations (and their availability) have gone way up lately. Here are a few of my faves…

Newsmap (Google News)

Bigspy (Digg)

Arc (Digg)

Stack (Digg)

30
Aug

TSP on the iPhone

29
Aug

The Metabolism of Industry

“In the United States, the materials used by the metabolism of industry amount to more than twenty times every citizen’s weight per day—more than one million pounds per American per year.”

… from Natural Capitalism.

Ouch.

27
Aug

Career Goals For The Next Six Months

I got tagged by Jim, so here’s my career goals for the next six months…

Learn more about usability, interaction design, human factors, and user experience.

I’ve had the opportunity to work with some individuals on recent projects that were incredibly good in these areas. There’s a lot that I have to learn here and it’s an area that developers are usually really bad at. I’m convinced that these areas are frequently overlooked and that we all need to learn how to integrate these items into our software. I want to understand the thought processes around these items deeper than I currently do.

Build out some (very) compelling presentations / talks / stories.

I love to speak, but I don’t do enough of it. I’ve got a lot of things that I want to say, but I haven’t been doing a good job of saying them (outside of my standard work environment) lately. I need to build out some really good presentations and start giving them. This takes quite a bit of time, but it’s well worth it.

Build a WPF app on the side.

I love WPF. It’s a great technology and I have some interesting ideas for places that it can be applied. I’ve got a simple side-project in mind that I want to create and distribute. I’ll probably do this as an open-source application and hopefully learn a lot in the process of building it out.

Question my assumptions about process.

I’ve been preaching the benefits of agile methods for quite a while now. Actually, maybe a little too long. I’m afraid that my “default” arguments are becoming routine. I need to step back from what I (think I) know and question myself more. There are still plenty of areas where agile methods can be extended and improved.

Strive for simplicity.

I’ve become obsessed with simplicity and minimalism. This is still playing out in everything from my day-to-day work to my living arrangements. I want to continue to explore this in my everyday work life. I’ve recently completely replaced taking notes with drawing mind maps. I feel like the next step is probably to make the mind maps much smaller and more precise.

24
Aug

Learning From Journalism - The Inverted Pyramid

In developing and envisioning software, it’s easy to forget about prioritizing value. Even with agile development teams, it’s common to see “sets” of functionality prioritized instead of rank-ordered. One idea that I’ve been pushing hard on lately is to not let anything into the backlog that’s not prioritized (as in rank-ordered).

Why? Well, one place we can pull ideas from is the inverted pyramid approach to journalism. The inverted pyramid approach is a common metaphor in journalism to avoid “burying the lead.” The “lead” of an article is the beginning of the article that conveys the core information of the story.
Journalism (and the publishing models of newspapers and periodicals) is a great place to look for ideas and inspiration for agile approaches. When a newspaper has to be distributed, it has to go. A newspaper isn’t held up for individual journalists to finish their articles. Sound familiar? This is exactly the same as doing time-boxed activities in agile approaches.

The essence behind the inverted pyramid (from Wikipedia):

The triangle’s broad base at the top of the figure represents the most substantial, interesting, and important information the writer means to convey. The triangle’s orientation is meant to illustrate that this kind of material should head the article, while the tapered lower portion illustrates that other material should follow in order of diminishing importance.

This makes perfect sense for a couple of different reasons (all of which have their own parallels in agile development):

  1. If everything doesn’t match up perfectly in the layout or limited real estate of the paper, the end of the story can be cut out without sacrificing the important essence of the story. This also allows for the staff to quickly make room for late-breaking news or for additional advertising.
  2. The reader of the story doesn’t need to read the entire article to understand the core elements of the story. In fact, they can usually get almost all of the information by just reading the first few sentences.

In addition to using this as a guiding principal for the prioritizing of the backlog (see reason #1 above), we can also apply this technique to our own writing for any documentation that we need to create (see reason #2).

I first ran across this concept while reading Made to Stick. One of the quotes from the book is by Dan Wycliff (an award winning editorial writer) who says:

“I’ve always been a believer that if I’ve got two hours in which to write a story, the best investment I can make is to spend the first hour and forty-five minutes of it getting a good lead, because after that everything will come easily.”

Practicing this approach can help us steer towards generating revenue faster (through prioritized features) as well as clear writing (by focusing on the important information).

21
Aug

The Power Of Silence

An interesting facilitation technique that I’ve learned to frequently rely on is silence. The first time I ran across the technique was in a CSM course taught by Hubert Smits and Tamara Sulaiman. One of the exercises that we explored was Silent Grouping. The exercise was great and worked very well in the context of the training session.

When I returned to work I started trying various techniques with silence and most of them went very well. The majority of our facilitated sessions were very large and it was usually a constant challenge to move off of side conversations and keep the group focused. One of the techniques that frequently returned good results was using time-boxed silence alongside various other techniques that are used often in agile meetings (brainstorming, prioritizing, sorting, grouping, etc.).

There just seems to be something about the ability to become rational, absorbed, and focused on the task when the “no talking” rule is in effect. It frequently seemed easier to drive towards consensus when the group used silence as a method for creating, grouping, and processing information.

20
Aug

Be Careful With Your Numbers

A couple of years ago I put together some collateral to use when “selling” agile to potential clients. As part of the effort to educate our sales team about agile methods I wanted to provide some strong evidence for our sales team to use.

The only numbers that I had seen at this point were the numbers cited in Agile and Iterative Development: A Manager’s Guide by Craig Larman. To say the least, the numbers were very impressive: Of those polled, 93% saw increases in productivity, 88% increases in quality, 83% improved stakeholder satisfaction, 49% reduced costs, and so on. I dropped these numbers in the collateral and I made every one of the sales members happy.

A few months later I was looking for some deeper numbers and I started to dig deeper for more quantitative data. The first place that I went to look for numbers was the study used that came up with the above numbers (by Shine Technologies in 2003).

When I started digging deeper, I realized that this survey has huge room for error. I’m not an expert on surveys or quantitative methods, but what I read didn’t leave me feeling convinced that it was worth publishing and standing behind the results.

After digging a little deeper, I noticed that these numbers (that I had been advocating) were based on a web-based survey that had only been taken by 131 people. Yes, 131 people and web-based. Ouch.

You can find the survey here.

Now, I don’t want to completely discount the survey and/or the results. This is important information; but I’m just not comfortable presenting these findings as “evidence” that agile works. I’m just not comfortable putting them up on my company website and I’m not comfortable putting them in my presentations. I believe in agile methods, I just don’t believe that this study “proves” that they are a valid alternative.

An interesting thing that I have noticed is that many individuals and many companies have used this survey as justification for agile initiatives. Last week (at Agile 2007) I saw these numbers presented multiple times in slide decks and I’ve seen them on plenty of web sites of vendors that are offering agile services.

Anyway, I just thought that this was an interesting bit to share about how you should always know more about the survey results and numbers that you use to backup any claims. Make sure you can stand behind your numbers and that you find out the information behind the numbers.

17
Aug

Agile 2007 - Parting Thoughts

Overall, Agile 2007 was a wonderful experience. I really enjoyed my time at the conference and attended some really good sessions (and a few that were really bad as well). This was my first conference and I’ll be back for sure next year.

My favorite sessions included:

(Follow the links for the abstracts, presentations, and handouts)

  1. Agile Enterprise Rollout–The Greening of the Software Industry (Jean Tabaka, Ryan Martens)
  2. The Role of Leadership in Software Development (Mary Poppendieck)
  3. Learning Kaizen from Toyota [with MindMaps] (Mary Poppendieck, Kenji Hiranabe)
  4. I Don’t Like Mondays - Improving Agile Team Collaboration Events (Jean Tabaka)
  5. Reaching New Heights: Learning to Adapt is Essential (Susan Ershler)
  6. Agile adoption at Google: Potential and challenges of a true bottom-up organization (Mark Striebeck)
  7. The Agile Enterprise: Real World Experience in Creating Agile Companies (Jeff Sutherland)

Some of the big-picture realizations that I came to:

  • Mary Poppendieck has turned into the Tom Peters of the software industry (well-deserved).
  • Lean thinking has started to move to the center of the agile universe (finally).
  • Executable specification / story-driven development is moving to the mainstream (finally).
  • Everyone wants to scale agile.
  • Everyone wants to distribute agile.

A few things that I’m concerned about:

  • Lean has moved to buzzword status. A lot of people are talking about Lean but I don’t think the majority understand the essence behind it. I think this will get better.
  • Everyone wants to make “Enterprisey” software with agile teams.
  • There are a lot of “agile” consulting firms that are full of shit.

And some other random thoughts…

I think the fact that everyone is focused on “scaling” agility to large teams and distributed projects and that there will be a lot of agile disasters over the next couple of years. Now that the bigger software companies are moving to agile, the teams are getting too big and they are adopting agile in scary ways (too big, too fast). I think that you need to evolve to big teams, not start out there. I would also (passionately) argue that you should focus on how to have smaller software instead of how to scale agile teams to accommodate large software. I seem to be in the minority.

Lastly, I really think that the organizers of the conference need to step it up. The programs sucked (hard to read, hard to navigate, mis-prints, missing pages, etc.), the event was really hard to follow (talk duration, locations, topics), the location of the conference sucked (tight hallways, hard-to-find rooms, etc.), and the beverages and food was awful (a big thank you goes to Rally for providing everyone with bottled water).

I certainly appreciate that everyone worked hard to put this together, but I expect the basics to be nailed for a major conference.

12
Aug

Best Error Page Ever?

Pownce 403 page…

403