Agile Hr

The methods now labelled agile emerged in software from a specific problem: requirements specified in advance were routinely wrong, and long delivery cycles meant the error was discovered too late to fix cheaply.

The response was to work in short cycles, deliver something usable each cycle, get real feedback, and adjust. The value is in the feedback loop, not the ceremonies built around it.

Applied to HR, the same logic says: stop designing a policy for nine months and rolling it out to everyone, and instead try a version with one part of the organisation, see what happens, and change it.

Where HR problems have that character, being poorly specified in advance and cheap to test, the approach genuinely helps. Where they do not, it does not.

• Performance practices. Annual cycles were the clearest case of a long feedback loop producing information too late to act on, and continuous feedback is the direct application of iterative thinking. It is the most successful instance of this in HR.
• Policy design. Piloting a leave or working pattern change with one function before organisation-wide rollout surfaces problems that no amount of drafting would have.
• HR service delivery. Prioritising a backlog of requests visibly, and working it in short cycles, is straightforwardly better than an unordered queue.
• Product-style thinking about internal tools, meaning asking employees what is difficult rather than assuming, and improving the worst thing first.

What these share is that the cost of being wrong is low and the feedback is available quickly. That is the condition under which iteration beats planning.

Several parts of HR are structurally unsuited to iteration, and pretending otherwise causes harm rather than inefficiency.

The third row deserves emphasis. Consistency is the property that makes disciplinary and grievance processes defensible, and iteration deliberately introduces variation. A process that differs between two employees because one was in a pilot is exactly the inconsistency that causes problems.

The general test is whether being wrong is recoverable. Where it is not, plan properly and do it once.

The most common form of agile HR is the vocabulary without the substance: stand-ups that are status reports, sprints that are fortnightly deadlines on unchanged work, and a backlog that is a task list with a new name.

This is detectable immediately by asking what changed as a result of feedback in the last three cycles. Where the answer is nothing, there is no feedback loop and the ceremonies are overhead.

It also has a cost beyond the wasted meetings. Adopting the language of adaptability while behaving exactly as before is noticed by the workforce, and it makes the next genuine change harder to introduce because the vocabulary has been discredited.

The honest version is to name what you are actually doing. Running fortnightly planning is a reasonable practice and does not need to be called a sprint.

There is a distinction worth holding between an HR function that works iteratively and an HR function that helps the organisation adapt. They are frequently conflated and the second is the more valuable.

An organisation that needs to move people between priorities quickly is constrained by things HR owns: how rigidly roles are defined, whether pay is tied to a fixed job description, how long it takes to move someone internally, whether performance is assessed against goals set a year ago, and how quickly hiring can start and stop.

• Broader role definitions, so moving someone is not a change of terms.
• Goal-setting cycles short enough that objectives are still relevant.
• Internal moves that are easier than external hiring, rather than harder.
• Pay structures that reward capability rather than a single fixed job description.

None of that requires the HR team to work in sprints. It requires the practices HR runs to stop being the constraint, which is a different and more useful project than reorganising how HR schedules its own work.