"Agile Hiring" Seems interesting

[Gagan Grover]

Heard about Agile development but "Agile Hiring" seems unheard. What are the ways in which this agile hiring is different from normal hiring? I want to improve the hiring process in my organization so what is that I can expect from Agile Hiring?

[Sean Landis]

Gagan Grover wrote:Heard about Agile development but "Agile Hiring" seems unheard. What are the ways in which this agile hiring is different from normal hiring? I want to improve the hiring process in my organization so what is that I can expect from Agile Hiring?

Good question. As I was writing the book, I had no intention to use the 'agile' moniker. But when we had to name the book, it became clear that much of what I recommend is deeply influenced by what I have learned in agile software development. I don't make a big deal about agile hiring in the book. It's more of an undercurrent. If you are familiar with agile development, you will see its fingerprints all over the place.

So I don't take the angle of: "Here's how to make your hiring agile." Rather, I focus on what I believe are the best hiring principles, practices and techniques. In doing so, I have drawn upon what I learned in agile software development. Agile principles and ideas are very useful in many other realms than just software development.

To name a few things, agile development is rooted in the notions of the manifesto and the principles behind it (www.agilemanifesto.org). Likewise, I favor people over process, collaboration over checklists, rules, etc., adapting to each candidate and interview situation. I believe a hiring system should have many opportunities for reflection and feedback to promote continuous improvement. Many of the games we use in agile development (such as planning poker) can be applied (roughly sometimes) to hiring.

Agile recognizes that software development is more an empirical rather than repeatable process and it is geared to work with that assumption. Hiring is similar in that it is an empirical process. Agile is as much a philosophy or mindset as anything else. I think hiring is too.

All this said, the book is more about the specifics of how to review resumes, how to conduct phone and on-site interviews, and how to make offers, than it is about agile. I take a very practical approach. To that end, I train straight out of the book and it works well.

[Gagan Grover]

Thanks Sean for explaining how the concept of agile can be applied to hiring as well, you explained it precisely. I am looking forward for this one so that it can benefit my hiring force as well as improve the hiring process overall. Good Work

[Gagan Grover]

Hi Sean,

As asked by you, I have listed down the agile development principles, so please relate these principles to Agile hiring.

Agile Development Principles

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Thanks in anticipation.

[Ilja Preuss]

Hi,

I'm not a hiring expert, still I'd try to take a stab at it. I'll try to simply translate the principles to hiring, without judging whether it results in a good advice or not. ;)

Gagan Grover wrote:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Who is the customer of the hiring process? Probably the company we are hiring for. And the product is the work force. So "Our highest priority is to help the hiring company through early and continuous improvement of the work force"?

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

I see two main domains where change can happen in hiring: our understanding of what the company needs, and our understanding of the best job for an applicant. So if you find out that the person who applied as a, say, Java developer, would in fact make a great usability expert, see whether it would make sense to hire him as a usability expert. Don't cling to the original job description.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Not sure how to reasonably translate this.

Business people and developers must work
together daily throughout the project.

Applies directly to the hiring process: both business people and technical people must be involved in the hiring process to find the best candidates.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Again, applies directly. Hire people that are passionate about their job, even if they are not a perfect fit, skill-wise. Trust them to acquire the skills they'll need.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Face to face. Anything needs to be said about this?

Working software is the primary measure of progress.

Let applicants do real work for you, in the real environment, with the team they will later be part of. That's the best measure on whether they will be a good fit.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Not sure how this applies to hiring. Any ideas?

Continuous attention to technical excellence
and good design enhances agility.

Don't let the hiring process happen to you, design it for your needs. Be sure you know exactly why you are doing each step of the process, and that it is the best way you are aware of to get the information you need for hiring.

Simplicity--the art of maximizing the amount
of work not done--is essential.

Any translation needed?

The best architectures, requirements, and designs
emerge from self-organizing teams.

Mhh, is the same true for hiring? Should teams do their own hiring, perhaps?

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Certainly applies directly to hiring. Inspect and adapt.

[Sean Landis]

Nice job Ilja! I am glad to see this makes some sense to others. I don't specifically address each of the principles in the book as I am here, but it would be clear where their influence was present. I'll add a few comments of my own.

Ilja Preuss wrote:Hi,

I'm not a hiring expert, still I'd try to take a stab at it. I'll try to simply translate the principles to hiring, without judging whether it results in a good advice or not. ;)

Gagan Grover wrote:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Who is the customer of the hiring process? Probably the company we are hiring for. And the product is the work force. So "Our highest priority is to help the hiring company through early and continuous improvement of the work force"?

Yes, the hiring organization the customer. Continuous delivery of quality candidates.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

I see two main domains where change can happen in hiring: our understanding of what the company needs, and our understanding of the best job for an applicant. So if you find out that the person who applied as a, say, Java developer, would in fact make a great usability expert, see whether it would make sense to hire him as a usability expert. Don't cling to the original job description.

Yes. Also, the market is always changing. The candidate can throw some curveballs as well.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Not sure how to reasonably translate this.

We want to deliver qualified candidates often in a hiring pipeline scenario where many must be hired. We want to have very short turn cycle times for each step in the process including informing the candidate of their status.

Business people and developers must work
together daily throughout the project.

Applies directly to the hiring process: both business people and technical people must be involved in the hiring process to find the best candidates.

The hiring team works closely with HR as well.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Again, applies directly. Hire people that are passionate about their job, even if they are not a perfect fit, skill-wise. Trust them to acquire the skills they'll need.

And we also want people in the hiring process who are motivated. Hiring well is hard work. I recommend the development staff do the hands on hiring as part of their job, so motivation is a key component.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Face to face. Anything needs to be said about this?

Although resume reviews and phone interviews add excellent information, on-site (f2f) interviews add much more.

Working software is the primary measure of progress.

Let applicants do real work for you, in the real environment, with the team they will later be part of. That's the best measure on whether they will be a good fit.

There is something to be said for that and we do it in one form or other. I'd say though the primary measure in the hiring system is the quality and quantity of hires.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Not sure how this applies to hiring. Any ideas?

The hiring process should be sustainable and scalable. It should be able to run indefinitely. Where I work, We've been able to grow our staff of developers and testers 50 - 100% per year for four and a half years now with very little attrition.

Continuous attention to technical excellence
and good design enhances agility.

Don't let the hiring process happen to you, design it for your needs. Be sure you know exactly why you are doing each step of the process, and that it is the best way you are aware of to get the information you need for hiring.

Yes, and you reflect and adapt as necessary. The hiring team and process are a living organism that requires continuous care.

Simplicity--the art of maximizing the amount
of work not done--is essential.

Any translation needed?

Nope.

The best architectures, requirements, and designs
emerge from self-organizing teams.

Mhh, is the same true for hiring? Should teams do their own hiring, perhaps?

Hiring organizations should be in control of their hiring process and needs. Just like in agile development, teams may not be ready for this much responsibility and may need support. The converse often occurs in large organizations where hiring is a top-down activity driven from the HR organization. That's not ideal.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Certainly applies directly to hiring. Inspect and adapt.

Yep.

[Ilja Preuss]

Sean Landis wrote:

Working software is the primary measure of progress.

Let applicants do real work for you, in the real environment, with the team they will later be part of. That's the best measure on whether they will be a good fit.

There is something to be said for that and we do it in one form or other. I'd say though the primary measure in the hiring system is the quality and quantity of hires.

Yes. And the primary measure of the quality of hires is how well they do on the job (in contrast to how well they did in tests or interviews).

[Sean Landis]

Ilja Preuss wrote:

Sean Landis wrote:

Yes. And the primary measure of the quality of hires is how well they do on the job (in contrast to how well they did in tests or interviews).

Absolutely! Good interview performance merely get the candidate an offer. I recommend some sort of trial period for candidates. This is a great way to monitor the quality of your hiring as well as the quality of the candidate.