Agile Otter Blog

It's a common thread in agile transitions that people are not sure what pairing, teamwork, and self-organization will do to their status on the team. Will the team be so leveled that nobody will stand out? Will the weak be exposed and humiliated? I am going to write this as if there were two states, strong and weak. Before reading anything that follows, remember that everyone is good in some areas and weaker in others. I have seen javascript gurus who weren't very database-smart, and people who were great with requirements and product knowledge but had no sense of scalability or performance. Any human characteristics are spectra, not point measurements. With that in always in mind, read on: There is good news, more good news, and some hard and potentially sad news in all of this. The first bit of good news is that nobody who works in an agile team ever asks these questions. In reality, it's not a problem. Let's get down to cases. Rockstars If you are the rock s...

This week I made some social networking advancements and started to build a few other new skills. The first is Tweet Feed which is likely responsible for you seeing this short article. I am not going to have to hand-tweet the AgileInAFlash or AgileOtter articles because they're auto-tweeted for me. The second is that blogger's admin screens let me turn on the social button bar after each article, so readers may more easily promote anything they find interesting or outrageous. It's a small thing, but already I've seen a new tweet from the page. It's a very small thing, but sometimes small things matter. I'm on ohloh now. My friend Sam Hart has prodded me a bit, and I finally realized he's right (it takes me a while sometimes) and I should take some credit for the work I've done in the public space, like the PDK. I never realized that I was the check-in leader there. Sam wants me to pick it up and make it a living project again, and I'm thinkin...

I have our first video finished.  Notice how my face never appeared.  I'm going to have to get used to hearing my voice on these, maybe I'll do the full-frontal face thing in one of the future videos. Either way, we now have a commercial that explains what this whole Agile In A Flash thing is about.

I have played with Django, but never really did any work in it. Even my toy app died before I got to a "good working model" state with it, because I did not maintain focus and wandered off too much. Since then I've developed a keen interest in learning more web technology, and so this time is Django Charge 2.0. I visited some very nice, very smart people this week to took me into their offices and showed me some of their Django code. We started to talk about testing, and I made a small abortive attempt to do some plain-old-unit-testing in their python code base. It was not all that I hoped it would be (Dean, please revert that code if you haven't already). I ran out of time to play, but hopefully will be back to enjoy some pair programming goodness in the near future. The cool and interesting bit about Django testing is that testing through manage.py will have you standing up an instance of the app complete with database. The setup is fairly onerous, but the t...

Today the deck is released for purchase. I'm getting tweets and messages from people who have either purchased the eBook or placed an order for decks. Thanks to everyone for their support in our crazy little project. So far many retailers are selling. Prag Prog Amazon O'Reilly Borders Buy.Com Deep Discount E Campus

The one thing I haven't said about my time as a remote pair programmer is that remote pair programming is a brilliant idea and it matters. The reason I didn't mention it there was because that was work. This is personal development. We improve our skills and our exposure in the world by pairing with more people. I've been a shy guy, not always jumping into the pairing sessions at conferences, and I'm the poorer for it. I could have been soaking up mojo from the greats instead of hiding out. But remote pairing? You are not in front of a whole bunch of strangers who are potentially judging you. You're in a one-on-one situation with someone you couldn't have visited personally due to any number of travel constraints. It's just the two of you and your headphones. You can work on your code, or the other guy's code, and it doesn't matter. It can be 6am or 2am or noon on a saturday, any time your schedules just happen to coincide. This is something ...

Being a telecommuter or remote team member is considered a pretty sweet deal and is recognized as a more "green" way of working. Remotes don't share illnesses with their teammates, and yet work when ill. Remotes don't participate in office gossip or struggle with personalities the way locals can. The perceived problem with remotes is that they are unmanaged (in fact, they are impossible to micro-manage effectively). The actual problem with remotes is that they can be disconnected. The solution to the perceived and real problem seems to be in the sweet spot of remote pairing. I was lucky enough to work for a few years as a remote pair-partner. As a remote, I worked common hours just as my peers did. I joined them in the morning, took lunch when they did, and worked until they went home in the evening. We spend most of the day on-camera together (or at least in voice via headsets), sharing the screen and development tools, writing tests and code, exploring technic...