Step 1. Burn Your PowerPoint Deck or How HR Can Go Agile

I recently was on a panel talking with HR leaders about Organizational Agility. The introduction to the discussion started with this:

How many times have you heard your leader express the need to be more quick and nimble? Recent studies show that agility and resiliency are critical for success, top-of-mind for many executives, and linked to profitable growth. Change has become the new normal, and change agility (the ability to out-change competitors and external forces) is now a strategic differentiator that needs to be integrated with human capital strategy and talent solutions.

I’ve seen a lot of non-software teams (especially HR) attempt to “Go Agile” in that “Change-Agility” kind of way. I think the intention is spot-on, but the execution so far has been, unfortunately, consistent with the pitfalls that young Agile adopters have experienced in the software industry since the Agile Manifesto originated in 2001.

A Brief Note on the History of Agile

There are plenty of blogs and books recounting the success and failures of early (and even recent) adoptions of “Agile” on software teams. Google any of the writers of the Agile Manifesto and you’ll find them. The people that wrote the Agile Manifesto (which was simply written to, “…provide an alternative to documentation driven, heavyweight software development processes” ) have all articulated the grave loss of it’s original intent as the commoditization of this new methodology of work evolved 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.

 
 

If organizations want to become more Agile they need to make sure they are not only able to move quickly but that they understand where they are going and why they are going there. Answering those questions alone can make business leaders pause; they think answering those questions will actually SLOW them down. And it may initially, but in the long run, moving too fast in the wrong direction doesn’t get you anywhere good and ends up creating a lot of work for very little value (See Waterfall.)

Shipping software fast at the expense of quality (and both customer and developer happiness) is a trade off that many organizations have made in product and engineering while still calling themselves “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 feel (and are) antiquated for today’s companies because of how we’ve 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. I offer you the internal monologue that played in my head during these static, painful HR meetings:

 
 

External competitors, marketplace growth, and the broader creative economy are all adding urgency to systems and processes that historically have not moved fast. 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 limiting the success of their internal strategies. They try to go faster to keep up, but end up doing more harm than good.
 

Combine Speed With Experimentation and Validation

At CTO2 we hear HR, Marketing or Sales teams call themselves “Agile” because they are focusing on velocity and speed. They use words like “dynamic” and “nimble” and “pivotability” to deliver anything to the business quickly.

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 process of demonstrating empirically that a team has discovered valuable truths about a business’ prospects). The strategy must be able to show that it is delivering some type of value to its customers immediately and iterate with feedback.

So what can an HR/People team do 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 customers with pilot programs.

    • Asking fellow HR members and your Executives what your most valuable employee programs are/should be.

    • Making optics (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. And do you know why the leaders don’t trust HR? Because they think HR doesn’t understand the business.
       
    • Focusing on people in your ecosystem when defining the original problem. 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 have more time if you’ve stopped with the Admin bologna and you’ll be driving a lot more value to the business.
       
    • Talking to your customers (employee base). The annual engagement survey? It’s not enough. The data is obsolete, not transparent and when the customer perception comes that no action has been taken (even if you’ve been typing away at that PowerPoint for buy-in deck) (and yes that will be the perception) you will actually drive lower engagement and lower personal credibility in your organization.
       
    • Creating a culture that supports individuals and teams doing their best work. If you have performance management programs that incentivize for 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.
       
    • 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”.
       

    Continue

    • Caring about the People.
       
    • Challenging compliance vs. coalescence.
       
    • Learning and growing your own HR/Talent/People teams. You need to put our own oxygen mask on first.
       
    • Partnering with the business itself. By bringing your employee base in to act as active partners in the design phase of an HR/People program you are BEING Agile. That is cross team collaboration to deliver the best product by definition. It drives connection and a sense of autonomy to the organization.
       
    • 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 huge value to your company.
       
    • Agile HR can have so much more impact than just speed to market. If we allow ourselves to stop building early presentations that leaders don’t want and stop planning slow, untested roll-outs, and start instead running experiments that can immediately impact a group of employees, and broadcasting our learnings and value add back to the business then we can truly call ourselves Agile. Our customers will be happier, and so will we.
     
     

    If you’re considering making a shift towards Agile in your department, and looking for advice on how to balance speed with quality, we can help. At CTO2 we developed our ACED framework to help solve problems exactly like this. We provide coaching and strategy in defining your organizational design, workforce planning that maps to the broader business strategy, recruiting the right talent for the right role at the right time and developing your teams and leaders of the future.

    Tweet us @wearecto2 @HRCorallo and @DoconDev
    Or send us an email: heather@wearecto2.com