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

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

I think it is a typical case of over-insisting on a specific skill set. Like employers who don't want someone who knows JBoss when they use BEA for their application server.

A good employer will recognize if someone is adaptable to an agile method or not. Now if they have two otherwise equal candidates in front of them, perhaps that is a bit different.

Answer 2

It is certainly a handy way out of having to explain other reasons that may play a more important role in the decision.

Answer 3

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 4

Maybe they take the mentality of the barkeep in the Mos Eisley cantina (paraphrased):

We don't want your kind here.

Answer 5

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 6

I understand your frustration but the truth is, if you never worked in an Agile environment you are very likely to behave in counter-agile ways (so to speak), and you will likely not even understand what is it that you are doing wrong.

Since Agile is so much about work philosophy it's not something you can learn merely by reading a book, you need to have intimate understanding of how non-Agile firms operate, what issues this causes, how Agile changes that, and how you to fight the entropy (the attempts of the external world to introduce the non-agility back in).

My advice is that you first read more about Agile and start analyzing your own behavior and behavior of whatever firm you currently working at from the Agility/non-Agility perspective. Once you're able to discern the patterns, you can start trying to change your firm from within. When you fail with that, go to the Agile company and they will hire you, I promise.

Answer 7

In your current job, can you implement some form of Agile Developement to show you are interested, have looked into it and actually have some experience? You may be able to find some non-developers to work with you. A power-user could sit with you during some coding. I'm sure no one would get in the way of using some of the Agile documentation (sprint log, burn chart).

Answer 8

I'd likely put forth this question: What development methodologies have you been using up to this point in your career? Do any of them encompass the spirit of Agile's ideals?

If you are someone that loves to develop via Waterfall and think it is just absolutely perfect for your world of development, then going Agile would be like going from driving a car to flying a plane or a boat. It is that fundamental a difference as you aren't going to necessarily know where you are going and deal with changes very differently than a waterfall style where each stage goes in order and there isn't any reprioritizing without jeopardizing the whole process.

Answer 9

Any company or opportunity that dictates SDLC by practice instead of best fit for the current project/situation is already showing signs of it's limitations and you are probably better served continuing your job search.

Answer 10

When a company uses the umbrella term "Agile" in recruiting without being more specific (e.g, by asking for XP or Scrum experience), it's often a placeholder for something else they're looking for. They may want "developers who will pair program" or "developers who won't dig in their heels about not having requirement and design documents before they get started" or "developers who won't go off into a dark corner for weeks on end". The trick is to figure out what they mean.

From a narrow Silicon Valley hiring perspective, a candidate who is familiar with Agile practices (e.g., knows what XP is), has done some of them (e.g., pair programming and TDD), and who wants to work in an Agile environment gets past that hurdle.

Answer 11

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.

Answer 12

Employers most likely stick to hiring people who are knowledgeable of agile, rather than not, because agile methodologies require that almost every team member know about the processes required by each agile methodology (SCRUM, Crystal, XP). For example, SCRUM requires that all team members, including management, understand and follow the concept of self-organization. They’ll need to understand that they won’t be dictated on their current performance: They need to instead address their issues openly (or what typically happens at the daily SCRUM). If you put someone on the team who does not know agile, they may immediately assume that since this methodology has low documentation, they can run in and code-and-fix to build a project. However, agile methodologies are process-heavy, rather than documentation-heavy.

Answer 13

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 14

Absolutely YES

There's a lot of teamwork and trusting your peers in agile and specifically in extreme programming. You need to know other people are writing decent tests and not breaking your code. Good XP developers don't want people on the team that are going to make their job much harder.

Nothing wrong with being a beginner, or somebody new to a team - but there is an element of building trust just like you would to get committer rights in open source.

These days everybody says they are agile and if you offer enough money, practically everybody with the slightest tech skill will apply for the job... so expect people to put you through a pair-programming interview.

Typically we need to know:

• Can you really pair program?
• Do you really know how to do TDD?
• Are you just saying these things or can you demonstrate you do them?
• Are you going to take the initiative or are you waiting for an old-school "project manager"-type to tell you what to do?

Stuff that will help get you hired in an agile shop:

• You have tried to introduce test-driven development somewhere even if you didn't get buy-in. (It worked for me...)
• You have sample code you wrote - or an open source project on which you can demonstrate test-driven development, automated builds...
• You find that you've worked in teams with short release cycles ...