Red Squirrel Reflections
Dave Hoover explores the psychology of software development

Dave Hoover
dave.hoover@gmail.com

Categories
All [Atom]
Craftsmanship [Atom]
Dynamic [Atom]
Intersection [Atom]
Learning [Atom]
Links [Atom]
Polyglot [Atom]
Projects [Atom]
XP [Atom]
Old Blog

Obtivian Blogs

Andy Maleh
Colin Harris
Fred Polgardy
Jim Breen
Kevin Taylor
Todd Webb
Turner King
Tyler Jennings

Archives

March 2009 (1)
January 2009 (1)
December 2008 (1)
October 2008 (3)
September 2008 (1)
June 2008 (4)
April 2008 (3)
March 2008 (1)
February 2008 (1)
August 2007 (1)
July 2007 (1)
June 2007 (1)
May 2007 (4)
April 2007 (3)
March 2007 (5)
February 2007 (6)
January 2007 (6)
December 2006 (10)
November 2006 (5)
October 2006 (8)
September 2006 (8)
August 2006 (5)
July 2006 (12)
June 2006 (7)
May 2006 (5)
April 2006 (5)
March 2006 (4)
February 2006 (2)
January 2006 (5)
December 2005 (5)
November 2005 (3)
October 2005 (3)
September 2005 (6)
August 2005 (4)
July 2005 (7)
June 2005 (14)
May 2005 (6)
April 2005 (8)
March 2005 (9)
February 2005 (11)
January 2005 (16)
Old Archives

 

Thu, 05 Apr 2007

Heading to D.C. to demonstrate One-Size-Fits-One

Tyler and I will be presenting the fruits of some of Obtiva's Rails work at Agile 2007. We have delivered several planning and tracking tools for software development teams using Rails over the last six months. Through these engagements, we discovered that Rails proficiency and Agile coaching are a killer combination for creating planning tools that you can adapt alongside your process. While there are plenty of one-size-fits-all agile planning tools out there, they often do too much, too little, or can't adapt to your needs. If you're an agile team using planning and tracking software (rather than Excel or index cards), you need software that's actually soft, like an agile process.
If you follow a methodology out of the box, you will have one that fits some project in the world, but probably not yours. --Alistair Cockburn, Agile Software Development

[/xp] permanent link

Tue, 31 Oct 2006

An Uninteresting Question

Martin's post on Pair Programming Misconceptions is littered with pragmatic insights for anyone considering adopting pair programming. This was the one most relevant to my current mindset:
"I should also point out that to most XPers I know the question of whether a team is XP or not is uninteresting; the real issue is whether a team is effective."

[/xp] permanent link

Mon, 09 Oct 2006

Phaedrus on Retrospectives

In the midst of the flood insanity, I've finished reading the classic Zen and The Art of Motorcycle Maintenance. It has certainly inspired me on many levels, and provided excellent food for thought as I continue to ponder the Apprentice to Journeyman patterns on a background thread. The most directly applicable quote I found in my study of the book related (in my head) to Retrospectives:
"You look at where you're going and where you are and it never makes sense, but then you look back at where you've been and a pattern seems to emerge. And if you project forward from that pattern, then sometimes you can come up with something." (pages 167-8)

[/xp] permanent link

Tue, 25 Jul 2006

Agile Retrospectives: Making Good Teams Great

Two of my favorite facilitators, Ester Derby and Diana Larsen, have written the long-awaited follow-up to Norm Kerth's seminal work. The following was my response after I read an early draft of Agile Retrospectives:
Two of the software industry's leading facilitators have taken their many years of retrospective experience and distilled them into an approachable reference for agile team leaders. For all of the self-made facilitators out there who have been winging it, this book will provide a solid foundation to improve the effectiveness of your iteration, release, and project retrospectives.

[/xp] permanent link

Fri, 07 Jul 2006

Let me Drive! A Pairing Story

I've been coaching a team of developers for a couple months. We have had a bunch of new people join the team while others have rolled off onto other projects. This has presented a lot of opportunities to redefine things, along with a bit of chaos. It's been great to see that a number of these new hires are women, which on an XP team tends to work well, since women tend to be more interactive. That said, some of these folks can also be fairly passive, which can be a challenge when they're pairing, because the more dominant personalities among us often grab the keyboard and never let go until someone suggests otherwise.

Today I was developing a black-box regression test with one of these more recent hires. We were about to rip apart a bunch of code across an entire sub-system and needed some high-level tests to ensure that we didn't change any behavior. Well, being the hyperactive-Ruby-hacker that I am, I was a bit overzealous with the keyboard. It was a pivotal (and exciting) moment when my soft-spoken pair programmer quietly berated me for hogging the keyboard and took it back. I was chuckling at myself the rest of the day as I watched her grow more comfortable with Ruby and the Watir API.

[/xp] permanent link

Fri, 21 Apr 2006

XP doesn't stand for XPlanner

My current client (Retail X) and my former client (Bank Y) both use XPlanner to manage their XP processes. If one must store stories electronically, then XPlanner seems to be the most stable free software around to do that, so thank you XPlanner developers for your work. One aspect of process management software is that it (inevitably?) embodies the opinions of its creators. Is process management software inherently opinionated software? While opinionated software is not bad, it does expose differences of opinions between users and creators, and this is where I find myself with XPlanner.

Bank Y began adopting XP prior to using XPlanner, and I think this gave them an advantage over Retail X. Bank Y had established its XP process through researching XP, hiring ThoughtWorks to lead the effort, and adapting it via iteration and project retrospectives. When the need arose for story tracking from remote locations, XPlanner was installed and we used it in the best way we could. Which meant we ignored/hijacked some of the ways it tried to make us work. For instance, it wants us to estimate in hours, but we used days. It wants us to track actual time spent, but we never did.

I could be wrong, but my new client, Retail X, seems to have started doing XP by installing XPlanner and giving it what it wanted. Velocity is tracked by using actual time and estimates are in hours. Basically, the process has conformed to the opinion of XPlanner. Guess what? It doesn't quite fit right. I'm reminded of one of my favorite Cockburn quotes:

If you follow a methodology out of the box, you will have one that fits some project in the world, but probably not yours. --Agile Software Development, Alistair Cockburn

If you're going to use software to manage your software development process, realize that you're going to run into differences of opinion. I hope that Desi, Obie and Aslak can continue their work in this area, because I know our opinions about XP are well aligned.

[/xp] permanent link

Sat, 24 Sep 2005

Constantine on Agility in 1993

I'm slowly working my way through The Peopleware Papers by Larry Constantine. It is a collection of short articles, which makes it ideal for intermittent train reading. I was reading "Chaos Manners" (Software Development, May 1993) when I was surprised to see the following quotes:
"Genuine innovation requires an agility beyond the traditional tactics of top-down management."

...

"The trick is to bring out and capitalize on the inventive energy of independent thinkers, encouraging free exploration and individual initiative, to foster a kind of creative chaos that hovers on the supercharged edge of running completely amok, a sort of controlled insanity that breaks out of accepted modes of thinking and challenges assumptions about limits and possibilities."
I was surprised because Larry was writing this 12 years ago, yet for anyone who has read Highsmith or Hock, Larry's ideas sound very familiar. On further reflection I realized I was being naive. It is not as if the thinking behind XP or any of the agile methodologies spontaneously sprang into existance. These sorts of ideas ripen over time, blossoming in a specific season under the right conditions.

[/xp] permanent link

Fri, 29 Jul 2005

Remote Ping-Pong Programming

In response to my StickyMinds article on ping-pong programming, Ivan Vaghi emailed me with a story of a remote ping-pong programming session. He doesn't have a blog so I figured I would post it here (with his permission)...
Yesterday I tried a remote ping pong coding session with a friend.

The social dynamics and the fun are amazing. If you want to try it out get the MoonEdit collaborative editor and setup a coding session. We split the editor space in 2 parts. While one of us was writing tests, the other just by glancing at the tests was writing the code.. the amount of information that passed through, just by coding, not even by talking about it, is amazing. People also somehow develop social protocols so that they don't get in each others' way.

It is an intoxicating experience :-) Who said that when two minds meet, a third mind emerges? That's the feeling that it gives you while you see the code emerge and evolve. It almost feels like you are looking after a living thing, pruning some code here, splitting some code there, rather than doing actual coding. I guess it's due to small seemingly unimportant changes building up into functional code.

It's amazing when, after having done the work, you replay the session using the 'history' feature and you see the living code evolving, growing, getting fatter, splitting and adjusting to a new position.. it feels like the tests are nudging the code to a new shape, to a new position.

[/xp] permanent link

Mon, 20 Jun 2005

XP Declared Not Trendy; Please Move Along

Jutta Eckstein gave the keynote at XP2005 tonight. She declared that XP and Agile Development are no longer trendy (they've reached the beginnings of maturity) and that the trendsetters should probably move onto something else.

I agree. But this begs the question: Where do they go? I hope that they go where Uncle Bob thinks they will go: onto Software Craftsmanship.

[/xp] permanent link

Out of America; Old Friends, New Friends

I flew into Manchester yesterday morning, caught a train to Sheffield, and showed up at the University in time to meet Laurent, Emmanuel, Uncle Bob, Liz, and Tim, for the Coder's Dojo workshop [PDF], which was marvelous. Uncle Bob wrote an excellent write-up.

Alan was lurking about in the hallways wearing a Mac OS X t-shirt that he later gave to me as a gift. Thanks dude.

[/xp] permanent link

Mon, 06 Jun 2005

Ping-Pong Programming on StickyMinds.com

I blogged about Ping-Pong Programming in January. That blog entry has morphed into an article on StickyMinds.com.

[/xp] permanent link

Fri, 01 Apr 2005

Ping-Pong Programming in Better Software

Rachel wrote an excellent article about pair programming in this month's issue of Better Software. I was interviewed about ping-pong programming for a sidebar to the article.

[/xp] permanent link

Mon, 28 Mar 2005

Reconsidering "Sustainable Pace"

It just occurred to me that I might have a problem with the term "sustainable pace" used in the context of extreme programming. Or perhaps I've never fully understood this idea and someone needs to enlighten me. I was just doing a bit of writing and was using "sustainable pace" in a sentence when it occurred to me that when I use the term "sustainable pace," I'm focusing on working a reasonable number of hours per week.

But "pace" doesn't refer to a quantity of time, it refers to a rate of speed.

I find myself wondering whether this phrase might be sending the wrong message. By metaphorically linking the number of hours worked with the speed of the team, are we implicitly discounting the idea that the speed of the team might be relatively independent of the number of hours worked?

[/xp] permanent link


powered by blosxom