[teampractices] Towards more holistic product/feature development

[Diederik van Liere]

On Tue, Sep 24, 2013 at 10:39 AM, Bryan Davis <bd808 at wikimedia.org> wrote:

> On Mon, Sep 23, 2013 at 8:59 PM, Diederik van Liere
> <dvanliere at wikimedia.org> wrote:
> > As you know, DoD's are always team-specific:
> > they reflect the consensus of the team and are tailored to the team's
> > individual needs. Because DoD's are team-specific I worry that each team
> > would have to learn the hard way the importance of (a set of)
> non-functional
> > requirements.
>
> It is quite possible and reasonable for the organization to set a
> minimum bar for DoD that all teams must follow. Each team is free to
> add to this common DoD as their process and proficiency expands.
>
> Agree but I am not aware that this has happened in a concerted effort.

> > Second, as mentioned in my original email, neither the customer nor the
> > scrum team can/will/should do user acceptance testing for the
> non-functional
> > requirements. So even when those non-functional requirements are part of
> the
> > DoD, who is going to verify that?
>
> In a multi-team environment some of these sorts of concerns can be
> addressed by practice groups and review boards.
>
> A practice group is a cross-team collection of individuals who are
> specialized or inclined to a particular role within each scrum team.
> QA, UI/UX and Operations are common practice groups in larger scrum
> shops {{Citation needed}}. Members of a practice group communicate
> issues and learnings across teams to lift the standard for their
> speciality across the organization.
>
I believe that Steven's recent posts about Spotify and Yammer illustrate
such practice groups. See for example Scaling Agile at Spotify @
https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf

>
> A review board is similar to a practice group in that they provide
> consistent advice and oversight across team boundaries. They differ in
> that a review board is a consultant to the scrum team rather than a
> resource for a practitioner. A common review board would be an
> architecture board {{Citation needed}}. One way to use a review board
> is to add a story/stories related to an epic that call for design
> artifacts to be created for a larger arc of work. The review board can
> then evaluate these designs and provide feedback to the team. Review
> boards can also be used as consultants to the Product Owner to help
> evaluate requirements and alignment of backlog with larger
> organizational goals.
>
The Analytics Team has had a number of such review boards lead by Ops
people.

>
> > Third, I do not think that all teams have all the competencies when it
> comes
> > to assess non-functional requirements for their specific situation. I
> love
> > that scrum places a lot of emphasis on growing a team but in our (=WMF)
> case
> > that can be quite costly learning curve if certain non-functional
> > requirements are not considered from the beginning (scalability,
> security,
> > etc).
>
> Personally I would say that if the teams don't have embedded experts
> or tightly coupled consultants with direct domain knowledge of the
> various "non-functional" requirements they aren't really scrum teams.
> How can the team produce a potentially releasable increment during
> their iteration if there are technical/operational issues that aren't
> being managed by the team?
>
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).

D

>
> Bryan
> --
> Bryan Davis              Wikimedia Foundation    <bd808 at wikimedia.org>
> [[m:User:BDavis_(WMF)]]  Sr Software Engineer                Boise, ID
> irc: bd808                                        v:415.839.6885 x6855
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20130924/1e06a7b7/attachment.html>