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.

Possible Duplicate:
Weeding out real agile from buzzword agile in an interview

I went for an interview. The company really wants to take me on. However my sticking point is that I have not received clear information on whether they are using Agile and Scrum methodologies.

I have arranged a telephone chat with the consultant there... what questions do I ask to test to see if they are really serious about agile and scrum?

I was thinking:

  • Can you build and release your software in one step?
  • Do you use continuous integration?

Can anybody give me advice to really get the truth out of them I will only get this one chance to quiz them.

Regards, Pete

share|improve this question

marked as duplicate by Robert Harvey, Jarrod Roberson, Mark Trapp Sep 1 '11 at 16:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4  
You would refuse to work for a company that didn't slavishly practice scrum? You don't sound like a very flexible person; I've worked with people before who are dogmatic like this in some way, and it's not a pleasant experience. –  Robert Harvey Sep 1 '11 at 14:39
3  
Shouldn't the focus be more on how they have interpreted Agile and Scrum? It isn't like there is a big book of Scrum rules that clearly define every aspect of the how the methodology is to be militantly implemented. –  JB King Sep 1 '11 at 14:42
5  
@Robert, God forbid somebody actually wants a chance to work on potentially successful projects that meet the customers needs. Granted there are a few business models that Waterfall works well for but it is best to view those as exception cases. –  maple_shaft Sep 1 '11 at 15:16
5  
@Robert, unwavering devotion to dogma aside, teams can claim to do Agile and do nothing of the sort. If you get into such a situation, it can be frustrating, because everything is flawed from the outset. (I'm in such a spot now.) –  Anthony Pegram Sep 1 '11 at 15:24
4  
More @Robert, the idea is that if you're interested in Agile, and they say they're doing Agile, find out exactly how much of it they're actually doing, that's all. If they're deviating, allow them to explain why. If the explanation is satisfactory, go with it. On the other hand, it could reveal exactly what you said in your original comment, that they're also too rigid (even arrogant) in their own ways and not open to change, or it could mean the team simply isn't experienced enough, or it could mean something else entirely, but perhaps it just means you continue your job search elsewhere. –  Anthony Pegram Sep 1 '11 at 15:33

6 Answers 6

up vote 9 down vote accepted

I'd consider these questions for the Scrum side:

  • How long are your sprints?
  • How long are your planning meetings, demos, and retrospectives?
  • Who is the Scrum Master and Product Owner? How big is the team?
  • How big is the back log?
  • How many sprints has the team done? How many projects have been completed using Scrum?
  • What is the team's velocity for a sprint?

On the Agile side, I'd probably take a step back though to ask:

  • Of the practices you use, which do you consider to be part of Agile? (Pair programming, XP, TDD, Prototyping would be some examples here.)
  • How do these practices fit with the Agile Manifesto?
  • How has your company defined Agile? Is it just the manifesto or is there more to it than that?

The key is to find those questions that aren't a yes/no question where someone could just give an answer they feel sounds right but rather trying to dig deeper into things.

share|improve this answer
    
Hi Jb, this answer is really helpful nice and concise and just gets me right to where I want to be! Cheers! –  Pete2k Sep 1 '11 at 16:45
  • Who moderates/leads the scrum?
  • How large is the development team, and how are the teams divided?
  • Does the team adhere to the standard 2 week sprint format?

Just a few questions I could think of ...based on the topics I discussed with a company I have recently interviewed with. The scrum lead is a software architect in this case; the team is very large but broken up into smaller teams with specific focus based on the projects; it was explicitly expressed that the team, by and large, adheres to the 2 week sprint format.

Also, you can get a feel for the company's dedication to Agile by how many people interviewed you. In my case, I had 5 different people conduct 45 minute interviews. This is done to determine which team I might best fit ...in which team I might provide some missing experience, etc. This particular point is not a given ...but it also gave me the opportunity to ask each individual about their Agile format.

share|improve this answer

One thing is for certain, every company I accepted a position at that told me during the interview that told me something to the effect of "we are TRYING to move to Agile" turned out to be a hot mess and grotesquely mismanaged. If you get a similar answer then I would turn around and RUN.

It is a good idea to ask them about their build and deployment practices and CI as well. Don't pay attention so much to WHAT they say, but HOW they say it. If you notice nervousness, agitation, incredulousness, or fear then those are huge warning signs as well.

For instance, look for signs of unusual perspiration, swift fluttering eyes, swallowing (movement of the adams apple, etc...). If they give you an answer and their eyes shift to the left while they talk that can be a sign of deceit or information witholding. If they look to the right or up or directly into your eyes then they are probably being truthful.

I know it sounds insane but a friend of mine in the Secret Service taught me to notice a lot of these things when interviewing people. I have been lied to more times than I can count on interviews and I am certain that I avoided some pretty bad places by employing these techniques.

share|improve this answer
1  
I can attest directly to this. Teams can claim to do Agile and actually do nothing of the sort (I'm a contractor on such a team now). It's frustrating and, at least in my case, it's accompanied by flawed concepts and implementations of a great number of things. –  Anthony Pegram Sep 1 '11 at 15:22

Don't start with asking questions. Let the consultant first explain in detail how they work, what roles do they have, what are responsibilities of roles, how is product planned, shipped etc. Then ask complementary questions based on the consultant explanation.

If you need to help with exact questions you don't need to ask at all. If you want to judge if Scrum / Agile approach in other company is good enough you should be able to define these questions yourselves. If you are not able how can you know that answer is correct?

If you really want to test the consultant you can even ask "wrong" questions so that he must oppose you to prove that they are going agile. But be aware that this can really goes against you and they can loose interest in you.

share|improve this answer

I would go with open-ended questions rather than yes/no questions. It's like when they interview you. They wouldn't ask, "Are you a hard worker?" or "Are you smart?" or "Can you deliver?" They would ask you to illustrate how you embody those qualities.

So rather than your sample questions, I would ask the consultant to describe their build process and release process, for example.

Also, I'm inclined to think there is no One Way to do things, so asking open questions gives them an opportunity to describe their processes rather than see if they pass the Scrum Test. Then you can judge whether it's something you can work with rather than whether they've checked all the scrum boxes.

share|improve this answer

Just ask someone to explain their development process.

  • Do they actually have a process and not just some popular label the slapped onto their haphazard practices.
  • Can they fluently and precisly explain it? This is what they do all day for a living so they should know it in detail. The whole team should be in the know. It's an indication of having a process and actually implementing it. This is not the time to start off with, "It depends..."
  • Can they give you some background about this adoption process and how it fits their needs? How does it work for them and why?
  • What do they hate about it the most and do they feel they can fix the problem? You want to sell me something, tell me what your customers hate the most. I don't want to just see the good side of the beef.
  • How do they keep track of everything? Code, bugs, documentation, workload, communications, etc.

This is better than someone who claims to follow Scrum until death, but does it poorly. Know how they use it because, "If you've seen one implementation of agile development, you've seen one implementation of agile development."

share|improve this answer
    
+1 very nice. It much better explains what I tired to mention in the first part of my answer. –  Ladislav Mrnka Sep 1 '11 at 15:45

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