[teampractices] Towards more holistic product/feature development

Tue Sep 24 02:59:32 UTC 2013

On Mon, Sep 23, 2013 at 12:21 AM, Siebrand Mazeland (WMF) <
smazeland at wikimedia.org> wrote:

> Hey Diederik,
>
> I think a lot of what you describe can be covered by a Definition of
> Done[1]: "Definition of Done is a simple list of activities (writing code,
> coding comments, unit testing, integration testing, release notes, design
> documents, etc.) that add verifiable/demonstrable value to the product.
> Focusing on value-added steps allows the team to focus on what must be
> completed in order to build software while eliminating wasteful activities
> that only complicate software development efforts." See the blog post for
> all kinds of details, ifs and buts.
>
Hey Siebrand,

I am not entirely sure if Definition of Done is the best place to address
non-functional requirements. 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.

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?

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

> Aside from these recurring requirements that are applied to deliverables
> for stories before they can be Done or "Ready for Signoff", you can have
> additional acceptance criteria in stories, the ones you call non-functional
> criteria, that may contribute to reducing technical debt.
>
> The Language Engineering team has documented its DoD at
> https://www.mediawiki.org/wiki/Language_portal/Definition_of_Done
>
> [1]
> http://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-%28dod%29
>
> Cheers!
>
> Siebrand
>
>
> On Mon, Sep 23, 2013 at 6:28 AM, Diederik van Liere <
> dvanliere at wikimedia.org> wrote:
>
>> Heya,
>>
>> Some recent discussions on different internal mailing lists seem to
>> indicate to me that we need to think about a more holistic approach to our
>> product development. In my mind, the following discussion threads point all
>> in the same direction:
>> 1) Faidon -- Site issues, past two weeks & in progress (Ops list)
>> 2) Erik -- Scrum of Scrums (Team practises list)
>> 3) Tomasz - The Rule of Three (Team practises list)
>>
>> One of the challenges that we face as we are adopting the scrum
>> methodology is how we cope with 'non-functional requirements' [0]. Within
>> the scrum methodology there is not a clear advocate for these
>> non-functional requirements. I do not think that we have found yet a
>> systematic solution for this problem. We are obviously not operating at a
>> startup-scale so we must take non-functional requirements into
>> consideration from the inception of a new feature/product.
>>
>> One of the mistakes that the Analytics team made last year is that we
>> focused too much on non-functional requirements and not enough on
>> functional requirements. I think we are striking now a much better balance
>> between these two set of requirements. In the area of non-functional
>> requirements, the Analytics team has made two changes to how it's using the
>> scrum methodology:
>> 1) We treat non-functional requirements as functional requirements and
>> have the customer sign it off. For example, with our recent collaboration
>> with Ops on developing varnishkafka we explicitly defined minimum
>> performance in terms of processing speed of messages per second.
>> 2) At the epic [1] level, we define both 'business value' (why does the
>> customer care about this feature) and 'platform capability' (how does this
>> epic contributes to building out our total offering of solutions and we do
>> not accrue technical debt along the way). This forces us to consider
>> non-functional requirements from the get-go.
>>
>> I can imagine that in the near-future, we will have to consider more
>> non-functional requirements besides (for example) scalability and security.
>> The following three come to mind (and sometimes we are already considering
>> them on an individual product basis and this list will evolve):
>> 1) Mobile -- all products / features will work on mobile from the very
>> first beta launch
>> 2) Measurability -- measuring the efficacy of the feature and how to
>> instrument it
>> 3) Privacy by Design -- what data is stored and how can the person whose
>> data we store manage this data
>>
>> How to manage these non-functional requirements is an open question.
>> Scrum subscribes to the view that the architecture is emergent but I am not
>> convinced that is going to work well for us. I think we need a more
>> holistic approach to discuss such requirements -- maybe we should treat
>> Ops, Platform, Mobile and Analytics as the 'customers' for such
>> non-functional requirements. It's not 100% scrum but then again scrum
>> always emphasizes communication over process ;)
>>
>> Curious to hear what other folks are thinking about this!
>>
>> Best,
>>
>> D
>>
>> [0] BTW, I believe that non-functional requirements are a misnomer; I
>> think that architectural requirement would be a better term.
>> [1] The Analytics team defines an epic as a high level function that
>> consists of either conceptually related user stories (End-to-End monitoring
>> for different products) or a complex new feature 'Cohort Management' for
>> Wikimetrics.
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
>
> --
> Siebrand Mazeland
> Product Manager Language Engineering
> Wikimedia Foundation
>
> M: +31 6 50 69 1239
> Skype: siebrand
>
> Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> 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/20130923/948d333b/attachment-0001.html>