Abstract
There is enormous interest in agile approaches to running businesses as the key to innovation. But when agile is taken seriously it demands very different kinds of support – almost a revolution in the way business is done – and that includes HR. Which means HR will have no choice but to adapt or risk standing in the way of the path to innovation. Whether HR itself can become agile is a question of skill levels around organisational change.
What’s new
Agile could be the biggest change in the way business operates in more than a generation; or the latest in a long line of fads that most businesses will ignore. The answer for your organisation depends on whether you think ‘agile’ is a noun or an adjective. When my colleague Anna Tavis and I began writing about agile we asked employers whether they are engaged in agile practices. Roughly a third said yes; slightly more in Europe than in the US. But when I ask what they mean by agile most say their organisation is trying to be more flexible (the adjective view of agile).
That’s the fad approach. There are lots of ways to become more flexible and move faster. We could outsource more, hire and fire faster, invest more in change management and so forth. There is no unique approach to becoming more flexible nor any guarantee on how to get there. It’s like saying ‘we want to be more profitable’.
The real excitement around agile has to do with the interpretation of it as a noun. A particular approach for managing projects that distills what’s been seen as Silicon Valley’s secret: how companies get innovations out the door so quickly. Some aspects of it have been around since the early days of inventions. But as a systematic model it was articulated most clearly in 2001 by the software engineers at Adobe.
As agile manifesto framers Alistair Cockburn and Jim Hightower noted the essence of agile is that it puts people and their interactions above process and planning. Defining precisely what constitutes an agile approach has become something of a fetish – more than 1,500 academic articles were written about it in the first decade after the agile manifesto was published – but there is agreement on the key themes.
A practical measure of whether an organisation has agile project management is to ask: when there is a conflict between the CFO’s financial plan for a project and the team managing it will the team win? With agile the answer is typically yes.
The most notable aspect of agile may be what it takes away: top-down planning and control systems. When we start a project most of us have to develop a plan that specifies what the end result will look like, what it will be capable of doing, what it will cost, how long it’ll take, and what the intermediate goals will look like (e.g. how much will be accomplished this quarter, how much next quarter and so on). That plan has to be approved by the leadership and especially by the CFO.
But everyone who has led a project using this approach knows it is nonsense. When doing something new it is impossible to predict all that with any accuracy. Good project managers have to learn how to hide money to deal with inevitable unforeseen problems, how to package interim results to make them look like progress, and how to hold back evidence of real progress to make it look like they are hitting the marks on the plan.
Key findings
Agile gets rid of all of that. The project team is tasked with a problem to solve and, while there may well be discussions as to what this might cost, they are then on their own to do it, asking for additional resources when needed and finishing it as soon as they can.
It is easy to see how this is a radical idea for many companies, and why it got started in tech firms where the costs of developing software are comparatively modest, the processes for developing it are idiosyncratic, and top-down financial control systems were not in place. Agile can also be seen as an extension of developments that have been underway in business for a generation.
If you think your employees could not be trusted with this much control then agile is not going to work. If they could be then it’s easy to see how much time, money and delay could be saved by avoiding the charade of the typical planning process.
From research to reality
A straightforward question is whether HR should manage its own projects using agile approaches. IBM excels in this area; HR uses agile approaches to develop all its policies and practices. The easiest differences to see are soliciting input from employees as ‘customers’ in understanding their needs, the use of prototypes to get feedback on proposed practices, and feedback and adjustments even after programmes are launched. As IBM CHRO Diane Gherson says, they do not do pilots. They introduce, adjust, and iterate. If you can pull it off it’s cheaper, faster and innovative.
How about supporting the business with agile? Few companies have consistent long-term business strategies now. Most of what they do is run projects: lots of them and often across different parts of the business. So ‘supporting the business’ means supporting these projects.
Supporting agile projects also requires a different approach to recruiting and staffing. Agile teams need real-time support for those unanticipated ‘sprints’. Sometimes that requires new hires, in which case the cumbersome process of issuing and getting approval for requisitions is impossibly long. The agile recruiting model developed for GE Digital and now used at IBM makes use of teams of recruiters working together on a pool of openings to recruit faster.
More important than hiring is the ability to secure short-term help – sometimes from outside the company but more often internally. Here the task is first to identify who inside the organisation has the requisite skills – a database management challenge – and second to free them up to work on the project. Some companies have moved to bidding and posting arrangements for projects, where individuals can check a list to see the available projects and apply for short-term assignments. Then the task is how to get their managers to let them off their current work to take on one of the projects.
The second challenge for HR is managing performance and associated rewards. The end-of-year appraisal conducted by a supervisor conflicts with agile project work in several ways. First, the idea that we should have goals that ‘cascade’ down from department and organisational goals goes out the window. Many projects are not led by one’s supervisor and, because projects almost never end on an annual cycle, a yearly appraisal ends up giving average feedback across projects, some of which are still in progress. A better solution is to get feedback on each project, following the constant feedback norms in agile. That is accompanied by a move towards more just-in-time rewards to coincide with performance on individual projects, playing down the annual merit pay increase.
Ultimately the bigger shift for HR lies with new competencies to support agile operations. Agile focuses even greater attention on teams and requires detailed understanding of team dynamics: how to identify and diagnose where teams are struggling and how to fix them.
However, agile may not be the right system for all parts of the organisation. Some functions don’t need to be innovative, especially those executing routine tasks or handling compliance requirements. Can HR support agile teams on the one hand and traditional work groups on the other? Doing so will push us away from the one-size-fits-all model that has been the hallmark of many HR functions to date.
Peter Cappelli is the George W. Taylor professor of management at The Wharton School, director of Wharton’s Center for Human Resources, and a research associate at the National Bureau of Economic Research
