what does the agile librarian do between library jobs? Pt. 2

No longer between library jobs. Big Yay! Started a new part-time library job last week. But continuing the discussion of Agile application to HR issues.  (Don’t fret, we’ll bring the Agile discussion back to librarianship soon enough. In the meantime, taking this HR detour might eventually be instructive). Today, we are going to take a brief look at the history of Agile methodologies.  Later in the week we will look at some considerations when converting or transforming existing processes to Agile ones.

Agile History

It is easy to trace the history of Agile to the Agile Manifesto of 2001 and the twelve principles that followed in its wake.  Easy but far from sufficient.  We need to look at a few of the antecedents to that 2001 gathering to know what is really going on.

Lloyd Wilkinson, in Agile Development: A Brief History, traces the roots of agile project management thinking to Toyota process in the 1950’s, more specifically, kaizen, or continual improvement in automotive manufacturing processes.  In case you haven’t already clicked on the link, kaizen is a Japanese word that is translated as “continuous improvement.”  In lean, or just in time manufacturing systems, the process itself must “continuously change in order to deliver value to the customer.” Before we take a deep dive, it is necessary to say that one might make an argument that HR systems bound by rigid rules and regulations are not capable of continuous change.  I would argue (1) that the multiplicity of rules and regulations, all overlapping, is precisely what opens the door to flexibility and dynamism and (2) what manufacturing process was more rigid that automotive assembly line production, and yet, Toyota’s introduction of Kaizen practices made it a world leader in the automotive industry.  But back to the subject…

Kaizen has a few foci that are particularly relevant to HR processes.  First is the Kaizen 5S concept: sort, or removing anything from the space not needed for daily operations; straighten, or placing the essential things in the right place for optimum operations; sweep, or removing anything that is clutter and repairing anything broken; standardize, or codifying best practices; and sustain, or establishing new, more efficient standards and resisting the tendency to return to old ways of doing things.

Second is the concept of employee involvement supported by employee trust. Specifically, this concept has as its antecedent, the work of Elton Mayo and the Hawthorne Effect (please click and read!).  Very briefly, Mayo concluded that

• The aptitudes of individuals are imperfect predictors of job performance.
• Informal organization affects productivity. The researchers discovered a group life among the workers.
• Informal organization affects productivity. The researchers discovered a group life among the workers.
• Work-group norms affect productivity.
• The workplace is a social system.

A moment here on James Martin and Rapid Application Development (RAD). James Martin, nominated for the Pulitzer Prize for his 1977 book, The Wired Society: A Challenge for Tomorrow, introduced in 1991 an approach to RAD that involved iterative development and the construction of intermediate prototypes. These two elements would play a critical part in Agile project management thinking in subsequent years.

For extra reading, this article also looks at the history of Agile thinking: The roots of Agile project management.

Later in the week we will look at some of the challenges and possible pitfalls of adopting Agile thinking to existing processes.  And to raise eyebrows, we will call the next post: “The Road Less Taken, or, People are software in any production process.”

In the meanwhile, a bit of Sarah Vaughan for the Labor Day Weekend:

what does the agile librarian do between library jobs?

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: