Can HR be agile?
We find ourselves in a world that is looking to be more agile by the minute; all the companies are seeking for a way to make this part of their DNA. As HR, we know we are transformation agents, and this means we need to be what we want our own company culture to be.
When we talked about agile, what will probably come to mind will be Scrum, Kanban, Lean, and so on. Most of them find their birth in software development, but these practices have been gaining territory and we can’t get behind.
So, where to start? We know we have to adapt these practices to our work, but sometimes it gets hard to understand the way to do it.
First, we should get this idea on mind: we cannot do a copy / paste, we have to think about it as a framework that we have to use in our advantage. Which means, take the ideals of an agile mindset an apply it in a way that you can use it in HR.
So lets begin with the Scrum values: Courage, Focus, Commitment, Respect and Openness.
When talking about a scrum team, we say that the members have courage to do the right thing and work on tough problems, which I believe is very relatable for us. We have to take the bull by the horns, with no fear and work to get the right solution for complicated issues.
While we do the tasks, focus on the work of the sprint and the goals of the scrum team. This one might be a little be more tricky, because in HR we are always receiving new issues and problems to solve, but keeping the focus on the most important and what will have the biggest impact, is going to help us organized our efforts.
The commitment to achieving the goals of the Scrum Team is not only a team commitment but also a personal one. In HR we look for the commitment of our people, but we also need to be committed to the goals we are looking to achieve.
The fourth one, I will call it an easy one, giving the fact that every team needs to have respect between its members; we need to believe that we are all independent and capable professionals.
Finally, I am convinced that openness is vital for us to apply as HRs, the scrum team and its stakeholders agree to be open about all the work and challenges with performing the work. We want the line to be honest with us, about what they expect, about the challenges they face, about their goals, about the roadmap they have planned.
Therefore, now that we have talked about the values, and we can agree that we share them. We need to set this on mind: The product increase is the one where you can see the value generated by work. If our clients can’t see the value, we are doing something wrong. However, what happens to us is that we have the complex problem, we take, we analyze it, we work on a possible solution, and after we have everything perfectly set, we apply it. Only to realize we have done it too late or that it doesn’t have the impact we were trying to achieve. And there is where the agile mind starts to make sense. Instead of delivering a full finished project, we have to deliver Product Increments. In scrum, the Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of each Sprint, the new Increment must be “Done,” meaning that it has to be in useable condition and meet the Scrum Team’s definition of “Done” which is defined by the team at the start and will evolve during the project.
If we deliver increments of the product, instead a finished one, it give us the time and opportunity to adapt it with the feedback we receive from the line managers. We work together toward our final objective. But it also gives us the possibility to show early results to the work we are doing. In agile it’s very common to show the example of a client that ask as for something that allows them to move from one place to another, with a lot of condiments. So first, we will probably deliver a bicycle, in a second sprint, maybe it will be a motorcycle, and in the third sprint, it will be a car, until we have it finished, and it becomes a full truck. Will the bicycle resolver all our clients problems? No, but it will be a first taste and a possibility to see possible changes from the first delivery.
So, let’s talk about Product Backlog, another important concept from scrum, which is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific result. The product backlog is consider the single authoritative source for things that a team works on. In more simple words, is all that we want to achieve in a final product, the more prioritized the features are, the more refined they have to be. It’s important to know all the things we want to accomplish in our product, and to prioritize them, so we can keep delivering increments.
Sprint by sprint we will choose some of the features in our Product Backlog, in our case improvements or new practices for our HR programs, that will become the Sprint Backlog. All of this will be separated from normal and usual tasks that we might face daily, because it’s not operational work, it’s transforming work.
In order to organize the tasks in the Sprint Backlog better, is very common to use a Kanban Board. I find it very useful for HR, it is an agile project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency. It was originated in japan, and it means “visual signal”. So if we want to be able to see the flow of our work, it’s a good technique that we can apply in our teams to make visual the things we want to do, the things that we are working on and the things we have finished.
In HR we tend to have different programs and responsibilities that become ongoing projects, each of them will have their own prioritized Backlog, and we can use a Kanban board for each project to follow the advances and pending. But what happens with the operational tasks that we are not discussing here? A possibility could be to create a “support team” that works giving answer to daily issues for the employees, and they even implement their own Kanban that helps them track their work.
Agile allows us to work together with our clients and to adapt faster, this way we save not only time but money also. We need to remember the four values of the agile manifesto:
· Individuals and interactions over processes and tools: people needs to work together to get better ideas and results.
· Working software over comprehensive documentation: it’s important to have something that you can see working instead of putting work time on something that you haven’t applied at all.
· Customer collaboration over contract negotiation: feedback is key to get better results, so working with our internal clients we can get better results, more useful, faster and cheaper.
· Responding to change over following a plan: we need to plan to organize, but we need to adapt so our plan doesn’t become a rock in our shoes, flexibility to change is also key to get closer to our goals.
Hence, to answer our question: Can HR be agile? Yes, it most definitely can! Agile, as sketched in the Agile Manifesto, is considered a philosophy. We can use some of the tools and concepts from the different methodologies, to our advantage but most important we need to live and breathe by its values.
