My relocation created an employment gap of sorts and I found myself between library jobs. But luckily for me, my old, former career reached out and steered me towards part-time employment focusing on finding solutions to HR challenges in a federal bureaucracy. Little did I know initially that that opportunity would open doors to fascinating potential applications of agile thinking and agile methodologies. (I’m hearing a combination of two tunes, Amy Winehouse, Back to Black, and Stephen Stills, Love the One You’re With. Will include the you tubes at the end of this post.)
There are striking similarities between HR work and the software development challenges that gave rise to agile thinking. Various types of HR work exist in a dynamic bureaucracy and each type has various phases. We will focus, for example, on the onboarding process, i.e., bringing new employees onboard for the first time.
Initially, the customer or client, in the HR case, the manager decides she/he needs a new position to fill the expanding needs of the office. Ideally, that manager will work closely with his HR colleagues to define the requirements of the new position, i.e., what work they will actually perform, and the skills any prospective employee will need to accomplish the work. A position description results.
The position is advertised. Hundreds of applications pour in. The HR staff winnows down the applicants whose qualifications actually meet the position requirements. Traditionally, this is a phase that is pretty much accomplished exclusively by HR. But we all know that excellent applicants get weeded out unnecessarily during this process.
Managers are handed a bundle of applications and a list of names for assessment. They make their selection, HR makes sure everything is in order, and the person is hired.
So why does this process take 4 to 6 months in government? The waterfall method may have clues!
A busy HR section may have several positions being filled at once, all at various phases, similar to software products being developed. And there are various places where “stacks of things” pile up, i.e., in HR as well as with the manager. And in the absence of a constantly updated tracking mechanism, no one can say for sure where the roadblocks in the process are located. As a result, managers blame HR for slowdowns in the process, and HR blames managers for their slow responses, and problems don’t get solved, until eventually, six months later, a person is hired (though not the best applicant, because she, exasperated with the process, finds just as good a position elsewhere).
So how can we apply the agile method to onboarding to make the process simpler, quicker, and just as efficient?
How about a picture!
From previous posts, we know the agile method values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Nice words, but how do we “do” this?
The first “principle” of agile software mentions early and continuous delivery of valuable software. From the HR perspective, this means program managers have to take the time to consult with HR staff about the new position, and HR staff have to make the time to consult with program managers. If it is the case that program managers already have a candidate in mind (and we know that happens!), that should be communicated to HR staff. As applications pour in, there should be regular comms between HR and the program office, expediting that winnowing process. The point of the matter is constant communications that lead to greater efficiencies.
The second principle addresses changing requirements and harnessing change for the customer’s competitive advantage. This may be a bit difficult, HR-wise, because positions are posted to USA.gov, which allows little alteration in the process. But locally, if requirements do change, there is no need to “re-create the wheel.” Again, the key to applying slight requirements changes is communications between HR and the program managers. This could be a bit tricky, but it is manageable.
The third principle: deliver software frequently. Traditionally, HR units pile up stacks of applicants (time consuming), then pour through them (time consuming), then deliver winnowed stacks to managers after a period of time (time consuming). Then managers postpone going through the stacks, and hopefully eventually go through them (time consuming). In an agile environment, that feedback loop is tightened through frequent engagement. But the onus is on both HR staff and program managers to reduce the wait time at each stage and to reduce the repetition of stages themselves through efficient communications.
OK. There are nine more principles and you can find them here (The “Agile” in Agile Librarianship) in a previous post (your homework assignment, dear reader), all relevant, and all pertinent to HR processes. If we go through them all here, we will never get to the videos!
OK. Dessert at the end of the meal. The videos: