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.

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 HarveyJan 14 '11 at 20:29

16 Answers
16

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.

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.
–
ChristopherJan 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.
–
user2567Jan 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 LoritschJan 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 LoritschJan 16 '11 at 12: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.

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 McIverJan 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".
–
user2567Jan 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 WickmanJan 15 '11 at 10:51

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.

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)

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.

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.

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.

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.

"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.
–
cbrandolinoJan 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.
–
gbjbaanbAug 3 '11 at 13:15

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.

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 LoritschJan 16 '11 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.