When an engineering team moves to Agile, it’s a change that will impact every area of a company.
Human Resources (HR)—in particular—is an area that often goes overlooked.
If your team is considering a switch to Agile, have you thought about what that will mean for your HR department?
The HR Challenge
In a waterfall organization, you have job titles such as:
- Product manager
- Program manager
- Software engineer
- Software architect
- Software project leaders
All of that changes in Agile. Instead you’ll have titles such as:
- Agile coach
- Scrum master
- Product owner
- Agile coach
The team at Seapine Software used this visual on its blog, and I think it captures the difference nicely:
(Image credit: Seapine Software)
As soon as you start thinking about what this means for HR, all kinds of questions emerge:
- Can we move our current staff into the new positions? Who should we put in these new roles? Will they know what to do?
- What new training programs will we need? Who knows enough about these topics to teach them?
- What about career progression? Should we have “scrum master” and “senior scrum master” titles? What’s the difference between those roles?
- What are the job descriptions for the various titles? What are other companies using?
- Will we need to hire from the outside? Are there people in our local job market with these specific skills?
- What’s the average compensation for these titles? Will we lose people three months from now because we’re not paying them enough?
I could go on, but you get the idea.
Switching to Agile means HR will have to throw out most of what they have on file for your engineering team.
They’ll have to start over from scratch, with a concept that might be completely unfamiliar to them.
The 5 Steps We Took with HR During Our Agile Transition
The first time I was part of an Agile transition, our HR team had never heard of Agile before we decided to make the change.
The Agile Manifesto has nothing in it to help you with a challenge like this. Neither do the books that describe how different versions of Agile are supposed to operate in practice.
Those resources focus almost entirely on how Agile works within an engineering team—not how Agile impacts outside departments such as HR.
Here are the five steps we took with our HR department (and what you should do if you’re facing the same challenge):
1. Clearly define the new roles
This is the foundation of everything you’ll do with your HR team moving forward. It’s also the basis HR will use to help you find new employees for your team when needed.
2. Establish a career progression plan for each role
You’re going to spend a lot of time and money training your people to work in an Agile framework. As you plan, you should also be thinking about how you’ll retain those people for the long term.
We found that having different levels of a role (“senior” product owner, ect.) provided a good way to help people grown within their roles.
3. Find current employees who can fill the new roles
Moving from waterfall job descriptions to Agile job descriptions will be a challenge. The skill sets for waterfall positions are different than the skills needed in most Agile positions.
You can’t just take a project manager and expect her to immediately know how to be a scrum master, for example.
You’ll need to look at every new position along with each employee’s full skill set and aptitude for the skills you need in your new Agile roles.
You’ll almost certainly find you’re missing skills for some areas. That’s where your new training programs will need to fill in the gap.
4. Use training to fill in as many gaps as you can
You’re going to have skill gaps. Some of your people won’t have any experience with Agile. You’ll need to institute training to bring everyone up to the same level of proficiency.
We used an outside consulting team to help us design our training. But we also heavily customized it to match the specific process we were going to use.
Customizing your training is critical to your success. Agile in the real world doesn’t look like the ideal laboratory version of Agile you’ve read about in textbooks. If you send everyone to a generic version of Agile training, it won’t be nearly as good as having a training customized for your specific process.
Remember that HR needs to be trained on Agile too. Don’t leave them out when you’re thinking about who to send to the classes. They are critical to evaluations, hiring, and the new career progression.
5. Hire new employees when necessary
You might find a few roles you can’t fill with internal staff. That’s the time to go looking for help. If you’ve worked with HR to clearly define your company’s new roles, they should be equipped to help you.
In the end, you’ll probably end up with a structure that looks something like this, which Scott Ambler shared on his blog:
(Image credit: Scott W. Ambler)
Moving Employees from Waterfall Roles to Agile Roles: What Seems to Work
When you transition from waterfall to Agile, you’re going ask this question over and over again:
- Does this person have the skills for this new Agile job?
This is normal, and you shouldn’t shy away from thinking hard about who’s the best fit for the roles in your new Agile team. It is critical to have the “right” people in the “right” seats on the bus.
Every team (and every team member) is different, so I can’t tell you exactly who will be a good fit for your new Agile roles.
However, having done this a few times, here are some things to look for:
1. Program managers tend to make good scrum masters
Program managers are usually good at coordinating schedules and shepherding people through a project. We found people with these skills can often make very good scrum masters, especially if they have technical skills.
2. Software project leaders can transition to a variety of Agile roles
Software project leaders usually have a broad set of technical and social skills. They know how to talk to software engineers. They’re good at working with leadership and administration.
This broad skill set seems to help them transition to a variety of Agile roles. I’ve seen several software project leads who’ve become very effective product owners, and I’ve seen others who did just as well as scrum masters.
3. Software architects seem comfortable as product owners
Software architects are typically very good at elaborating requirements in ways that developers can understand and implement. That makes them very good candidates for product owner-type roles within Agile.
4. Product managers sometimes struggle to find a fit
Transitioning from waterfall to agile can be a challenge for current product managers. Many product managers are used to writing requirements and then handing them off to development.
In Agile, there needs to be a constant feedback loop between the end user and the development team, and some product managers struggle to adopt the “sprint” mentality that comes with Agile.
That’s not to say product managers can’t make the transition. It just means you (and your HR team) will need to help them get the training they need for whatever new position they’re going to fill.
If your engineering team is preparing to move to Agile, involve the HR team as soon as you can. You should also be prepared to answer a lot of questions as you help them learn about the Agile approach.
Send this article to your HR director today if it will help. And, reserve some time with your HR team as soon as you can get on their schedule.
In my experience, doing this early will save you lots of headaches down the road.
What About You?
Have you worked with an engineering team that changed to Agile? I’d love to hear how you worked with your HR team (and other outside departments) during the transition.
Leave a note in the comments and let us know.