“We need 6 developers to start in 2 weeks!”
“We have to have 2+ years’ experience of everything in the full stack”
“We’ve not got that much development work for the next couple of sprints, so another project can pay for 50% of our developers’ time and get some work done, and we save money”
Any of these sound familiar? If so, you might be trying to have your cake and eat it. “Agile” ways of working move the centre of power into the delivery team, which can be hard to deal with, especially if you’re in a more “traditional position of power”, like a Project Manager or the Head of Department.
One of the lesser understood principle in the agile manifesto is the subject of websites such as http://12thprinciple.org/
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
What does that mean in practice when your teams begin to detect a skills shortage? If you’re in a leadership position, you might be tempted to try and fix this – after all, that’s what you’re supposed to do right? Deal with those pesky blockers. You might need to know what the scale of the problem is, and seeing as you recruit in whole numbers, you might need to translate the size of the problem into a “number of developers”. What sort of skillset should they have? Your team’s trying to do some complex stuff, so you’ll need someone who could do all of it right? Your management structure or your client is complaining that work isn’t going fast enough to meet a key date so you’ve got to increase your capacity somehow?
It’s worth taking a step back to think about just what the team is responsible for. It’s pretty obvious that they’re responsible for doing the actual work. What can sometimes be overlooked, is that they’re also responsible for how they do the work. And that includes who does the work – part of the team’s responsibility is to make sure it has all of the skills needed within the team. If they’re detecting a skills shortage, they’re best placed to try and find the right fit.
As a leader, you’ve got to worry about your organisational recruitment – pay and conditions, legal requirements, that sort of thing. But don’t let the mechanics of recruitment be your only process – make sure you’re recruiting the right person for the team. You’re not looking for a generic skillset, you’re looking for someone to fill the very team specific hole they’ve got. And they know exactly what that hole looks like. I’ve had the most success when I’ve let the teams recruit their team members, and the leaders sort out the paperwork.
And as for the third example at the beginning – my only real advice is to avoid doing that. Teams are entities in their own right and it’s well worth thinking about them as atomic units. Chopping and changing internal team structures is generally only really good for disrupting the work. If your team’s got a little slack time, use it productively – pay off some technical debt (there’s always some). If you’re in the ideal situation, then why not just reward the team with some R&R? They’ve probably earnt it.