I listen to three regular weekly management podcasts:

• Manager Tools
• The Cranky Middle Manager
• The Middle Management Lobotomy

Manager Tools is just great. It is easily the best management podcast I’ve come across so far. The two hosts, Mark and Mike, are good friends who have been managing for many years. Mark is a management consultant and Mike spent a lot of time managing at IT companies. The key to the show is pragmatism. Every podcast is centered around practically implementing one-on-ones, performance reviews, or expanding your network. And it’s not high level strategy, it’s tactical details like remembering to reserve a good conference room a month ahead of giving performance reviews to relying on paper when taking notes for one-on-ones because even writing on a Tablet PC can give the impression that your not fully focused–how does the employee not assume you’re checking your email? Enough said, this one rocks.

The Cranky Middle Manager show is another high quality management show. The format is traditional interview, and the host Wyane Turmel is sort of a standup comedian. Since it is an interview format a lot depends on the guests. I’ve really enjoyed some of them including one with David Allen of GTD fame. Since many of the interviewees are the sort of people who write the management books you find in the business section of your local bookstore there is the danger that the guest talks in pretty high level generalities without much substance. Wayne does try to at least ask all of them at some point, well how would I implement some of this or use it in my world? Unfortunately some of them have trouble answering those questions. Still there’s a lot more hits than misses on the interviews and heck it’s only half an hour anyway.

The Middle Management Lobotomy is put out by Kevin Williams who is feeling his way through his first management job. I’ve listened to about 4 or 5 episodes now and it has some aspects that keep me returning. One of the nice things is he’s pretty honest about how things are going. He’s even discussed hiring two people onto his team and dealing with one of the hires who ended up not being that great of a fit.

One of the developers from another team leaned over my cube wall this morning and very bluntly asked:

So, why are you in a cubicle?

Given that it was 7:30 in the morning and no one else was around this was a bit jarring. I retorted that I moved out to the cubicle to make it easier to work with my team pairing up and helping with writing unit tests. That answer probably puzzled the developer a bit, and in truth there are quite a few reasons:

• I always felt just a bit uncomfortable in an office. I remember being shocked having an office at first since I’ve managed from cubes or even tables on all my former jobs. It just still feels just the smallest bit elitist to be sitting in an office.
• I do really want to be available to help with test infecting my staff.
• When you’re out in the cube farm you overhear and see a lot that you miss from behind a wall.
• My office has become more of a true project room, primarily used for standup meetings.
• People can visually see if you’re available and get answers faster. I overheard a conversation the other day that an employee wished there was a green and red light over her manager’s office so she could tell when they were available without slogging over and peeking in the door.

Of course the downside of all of this is you’re probably interrupted more, but at the end of the day those interruptions are primarily from your own staff. And a manager’s primary job is to grow and serve their employees. At some point my goal is to get everyone on my team proactive and self sufficient enough that I pretty much eliminate the need for my position.

Since I moved out to the cubes about two months ago managers, PMs, admins, and others still express surprise that I wanted to move out onto the floor. I think for a whole lot of people an office with a door is still a very desired perk. Some of this may also be that I grew up with four other rowdy brothers so being in a busy, noisy environment and still being able to concentrate is something I take for granted.

One one of my projects where we’ve now got a reasonable amount of unit test coverage I did notice a peculiar trend. I’ve been emphasizing with the development team that we want to move to TDD from running a day long class with all of them to posting daily charts of the number of unit tests and the percentage of unit test coverage everyday outside my cubicle wall. I think I’ve been pretty clear on my expectations.

So on this project the developers wrote basically almost zero tests for the first 1.5 Sprints. Then after the felt they’d nailed most of the functionality they started to get around to refactoring, fixing Checkstyle warnings, and writing tests. As it turned out there were initially a lot of Checkstyle warnings about methods that were too large, or lines that were over 120 characters, or imports that weren’t needed, at least several hundred. There were also virtually zero tests.

They did start writing a few unit tests, but they quickly got more interested in fixing Checkstyle warnings. Given an option between fixing a Checkstyle problem and writing a unit test they would choose doing a Checkstyle fix. My intuition tells me that this stems from:

• A lot of the Checkstyle warnings were low hanging fruit and just faster and easier to fix like lines that were over 120 characters or longer methods that needed simple extract method type refactorings.
• They could see faster progress fixing the Checkstyle warnings since it went from say 800 warnings down to less than 100 in the space of a few days.
• Not being that familiar with unit testing and realizing they had to write a large number of tests for all of their code the task seemed simply more daunting. The benefits also seemed less obvious since they weren’t using TDD to drive their design.
• They still aren’t completely sold on the benefits of writing unit tests, though they did realize they were catching some things they missed initially like a lot of situations that could result in null pointer exceptions.

According to Ken Schwaber his recommendation is to wait about 6 months after introducing Scrum before you start to introduce many of the XP practices, because the team is going to have a hard enough time getting adjusted to Scrum. I remember nodding along in agreement when Ken mentioned this.

I’ve watched my company begin to understand that they can cancel software projects. From what I can tell this is relatively new to the culture. Though no one truly likes to be on a cancelled project, it’s a whole lot better than delivering a project 3 years later that doesn’t even have a single customer.

So in the last month I’ve seen at least two projects cancelled:

• One because a third party software system coming online duplicated the custom application functionality. This one got canceled after the first Sprint had kicked off, but better than nothing.
• Another because the business drivers behind the project have evaporated. This was a successful project with multiple phases delivered, but they’ve now decided that the lowest priority phase is not worth doing and that the product is complete.

Both of these are signs that we’re starting to get Agile a bit and that we’re understanding the power of failing fast instead of marching along to an inevitable disaster.

Attended my first Java Users Group (JUG) meeting in Sacramento tonight. My Dad’s attended a computer club meeting in Las Vegas for the last 20 years or so, but I’d never actually gotten around to going to one of these. But given that I feel the need to meet other geeks I decided to check it out plus there was a bit of free food.

The meeting didn’t have an agenda beyond open discussion, so that was a bit worrisome. It appears they’ve had a lot of presentations in the past, but they’ve had a recent drought the last two months. I got a good idea of the cross section of developers and shared a few insights. The majority of the 20 or so people in attendance varied from people new to java to fairly experienced J2EE web developers from what I could tell.

The meeting was actually run by a consultant who spoke off the cuff about a lot of topics and included interestingly enough a java job market update from a local recruiter. Obviously there’s some self interest there, but his basic message of the night was that he had a lot of call recently for EJB experience. His thought was that no one wants to do EJB anymore so the demand for places that still use it is going up. He also explained the realities of experience and resumes for people new to Java. Basically ever since the dotcom days it’s hard to break in until after you have at least a few years of experience.

I brought my 12″ iBook with me and at one point explained to the group that I hadn’t had any issues running Java, Eclipse, IntelliJ IDEA, or JBoss on my Mac running 1.5. Many of them hadn’t seen a lot of Macs even though when I go to conferences these days all the leading edge developers have Powerbooks now. (I actually expect to see a lot of the new Powerbooks announced today with the duo Intel chips in the hands of developers soon.)

Anyway I might just volunteer to run a TDD presentation or a Fitnesse or Cruisecontrol talk since I feel like I should give back a bit to the community. And there’s the concept that eventually my company will have an open position or two and I’d like to have an easier time finding a good candidate. Plus, if I can test infect a few developers so much the better.