Agile HR

Part 3— What changed

In Part 1 of this blog, we covered the problems behind needing to make a transformation in our team. In Part 2, we shared our discovery of Agile. In this article we share with you how we deconstructed and rebuilt our team, our ways or working, and our products in different ways.

As we mentioned in Part 1, we don’t believe you can just “do Agile”. We wanted to make a fundamental change. So we looked at all the rules that were currently governing what we did. We found many rules in our world:

Cohorts | Programmes | Schedules | Instructors | Linear | Competencies

We thought: “What if we broke some of these…?”. But that would be quite aimless. Instead of just not doing something, what is it we were in service of? So the third piece in the jigsaw was to decide what our design principles were going to be. We took inspiration from some of the related worlds around us, like technology and marketing, and we decided that our products needed to be:

1. Flexible — Give people more choice in what, when and how they access performance support and experiences at work (note: we quickly learned the downside of too much choice, so this became about carefully selective options).
2. Accessible — Move away from the traditional Learning Management System (LMS), and towards consumer-grade digital platforms. Give people access to simple support, when and where needed
3. Personal — Understand our end-users motivations, needs and requirements. Identify meaningful segments of users, rather than all of them as one. Target our messages and resources to feel more relevant to them.
4. Inclusive — Create a wide open door for as many people as possible. Move away from anything that felt like it is excluding the majority. No HiPo (High Potential) programmes!
5. @ Point of Need — Focus our efforts on the pain or pinch points our users experienced (because they told us what these were when we spoke with them directly). Prioritise products to help people through transitions like becoming a manager for the first time. Focus on periods when people are most receptive to change and learning.

Lastly, anything we designed needed to pass a final test of being low cost, scalable, easily repeatable and admin-lite!

So, we started with 4 problems — Pace, Opinions, Waste and Silos. We deliberately broke the rules. We decided on our new design principles. Agile then became the critical enabler for creating solutions that were adding the most value to our end users. The key change here is about switching the focus from being HR-centred to Human-Centred.

An example

Let’s now dive into a real-life example of how we have iterated manager development. The starting point is that we needing to solve the real problems our managers were experiencing — not HR’s problems with managers. There’s a big difference.

We started very small. We became very comfortable with MVPs (Minimal Valuable Products) — the “just enough” solutions we could test with real people.

Almost immediately, along came a real (and stressful) problem. Our organisation needed to shed a large number of roles quickly. Really quickly. It was further identified there were two parts of the business that held the greatest concern about redundancies becoming ER issues. So we targeted them. Not all managers — just the high risk ones. The discipline to keep the work clear and focused, is a key part to being successful with Agile in non-tech teams.

We identified the MVP would be a small collection — no more than five — digital resources, and no more than two 90 minute small group workshops. The resources and the workshops were researched, designed and made live in just over 2 weeks — the equivalent of one Agile “sprint”. Close to 50 managers were given access to the resources on a new consumer-grade app. No LMS. They all attended two separate workshops, two weeks apart. It was pretty rough and ready, and nothing ground-breaking — but we were fast and responsive, and the resounding feedback was that the managers found them very useful. And, importantly, not one single grievance nor ER case surfaced. When we looked back at those resources only 4 months later, we were stunned at how basic (and badly written) they were — and how quickly we were evolving ourselves within the Agile mindset and methods.

Two years ago we would have beavered away for months before releasing anything to anyone. This is what made us slow. Or we would have said the time available was too short. This is what made us unresponsive. Or maybe we would have pushed some elearning and ticked the training box. We wouldn’t have any idea what our customers would have valued. The risk, always, is wasted time, effort and money — and zero impact.

So when we say we work as an Agile team, what does that look like in real life? We cover that next in Part 4.