Overtime on Agile Teams?

My recent article on Overtime and Agile Teams was accepted and published in Software Quality Connection.  Here are a few statements extracted from the article to summarize its direction:

• "Predicating project plans on constant overtime is a bad idea." 
• "Agile requires whole people."
• "Overtime is for bumps."
• "You have to ask if your overtime is hiding problems instead of exposing them so that the team can solve them."

My OSS Software (inventory)

What I need to replace when I get the new machine:

Chrome, Firefox, Midori: Browsers - usually two or more open at one time.
gvim, git, svn, poor ole' cvs: Essentials for software dev, b/c I often have three or four bash sessions open.
Miro, Gpodder: audio and video subscribe/play - free video, audio, kept consistent.
FBReader, Calibre: ebook & magazine readers -- I need to move my ebook collection, too.
OpenShot, Arista transcoder, mencoder, Istanbul: video editing, transcoding, and screen capture
Inkscape, Gimp,  F-Spot:  svg drawing, image editing, image manager
OpenOffice: free office suite w/ word processor, drawing, spreadsheet, presentation
FreeMind: mind mapping
Skype, TeamViewer: remote pairing
Rhythmbox: music player and access to UbuntuOne DRM-free music store.
Eclipse: rare instances when I need to use an IDE (I don't do much Java).

Most of the stuff I do is with these.  I am surprised that it's such a short list, but programming is mostly in gvim, using python (pip, etc) or a little ruby, and some fun stuff in bash. Not as many apps as I thought.  An awful lot of what I do is "in the cloud" rather than local these days, and hopefully more if it will move that way.

Sell Me A Computer?

I do everything as a geek would do it, because I am a geek. This extends to buying a computer. I'm picking out my next home-wherever-I-am now, and I'm wanting to ask questions that nobody answers. Here's what I'm about:

1. Does it come with a non-shiny screen? I don't know how "glare" ever became a feature.
2. If I'm just reading and editing text files, will the battery last all through a 6-hour flight?
3. How much battery life can I get if I'm programming in python with autonose running? 
4. When I put Ubuntu on it, will it find drivers for everything? Video? Wifi? Camera? 
5. Which extended function keys won't work in Linux?
6. Will the oversensitive touchpad register a mouse activity when I come within 1/2 inch of it? Can I shut it off?
7. How badly will I get burned if I put the laptop on my knees while compiling a .NET project? 
8. Is there enough RAM for me to run my OS, a windows virtual box with VS.NET and resharper in it, a browser on the side?
9. Can I use it comfortably on a train or on an airplane, even if the inconsiderate jerk in front of me slams his seat back against my knees like usual?
10. How long is the fan going to last? Is it going to die after a measly 4 years like my previous two full-sized laptop computers? 
11. How much does it suck battery when suspended? How much does it eat on reboot if hibernated?
12. Can I hook it up to digital video? HDMI?
13. How water-resistant is it? If I spill one drop into the keyboard, is it gone forever, or is there some hope? 
14. How sturdy is the hinge? I've seen too many laptops gone forever when the hinge weakens.

I know that's not the normal set of questions, but that's why I'm so much fun to shop with.

I've had great luck with Thinkpads and my Asus EEE PC is just wonderful with Ubuntu. I don't have the battery life I want, but a guy makes compromises. We're pragmatists.

My only problems with the Asus EEE PC have been the oversensitive touchpad, lower battery life than desired (2 hours + with Ubuntu), smallish hard drive (160G), small RAM (1G originally), and being vga-only (later models solve this). For the money, I can heartily endorse these little netbooks. Actually, despite these problems, I've come to love the little beast. It's just underpowered for my needs now.

I'm thinking about a Thinkpad T410s, loaded with RAM, 500GB drive, and 9-cell battery. I'm betting it will come as close as anything to what I want.

I'm still considering a Mac, though. I don't like OS X as much as Ubuntu, but if it is solid and my windows VM runs okay, I bet I can comfort myself with a real *nix file system and a good bash shell. Last time I was frustrated by not having a great APT/YUM repositories (ports was not as good) and the whole issue of native app updates. Either each app checks for itself, or you have to go check for them and download new versions. On OS X, I had to do a lot more manual system management, and Windows was worse than that in addition to being slower and buggier.

On the other hand, OS/X had some great power management and ergonomics and the MBP had some really stellar hardware. It did work well, only crashing maybe twice in the year I had it (far better than windows, not as good as Ubuntu). The only thing I would consider superior about windows is its power management. My son's Asus EEE is identical to mine, but windows stretches the power use over a much greater period.

Well, unless someone talks me out of it, it will either be a MBP or a Thinkpad when I place my order. It will be either Ubuntu or OS/X and windows in a VM.

Fun times in Honeymoon Mode

I started the new job at Industrial Logic. In addition to receiving online training from my peers here, I'm getting into the source code of our products (some cool stuff in there). Yesterday I got to exercise my google and stackoverflow skills as we dug into a windows-based product. My .NET work until now has been web, not native, so this was new territory for me and I had a great time.

In addition, I'm getting involved in contract work here and strategy. It's only day 4, and I'm feeling like I'm really a part of the team. You would not believe how much we are in contact even as remotes. I probably talk to my coworkers ("boss" included) much more often than you cubicle-dwellers do. I still get think-time alone, but I'm getting to know and enjoy people pretty well.

Enough of this, there's code waiting...

Industrial Logic

Your agile otter has joined Industrial Logic. We have so much in common that it didn't make sense not to join forces. I will be neck deep in products, courseware, metrics, and all of the other work that makes them so cool. This will be like chocolate and peanut butter, friends. I can't wait to join all my new best friends!

Uncle Bob's Clean Code Video

The latest Clean Coders video by Uncle Bob Martin covers Chapter 2 of the book Clean Code. This is a chapter that is near to my heart, since it bears my name and Uncle Bob even presents some flattering introductory material with a decidedly unflattering picture of me (all in good fun). The video is $12.00, but is quite well done and interesting.

The less entertaining version which was the source for the well-edited version in Clean code is still available, and has examples in Python rather than Java. Bob's presentation has some thoughts not included in my paper (and which I endorse). The paper is not a replacement for watching Bob's zany and entertaining video but it can give you some of the same material while you ponder spending your hard-earned ten-spot-and-change.

Make the Retrospective Effective

With my last employer, we had noticed that our retrospectives were starting to lag in effectiveness and attendance. People felt like they were too busy delivering stories and solving problems to do anything substantial toward meeting retrospective goals. I knew that it wasn't the kind of company that would accept stalled improvement, yet developers were instinctively afraid to invest time.

To resolve the problem, I talked with the CIO. Our discussion ended up with this set of triage rules for retrospective follow-ups:

If it is free, just do it.

There is no reason to delay implementing some changes, including (but not limited to):

• posting a graph,
• composing a "top-ten" list,
• swapping pairs more often,
• trying pomodoro technique,
• changing how stand-up meetings are performed,
• making better use of QA, tech writing, or Customer resources
• instituting changes to coding standard

There is no reason to delay this kind of work. The CIO told us he considered it our job to keep improving the team through reflection and experiment, or else he would have asked us to stop months earlier. Other behaviors developers were skittish about (refactoring, speeding the tests, getting legacy code under test) were considered part of the job but programmers were afraid of "losing" productivity to those tasks. Our enlightened management re-affirmed a commitment to quality work.

If it takes a couple of man days, just do it.

The team was surprised that they could peel off a member or a pair to do technical work that would improve the team. This allowed the team to take on tasks like improving the build system, metrics gathering, checking out new mocking libraries, solving version control process problems, performing global clean-ups like duplication removal, writing instructions on the team wiki. We were, in fact, not permitted to not do these things. We happily devoted a few man days per iteration to accelerating the team.

If it will take longer, we should talk about it

There were architectural changes, large legacy code reworks, and grand experiments that came up in the retrospectives. Some people were afraid to even mention something that might take *weeks* of developer time to complete. People were surprised to hear that management was not against such things, but merely wanted to be measured and cautious with goals, measurement, and timing. We did some large things, and we failed some grand changes (as one might suspect) but we didn't fail for lack of permission.

This triage system worked, and for the next several months we had items in all three categories.

No retrospective technique I've found will be able to single-handedly keep retrospectives fresh and vibrant and productive in perpetuity, but this one was useful to shake off a fear of lost productivity long enough to get some good changes in place and to conduct some good experiments. We did a few large-scale changes, which really were also experiments. A lot of the work paid off.

If your retrospectives are going stale, you might talk with your C-level supporters and bring the team a policy that clearly spells out their permission to try, change, and grow. Developers want to be productive (a fact worthy of a blog series if not a new book), and may need to be encouraged to look past the stories and tasks to work that might accelerate the whole team.