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.

I posted about a year ago on my doubts about offering employee referrals. I’ve seen them badly abused before where a single employee made 20k+ on referrals many of which turned out to be less than great hires. Apparently Joel who spends a lot of time thinking about how to hire the smartest programmers has a similar opinion:

But the real problem with employee referrals is what happens when recruiting managers with a rudimentary understanding of economics decide to offer cash bonuses for these referrals. This is quite common. The rationale goes like this: it can cost $30,000 to $50,000 to hire someone good through a headhunter or outside recruiter. If we can pay our employees, say, a $5000 bonus for every hire they bring in, or maybe an expensive sports car for every 10 referrals, or whatever, think how much money that will save? And $5000 sounds like a fortune to a salaried employee, because it is. So this sounds like a win-win all-around kind of situation.

The trouble is that suddenly you can see the little gears turning, and employees start dragging in everyone they can think of for interviews, and they have a real strong incentive to get these people hired, so they coach them for the interview, and Quiet Conversations are held in conference rooms with the interviewers, and suddenly your entire workforce is trying to get you to hire someone’s useless college roommate.

And I will admit I have gotten two referral rewards at past companies. In both cases I referred in really good hard working programmers who helped make the companies successful. In one case I split the referral bonus with one employee and in the other I just had HR turn over the whole referral bonus to the employee. The point is you want to work with smart people who are going to help the company, not refer in any old acquaintance who might make a decent employee.

I’m digging into Software Security: Building Security in by Gary McGraw and I came across a strong opinion on C and C++:

If you are concerned about buffer overflow problems and other basic software security bugs, don’t use C. If you must use C, use a source code security scanner. By the way C++ is even worse than C from a security perspective. C++ is C with an object model crammed halfway down its throat.

Ouch.

During a short conversation with our new Chief Security Officer he explained:

If we can certify that we have a secure software development life-cycle we stand to increase our overall revenue with clients from 10-20%.

Wow, actually utilizing our methodology as a competitive advantage. Typically if I mention methodology to anyone on the business side and many on the IT side they sort of shake their head no, never heard of XP or RUP. Indirectly it has a big impact on our ability to deliver and maintain applications, but it’s far from a direct revenue generator.

Over the next year we’ll be looking at adopting some practices, getting some training, and further integrating our QA and development teams. Many of the Agile practices we’re adopting parallel with established practices for improving application security. Thus unit, integration, and acceptance tests and their automation mean you can actually certify that you’re software is reasonably secure at least for what you’re testing for. Automated builds and code reviews mean no issues lay undiscovered for long. This also means QA will probably have to get involved at the coding and scripting level rather than their current pure UI testing and automated scripting against that UI.

Scrum and its 30 day Sprints allow us to inspect and adapt quickly instead of approaching security as an after thought that we find out when a security firm busts and application with a penetration test. And adding things like abuse use cases to our requirements make it clear how we can verify we’re ‘done-done’ with some particular feature.

If you take a non-paranoid approach to implementing better security you can actually stand up at a company meeting and explain how your software process improvement project delivered 100 million for the company. Not bad.