ScrumMaster Removing Impediments

Scrum and XP and indeed many of the Agile methodolgies value the idea of from XP of courage. In Scrum this is the ScrumMaster bubbling organizational problems to the surface and trying any reasonable tactic that won’t get her fired to resolve the issue for the team. In the Agile Manifesto it’s People over Process.

Today I successfully applied this idea by reexamining a problem I thought was beyond my control. The issue revolved around sending one of my developers, Ian, to an internal use case training course that we’re offering. The history of this effort:

  • Ian asked for some use case training 1.5 years ago due to a professional interest around requirements gathering. I asked Ian to research possible classes.
  • A class was arranged, but cancelled due to low enrollment.
  • We brought in a coach/mentor to do some Agile training including a two day Use Case class about 7 months ago.
  • A use case class was arranged in September, and I was assigned to attend despite being pretty proficent with use cases.
  • I argued that I would go so that I understood how we were implementing use cases, but I really wanted Ian to get a slot. Ian didn’t get to attend the class, but there was supposed to be a second class.
  • There was a second class in November, so I asked if Ian could attend this time. It was explained to me that there might be some open slots, but no promises. Ian again couldn’t go because there weren’t any open slots.
  • I had Ian research Use Case courses available even if it involved travel. He found one in San Francisco by the coach/mentor that we had hired and their company and another one by a different company in Boston.
  • He talked to our coach/mentor about attending the training, but she explained that the class was being cancelled due to low attendance.
  • In the meantime Ian researched and found training in January for ScrumMaster training in San Diego.
  • Then in late December two of my developers were assigned to an official Agile project and signed up for Use Case training with the coach/mentor.
  • I again made the case that Ian should be added, and I got the feeling that there were open slots this time, so on the fly Ian had to switch the ScrumMaster training because it was on the same dates as the Use Case training internally.
  • Following up on the Use Case training slot for Ian I was told that spots were being reserved for other organizational groups. I explained the whole history of trying to arrange this one class for Ian, and got the promise that if there were empty slots that Ian could have one, but no promises.
  • I calculated that if we had to send Ian to Boston for the same training that it would cost the company about $2000-$3000 versus almost free since the coach/mentor doing the training is being paid on a billable hours basis. As a business decision this seemed obvious.
  • I didn’t get any answers about whether Ian could go or not this morning so I sent him over to the class.
  • Tomorrow Ian will successfully complete the Use Case training class finally.

I may have to deal with fallout from this action, but as a manager trying to remove impediments I’m willing to take a little bit of heat. And it’s good to reexamine your assumptions every so often. If I had just waited to be told there were no slots again Ian would still be waiting and we may have had to spend $3000 and send an employee across the country just to get training we’re offering internally through a very capable trainer.

Technorati Tags:

, ,

Management Coding Breaks

Despite the enjoyment I get from doing development or even working through a configuration or installation issue I often find that I have weeks like the last one. Last week I was unable to code at all either at work or at home. Work was just a series of firefighting exercises largely to get to new projects deployed and at home I spent my few free hours coding and catching up on some old household todo items.

I’ve accepted that my job as a manager is largely to develop my people. Still, I realize that most technical folks will quickly lose respect for you if your technical skills wither substantially. My compromise has always been to devote myself at home to doing a lot of learning and coding. This week was just one of those where I didn’t get time to fire up an IDE and work through some more unit tests while learning Ruby.

Balancing technical skills versus management skills is something I expect I will probably always struggle with and is just part of the territory. I’m just glad I really enjoy both or the balance would get out of whack in a hurry.

Technorati Tags:

,

PHP to Ruby/Python Migration

I’m making my way through the Snakes and Rubies presentations of Django and Rails. One thing that surprised me a bit was that both Adrian Holovaty and David Heinemeier Hansson both came out of a PHP web development background. Within these presentations both explain that PHP was so messy that they developed their frameworks in Python and Ruby so they could write beautiful code.

Given that there’s been a lot of attention around high profile java developers jumping over to Ruby on Rails, I was a bit surprised to see a migration from PHP as well. I’ve actually been in web development long enough to remember that PHP stood for Personal Home Page. I migrated to Java from Perl and really enjoyed Java’s static typing and the wealth of libraries that have developed. Long ago though, I did a lot of Perl CGIs. So I guess it shouldn’t really surprise me that when PHP developers go looking for new pastures that they Ruby on Rails is an obvious path these days.

One nice side effect is that some of this is leading to PHP developers being exposed to better engineering practices like unit testing. In a recent Ruby on Rails Podcast, Scott Raymond, a longtime PHP developer, explains how he had heard about XP and unit tests, but Rails made it so easy that he started actually writing them and improved the quality of his code.

Management Podcasts

I listen to three regular weekly management podcasts:

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.

From Office to Cubicle

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.