[teampractices] Towards more holistic product/feature development

[Diederik van Liere]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20130923/fb4cf863/attachment.html>