Burn Your Powerpoint Deck, or How HR Can Go Agile

How many times have you heard your leader express the need to be more “nimble”?

Change has become the new normal, and change agility (the ability to out-change competitors and external forces) is now a strategic differentiator. Recent studies show that agility and resilience are critical for success, top-of-mind for many executives, and linked to profitable growth, but to change successfully, and often, companies need to integrate their agility training with a smart approach to human capital and talent.

As agility is all the rage, I’ve seen a lot of non-software teams (especially HR) attempt to “Go Agile” without adequately preparing for the common pitfalls Agile adopters have been tripping over since the Agile Manifesto originated in 2001.

A brief digression on the history of Agile

Blogs and books recounting the success and failures of early (and even recent) adoptions of “Agile” methodology on software teams are a dime a dozen. Google any of the writers of the Agile Manifesto and you’ll find them. The Manifesto was written to, “…provide an alternative to documentation-driven, heavyweight software development processes”, but its writers have long bemoaned the loss of its original intent and how it was commoditized over the last sixteen years. The bastardization of the principles in relation to the speed of work (among other things) have exasperated many an Agile thought leader. Speed without direction is not strategy, it’s chaos.

Shipping software fast at the expense of quality (and both customer and developer happiness) is a tradeoff that many organizations have made under the banner of being “Agile”. A lot of those businesses aren’t around anymore. That isn’t Agile, that is bad business. Instead of trying to copy tech teams that went Agile badly, non-technical teams should learn from those painful (and expensive!) mistakes.

Why HR wants to go Agile

The concepts of “change management” and “organizational agility” have been around in business far longer than Agile has been around in software development. That said, traditional change management strategies haven’t kept up with how companies have shifted from simple to complex work environments.

The traditional approach — top-down buy-in, War-and-Peace-sized requirement PowerPoint decks and glacially paced program rollouts — no longer works for companies trying to keep up.

External competitors, marketplace growth, and the broader creative economy are all adding urgency to systems and processes that were not designed for speed. It makes sense that HR teams want to borrow the best of Agile methodologies to stay competitive.

Yet, in attempting to transition from this outmoded approach, many teams make the misstep of assuming that it’s only their pace that is holding them back. They try to go faster to keep up, but end up doing more harm than good.

Speed isn’t enough

HR, Marketing or Sales teams have started to call themselves “Agile” because they are focusing on velocity and speed. They use words like “dynamic” and “nimble” and “pivotability”.

This was a mistake in early Agile adoptions for tech teams, too. Speed is an important component of agility in a dynamic strategy, but only when combined with the experimentation and validated learning. The strategy must be able to show that it is delivering some type of value to its customers, iterating, and then ramping up speed.

What can an HR do to embrace Agile more holistically?

Stop:

Moving fast for the sake of speed.
Caring more about policies than people.
Spending literally any more than one hour writing PowerPoint decks for executive buy-in. (They won’t read them, and you could have been spending those hours actually serving your employees with customized programs).
Measuring the wrong things (Look how many people filled out the survey!) the goal.

Start

Building business acumen. You can’t advise on the business if the leaders don’t trust you. Why don’t the leaders trust HR? Because they think HR doesn’t understand the business...
Defining the original problem, starting with your people. Developers need programs that are different from Sales teams that are different from Finance. Smaller programs tailored to specific types of workers may sound like more work, but you’ll find that time if you stopped with the Admin bologna.
Talking to your “customers” (your employees). The annual engagement survey? It’s not enough. The data is obsolete, not transparent, and when employees believe that no action will be taken (and yes, that is the perception), you will actually drive lower engagement and harm your personal credibility.
Creating a culture that supports teams doing their best work. If your performance management programs incentivize the individual, you are in conflict with the Agile work methodology. People need to be encouraged and rewarded to act as a team member, not as an individual.
Measuring the long term viability of the program you’ve delivered. Participation is not the most important metric. How has this initiative affected engagement? Retention? Morale?
Illustrating how the program adds to the company’s bottom line. The data is there. Once HR starts telling the right story around value creation, they will stop being looked at as a “cost center”.

Whether your title is HR Manager, Chief People Officer, Change Management Specialist or Change Artist, you can help the business enormously if you can bring the best of Agile to your team while avoiding the pitfalls. Creating human capital programs that build the capabilities of your team, and reward and recognize high-quality team performance will bring tangible value to your company.

Agile HR can have so much more impact than just speed to market. Becoming more Agile means understanding where we are going and why, not just getting there quickly. Answering those questions makes us pause, won’t it slow us down? Initially, maybe, but in the long run, moving too fast in the wrong direction doesn’t get you anywhere good.

Let’s stop building presentations that leaders don’t want. Let’s stop planning slow, untested roll-outs. Let’s instead start running experiments that can immediately impact a group of employees. Let’s broadcast our learnings and show the value we add back to the business. Then we can truly call ourselves Agile. Our customers will be happier, and so will we.