Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, GlenH7, jwenting, Kilian Foth Oct 6 at 11:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

14  
Um, ask them if they are a pig or a chicken? –  Robert Harvey Jan 14 '11 at 20:29
1  
@Robert Lolwut? –  Matthew Read Jan 14 '11 at 20:32
3  
@Matthew: en.wikipedia.org/wiki/The_Chicken_and_the_Pig –  Robert Harvey Jan 14 '11 at 20:33
1  
@Robert They should answer: "Blah blah Agile. Blah blah waterfall. Blah blah paradigm." –  Mark C Jan 15 '11 at 10:18

16 Answers 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.

share|improve this answer

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.

share|improve this answer
3  
+1 It's always good to find ways to interview the company. –  Jeremy Heiler Jan 14 '11 at 20:41
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 '11 at 20:58
2  
I think asking them "to defend agile methodologies" is probably not the best method of asking ;) –  Matthew Read Jan 14 '11 at 21:16
  • 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.
share|improve this answer
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. –  Berin Loritsch Jan 16 '11 at 2:46

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.

share|improve this answer

Ask them why they use it.

You will immediately know.

share|improve this answer
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. –  Aaron McIver Jan 14 '11 at 22:19
1  
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 '11 at 22:22
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. –  Martin Wickman Jan 15 '11 at 10:51
1  
Totally agree. Ask them why they even chose Agile. Solid. +1 –  Agile Scout Jan 17 '11 at 3:16

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.

share|improve this answer
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. –  cbrandolino Jan 16 '11 at 4:48
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 '11 at 13:15

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.

share|improve this answer

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.

share|improve this answer
4  
The defacto standard is 2 - 4 weeks. 1 week sprints...? Hmm...I would be suspicious. –  Aaron McIver Jan 14 '11 at 22:16
4  
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. –  Christopher Jan 15 '11 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 '11 at 22:28
1  
For your definition of release, do you mean to testing or to the client. If you say to client, that can only possibly work when you are on maintenance. Even then, I still find it best to wait until a predefined set of changes are incorporated before the client gets it. –  Berin Loritsch Jan 16 '11 at 2:39
2  
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. –  Berin Loritsch Jan 16 '11 at 12:16

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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