Software Development is a Team Sport! : Books

Agile 2007: The First Thing to Build - Trust on Agile Teams

aridle — Wed, 22 Aug 2007 00:12:29 GMT

Diana Larsen is a special sort of nut. She's an organizational development and communications expert, not a technologist. Her sessions touch on many of the softer skills necessary to thrive on a team (any team, not just an Agile team).

I've been seeking out and attending Diana's sessions since my first experience with her and her toys back at ADC 2004 when she ran a Discovery Session that explored self-organization. (Speaking of the toys, I didn't see them this year. Where were they, Diana?)

In this session, Diana explored the concept of trust, starting with a quote from Brad Appleton: "The first thing to build is trust." I took several pages of notes during the session. But, of everything, one point stood out for me: individuation.

Individuation is the process of getting to know someone as a person, finding out what differentiates them as an individual. Without individuation, all you have to judge someone are the stereotypes and prejudices that you carry with you. (And, I with me.) In order to truly trust someone, you must get to know them personally.

It seems so simple that it's almost silly. But, I'd never thought about it before. And, it explains a lot about my own behavior and that of others with whom I've worked.

During the course of the session, Diana recommended several books, including:

And, one of the folks at my table highly recommended another, related book:

The Five Dysfunctions of a Team

There was much more to the talk than I'm mentioning here. I recommend looking through Diana's slides if you are interested in more information. The slide on symptoms of distrust (12) is work the click alone!

Agile 2007: Having Fun with Rails & Agile Development

aridle — Tue, 14 Aug 2007 21:46:00 GMT

In 90 minutes, Garg, Matt and David built a working web photo sharing web site. Garg played customer. David played whip-cracker (um... PM), and David did all the heavy lifting with Rails.

This talk was a high level introduction to the speed and power of Rails as a development environment. As such, I found most of the material repetitious of other demos I've seen. But, the guys did a good job of showing off the Rails notion of "convention over configuration." They also showed off RSpec and demonstrated the plug-in architecture.

Recommended resources (from Garg, Matt and David):

I would have liked the session to be more hands-on. I'll have to check out the Rails lab for that level of immersion.

Agile Prioritization

aridle — Sat, 28 Apr 2007 04:26:00 GMT

Joel Spolsky and Dmitri Zimine mixed it up last November over whether or not to interrupt a team in the middle of an iteration. I'm pretty late to this thread. But, I think I have something to add. So, here goes...

Dmitri started the thread by arguing on behalf of never interrupting an iteration once it starts. Basically, he's just parroting the party line from the Scrum doctrine: Management is not allowed to interfere with the operation of a team during a sprint. If they do, the team can cancel the sprint.

Joel countered that you should consider the nature of the interruption before blindly preventing it. He argues in his inimitable way that the financial independence of the individuals involved could very well be at stake. He may as well have been yelling: "Take door number 3!"

What both guys missed is that they are arguing the opposing sides of a pendulum, and that the real truth probably lies somewhere in the middle. (Ironic considering the tagline on Dmitri's blog.)

Here's my advice when faced with the decision of whether or not to accept new work after an iteration has started:

Take five minutes to estimate the newly requested work.
Communicate this estimate to the person who requested the change in scope.
Explain the concept of velocity (if necessary).
Ask them to stack rank the new work into the remaining backlog of unfinished work for the current iteration.

There, now. Everyone has visibility into the process. And, the person in the best position to make the call as to priorities - the one who knows both the benefits and (now) the costs of swapping in new work - is the one responsible for making the decision. That's what I call Agile Prioritization.

For further study, I recommend that Dmitri and Joel (and everyone else) read Mike Cohn's excellent book: Agile Estimating and Planning.

Crucial Conversations

aridle — Thu, 29 Mar 2007 20:51:00 GMT

Need to fire someone? That's probably going to be a crucial conversation. Need to talk to your spouse about the fact that they are having an affair? That's almost certain to become to be a crucial conversation. Need to gently, but firmly ask your pair-programming coworker to do something about their chronic halitosis? Even that could turn into a crucial conversation.

So, what exactly is a crucial conversation, anyway? Well, according to the authors of Crucial Conversations: Tools for Talking When Stakes are High, any conversation becomes a crucial conversation when the following three elements are present:

High stakes
Differing opinions
Strong emotions

And, also according to the authors, how we handle these conversations has a measurable impact on our success in life. If we withdraw from these conversations (or "go to silence" in the book's vernacular), we risk not ever getting our needs met. If we force the issues (or "go to violence"), we risk our long term relationships with those involved.

The best among us handle these conversations honestly, earnestly, and without hurting others. They express their needs, listen to the needs of others, and work toward a mutual purpose while maintaining mutual respect.

To be honest, I found some of the imagery in this book a bit silly. ("Shared pool of knowledge?") But, I found the underlying message about how to talk about difficult subjects with literally anyone extremely useful, both professionally and personally. It has provided me with much fodder for thought. Ultimately, I think it would be most useful in an environment where an entire team reads the book. That way, the silly vocabulary will be a shared point of reference the next time tempers flare.