In 2008, global banking giant HSBC wanted to launch a new financial product and needed to develop the software to support it from scratch. This was just around the time of US investment bank Lehman Brothers’ spectacular collapse, and money was suddenly under tight control. That led the project team to adopt the Agile software development methodology to build the system.

“The business said, ‘The one thing we cannot do is spend three months with a business analyst writing a spec, only for it to fall on its nose after three months,’” recalls project manager Stuart Mitchell. “They wanted to get something going as quickly as possible, so Agile was perfect.”

In the end, the £5 million project was a great success. It was delivered within budget in 18 months and has since won awards in the Agile community.

According to Mitchell, one of the principal reasons for the project’s success was the personnel. The team consisted of just nine people: five software developers, two software testers, a business analyst and Mitchell himself as the project manager.

In Agile projects, he says, it is vital that every team member is willing, able and motivated. “If you’ve got devolved responsibility and everyone is offering to help each other out, that’s when Agile is at its best. But if you bring someone in who doesn’t pull their weight, it can drag everyone else down.”

This explains the rather gruelling process that Mitchell used to recruit new software developers as the project went along. That process was designed to test candidates’ ability rigorously without wasting the various stakeholders’ time. The first stage of the process was to write the job specification – “A good job spec is just one page long,” says Mitchell – and to explain to the recruitment agencies precisely what is needed.

When the CVs came in, Mitchell and his colleagues spent half an hour filtering the candidates based on certain criteria: “education, experience, the requirements of the job, what tools they’ve used in the past”.

Weeding out the chaff

The next step is to conduct a 30-minute telephone interview with the shortlisted candidates. “This is perhaps the single most valuable lesson I can give,” he says. “Sometimes, you look at a CV and think ‘this guy looks fantastic’, but when you speak to him you realise he’s lied to try to get the job.

“We were very strong on those calls,” says Mitchell. “I’m not calling them to make friends, I’m calling to make sure that we understand each other and determine whether they are any good.”

Candidates who pass the telephone test were invited in for a two-hour interview. In fact, they are subjected to a “cascading” process during which they meet team members of growing seniority. This means that the people whose time is most valuable are not needed unless everyone else has approved the candidate.

The cascade begins with a programming exercise. “I want to see them roll their sleeves up and get stuck in, and I want to see how quickly they can solve problems, because when they join us that is exactly what they are going to be doing,” Mitchell explains.

During this exercise, team members would assume the role of the project sponsor to test the candidate’s ability to operate on a business level. If they make it through that stage, the candidate is then interviewed for half an hour by the business analyst and the project manager. Finally, they spend 15 minutes with the actual project sponsor.

“When you employ someone in your Agile team, make sure that at least one person from the business side is in the room at the last moment,” says Mitchell. “That way, if it goes wrong, it’s not just your fault – they were involved in the hiring process as well.”

The downside of his project’s success, Mitchell says, is that other HSBC managers regularly poach his team members. But so sensitive is the Agile methodology to the motivation of team members that this process is essential, he says. “The right team member makes the team stronger. The wrong one drains the team’s energy and brings down morale.”