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.

Over the course of the past year I’ve successfully added developers to a number of Scrum projects. The key things to remember are:

• A new Sprint is a terrific opportunity to officially onboard someone on a project. Preferably at the Sprint Review meeting.
• Have the developer commit to something small for there first Sprint and remind others in planning that they’ll be spending some time getting the new person up to speed.
• Nearly self-contained items like CRUD functionality for some admin item make really good stories/features to sign up for.
• Try to add only one person per Sprint.
• Remember to make your case to the PM/Product Owner that you are trying to get the project done sooner not explode the budget. Don’t deny there isn’t a bit of a learning curve for the new person, but explain that impact is lessened by the iterative approach you’re taking.
• Take into account whether adding a developer throws off the balance with QA or business analyst staff and have a plan to address it. Perhaps the new developer will take on some testing tasks at first or another developer will help with requirements.