<div dir="ltr">Spinning off a thread here... <br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 3, 2015 at 10:16 AM, Kristen Lans <span dir="ltr"><<a href="mailto:klans@wikimedia.org" target="_blank">klans@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I'm thinking about working with a team on formulating their values in the near future, so I'm curious to know if there was a particularly useful way that you were able to come up with yours?</div></div></blockquote><div><br></div><div>Expressing a team's values or an organization's values is trickier than it might seem.  You can think of it as marketing, if that's useful. You're taking knowledge that is mostly tacit [1] shared among insiders, and projecting a simplified version of that knowledge for outsiders to consider.  A great model is the Agile Manifesto [2].</div><div><br></div><div>I don't think there is any one way to do this, but I do have a few guidelines to suggest. </div><div><br></div><div>* Put people first. Don't talk about roles and interfaces and handoffs (at least at first). Talk about the actual people involved and what they actually do and when they actually do it, and (very important) why they do it. Much follows from this. </div><div><br></div><div>* Tell a story, with a beginning and a middle and an end. You may frame that story as a sequence of events, or as a set of relationships, or a list of principles, but tell a story that makes sense to an audience. </div><div><br></div><div>* Talk about your values within your team. The Health Check for the Release Engineering team was pretty good, and I think a big factor in that is that we do in fact talk about values in our team meetings on a fairly regular basis: stuff like "This change will help developers", "This will make deployments more reliable", "This is an improvement for Team X".  </div><div><br></div><div>[1] <a href="http://en.wikipedia.org/wiki/Tacit_knowledge">http://en.wikipedia.org/wiki/Tacit_knowledge</a></div><div>[2] <a href="http://www.agilemanifesto.org/">http://www.agilemanifesto.org/</a></div><div><br></div><div>PS A lot of people conflate Quality Assurance with software testing. In fact, many software testers object strongly to being labeled QA. But I've always embraced QA, which is process work and methodology work. The origin of the term comes from manufacturing (unfortunately) where Quality Control is testing, the business of measuring the output to check that it conforms to specifications, where Quality Assurance is designing processes that ensure that the product is of sufficiently high quality. </div></div></div></div>