[teampractices] Towards more holistic product/feature development

[Bryan Davis]

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.

> 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.

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.

> 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?

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