Talk:Team Practices Group/Health check survey

Open questions

 * Where should data be stored - in a simple spreadsheet?
 * Talk to analytics about this [Arthur]
 * How will we generate and publish visualizations of the data?
 * What do we need to do to automate this process?
 * Are there impediments to or strong reasons against making the data publicly visible?
 * Do we do this with every engineering team at the WMF from the beginning?
 * If so, should the TPG have responsibility/accountability for teams we don’t work closely with (eg through either scrummastering or via structured workshops)?
 * Also, I think any set of survey questions should apply to TPG itself: e.g. can TPG say of its "product" that "Releasing is simple, safe, painless & mostly automated"?  Cmcmahon(WMF) (talk) 21:17, 12 August 2014 (UTC)
 * Should this intersect at all with annual performance reviews and if so how?
 * Should we translate the crappy -> awesome scale into numerical values for quantitative measure (eg crappy = 1, awesome = 3 or is it better to use larger numbers/logarithmic/etc)?
 * Talk to analytics [Arthur]

A few thoughts and suggestions
Firstly, I think this is a great start. I like that you're trying to cover the range of topics from very process-oriented to the human side.

Here are a few suggestions based on experience conducting similar kinds of surveys:


 * the 3 point scale is appealing in terms of its simplicity but I suggest a 5 point scale. The additional nuance is useful because one of the objectives of this kind of survey is to spot trends early and then to scrutinize and intervene, if necessary.  Having midpoints between "awesome" and "meh" and between "meh" and "crappy" helps spot those trends early.
 * +1 Manybubbles (talk) 17:54, 12 August 2014 (UTC)


 * I've previously always framed the questions as "On a scale of 1-5 (5 being highest), how strongly do you agree with the following statements". It's good to have a mix of statements formulated in terms of strong agreement being good and strong agreement being bad (to avoid various cognitive biases).
 * +1 on the "how strongly do you agree" language. -1 on switching whether agreement is good or bad.  That tends to frustrate me while taking the survey. Manybubbles (talk) 17:54, 12 August 2014 (UTC)


 * I suggest doing this monthly rather than just quarterly - again, it's about spotting trends before it's too late.


 * I suggest some additional questions on the human side. e.g. (again, statements rated in terms of the degree of agreement):
 * "I feel challenged in my work currently"
 * "I am experiencing discord with one or more of my team members"
 * "My coworkers are acting in a way consistent with Wikimedia values and culture"
 * "Overall, morale on my team is good"
 * "I am frustrated currently"
 * "We have enough people to do what is expected"
 * "I feel proud to work on this project"
 * Why not stick these questions in the table? Manybubbles (talk) 17:54, 12 August 2014 (UTC)


 * Some of these questions are funky to ask about the team as a whole. The open source citizenry one, for example, would get odd answers.  We're active and welcomed with some upstreams and unwelcome with others.  Might make sense to ask the question in terms of min and max for all the projects we deal with.  Like "For the open source project for which we're the best citizens we're actually good citizens." and "For the open source project for which we're the worst citizens we're still good citizens." Manybubbles (talk) 17:54, 12 August 2014 (UTC)


 * Thank you both for the feedback. Your perspectives on the 5-point scale are really useful. I agree with Manybubbles that some of the additional questions posed do not make as much sense in a whole-team context. The idea is that this survey will be given to a team as a whole, and a facilitator will guide the team through coming to consensus on how the whole team feels about each focus area. There are a number of reasons for this, the biggest of which I think is that this helps the team gain a shared understanding of how they are doing, which would otherwise be lost if this were an individualized survey. That said, feel free to add focus areas you think would be useful to the table on the main article :) As for the frequency, I agree that it's important to identify trends as early as possible. However I'm not sure we'd be able to support doing the survey monthly as we (the Team Practices Group) is currently staffed - particularly across all of engineering. Also, this will introduce additional meeting overhead for teams - many (if not all) of which are wary of additional meetings and feel like they already deal with too many of them. Quarterly feels like a nice compromise to me, particularly to start. If teams find this exercise useful and express a desire to do the survey more frequently, we should then figure out how to support that. Arthur Richards (talk) 20:53, 15 August 2014 (UTC)

Release Planning (as a focus area)
I think this should be a focus area for teams too. It takes some maturity to have a backlog pointed out and a subset of stories prioritized and slotted into future sprints in order to declare a release date for a major update to a product. Teams could measure their effectiveness at delivering major releases by measuring [actual/expected number of sprints], [actual/expected number of points] and/or [actual/expected number of features]. KLeduc (WMF) (talk) 17:02, 12 August 2014 (UTC)
 * Kevin feel free to stick this into the table :) Arthur Richards (talk) 20:28, 15 August 2014 (UTC)
 * Any such criterion should take into account different teams' deliberate choices in how they do planning and how agile they are. This may even vary for the same team quarter-to-quarter.  For example, we're currently in a more agile mode, iterating based on A/B experiments, but we're considering going in depth on a feature (which would be the kind of thing we likely might plan more up front). Superm401 - Talk 22:04, 18 August 2014 (UTC)

Link to Spotify survey
Can some wonderful helpful person link to the Spotify survey? Manybubbles (talk) 18:05, 12 August 2014 (UTC)
 * Unfortunately not - at least not yet. The folks at Spotify are going to be publishing information about their survey and how they do all of this at some point in the near future; we'll have to wait til then to link to it publicly. Arthur Richards (talk) 20:30, 15 August 2014 (UTC)

Feedback
I don't know how much control teams have over "Easy to release". Mostly my team relies on the standard WMF-wide release procedure (which admittedly, should be more automated, but that's not a focus of our team). An alternative one we're currently working on is having more automated testing, and in general strengthening our continuous integration (this is a sub-point of "Tech quality (code base health)".

The "User/customers" criterion should be rewritten to reflect that we're writing both for people we want to become editors (and users) and people who already are. If we write solely for our existing users, that will not encourage growth. Suggestion:
 * Good: We have a solid grasp on who our current editors and readers are, and how we can reach out to potential new ones. We understand what their needs are, what obstacles they face, and what motivates them.  When we don't know, we conduct research to find out.  We build features that encourage and satisfy them.
 * Bad: We don't know who our editors and readers are, or how we might encourage new ones. We don't know what they need, what obstacles are in their way, or what might motivate them.  Instead of finding out scientifically, we guess.  We have no idea if what we build is encouraging or satisfying anyone.


 * --Superm401 - Talk 22:36, 18 August 2014 (UTC)