[teampractices] Experimentation time within the Mobile Department

Tomasz Finc tfinc at wikimedia.org
Tue Sep 17 22:32:22 UTC 2013


I've had a number of people ask me to explain how experimentation time
works within the Mobile Web and App teams so instead of just another
verbal discussion I thought I should practice what I preach and put it
into a searchable and archivable space here on the team practices
list.

At its basic level, experimentation time is a vehicle for engineers to
have time boxed unstructured work that will benefit the team and
department.

The mobile web team has been practicing it for about 2 years now and
its been responsible for features like echo on mobile, editing on
mobile, bingle/bugello, and many more. It has always been distinct
from the foundations 20% for community contributions and when that
program was active we did both.

Practically its *one* day per iteration that is chosen by the engineer
to use as they wish. No one oversees how this day is used, the work is
not in any project tracker, and it is not a vehicle for
managers/external stakeholders to *sneak* in work. Typically it may be
work that is months away that an engineer is interested in or it might
be a new idea that came from a community member.

Ultimately its up to the engineer to decide what will benefit the team most.

We asses the work monthly at our showcase where engineers demo what
they've been doing with their experimentation time. It is up to the
group to say 'yay' you should do more or 'nay' this wont be that
useful. Instead of the product manager or director approving/denying
work its the collective that deems it useful or not. This
decentralizes the decision making model and lets it scale easily.

It's important to know that regardless of wether time is carved out or
not, our talented engineering will find development work that wont be
in our backlog. This is excellent and we should encourage this kind of
empowerment to constantly bring in new innovation from every angle.
Once a day is allocated then its very easy for the engineer to time
box his/her work and not feel guilt for trying something new and
risky. If it ends up not working out then its simply two days a month
for us and low risk.

I see this as a critical tool for a safe to fail experimentation environment.

Do any other departments practice this ?

--tomasz



More information about the teampractices mailing list