Weeding out real agile from buzzword agile in an interview [closed]

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

Ask them why they use it.

You will immediately know.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

• 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.

Answer 14

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.

Answer 15

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.

Answer 16

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.