Are teams working in Agile typically resistant to hiring people who haven't worked in Agile? [closed]

Question

As a developer who's never worked in Agile specifically (but have worked in TDD shops), I see employers that are running Agile shops resistant to hiring someone who hasn't worked in Agile. I've run into this a few times over the past few years. Is it really that fundamental of a philosophy change? After working in TDD, I can almost make an argument for not hiring someone who's never done TDD (when working in a heavy TDD environment). Perhaps I don't understand Agile and the difference between it and TDD.

I'd actually like to work in Agile, but this seems to be one of those times where you have to have the experience to get the experience. Sure, you can do it on your own, but that doesn't qualify if you ask me. As an employer, I wouldn't really call it applicable.

Answer 1

Agile is not an engineering philosophy in the strict sense - TDD, Peer Programming, etc are engineering practices that Agile uses - but rather Agile is a management methodology. As such, it's more important that someone be open to the mindset that Agile demands, rather than them actually having worked in an Agile shop before. Yes, it really is a different philosophy and approach to software development. People who expect everything up front and to be told what they need to do will be very out of place in an agile environment.

When I have interviewed people, I do ask whether they have any Agile experience or knowledge, but what I really look for are some of the following:

• Flexible mindset
• Confidence to allow self-empowerment (critical in any agile environment)
• Ability to self-assign tasks
• Communication skills (top 3 most important)
• Ok with vague instructions, able to self-teach

Those are some of the qualities that I think qualify someone to work in an Agile environment.

Answer 2

Having an understanding of what Agile's core principles are is important to understanding Agile. TDD is just a small part of Agile and more specifically XP (Extreme Programming).

First I would take a look at the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Then I would take a look at the SCRUM process (which is also a small part of Agile) to see what's involved there.

When I interview developers I look to see that they have an understanding of Agile and what that entails so that I can then determine if the Agile enviroment/mentality is one what they would enjoy working in.

Answer 3

I've hired developers into agile teams quite a few times. I'm not at all resistant to hiring a developer with no prior agile experience - they'll be slightly cheaper ;-)

However there are questions that I would ask such a candidate and there are certain responses that set off alarm bells - letting me know that this person is going to be too much work to re-train.

For instance being precious about their code and designs - a sure sign they'll be a 'mare in scrums and code reviews.

Agile is an extreme democracy - everyone is equal, but that doesn't suit everyone. Some developers just seem happier in an autocracy (tell me what to do and how to do it), monarchy (layers of middle management) or bureaucracy (specs and development by rote) - those guys just don't work in agile.

Some developers are much happier with the agile ideas, and those guys can get hired whether they have have prior agile or not.

I wouldn't worry about not knowing all the process details - good developers read up and stay current on the technologies they use, not process methodology. Since every company tailors their agile model anyway (if they don't they're doing it wrong) it really doesn't matter which variant they started with. You should know some of the terminology, but that takes a day of reading up before the interview at most.

Answer 4

The brand of agile that we use is composed of Project Management Practices as defined by SCRUM and Engineering Practices as defined by XP. If we are starting a new team, we will look for key roles to serve as embedded coaches for the team (an Iteration Manager/ Scrum Master Coach, Analyst Coach, Technical Coach and Testing Coach). For an existing team, given that we use pairing, we are more interested in developers that work well with others than a super programmer.

Because we using pairing, a new developer will become productive within a month with the agile engineering practices as well as the business and application domains. It provides the team with little value if a strong programmer joins the team but is unable to pair effectively.

When we interview, we ask the candidates to pair with several team members. Through pairing, we learn if the developer works well with others in a pair. In addition, we gain insight into the developer's technical skills. Because the candidate works in several pairs, we get the perspective of a number of team members.

All of our agile teams have been very effective and their projects successful. We have trained more team members to become effective with agile than we have hired experienced agile personnel.