“I cringe when I read it now.” (1st edition of Extreme Programming Explained)

“You can’t make XP work somewhere.”

— Kent Beck

Listening to an interview with Kent Beck on Team Agile I got a much better understanding of how his ideas of changed. XP has become more a set of good practices and things you might try implementing, not an all or nothing recipe. I felt back when there were lots of debates over XP was an all or nothing affair that much of the dogmatic arguments about having to do it all or it wasn’t XP were really meant to more as a defensive gesture.

After 7 years Kent has come around to the idea that you can’t completely remake an organization. He cites an example about a good developer who wants to keep a continuous build going, but no one cares about it and his boss keeps asking why he’s wasting time on the build box while other people are getting more code done. To this Kent has no real easy answer. The point is that XP or any other methodology has to be sub-optomized from it’s pure implementation given the constraints. (Kent is careful to note that just because the culture is set that you should still question basic assumptions like that pair programming couldn’t work.)

Good interview though, it feels nice to have someone like Kent assert that even changes like TDD can be difficult to implement in an organization.

Technorati Tags:

podcasts, test driven development, tdd

After procrastinating setting up weekly one-on-ones I’m finally kicking them off. Everyone from the Manager Tools podcast to the authors of Behind Closed Doors suggest that this is a very powerful management technique to really help take your team to the next level.

I’ve already done a strange reverse experiment in setting up weekly one-on-ones with my manager and they’ve gone surprisingly well. Getting direct feedback on items from your manager on a weekly basis is powerful stuff.

Technorati Tags:

management, software development

It’s been two months since my teams last code review.

After spending a lot of time thinking about the best way to introduce them, and then finally rolling them out on a project, the process quickly lost momentum. The plan was to have code reviews on all new projects at first on a weekly basis, with the tech lead on each project leading the way. Instead we did one review which went fairly well, and then never followed up on the mandatory changes and never held another code review meeting for new code. The ball was dropped, and I was the fumbler.

Some obvious things to rethink as I get ready to relaunch them:

• Make sure I have time to really dedicate to the process. The code review process isn’t going to happen on its own.
• Try to rethink buy-in. Given that no developers really ran with the process, I’m certain they still have doubts about it. Of course in that case dropping the ball is a really bad way to reinforce those doubts.
• Set my sites lower. Maybe code reviews only happen on one pilot project to begin with.
• Possibly take over scheduling and selecting all the code for the reviews and doing the follow-up meetings. This would reinforce the commitment, but risks again getting real buy-in. (Though I’m not sure code reviews are every very easy to get buy-in on unless there is some management backing. This is also why code reviews are obviously easy if you do pair programming, but we’re really not there yet at all.)
• Revisit tool support. Most of the team has migrated to RAD now so we could use the free Jupiter plug-in. Tim Shadel has a few podcasts and posts around it which make me think it might be worth considering.

One thing I did learn on the project we tried out code reviews on was that using Checkstyle was the single most successful way to ensure some good coding practices were followed. The developers really wanted to knock down the warnings to practically zero which helped clean up a lot of small issues like magic numbers instead of constants or long method bodies.

Technorati Tags:

software development, code reviews

I’m about to embark on another project next week, an intranet portal, where I have self volunteered to be the ScrumMaster. A few fears about this:

• This is a big project, typical high-profile deal. On top of that it wandered seriously off course, so in a way I’m being asked to get it back on course.
• I have at least 2 other projects underway so I’ll be paying less attention to them. I put a lot of trust in my staff so I’m not actually that worried about this effect.
• I have other priorities which are going to conflict to some extent from finally launching weekly one-on-one sessions to attending architecture meetings about our SOA plans.
• I’m the sheepdog for the team, but I’m also the functional manager for many of them, so when I make suggestions am really letting the team self-organize?
• Many on the team including the product owner have never truly experienced anything like Scrum.
• No one on the team has done much with Websphere Portal, and like any enterprise software it appears to have a lot of gotchas.
• I’m taking away some creative editing for our companies content authors and giving them more defined authoring templates. Today they have full control of static HTML pages they can author in FrontPage. It’s right think to do, but never much fun to deliver the news.
• By default being a functional manager, this is a sub-optimal situation because I’m not 100% focused on this project.

Given all these fears I’m still pretty confident everything will turn out OK on this one, for pretty much one simple reason. I really trust the team I have on this. They are talented, dedicated, tenacious at solving configuration problems, and they really want to deliver. In the end I always trust the people on a project as the best predictor of success. (People over Process)

Technorati Tags:

software development, scrum, websphere

We just can’t get any of our Scrum teams to agree to a small penalty for arriving late to daily standups. Three official projects now and all of them have turned down the idea of having a cup with $1 donations if you show up late, aka a container of charity.

I plan on trying to get it agreed to on my next unofficial Scrum project, but it may not be part of our culture. We definitely have the late meetings complex that plagues just about anyplace.

Technorati Tags:

management, software development, scrum