In Agile, It’s Not Just Whom You Hire, But When You Hire Them
In the traditional view of the world, there’s an uncomfortable truth that we try to shy away from. As much as we talk about the people we hire as real people, with real feelings, emotions, goals, and dreams, and try to treat them as the individuals that we all are, at a resourcing level we often think of them as, well, resources. You even see it writ large in the very name of the department that gets involved with managing these people: human resources.
On one level this is just a name, but on another, it’s a mindset that holds real problems for successful Agile hiring.
In other areas of life, we usually imagine a pretty linear relationship between resources and results. When you’re boiling a pan of water, if you turn the heat up, the pan will boil faster. More heat resource in, faster results out. Hit a nail harder, and it goes into the wood deeper. Work hard, we are told, and we will achieve our goals. Given how many of us are taught science at school, I suspect this sort of “more resource equals more outcome” thinking is ingrained in our minds. The problem is that when it comes to Agile recruitment, very often the opposite is true, for a number of reasons.
The first part of this involves a law thought up by Fred Brooks, which states, “Adding manpower to a late software project makes it later.”
Now, Brooks admits that this statement is an oversimplification of a complex set of phenomena. After all, if you’re working in an area that’s simple and allows people to follow standardized, repeatable processes, then adding more people is a pretty simple and effective thing to do. If each worker on a production line just has to do one task over and over again, then teaching them that task is a quick and simple thing to do, and you can then just slot them into the production line with little issue. In this instance, Brooks’s law probably doesn’t hold true.
However, Agile is all about working in complex, fast-paced, and uncertain environments, so anyone new joining the team has a lot of different things to learn, and these things may even be changing as fast as they can learn them. So if someone joins the team, it can take a much longer time for them to start becoming productive. Their addition may even slow the team down, as they have to take time out of being productive to get the new person up to speed. Which is why Brooks specifies that adding more people specifically to an already late software development project makes it later. Software development projects are generally complex, fast-paced, and uncertain, which is why Agile is used for delivering them in the first place.
There’s another problem with adding new people into an Agile team. Bruce Tuckman came up with the idea of four stages that a team can move through in relation to each other over time, commonly known as “forming, storming, norming, and performing.” You can read more about this model online, but, in essence, when a team first comes together, it will spend some time forming. This is generally a pretty happy stage, when everyone gets along, even if they’re all working reasonably independently of each other. After this, though, comes the storming stage, when people start to form opinions, good and bad, about each other and voice those opinions to others. This leads to a drop in team cohesion and productivity, and the team needs to get through it in order to get up to the better delivery stages of norming and performing.
The issue you get with this is that every time you add a new “resource” or person to the team, you risk tipping the team back into forming, meaning they have to go back up through storming again in order to get to norming or performing. I’m sure you’ve seen this yourself at work. The team’s going along fine, then suddenly some new person joins, and perhaps through being keen to make a good impression early on, they decide that some of the things the team does can be “improved.” So they start to criticize the way things are working, and productivity slows right down as the team has to revisit all its old arguments. I’ve seen teams get stuck in storming for ages due to situations like this. Like the previous problem, it’s often less pronounced in teams working in simple areas with codified, repeatable processes, as the new joiner can just be told the way things are done around here and get on board. But if you’re using Agile to work in complex, fast-paced, and uncertain environments, then the potential for debate and argument about the “right” way to do things is much greater, thus so is the potential for long, drawn-out periods of storming.
The third and final problem you get with adding new resources to an Agile team is around the issue of self-management.
In traditional teams, the team is managed by a manager, and this manager will do things like make resourcing decisions, deciding whom to hire and when to hire them. However, an Agile team self-manages. So if you take away the ability of the team to decide whom to hire and when to hire them, you’re reducing their self-management. The result is that everyone will suffer all the hard-to-see but hugely damaging problems you get from reducing a team’s autonomy — like reducing their intrinsic motivation, trust, collaboration, and discretionary effort.
So there we have three big problems that can be caused by adding new “resources,” or people, to an Agile team. You slow things down, you tip the team back into arguments and uncertainty, and you take away their self-management and all the benefits that come along with it. So how do we solve these problems?
Well, the answer is in the title of the blog post. It’s not just about whom you hire, but when you hire them.
Adding more people to a software development project doesn’t always make it later; it just makes it later if the project is already late. So if you’re adding a resource, then do it much earlier on in the project, not as you get closer to the finish line and realize that you’re going to miss your delivery date. Similarly, if adding new people risks tipping the team back to the start of the forming-norming-storming-performing cycle, then limit the number of times you add people into the team. Rather than adding one new person every two weeks, build up your pool of people you want to add into the team, then add them all in one go, after giving everyone plenty of notice. This gives the team a period of stability with no new joiners, in order to get themselves back through storming and up into performing. Finally, let the team itself take on these decisions about when to add new people. The team will have the best view of when it’s easiest and of most use to add in new people, so listen to them and let them guide the decisions in this area. If the team says now is not the right time, then now is not the right time.
No matter how much your upbringing may make you feel like adding new people to a team will get you out of the delivery deadline hole you find yourself in, it almost certainly won’t. However, collaborate with the team on some clever thinking around when to add people in, and you’ll be hiring in an Agile context as well as going a long way toward getting the results you want.
Gez Smith is Lead Agile Coach at HSBC and he runs www.agileforrecruiters.com, teaching recruiters and HR people all about great Agile hiring practices.