I’ve yet to develop carpal tunnel injuries as a developer. I spend much of the day standing, walking around, talking to staff, and going to meetings. Not much time to spend hours on end at the keyboard without breaks.

One of my brothers who likes to experiment with different keyboards brought over his vertical keyboard this weekend to show us how it worked. He’s so impressed with it he’s bought one for home and one for work.

I only spent about 15 minutes with it, but I found it easy to use. Apparently touch typing works just as well with your hands tilted at 90 degrees. I was probably a few words per minute slower, but I assume that goes away with a little practice. The one change that clobbered me a few times was on the left the space bar produces spaces, but on the right side it’s a large backspace key. Anyway if you have carpal tunnel issues it might be worth taking a look at.

Tobias Mayer has a great post on modifications to the standard Scrum that have worked for him. One of these is the idea that tasks are not measured in hours:

Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such. This approach serves two purposes: firstly, ease and accuracy of burndown (burndown on tasks rather than hours, making the whole process binary: a task is done or it is not done) and secondly it raises impediments which developers themselves may not see. For example, an incomplete task may be in that state because a developer was called off into some long and meaningless meeting, but because “that is the way we work around here” this is not seen as an impediment. Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.

Nice to know I’m not alone on this idea of trying to get away from a focus on the exact hours for a task. If all of the tasks are a day or less, tracking becomes simply done or not done. We haven’t used this approach formally on any Scrum projects, but I may bring it up at a retrospective and suggest to a team that they might try it out for a Sprint. I also really like the idea of having a burndown chart that tracks number of tasks completed rather than hours.

The whole point is are you getting the backlog items, aka features, done or not. The tasks are just some of the details on how you get there.

Yes, Scrum does have a secret handshake, you can find out about it if you take one of the CSM courses. It’s a little bit of fun nothing all that serious. It also involves ‘woofing’ like a sheepdog. Apparently it’s ruffled the feathers of some ‘serious’ Agile practitioners, to the tune of 30+ messages on the Scrum Yahoo group. After seeing some of the debate Ken posted his thoughts:

You know, I think I’m really glad that I added something light such as a secret, encrypted handshake. It really seems to be a good way of weeding out people who don’t have a sense of humor and are, maybe, too serious about everything. Or, maybe, I expect too much from CSM’s. I think that the work we are undertaking is so serious and so hard that any way that we can inject levity is well worth the effort. I always thought that “woof” created some sense of camaraderie, but maybe I’m wrong.

If you’re not having fun at work, at least some of the time, it’s time to find a new job. It’s an ‘Agile’ lightweight process not a high ceremony, formal, always serious process.

CIO Magazine has a great article on Users Who Know Too Much (And the CIOS Who Fear Them). The tone of the article suggests that IT organizations need to embrace new web based technologies from IM and GMail to BaseCamp and WordPress. They’re making your business a better more productive place even if your sysadmins are screaming about those ‘idiotic users.’

Rob Israel, CIO of John C. Lincoln Health Network, has seized on this and come up with a novel solution:

“I’m the only person in IT allowed to say no,” he says. Conversely, his IT employees have only three options: approve a request, research it or pass it up to him. According to Gold and Israel getting a reputation for saying yes will encourage users to come to you with ideas. That gives you the chance to learn what it is that the user is really trying to do and come up with a way to do it that won’t compromise security.

Assume that your internal customers are using a new tool for a good reason and support their attempts to improve productivity. Rob sounds like the sort of progressive CIO we need to see more of.

Twenty-three hours later the nasty bug is squashed.

Turns out I descended into completing project tasks last week. Generally I get massive pangs of guilt. I know some other management tasks fall by the wayside from that PO I was supposed to fill out for Acrobat to following up with a business manager on a potential new project. On top of that I get emotionally attached to squashing a bug and I typically can’t let it go. The 23 hour bug spanned out over a couple of days of work and some really late nights.

Rands of Rands in Repose explains that despite all the enlightened ideas of moving away from the technical work that you just have to stay in the code:

I’m not wishing confusion and chaos on your team. I’m actually wishing better communication on it. My belief is that if you are building the product and touching the features that you’ll be closer to your team. But, more importantly you’ll be closer to how software development is constantly changing in your organization.

So I’m in good company, as based on his blog alone Rands appears to be a hell of a development manager. He makes four points about what you need to do:

• Use the development environment to build the product.
• Be able to draw a detailed architectural diagram describing your product on any white board at any time.
• Own a feature.
• Write a test script.

I managed to do all of these suggested items in some form already, I’m a genius!

I run two IDEs currently on my work laptop. One by choice and for productivity (IntelliJ IDEA) and one because all of my developers use it (RAD).

I can whiteboard any of my three big projects right now to some level of detail if asked. The one that I get the architecture least is a 3rd party vendor product and I just need to sit down and actually do some code reading to understand it better. And not knowing it’s architecture in more detail bothers me.

Owning features, that’s just crazy. There’s danger of going overboard here on Rands account, but since my developers are on at least three projects at a time I think owning a feature on each would be pretty much management suicide. The PMs/Scrum Masters on the projects would love it because I’m a ‘free resource’ who isn’t going to bill time against their project. I do my part though with helping out on the occasional bug, keeping the build box running, participating in a code review and on rare moments owning a bug or feature.

Finally, writing a test script on the build is a specialty. I tend to write the actual ant scripts that run our builds, and I maintain the build box running a copy of Hudson. I also manage our code review tool, and hook in Clover and Checkstyle into our builds. I know the code that’s getting checked into source control.

I’m rethinking my little voice that keeps saying, ‘don’t even think about firing up your IDE today, you have 6 meetings to go to.’ Maybe I should finally get around to pairing up with individual developers to go through a TDD exercise for a few hours each, couldn’t hurt.