HR’s Agile Transformation: A Gradual Evolution

I’ve been applying agile methodologies to HR projects for nearly 5 years and I’d like to share my advice on how to navigate that journey.

My journey started with a big, hairy system implementation. I won’t bore you with the details, but let’s just say the start of the project was a little chaotic and we needed to instigate some structure to keep hold of the timelines and requirements between us, the implementors, and the supplier.

We, as Alex outlines in his article on agile HR, settled into sprints and communication rituals that ensured everyone in the project had clear deliverables stemming from prioritized requirements.

These took the form of regular stand-ups in which the team shared their progress and potential roadblocks.

Program and workstream leads could then follow up on any roadblocks to work through them or adjust timelines. 

The value of this is that the people handling the hands-on delivery of the project (system developers, testers, requirements gatherers) were clear on their tasks and didn’t have to worry about solving roadblocks—others were managing that.

Overall, this sprint methodology gave us some significant advantages:

• Clear requirements for deliverables broken down into what needs to be achieved in the next sprint
• All tasks had ownership and were clearly prioritized
• Test cases were created for each deliverable
• More focus—no need to worry about things outside of a short time horizon
• A backlog of things we knew we needed to do but weren’t tackling immediately
• Internal communication rituals to focus on any issues so they can be dealt with instantly
• External communication rituals (at the end of the sprint) to share with stakeholders what has been achieved (and what hasn’t—with reasons why)
• A change management process for deliverables—testing, training, policy updates, etc (this is part of the external communication rituals).

This structure made it easy to discuss and communicate progress on a challenging project.

If we were behind schedule somewhere it was easy to highlight what was behind and why with root cause analysis.

And that was phase 1 really—how to use a sprint-based methodology to implement a tech-related project whose stakeholders worked in HR.

But that’s not particularly interesting or exciting. The key bit is how we iterated this process over 50 sprints to cover all HR delivery and how you can do the same.

By the time we were rolling out parts 2, 3, and 4 of our system infrastructure, we realized that we had some challenges—and opportunities—in the methodology we were following. These included:

• Opportunity: Our system implementation didn’t sit alone, it was an enabler for HR and the wider business to achieve goals
• Challenge: We could prioritize our team’s time but we struggled when we needed to prioritize other people in HR’s time (for testing, requirements gathering, vendor meetings, etc) or users for assessing feedback on deliverables
• Challenge: It wasn’t always clear to everyone how we were delivering value to the organizational goals
• Challenge: HR’s unique challenges including big, calendar-led deliveries like performance reviews and salary cycles that can’t be moved. As a department, it’s also naturally reactive to any business pivot that might require organizational restructure, acquisition integration, and the day-to-day delivery of changing business plans as they pertain to people processes.

After careful analysis, we decided to adapt the methodology to the wider HR team to overcome some of the challenges we were facing and continue utilizing the benefits we were seeing from working in sprints.

We did this in gradual steps as we treated the process itself in an agile manner, but the new project delivery methodology had the following key elements:

• Structured project plans broken down into deliverables for each sprint with clear owners, from cross-functional teams, for each deliverable
• HR management team prioritizing the projects for each sprint
• A review process whereby teams can sign off the prioritized list and make sure there is enough time, capability, and resource to deliver what’s expected
• A prioritized backlog of smaller items
• Delivery time where priorities shouldn’t change
• Regular stand-ups throughout delivery to align progress and discuss challenges
• Review of what’s been delivered
• Communication with wider team and business at the end of each sprint
• Retrospective to see what can be improved in the process
• Documentation of everything.

This model delivered significant benefits but wasn’t without challenges. For example, the 4-week sprints came around very quickly, with overlapping work at the start and end and numerous administrative tasks required.

But, as with any process, as long as you keep listening and improving it gets better and better.

Overall, we were more nimble as a function and more focused on priorities. It also gave us a change management process and regular communication with the business about what was changing.

Some of the key advantages of approaching projects like this are:

• You’re much more aligned with the wider business needs as you’re regularly communicating throughout the delivery. This helps elevate HR as a function as it’s clear what you’re working on
• You deliver projects in smaller steps, each one moving you closer to the end goal
• Each step is a change that impacts users, giving you the opportunity to get feedback
• Helps break down silos by bringing teams together on deliveries
• Grouping lots of smaller changes under a single project helps make change more visible and meaningful
• If there are issues with delivery, such as unclear requirements or technical issues, you find out sprint by sprint rather than months down the road
• The prioritization elements allow you to mix together the operational fixed projects that exist in the HR calendar with the transformational and organizational change projects and assess how they can (or cannot) be delivered simultaneously
• You are much closer and aware of resource challenges—both numbers and capability—which allows you to assess and address them more quickly.

It’s probably worth mentioning that business-as-usual tasks like employee relations, interviewing, responding to employee queries, delivering training, etc were classed as BAU activity and different roles had different amounts of time to spend on project vs operational activity.

So let’s look at a couple of examples of how this works in practice; one large project that is fixed in the calendar and one project with a greater emphasis on iterative improvements.

Project One: Annual Salary Review (March)

This project included most people in HR, partners with finance, involves all managers and employees, and is something that had to go smoothly because it deals with extremely sensitive data that has to be delivered in a very structured way.

A hairy beast!

But, using our agile delivery model, the process was broken down and prioritized and then reviewed and improved.

First, we split the critical elements of the delivery of the project into 4-week sprints covering December to March. 

The project deliverables were assigned to a sprint, each deliverable having an owner.

The project was then given top priority for each of the sprints ensuring that everyone concerned could carve out enough time to deliver their part. If there were issues they were flagged quickly as it was a key priority.

Each sprint was reviewed and any challenges with delivery (resource, capability, system) were discussed and fixed.

The critical part of this was making sure everyone knew what was to be done in each sprint and, because it was prioritized ahead of other projects, everyone had plenty of warning to review their other projects and priorities to ensure they had enough time to deliver salary review.  

Adjusting your planning using this type of prioritization makes it much clearer what can’t be achieved and provides clear boundaries for the team about what to say no to.

Secondly, the whole project was reviewed (as you should with all projects) with a “washup”. 

Feedback was gathered from HR stakeholders, finance, managers, and employees (using direct feedback that was sought or given and from regular employee surveys).

All of the issues (unsatisfactory raise, the methodology used to split review amongst teams, the training, the process, the timings, the system interface, etc), were assessed, prioritized, broken down into individual elements, assigned to owners, and added to the backlog with a deadline of November (the month before the process restarts) by the project owner.  

Many of these elements were tiny, for example poor wording in training materials or a lack of understanding about how something works. Others were bigger requiring systems development, testing, and adjustment of future training materials.

Each piece of feedback was listened to, reviewed, and replied to (where possible) and those giving the feedback were involved in the testing.  

For example, if someone gave the feedback that the training material wasn’t clear about something, then they were sent the adjusted training material to check it was improved.  

It’s great to work in this way because you’re concentrating on improving the experience and recognizing that feedback is listened to and acted upon.

So, overall, how did this methodology improve things? 

The main challenge had always been one of salary reviews hitting at a busy time and a feeling of members of the team being overwhelmed by multiple requests to do things.  

The prioritization process made it clear to everyone what they must do and what they can push back on, which allowed management to focus on reprioritizing other projects.

This was a huge improvement.  

Secondly, the approach of listening to the feedback after the project, collating the improvements, and fixing them bit by bit gave us a better process over time.

Project Two: Onboarding

We undertook a significant project to try and improve onboarding for new employees across many countries. This included:

• Getting new employees to add their personal details directly into the HR system themselves vs filling out paper forms or digital forms which were then added to the HRIS by HR
• Employees choosing their benefit selections online before joining
• Digitizing all of the documentation that requires signing, moving that to digital signatures, and adding them to the HR system

Overall, there were 5 local onboarding experiences and around 6 that were local per 15 countries—so roughly 95 pieces of work or experiences that needed digitizing.  

A project like this is a classic example of “boiling the ocean”—where do you start? How long will it take? It can feel overwhelming!

But, by approaching this project using an agile methodology, we were able to break all of these items into manageable chunks.

We used the sprint methodology to make progress with a combination of global and local items. 

We were also able to link some of the work to other projects, for example a new pension provider in country X meant that digitizing the pension process for country X was completed simultaneously with the onboarding.

The prioritization process was critical in ensuring that the global elements were completed when the global team had time and the local items, which required work and testing from specific local teams, could be prioritized around their needs. 

Most of the items were relatively small and we got more efficient as we progressed.

As a management team, we were able to see, measure, and influence the progress of the wider project but each item and deliverable was fairly small.

This was a great way to approach this project as some of the items were harder to achieve than others. 

So, if we ran into an issue with one benefit in a country with a small number of employees, we were quickly able to bypass an item, put into place clear documentation and process on how to manage it, and move on to the next one. 

We weren’t aiming for perfection by X date, we were aiming for incremental improvements month over month.

So, overall, the conclusion to the onboarding project was that by tackling every piece individually—with a strategic aim of digitization and self-service—we were able to make progress on day one without a huge plan and rapidly deliver benefits to the organization in employee experience and cost savings.

Why Agile Is The Future

As work continues to increase in pace, complexity, and volatility, working in long, inflexible, multi-year waterfall methodologies has inherent weaknesses. 

Adopting an agile methodology and mindset gives you many benefits such as:

• Prioritization
• Clear deliverables for all team members
• Breaks down silos and brings teams together
• Breaks the bigger projects down into manageable pieces
• Greater visibility to the wider business on what you’re working on
• Measurable iterative improvements
• Clearer connection of HR to wider business needs and objectives
• Better demand and capability management

If you have any questions or comments then you can find me in the People Managing People Community, a supportive community of HR and business leaders sharing knowledge and expertise to help you grow in your career and make bigger impact in your organization.