<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 24, 2013 at 10:39 AM, Bryan Davis <span dir="ltr"><<a href="mailto:bd808@wikimedia.org" target="_blank">bd808@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 class="im">On Mon, Sep 23, 2013 at 8:59 PM, Diederik van Liere<br>
<<a href="mailto:dvanliere@wikimedia.org">dvanliere@wikimedia.org</a>> wrote:<br>
> As you know, DoD's are always team-specific:<br>
> they reflect the consensus of the team and are tailored to the team's<br>
> individual needs. Because DoD's are team-specific I worry that each team<br>
> would have to learn the hard way the importance of (a set of) non-functional<br>
> requirements.<br>
<br>
</div>It is quite possible and reasonable for the organization to set a<br>
minimum bar for DoD that all teams must follow. Each team is free to<br>
add to this common DoD as their process and proficiency expands.<br>
<div class="im"><br></div></blockquote><div>Agree but I am not aware that this has happened in a concerted effort. </div><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 class="im">
> Second, as mentioned in my original email, neither the customer nor the<br>
> scrum team can/will/should do user acceptance testing for the non-functional<br>
> requirements. So even when those non-functional requirements are part of the<br>
> DoD, who is going to verify that?<br>
<br>
</div>In a multi-team environment some of these sorts of concerns can be<br>
addressed by practice groups and review boards.<br>
<br>
A practice group is a cross-team collection of individuals who are<br>
specialized or inclined to a particular role within each scrum team.<br>
QA, UI/UX and Operations are common practice groups in larger scrum<br>
shops {{Citation needed}}. Members of a practice group communicate<br>
issues and learnings across teams to lift the standard for their<br>
speciality across the organization.<br></blockquote><div>I believe that Steven's recent posts about Spotify and Yammer illustrate such practice groups. See for example Scaling Agile at Spotify @ <a href="https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf">https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf</a> </div>
<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">
<br>
A review board is similar to a practice group in that they provide<br>
consistent advice and oversight across team boundaries. They differ in<br>
that a review board is a consultant to the scrum team rather than a<br>
resource for a practitioner. A common review board would be an<br>
architecture board {{Citation needed}}. One way to use a review board<br>
is to add a story/stories related to an epic that call for design<br>
artifacts to be created for a larger arc of work. The review board can<br>
then evaluate these designs and provide feedback to the team. Review<br>
boards can also be used as consultants to the Product Owner to help<br>
evaluate requirements and alignment of backlog with larger<br>
organizational goals.<br></blockquote><div>The Analytics Team has had a number of such review boards lead by Ops people.</div><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 class="im"><br>
> Third, I do not think that all teams have all the competencies when it comes<br>
> to assess non-functional requirements for their specific situation. I love<br>
> that scrum places a lot of emphasis on growing a team but in our (=WMF) case<br>
> that can be quite costly learning curve if certain non-functional<br>
> requirements are not considered from the beginning (scalability, security,<br>
> etc).<br>
<br>
</div>Personally I would say that if the teams don't have embedded experts<br>
or tightly coupled consultants with direct domain knowledge of the<br>
various "non-functional" requirements they aren't really scrum teams.<br>
How can the team produce a potentially releasable increment during<br>
their iteration if there are technical/operational issues that aren't<br>
being managed by the team?<br></blockquote><div>Fair point but I do think that this the current state of WMF. We are pivoting from a purely engineering-driven organization to a (largely) product-driven organization -- it's only in February 2012 that we started a formal Product department. So currently we are partly organized in functional teams 'Security', 'Ops', 'Search', 'Platform' and partly organized along Features and not all teams will have the required competencies within their team. This obviously creates interdependencies between teams and we haven't quite yet figured out how to manage those efficiently (IMHO).</div>
<div><br></div><div>D</div><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">
<span class=""><font color="#888888"><br>
Bryan<br>
--<br>
Bryan Davis Wikimedia Foundation <<a href="mailto:bd808@wikimedia.org">bd808@wikimedia.org</a>><br>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID<br>
irc: bd808 v:<a href="tel:415.839.6885%20x6855" value="+14158396885">415.839.6885 x6855</a><br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
</div></div></blockquote></div><br></div></div>