I've been interviewing for co-ops (paid internships) lately and a large number of the companies I've been interviewing with have been saying they use Scrum or some other agile methodology (scrum being the most popular). I know that there are real agile shops and there are places which say they use an agile methodology but are really doing something else and using agile as a buzzword.

My question is, what are some questions I can ask in an interview which would separate these shops out?

EDIT: While I am looking for an internship, I feel that these questions are relevant for everyone. The internship part is context.


16 Answers 16


I always begin by asking this question:

What's the duration of your iterations?

Rate their answer:

1 week is awesome, 2 weeks is great, 3 is ok and 4 mediocre. Longer than that indicates they are struggling and more then 8 weeks is just weird. If the answer is it depends, you know they have no clue whatsoever.

Follow up with:

How often do you release?

This is to verify the first question. The right answer is daily or end of each sprint. An agilist would know there should be no technical difference between an internal and external release.

  • 5
    The defacto standard is 2 - 4 weeks. 1 week sprints...? Hmm...I would be suspicious. Jan 14, 2011 at 22:16
  • 5
    There is no "standard"; it varies between companies/teams/situations. I find the overhead of Scrum is, as a proportion of the sprint length, too wasteful for one-week sprints, therefore we use two. Jan 15, 2011 at 11:54
  • 1
    I've tested many different duration and I like 1 for very small projects in small teams, but for large enterprise projects, 3 or 4 gave me better results.
    – user2567
    Jan 15, 2011 at 22:28
  • 3
    I think its these terms of "real" vs. "watered down" agile that rile my feathers. I've always applied the concepts and principles of the Agile Manifesto, but never used one of the branded versions of Agile. Insisting on only one of the many agile methodologies violates the first tenet of the manifesto. But I get what you are saying. Jan 16, 2011 at 12:16
  • 2
    To me, "real" agile is agile that applies the manifesto and its 12 principles--regardless of what it's called. There are a lot of buzzwords that add to the core meaning of agile and then claim you aren't agile if you don't do those. Jan 16, 2011 at 12:19

Ask them to defend agile methodologies. And then ask them to refute it by outlining its weaknesses. Bonus points if they can navigate this course without littering it with meaningless buzzwords.

  • 4
    +1 It's always good to find ways to interview the company.
    – Jeremy
    Jan 14, 2011 at 20:41
  • @Jeremy unfortunately they wouldn’t take it very well. I wouldn't recommend it! Jan 14, 2011 at 20:43
  • @Amir: Please explain! I have never left an interview without them asking if I have any questions. What's wrong with the job seeker wanting to know more about the company? If they don't take it well, then it's a sure sign I do not want to work for them!
    – Jeremy
    Jan 14, 2011 at 20:55
  • 1
    I know some companies actually don't like it when their interviewee doesn't ask questions... to them it shows a lack of interest in the job.
    – Rachel
    Jan 14, 2011 at 20:58
  • 2
    I think asking them "to defend agile methodologies" is probably not the best method of asking ;) Jan 14, 2011 at 21:16

Ask them why they use it.

You will immediately know.

  • 8
    This can be answered pretty easily though with canned answers. "To reduce our time to market and remain competitive." It has to be a more back and forth approach. If the OP is familiar with Agile/Scrum and wants to be certain the business is as well; I would gather the OP should have a wealth of questions on the matter...specifically what bothered them at a previous place of employment and how might the new business address this. Jan 14, 2011 at 22:19
  • 2
    The answer you mention could not be said by someone understanding agility. It's a pretty good indication they don't know why they should use scrum. Every company try to reduce time to market and remain competitive. If you answer me the question I would reply "it's the only methodology adapted to software development" or "it brings lot of visiblity on what we should improve".
    – user2567
    Jan 14, 2011 at 22:22
  • @Pierre 303 Any reason to suggest why, from a business stance, that Agile adoption was a process which could increase our time to market and remain competitive with timely releases of our software is not valid and would define that individual as not knowing why the should use Scrum? You have to understand that the hiring managers are not always technically inclined but it doe snot mean the use of Scrum within the organizaiton is in vain. Jan 14, 2011 at 22:25
  • 1
    @Pierre 303 Can you elaborate your answer a bit? The reason for using any software development method is to "deliver value as efficient as possible to our customers" and that applies to agile as well as RUP and others. Jan 15, 2011 at 10:51
  • 1
    Totally agree. Ask them why they even chose Agile. Solid. +1 Jan 17, 2011 at 3:16

I would ask them to describe the software development life cycle when using the Agile methodology. If they're familiar with it they should be able to describe each phase in the SDLC accurately.

EDIT: I just realized that you were asking from the point of view of the interviewee, not the interviewer. In that case I would probably ask them about their SDLC and see if the steps they say they take matches up to what Agile really is.

  • Good point regarding asking about SDLC. However I have been in organization where they followed all step in SDLC but the team applied the methodology badly. Jan 14, 2011 at 20:40
  • @Amir: If that were the case I would assume they were at least trying to follow the agile methodology. Chances are they either have a good reason for deviating away from it, or they don't know what they're doing and would be willing to learn if you took the time to teach them.
    – Rachel
    Jan 14, 2011 at 20:45
  • They do have good reason. They adapt the methodology to their reality. Jan 14, 2011 at 21:01

The approach I take really has little to do with the agile buzzwords, but it does have to do with agile practices. One of the commonalities in all agile teams is the short iteration, most people get that part (it's one of the 12 principles behind agile on the http://agilemanifesto.org site). The purpose of the short iteration is to get feedback early on the quality of the software developed. This is where I start.

  1. Ask about unit testing. Overwhelmingly the answer I get here has been "uh, we cut that out because we didn't have enough time" (note: first 2 warning flags--no time and no unit testing)
  2. Ask about when the software was tested, and how often. Answers can get creative here. Particularly if the team uses "Agile" as an excuse to throw all process aside. If the answer is toward the end of the project, or anything other than with each iteration, they don't know what agile is.

So far, I haven't had to go any further than this to know that the person doesn't know what agile is. I've also only been in one interview with a company that already had well established agile processes in place.

There's more than one way to do agile, and I care more about the principles of agile than any particular brand or buzzword.


There are several things that separate those who are "doing" agile from those who are agile:

  • Ask about continuous integration if they're not using CI deduct a point. Add a point if they are. Extra points:
    1. Add 1 if they use two phase commits (code must successfully build before the developer can check in).
    2. Add 1 if the build script includes running a test suite
    3. Add 1 if the build fails if code coverage falls beneath a certain threshold
    4. Add 2 if it is possible to deploy the application so that is ready to run in one click
  • Ask about TDD (test-driven development) subtract 2 points if they don't use TDD add 1 if they do.
  • Ask about iterations, how long are they (subtract 2 points if they don't do iterative development, subtract 1 if the iteration is longer than a month or less than two weeks, add 1 if its 2 weeks)
  • Ask how estimation is done add 1 if they use story points, add 2 if they do planning poker or something similar, subtract one if they use absolute time estimates, subtract 2 if developers aren't involved in the estimation process.
  • Ask how features are built add 1 if a developer is responsible for the feature from top to bottom (vertical slice) subtract 1 if developers are responsible for a specific layer (horizontal slice)

There are a number of other indicators, but those alone should give you a good picture if the team actually IS agile. A team with 5 points or more qualifies. Anything else means they're "doing" agile. Agile is not just about iterations, it's about enabling the team to adapt to change easily. If you're iteratively writing untested, muddled code, written under external pressures, well you're just writing crap code in iterations. Notice that you can get a lot of points just from the continuous integration bullet. But that alone isn't enough to bring you over 5 if you're not following the other practices.

  • 1
    "Ask about TDD (test-driven development) subtract 2 points if they don't use TDD add 1 if they do" makes no sense. Just add 3 if they do. Jan 16, 2011 at 4:48
  • I see what you're saying...I didn't simplify my formula...but I think my point is clear. Jan 17, 2011 at 8:12
  • 1
    WTF has CI and TDD to do with Agile? Sure, makes releasing easier but you really don't need it to work in an agile way. And believe me, I know companies with TDD and CI that are NOT agile whatsoever.
    – gbjbaanb
    Aug 3, 2011 at 13:15
  • TDD and CI alone does not make an environment agile. However, missing those elements is a warning sign that there isn't a true commitment to being agile. Aug 3, 2011 at 18:03

As with all of these things you ask for real world examples from projects they've worked on, not theory. Accepting theoretical answers is the easiest way to be duped by someone who hasn't actually been there.

So you ask to speak to actual developers and ask things like:

  • So talk me through your current project. What was the initial end goal? What did the first sprint contain and what could the software do at the end of it?
  • Can you give me examples of functionality or design on your last project you believe worked out differently than had you done it as a waterfall project?
  • Give me an example of how a large piece of functionality was broken down over multiple sprints? What inefficiencies / rework did this lead to? And what improvements or changes from what was initially envisioned.
  • When you started working with agile, what things that you were doing during the early sprints did you change during later sprints (or projects) as you got to grips with the methodology?

Keep bringing them back to the actual projects - what were they trying to achieve, examples of what was in each sprint, examples of the sorts of things that came up in meetings, examples of interactions with the users.

Do not accept theory, do not accept other people's projects, only things they themselves have worked on and can talk about from first hand experience.

They would have to be a stunningly good liar to be able to make up 10 - 15 minutes worth of stuff that would get past you if you know your stuff.


If you don't want to make them defensive, I've found the following question will initiate a conversation that will tell you everything you need to know about whether they are actually using an Agile approach or just paying it lip service:

Who is responsible for writing requirements/specifications for your software projects?

I have seen numerous companies who claimed to be agile and even wanted a Scrum Master certification describe a classic big up-front design process when you ask about their requirements gathering process.


The thing that stands out to me is that you're looking for an internship, which leads me to wonder what your purpose is in asking these questions. Are you trying to ask a question about agile to make the interview go well, or would you actually refuse an offer from a company using buzzword agile? If you're really looking for an agile environment, pick a question (why do you use agile, what time are your standups, how long are iterations, whatever), and ask it over the phone or in an email without wasting time on an interview. If you're looking for income, wait for the interview, and ask questions that show your knowledge/excitement about agile methodologies (Tell me about your software development lifecycle) without embarrassing the interviewer if they're using some semi-agile abomination.

  • This is a question I would ask during the "Do you have any questions for me" portion of the interview. I'm asking a question to determine if they're telling the truth when they're saying they are agile. I've already been in a cowboy environment and would like to prevent that from happening. I know that there are organizations that use agile as a buzzword, so I'm trying to filter those out. Also, interviews go both ways, I'm interviewing the company while they're interviewing me.
    – indyK1ng
    Jan 21, 2011 at 16:53

I ask them to describe a typical request, from inception to finaly delivery to client.

I also ask whether they typically handle long-term support for the product they provide the client (because teams that do will generally build a better product, knowing they're gonna be the one fixing it at 1AM on Sunday during Labor Day weekend).

I also ask how management sees its role during the process. It's pretty easy to see if they have the fire-and-forget attitude (we launch, you fly, we ask if you hit the target) or the "we help you row the boat up the river" attitude.

These will generally show you how they really do things, not how they're Supposed to do them, or how they Claim to do them.


The best way I've found to see if someone knows what they are doing from an SDLC perspective is to ask them where they have screwed up in the past, and how they would do it differently. People who've been through the process a few times and will fully admit where they screwed up, and the are generally pretty detailed about. They openness to discuss it shows a level of confidence, because they admit they aren't perfect. Avoiding the question by saying "They pretty much do it OK all the time," is a real warning sign.


How often they release to production. The longer the time the less Agile they are. How often they have reflection workshops. If they know what you are talking about then good. How often do they have team 'catchup' meetings. Daily is great, monthly is bad. Do they have a continuous integration server. This isn't a must have but will give you an idea about their use of tools. How often do the end users sit with the developers. Never means they aren't Agile.

  • +1 IMO, the first thing that dies in an agile-wannabe organization is the retrospective. That's really more a Scrum concept, but successful agile comes with understanding how well your process is enabling instead of disabling your organization. Without some introspection mechanism I don't see how that's possible.
    – MIA
    Jan 16, 2011 at 0:04
  • Give them a situation and ask them to solve it in agile way;
  • Ask them about their favorite agile practices (planning poker, pair programming, bdd/tdd, kanban);
  • Ask them why they did not choose or moved from other methodologies (waterfall, rup, etc.)
  • What are most known people in agile methodology world, who coined the term and what most popular books are written about it.
  • 1
    Honestly, I would fail the fourth point. I know what agile is, and I've read a number of online resources about how different people walked stuff out. However, my path to agile has always been custom to the team/environment I work on. Jan 16, 2011 at 2:46

If they are using Scrum, you could ask if you could watch the next stand-up. If they don't have them, then ask why not as that would usually be part of the methodology.

There are some aspects to Agile that could also be worth mentioning. Ask to see the story board, how big is the back log, or what were some of the highlights in the last retrospective, for a few other ideas. The key here being to get to something tangible that shows what is happening compared to just fluffy words that don't really mean much.


Ask them how they handle design. If they tell you there's no design in agile, they aren't getting it.

Ask them how they manage changing requirements. If it sounds like changing requirements has its own process, they probably aren't getting it.

If they're claiming to use Scrum, look to see how they write it. Shops that do Scrum well tend to know well enough how to write it. Hint: it's not SCRUM.

That may seem like pedantry, but I'm firmly of the belief that in order to successfully apply a process template like Scrum, RUP, XP, or whatever, you need to understand the philosophy and the "why" so you know how to adapt the "what" to your organization. In Scrum, most folks who are doing their homework will come across that little bit of info. Folks who are looking for cookbook recipes for project management will usually miss that detail.


What makes sense to me is to ask them to describe how they handle part of the Agile process. Right now my favorite is the beginning of an iteration, but you might develop your own favorite.

Ask: "given a pile of tickets at the beginning of the sprint, describe your workflow from here"

Key points to listen for here:

  • Do the devs estimate the tickets?
  • Do you keep track of velocity?
  • What happens when your estimates come to more than your velocity?
  • What happens when your estimates come to more than your velocity when you have a deadline? (Watch for spin here: do they reduce complexity, or reprioritize, or just deathmarch the development team?)

None of these are deal breakers by themselves, but if their answers to enough of these questions make you wonder, then maybe they're interested in agile rituals, not actual agile development.

Not the answer you're looking for? Browse other questions tagged or ask your own question.