ScrumMaster isn’t exactly the sort of job description someone goes looking for. As I remember Ken Schwaber explained that the term was specifically chosen to be uncomfortable because the process of adopting Scrum sucks.
The term reminds me of DungeonMaster from the old D&D days or more recently Webmaster. I actually think my job title was Webmaster at at least one company. At another one I remember working with another developer who referred to himself as the Webmaster and occasionally to me as the WebSlave. Not that that irked me at all.
Anyway we now have a Scrum Queen for one of our projects. The converted PM has rugby jersey embroidered with Scrum Queen on the back courtesy of a developer. I have to say that team is starting to gel. It’s their first Sprint and they’re already jumping in and having fun, which is one of the sure signs things are working.
Say you have a developer, Brad, on a project. Brad is a pretty senior developer and is fairly sarcastic. On a typical waterfall project with defined phases, no collocation and a long testing phase a lot of frustration develops. Typical miscommunication happens and too much is contained in documentation from emails, to defect tracker comments. Distance increases the need for documentation.
On this sort of project Brad’s sarcasm is often misinterpreted as confrontation and further separates factions on the team. The project is actually pretty successful, but at the end Brad is burned out and frustrated.
Contrast this with a Scrum style project with daily standups. Same Brad, same sarcasm, but everyone just giggles when Brad explains his impediment that the sunlight reaching his cube is distracting him and that he really would prefer fluorescent lighting. The sarcasm is understood and even appreciated as a humorous release. The team tends to gel because they’re collocated and meeting regularly. Everyone is visibly on the same team and the conflicts that often develop over distances are handled by the Scrum process.
Not a side effect I would have expected, but one I’m beginning to really appreciate.
“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.
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.
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.