Red Squirrel Reflections
Dave Hoover explores the psychology of software development
|
|
Red Squirrel Reflections
Dave Hoover explores the psychology of software development
|
|
Thu, 05 Apr 2007Heading 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 Tue, 31 Oct 2006Martin'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." Mon, 09 Oct 2006In 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) Tue, 25 Jul 2006Agile 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. Fri, 07 Jul 2006I'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. Fri, 21 Apr 2006My 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. Sat, 24 Sep 2005Constantine 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."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. Fri, 29 Jul 2005In 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. Mon, 20 Jun 2005XP 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.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.Mon, 06 Jun 2005Ping-Pong Programming on StickyMinds.com I blogged about Ping-Pong Programming in January. That blog entry has morphed into an article on StickyMinds.com.Fri, 01 Apr 2005Ping-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.Mon, 28 Mar 2005Reconsidering "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? |
