Practicing Agile with HR Teams

A conversation with Enterprise Transformation Consultant Jeff Howey about Agile practices being used outside of IT organizations.

How did you start working in HR?

When I started working with the HR business organization, it was actually helpful that most of the technology teams were individually running with a basic form of Scrum or Kanban already. The leaders of the business area understood the value of visibility, predictability and adaptability that were improving through the practice of Agile in the technology teams. They knew they also wanted predictability, to focus on value, to make and meet promises out of the HR business unit. So they asked me to help their teams in Human Resources. Teams like recruiting, learning and development, compensation and various other groups within the actual HR services area practice some of those agile techniques.

What were some challenges working with the non-IT groups?

One of the key things that was interesting was that I had to change some of the language that I’m used to using as an agile coach. For instance, to use the word Scrum with someone whose job has been helping to coach and lead people in conflict resolution and explain its roots in the somewhat violent game of Rugby, created a bit of a angst within the group. So I had to make some simple changes. Instead of Kanban, I talked to them about a visual management system. Our goal as a team is to know all the work we are doing and manage it in a visual way so we can see it where it’s at, where it’s moving, where it might be getting stuck. That resonated. In a non-technical environment it’s the concepts that apply and the language that we use can sometimes get in the way.

Besides language were there other impediments that you found?

There were some obvious problems. Pretend you’re a caseworker on an employee relations team, that is dealing with an employee that just kicked their boss. Now the system we are trying to create is a visual management system where everything is on cards and everyone can see what you’re working on. The last thing you want to do is make a card that the whole organization can see that says that someone has kicked their boss and is going to get fired. There is a limit, sometimes even legally, to the amount of transparency that you can have.

There were also some teams that simply opted out because they had ideas around privacy and privileged information and things that are confidential or just messy which they felt couldn’t be managed this way. And a few individuals who were specialists that felt it was too much overhead to be managed this way.

How did you address these impediments?

Let’s start with the teams that adopted it easily. One of the concerns of the teams was specialization, “I’m the one that does this and you’re the one that does that.” When I asked why, the answer was more often than not, “because that’s the way it’s always been.” So I began to discuss why you might want to share responsibilities, things like succession planning, back-ups for vacations and illness and introduced the concept of pairing. The patterns that we see in technology we are able to apply to a non-technical organization. People in single-threaded roles, making more functional and cross-cutting teams with more experience, dealing with dependencies on those roles. The problems we are dealing with are “people problems” that are not that different from the problems we deal with in the technical world. There are different platforms, different ideas and different language that we are using but it’s honestly the same problem that we are trying to solve.