Asking about internal notes about Scrum process during an interview

Question

I'll have an interview with a company which uses Scrum. During the interview, I was hoping to ask for notes from their last sprint retrospective (if they record it)?

In my current company we write the notes to an intranet site and it says a lot about the company (what developers love and hate about the last few weeks).

My question is first, whether asking for information during an interview which may contain confidential information is a good idea, and if so, how I should present such a request?

Answer 1

Monica's answer addresses the point about understanding what may be confidential and how to ask, but I'd like to suggest that you can get useful information without asking to see a document that may or may not even exist, let along dealing with its possible confidential status.

You indicate that one of the reasons for wanting to see this information is because in your experience the artifact of the sprint retrospective can show "what developers love and hate about the last few weeks". But could you not also simply ask in the interview for a summary of some of the common/frequent things that the development team wants to a) stop doing, b) start doing, or c) continue doing well?

For me as a hiring manager, a question of that type (rather than just "can I see your retrospective artifacts") would indicate to me that you respect potentially confidential internal information (again, Monica's answer also describes a way to do that), understand the typical goals of a sprint retrospective, and are comfortable having a conversation to elicit and discuss information rather than reading and interpreting something on your own. That last one might not be meaningful to you or them, but it's something that I value and I don't think I'm that weird: being able to ask for information and have an ongoing dynamic/organic conversation about it rather than just reading something and saying "ok, thanks" or whatever.

Another reason for asking for a summary or interpretation of common retrospective outcomes rather than an artifact is because not all groups produce artifacts. On my teams, our public artifacts are extremely minimal if present at all, and we most certainly don't record them, because typically these are the "safe spaces" where the team talks about issues meaningful to them, sorts them out, and has to assume that they're in a "circle of trust" in order to be open and bring about change. If we recorded them or took detailed notes, then it would be just another public activity, and I've found that not to be the best approach -- but again, that's me and my teams, and everyone is different.

In other words, as a hiring manager I would balk at the request to see internal documents or raw data, but if the question were phrased appropriately I would be happy to discuss in general ways anything that would be helpful for a candidate to judge the company and the team. So, I would recommend thinking about the information you're trying to elicit and how you might do in the typical course of an interview (especially during the important "Do you have any questions for us?" time).

Answer 2

Interviewing is bi-directional, so it is appropriate to ask questions about their technology, processes, culture, and whatever else would affect your decision.

That said, the material you're asking to see is probably confidential, so you should expect to sign a non-disclosure agreement (NDA). In asking the question you should demonstrate that you understand this point. I've used the following formulation: "Could you show me X? I understand that that's sensitive and would be happy to sign an NDA first." In the interview leading to my current position I asked to see APIs (since I would be helping to build an SDK), and I asked some pretty deep questions about their architecture (I wanted to judge how technically sound it seemed to be). This was in the context of a small, informal software company and they didn't even ask for the NDA, but we've since been acquired by a large company and I still field those kinds of questions when I'm doing the interviews. No one has asked to see an artifact yet, but we do discuss design and process in some detail.

Answer 3

Where I work I do not think it would be a big deal to ask to see a recent retrospective report. It would provide you with some information but little that would compromise the team if it got out. I am sure there are companies that would have more reservations though. If you are at an all day interview I would tell the first person you talk to this is a document you would like to see and talk with the team about.

The biggest problem I see is that the interviewer is unlikely to have the document with them at the interview. I would simply ask what areas were identified as the biggest need to improve going forward, and what experiments they have taken on and why. This question by itself should tell you a lot of what you want to know. You also might ask what strengths were identified. Sometimes having the important things be good can override concerns about the areas that need improvement. If you have multiple interviews with different people this question can be asked over and over allowing you to see where each part of the team thinks the focus should be.

Answer 4

If I'm the interviewer I consider any question fair game -- maybe I can or will not answer, but it's okay.

This particular question could apply to my previous workplace. I'd answer it with the truth, that we don't create notes on retro, just talk and it is enough. (If a discussion results in creating some task it might be entered or anyone is welcome to make personal notes but I guess that is not your aim.)

If we had notes I don't know whether I'd show them. I would guess it would be unlikely but we could talk about how retro goes, etc.

If I were in your place I'd not state the question that way. Instead ask about the execution of Scrum, about retro events, problems, resolutions, whatever. This was sounds way more sensible.

Answer 5

It seems to me like you are more interested in their processes. You should want to know how they implement Scrum. Instead of needing to see actual documenation, at the risk of calling them a liar, just ask if they do it at all. Maybe they have a form or some training information on how it should be done and could show you that.

This is the same problem if asking to see production code. If they have a boiler plate NDA that covers these things, they may make them available to you. You can also ask about the processes that lead to quaility code: reviews, tests, format standards, etc. without actually having to see if.

If it gets to the point you don't trust how they're doing things or they haven't indicated they expect someone to come in and clean up the mess, I don't think you need to see actual examples of the gory details.