Software Development is a Team Sport! : Recommended

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.

VSTS Guidance

aridle — Fri, 30 Mar 2007 20:35:00 GMT

A few years ago, patterns & practices published a book entitled Team Development with Visual Studio .NET and Visual SourceSafe. The book offered solid advice for teams developing software atop .NET using Visual Studio and Visual SourceSafe. It covered things like structuring solutions and projects, setting up a build process, working with source control, and even setting up the infrastructure for a team development environment.

As you might imagine, the introduction of Visual Studio Team System pretty much obsoleted the book. It was a fantastic book in 2002. But, it was very specific to Visual Studio .NET (2002) and Visual SourceSafe (6.0c). So, naturally, p&p started receiving requests to update the guide as soon as customers began using VSTS with all of its new team oriented features.

Well, we've been busy working on software factories for a while now. But, recently, J.D. Meier and crew have been building up a library of VSTS guidance over on CodePlex. I just spent a few minutes exploring the site. And, I've got to say that I'm very impressed with the volume and quality of work that J.D.'s team is doing. (Full disclosure: I'm a reviewer on some of the work.) I'm also a big fan of publishing the work as a Wiki on CodePlex.

My congratulations to J.D. and the entire team! Way to go! Keep up the great work!

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.