I’ve watched a video of Dave Astels on BDD at Google in the past, but Kane Mar recently pointed out a Google talk by Ken Schwaber on Scrum. Doing a search for Google engEDU reveals about 150+ talks. When I get some downtime I’m going to look through a few of them.

I recently posted about how Scrum + some XP practices isn’t necessarily the most common Agile methodology type. This survey from Version One seems contradict my idea. Still hard to tell claim any hard proof from self selecting surveys.

Checking in to source control should be done early and often. I’ve taken this as a given since my first early days working in CVS. (I still working in CVS these days as it’s a good enough tool.)

In a current project I got really busy with vendor meetings and other items during which time:

• Over the course of a week I saw only an occasional check-in maybe once per day.
• The check-ins were all by the same developer.
• There were a total of zero check ins by the other three developers.

My preference is to check in at least every hour or so when working. The only rule is it has to still compile and the tests have to run. If I have to I’ll even comment out a broken test so I can do a successful checkin.

An opportunity for group feedback next week.

I work in a decent sized application development division of a medium size company. Today I realized the bulk of our line managers haven’t yet pulled away from technical work to focus fully on management. Signs include:

• Attending almost all project meetings to weigh in on the technical architecture of the project.
• Personally conducting the bulk of all code/design reviews.
• Coding on projects on a regular basis.
• Utilizing the same team members for every project since it’s faster then ramping up others.

I know it’s a well worn cliche that many senior technical folks promoted to management fail to grasp that their role has changed, but I assumed that for many that was a temporary situation. After a year or two you learn to pull back on the coding role.

I think staying somewhat technical is important, but it has to be secondary to managing and developing your team, period. And assigning yourself technical work just creates a bottleneck.

I’m not completely beyond some tendencies myself:

• Having to fill in as a full time Scrum Master on an intranet project for 7 months is wrong and I’d rather have someone else take on the role. On the other hand it’s a very messy political and technical project so I’ve resigned myself to the role. I’ve probably missed a chance to mentor someone into the role.
• I’m still the resident expert on continuous integration which means if something crops up with cruisecontrol I end up troubleshooting it.
• I’m tempted to stay really involved in another project where I attended almost every meeting for the first Sprint to keep it from stumbling off track. For the subsequent Sprints I need to tone down my involvement. Better to let the team self-manage here and learn on their own.

Recently Brian Marick posted on Scrum + XP practices being the default Agile methodology:

The gorilla of Agile is Scrum + a selection of XP practices

This gels with my experience as well. Most of the Agile practitioners I know are using Scrum with at least some XP practices, and a few are using straight XP. Beyond that I don’t have a lot of exposure to other Agile methodologies.

I do realize that my experience may be badly skewed. I assume the appeal of Scrum is that it’s a pretty lightweight project management methodology which almost assumes you’ll be doing some XP practices. XP is harder to fully adapt since it prescribes things like pair programming that are typically a harder sell.

I have seen some counter evidence from Scott Ambler’s Agile survey:

• Agile MSF 191
• Agile Unified Process (AUP) 216
• Crystal Clear 91
• Dynamic System Development Method (DSDM) 26
• Extreme Programming (XP) 954
• Feature Driven Development (FDD) 502
• Scrum 460
• Other 171

Scrum doesn’t do too badly, but it’s only 18% of the total. XP makes up 37% and FDD is 19%. Maybe Scrum isn’t the default just yet. And things have a long ways to evolve still so we’ll see is Scrum + some XP practices really becomes the most common Agile process over the next few years.