How to tell if an Agile team is doing it right

Question

I just applied for a job doing Agile development. I've never done it before, though I'm aware of the basics. I'm otherwise well-qualified, and they didn't even mention Agile experience in the requirements, so I'm likely to get an interview. I'm afraid that they are doing it all wrong - not "Agile development" but instead "too overworked and stressed to bother doing it right so being sloppy and pretending".

What questions should I ask in the interview?

Edit: One of my red flags was that they say that they work 40 - 60 hours depending on the project. Another was that it's a team of 16 people, which seems too large to be agile in any sense of the word, and another was that they said they hold daily scrums remotely "when needed".

Answer 1

How about "who are the chickens and who are the pigs?" :) Try to understand if they truly understand what agile is all about. Do they indeed value individuals, working software and collaboration or are they hiding waterfall in small iterations and calling it agile?

But remember, the in-person interview is about getting an offer. Once you get an offer, you can decide if you want to accept it or not. So, I would not go in with the attitude of trying to prove to yourself that they "are doing it wrong." I would go in with the attitude of asking questions to show that you are excited about the contribution you can make.

GL!

Answer 2

What type of Agile are they doing? If they're doing Scrum, you might try asking questions like how long each sprint is, what time the daily scrum meetings are, how large the backlog is, etc.

In general; you might ask how the OTHER members of the team like the Agile process. This is a little bit sneaky, but it used the fact that most people are more easily able to lie about their OWN state of mind than they are about others'. Not that they won't prevaricate and say that the other members of the team love it, but it'll be easier to tell if they're just making it up if you ask about how everybody else likes it rather than if you ask how your interviewer(s) like it. Just a thought.

Answer 3

Bear in mind that Agile is a loose term for loose development methodologies (that tend toward developing in iterations). In other words, as long as you have some sort of organisation to your development process, then you're "doing Agile". Obviously, you can abuse it by, basically, not following any of the guidelines you've set up, but you can ignore any other development methodology too!

If you're worried they are developing in an ad-hoc fashion I'd ask to see some of their quality documents, or any documents proving that they develop in iterations. I suppose splitting the project into phases is ok, because Agile does mean different things to different teams. Alastair Cockburn said about Crystal Clear -

Crystal is non-jealous, meaning that a Crystal methodology permits substitution of similar elements from other methodologies.

Though I recall a different quote that said "take as much as you want, and see what works for you and your team" (sorry, can't find link to that, it was many years ago).

So ask them which agile methodology inspired them, and what changes they have made to it. If they can't think of any, or say "we use X", then start to ask why they didn't change any of it -after all, no methodology is perfect for every team.

Answer 4

Also check if the leader of the team or the push takes each programmers progress seriously. Many teams try to do Agile but are usually Fire and Forget (in regards to planning and the standing meetings)

Answer 5

I would ask what flavor of Agile they are using, or based on (there are many, XP, Scrum, etc.). Then pick the least likely/most business commitment difficult ones and ask if they do it, and if not, why not.

In XP, some of the difficult ones would be test driven development (with developers writing their own tests), never working more than 40 hours a week two weeks in a row and paired programming.

Although it is normal to not do all of them if they aren't doing the hard parts, they are just cheating and will get burned using the easy parts. Sometimes people say they use XP to mean they don't bother documenting or making significant specs.

Answer 6

"Agile" covers some things that are difficult to pull off in a traditional office and require real dedication from management and the coders, and some things that are very easy to pull off with no real positive change to the way things are done (or get done).

Hard but useful practices include are pair programming or test driven development. Easy methods that don't necessarily help include piles of meetings and firing the guy who writes the spec.

Answer 7

I'd ask to look at

• some example unit tests
• a live run of their unit test suite
• their pairing stations, preferably in use

In a great Agile shop, I'd expect to see beautiful, easy-to-follow, well-named unit tests, a quick green run, and active, chatty, development at comfortable workstations.

In a lousy Agile shop (or a non-Agile shop), I'd expect them to be shy about showing their tests ('cause they're ugly or nonexistent); bad coverage, redbar, slow; and no pairing stations, or no pairing happening at them.

Answer 8

Here is my short list:

• Ask them to explain more what they mean by Agile, does that include Scrum, XP, and other practices?
• Do they have a "Card Wall"?
• How is developer work assigned and tracked?
• If possible try to get to talk to both a manager and a developer there so that you get different perspectives on things.
• Try to get them to describe a typical developer day and how are projects and developers matched.
• Do they have Iteration Planning Meetings, Retrospectives, Demos?

Edit: Note that most of these are around process rather than what tools are used, e.g. what bug tracker, what time tracker, what unit test framework, what version control, etc. The tools are another part which I think are covered well by other responses.

Answer 9

My favorite metric is How often are developers switching pairs This tells you many things about the team/project , if they have no problem switching pairs every few hours

1. Code is well written with lot of unit tests
2. Developers are working on building minimal thing that works instead of a gradiose dream of an architect.
3. Team is well bonded , sharing common goal, everyone understands every story.
4. All the developers are working on all the code ( collective code ownership ).
5. Management most is most likely committed to being agile , otherwise they wont allow the ridiculous looking ( on the surface ) practice of pair switching .

Answer 10

Ask when they last released a product to the customer. Ask to watch a daily standup/huddle.