I just returned from Singapore where I had the opportunity to meet with many of Asia’s senior HR leaders. This is a geography where adigital business has thrived, with companies like Grab (topping Uber) and DBS (the worlds #1 digital bank) setting the pace.
And as I reflect on many of our conversations, it became clear that one of the biggest topics on HR people’s minds is adopting the principles of Agile. Once considered an arcane methodology used by software engineers, the concepts of Agile are sweeping across the business. And they are radically changing HR.
Fig 1: Google Trends Searches
What Does Agile Really Mean?
Agile is a philosophy, a culture, and a set of management practices. Let me give you a little background.
The Agile Manifesto was first written in February of 2001 when a group of programmers met in Portland to figure out how to speed up their development. (They called it Extreme Programming.) These engineers developed a set of principles and from there designed to greatly speed and improve the software development process.
You have to realize that in the 1980s and 1990s it took huge teams to build software, and they built it in a years-long “waterfall” method. The fascinating book “The Mythical Man-Month,” written by Fred Brooks at IBM (1975), talks about how big projects at IBM got slower and slower as more people were added. Brooks experimented with small teams and discovered the ideas of Agile before the manifesto was written. (Download here, it’s well worth reading.)
Brooks found that the more people he had on a team, the slower the project went. Essentially middle management was creating friction in communication, preventing true experts from doing their work and talking with each other.
As he studied the problem he concluded that software development was not a “scale” process but rather more like “skilled surgery.” He realized that small multi-functional teams, armed with very limited and clear goals, could work together to outperform large projects.
His principles focused on three fundamental things: first, the software teams had to get closer to customers so they could learn and iterate faster; second they had to build software more quickly and get it to customers soon, and third, they had to coordinate these projects without the overhead of middle management.
As Agile principles have matured, techniques like standup meetings (daily meetings to talk about what’s happening), SCRUM (a method to manage projects simply), MVPs (minimally viable product), and OKRs (a very simple way to set and share goals) became popular artifacts. I walk into many HR departments and see small teams in group offices with sticky notes on the wall, all attempting to “be agile.”
In reality, however, as Maarten Van Beek of ING bank explains, copying these tools don’t necessarily make you agile. Agile is really a philosophy: one of making decisions at the level of expertise, empowering people to learn, and experimenting with solutions that are co-developed with customers.
If you visit ING you see lots of small, multi-functional HR teams working together on various programs. People iterate regularly and the process fits into the “digital tempo” of the bank itself. Learning and collaboration is rewarded and encouraged, and people move from project to project throughout their HR career.
In the case of HR, sitting in a conference room in long process meetings is not always the right solution. We need to “co-develop” solutions with the business, and then roll them out in an experimental and iterative way.
And just as Agile has transformed software development, so it will transform HR.
Yes we do need to design enterprise-wide processes – but they’re no good if they aren’t localized and relevant to peoples’ daily work lives. So rather than design solutions in a conference room, we need to design them with customers, experiment and observe how well they work, and quickly improve them every day. This is hard to conceive in HR, but it’s now possible and works very well.
(ING practices Agile in HR with tremendous success, Sky in the UK does it in L&D, and many other companies now do too.)
Agile Design and Agile Service Delivery (DevOps for HR)
But there’s more. In HR, like software, there are two parts to solving problems. The first is “designing” a solution – the second is “serving and supporting” the solution in the market.
In the software industry, we’ve developed a role called DevOps to support the solution in the market. IDevOps is a set of practices that help us apply agile principles to the service delivery part of our work. In the case of HR, this means creating cross-functional service roles, instrumenting and monitoring our employee solutions, and getting lots and lots of feedback so we can tweak, improve, and iterate the programs we build.
One of the companies I recently met is using Agile in their performance management process. Not only are they using OKRs and other agile approaches for the employees and managers, but they developed three “versions” of the process to test on teams. Each of these three pilots used different approaches to evaluation and goal-setting, and in an agile way, they are using “A-B testing” to decide which will work best.
I believe Agile principles will radically change service delivery models. While I know many of you have gone through HR transformation projects over the last few years, often focused on creating centers of excellence and service centers, I’d suggest all that is changing. In Agile we need multi-functional COE’s (focused on solutions, not HR functional silos) and multi-functional support groups (DevOps type groups).
How to get started? A great example is employee onboarding and job transition. These are essential employee experiences that always cross functional boundaries.
Think about your company’s onboarding strategy. It needs to be customized for different roles, different transitions, different geographies and business units. There’s no way to build a generic onboarding program for everyone. We need to co-design it with the business and decide how much is checklists, how much is training, how much is community building, how much is facilities and travel, and how much is compliance and IT.
Then once someone needs help, we need a service center that understands “the onboarding process” and “the job transition process,” not just one little piece. This means we need an Agile design and an Agile model for service delivery.
(For more examples read Riina Hellstrom’s article on 8 ways to apply Agile in HR.)