[teampractices] [Wmfall] Roles and Processes for WMF Design

Tue Oct 8 22:57:13 UTC 2013

CC'ing team practices list for broad awareness

And for those that are looking for other teams process/definition there is
a nifty category that has all of it

https://www.mediawiki.org/wiki/Category:Wikimedia_Foundation_teams_internals

On Tue, Oct 8, 2013 at 3:55 PM, Jared Zimmerman <
jared.zimmerman at wikimedia.org> wrote:

> *Thomas*, looks great, I'll start
> https://www.mediawiki.org/wiki/Design/Team this week.
>
> *Arthur*, Yes, please work this out with your Primary designer
> specifically. In your case Kaity. The reason we're attempting to have all
> designers on the same schedule for Focus & Explore is so they can work and
> brainstorm together if they prefer.
>
> *
> *
> *
> *
> *Jared Zimmerman * \\  Director of User Experience \\ Wikimedia
> Foundation
> M : +1 415 609 4043 |   :  @JaredZimmerman<https://twitter.com/JaredZimmerman>
>
>
>
> On Tue, Oct 8, 2013 at 3:50 PM, Jared Zimmerman <
> jared.zimmerman at wikimedia.org> wrote:
>
>> Yes, *Steven*, do you have a specific place you'd recommend it go on
>> office wiki, I'd be happy to post it there. As far as the audience, the
>> design group has many "clients" within the organization and I didn't want
>> to accidentally omit any. As with any other thread that isn't relevant to
>> you Gmail's mute feature<https://support.google.com/mail/answer/47787?hl=en>is great.
>>
>> Correct, *Arthur* while gmail excels in muting, it fails in search and
>> replacing. Flare = secondary
>>
>> *
>> *
>> *
>> *
>> *Jared Zimmerman * \\  Director of User Experience \\ Wikimedia
>> Foundation
>> M : +1 415 609 4043 |   :  @JaredZimmerman<https://twitter.com/JaredZimmerman>
>>
>>
>>
>> On Tue, Oct 8, 2013 at 3:30 PM, Steven Walling <swalling at wikimedia.org>wrote:
>>
>>> Can we put this in a document somewhere, like Office Wiki, instead of
>>> via wmfall email?
>>>
>>> I am not sure this email was relevant to all 150 staff including HR,
>>> finance, and others who almost never work with designers.
>>>
>>>
>>> On Tue, Oct 8, 2013 at 3:14 PM, Jared Zimmerman <
>>> jared.zimmerman at wikimedia.org> wrote:
>>>
>>>> Meetings are the mind killer. But collaboration can set us free.
>>>>
>>>> I've been thinking a lot lately about how Design works in tech, what
>>>> works well and what is broken. How Design can use Agile methodologies to
>>>> its advantage, and how the proliferation of meetings in agile can be a
>>>> serious detriment to the creative process.
>>>>
>>>> I'm rolling out a few changes to the way Design will work with the
>>>> teams and functional groups at the foundation.
>>>>
>>>>
>>>>  New Roles : Primaries & Secondaries
>>>>
>>>> Each focus area will be assigned a Primary and a Secondary from Design,
>>>> these are the designers who will be your primary contact for a project or
>>>> feature area.
>>>>
>>>> Primary— Invite the Primary to your standups and all meetings where
>>>> design should have a presence. They will attempt to attend as many meetings
>>>> that are relevant to design as possible. Invite Primaries to any project
>>>> specific reviews and planning meetings, they will speak for design in these
>>>> meeting. If they don't know the answer, they will find out. Primaries  are
>>>> responsible for working with PMs to define realistic schedules based on
>>>> their own availability and that of the designers that will support them.
>>>>
>>>> Secondary— Secondaries support Primaries when it comes to making the
>>>> work happen. While each group will have one official Flare, they may not be
>>>> the only design support on a given feature. You should invite them to
>>>> meetings where entire engineering teams are present. When a meeting needs
>>>> to happen ASAP look to the Primary first, if they are not available the
>>>> Secondary can represent design in their absence.
>>>>
>>>>
>>>> Focus, Explore, and Collaborate
>>>>
>>>> Sometime designer work best when they are juggling 10 projects at once,
>>>> sometimes they work best when they can focus on a single task with no
>>>> interruptions.
>>>>
>>>> Going forward the designers will block off one day of their calendar
>>>> every week for Focus, and one for Explore. The remaining days will be for
>>>> scheduled work and collaboration.
>>>>
>>>> Ideally we would have every designer have the same schedule for
>>>> Explore, Focus, and Collaborate but this might not be possible due to
>>>> individual and project team schedules. Designers will block out Focus and
>>>> Explore on their calendars so externally it will be obvious which days are
>>>> reserved.
>>>>
>>>> Focus
>>>>
>>>> In order to give their full attention to a design problem without
>>>> having to context switch between meetings, Focus is a day without
>>>> structured meetings. During Focus, designer may be in the office or they
>>>> may be working from home, or a park, or a cafe, or in the office. Please do
>>>> not schedule meetings with designers during Focus, or expect them to attend
>>>> standups or other recurring meetings on this day.
>>>>
>>>> Explore
>>>>
>>>> During Explore designers can explore areas that they aren't assigned
>>>> to, focus on projects that are important to them, and devote time
>>>> researching new project that could shape the future of the Foundation and
>>>> its projects. Please do not schedule meetings with designers during
>>>> Explore, or expect them to attend standups or other recurring meetings on
>>>> this day. Monthly the design team will host a 1 hour brown bag "Explore
>>>> Wikimedia Design" that is open to the Foundation to attend, to showcase
>>>> what designers have spent their Explore days focusing on as well as
>>>> increase visibility for other projects that they are working on.
>>>>
>>>> Collaborate
>>>>
>>>> Mostly the same fun times you're used to, schedule meetings, write on
>>>> whiteboards, have working sessions, etc. desk time doing design work.
>>>>
>>>> What does this mean to me as…
>>>>
>>>> an Engineer?  You should still feel free to bring designers into your
>>>> discussions and brainstorms, approach them with your projects, and
>>>> questions. In lieu of scheduling meetings with designers on Explore days,
>>>> simply walk over (or ping on IM) and see if they are available to talk.
>>>>
>>>> a Product Manager?  When you're planning small meetings and projects
>>>> make sure to invite your Spark, when planning larger meetings (quarterly
>>>> kickoffs, roadmap planning) invite both your Primary and Flare, communicate
>>>> project needs and timelines directly with your Spark.
>>>>
>>>> Everyone else? Come to Explore Wikimedia Design brownbag to get
>>>> inspired, and understand what the Design team is working on.
>>>>
>>>>
>>>> Feature Areas and Project
>>>>
>>>> Key:
>>>>
>>>> Design area
>>>>
>>>> Primary
>>>>
>>>> Secondary
>>>>
>>>> Analytics tools
>>>>
>>>> Pau
>>>>
>>>> Kaity
>>>>
>>>> Core Features
>>>>
>>>> May
>>>>
>>>> Brandon
>>>>
>>>> Growth
>>>>
>>>> Pau
>>>>
>>>> Vibha
>>>>
>>>> Language Eng.
>>>>
>>>> Pau
>>>>
>>>> Kaity
>>>>
>>>> Mobile
>>>>
>>>> Kaity
>>>>
>>>> Vibha
>>>>
>>>> Multimedia
>>>>
>>>> Vibha
>>>>
>>>> Pau
>>>>
>>>> Platform
>>>>
>>>> May
>>>>
>>>> Kaity
>>>>
>>>> Visual Editor
>>>>
>>>> Vibha
>>>>
>>>> Kaity
>>>>
>>>> Global Profiles
>>>>
>>>> Brandon
>>>>
>>>> Vibha
>>>>
>>>> Affiliations/Groups/Campaigns
>>>>
>>>> Brandon
>>>>
>>>> Kaity
>>>>
>>>>
>>>>
>>>> Questions & Answers
>>>>
>>>> Q: What if my team or project isn't mentioned?
>>>>
>>>> A: Try as I might I can't always be aware of every project that’s
>>>> going at all times, if I've missed your project or feature please get in
>>>> touch with me and I will make sure I do my best to make sure we provide
>>>> design coverage for you.
>>>>
>>>>
>>>> Q: How will you handle new designers being added to the team?
>>>>
>>>> A: As you can see above, even with the Design team growing many
>>>> members are doing double duty as both Primary and Secondary on for multiple
>>>> projects, as new designers are added to the team we will load balance as
>>>> needed. Mostly likely new designers will join a project as a Secondary to
>>>> get up to speed before being assigned to a new project or iteration of an
>>>> existing one.
>>>>
>>>>
>>>> Q: Does this mean I'll have the same designer(s) for the length of a
>>>> projects?
>>>>
>>>> A: This is the goal, especially for the Spark, however as projects and
>>>> resources change the Secondary assigned to a project may change if they are
>>>> needed as a Primary on another Project, and vice versa.
>>>>
>>>>
>>>> Q: What is the analogy between agile terms and Primaries and flares
>>>> (for instance, is a Primary a scrummaster? a design tech lead? and a flare
>>>> an engineer?)
>>>>
>>>> A: I had to do a lot of thinking about those roles and how they fit
>>>> with design, if you must draw correlations between this framework and
>>>> agile, the Primary is more like the Product Owner, In most teams both
>>>> of those agile roles are already well covered and I'm not attempting to
>>>> replace them. The Primary may also not be the one doing the most work on a
>>>> feature area, but they are the main point of contact for other
>>>> stakeholders.
>>>>
>>>>
>>>> Q: Will Primaries sit with their teams?
>>>>
>>>> A: Maybe, this is up to the individual designers, I'm not going to
>>>> mandate it, since each designer is a Primary for multiple teams (for
>>>> now) it might end up with a lot of moving around day-to-day, also the
>>>> designers like to sit next to each other so they can bounce ideas off each
>>>> other.
>>>>
>>>>
>>>> Q: What is the schedule?
>>>>
>>>> A: Designers have blocked out on their calendars Wednesday for Focus,
>>>> and Friday for Explore, starting the week of 10/14
>>>>
>>>>
>>>> Q: When is Explore Wikimedia Design?
>>>>
>>>> A: Monthly, dates TBD.
>>>>
>>>>
>>>> Q: How will explore projects be built?
>>>>
>>>> A: In the case of Brandon and Pau, they may build their Explore
>>>> projects themselves, in the case of the other designers, the monthly
>>>> Explore Wikimedia Design brownbag share out will be a venue for developers
>>>> to see things they are interested in building during their own time/20%
>>>> time.
>>>>
>>>> All of the Explore work will be on-wiki both for feedback and for the
>>>> community to be inspired by, We can work with Quim/Sumana to see if there
>>>> is interest/availability in the community to build some of the explore
>>>> features as well.
>>>>
>>>>
>>>> Q: Is there a possible consensus/collaboration-driven way of handling
>>>> designer/team assignments in the future?
>>>>
>>>> A: I can see this happening for future projects, but right now my
>>>> focus is good coverage on projects that are already underway. I'm certainly
>>>> open to individual designer mutually agreeing to swap roles for projects as
>>>> well.
>>>>
>>>>  Q: Will weekly design critiques go back to being design only? How
>>>> will other teams hear about the decisions and discussion?
>>>>
>>>> A: Yes, Design reviews will be designers only going forward, they way
>>>> they were originally, we've tended to post the feedback/notes, on a per
>>>> project spaces, but we can also have a more general place to post these
>>>> notes as well.
>>>>
>>>>
>>>> Q: What if the days for collaborates for a team don't leave this
>>>> flexibility in the schedule (no single match point)?
>>>>
>>>> A: This new schedule may alter the team velocity, however I think it
>>>> will also increase quality and team happiness. Therefore it is in line with
>>>> the tenant of "Do less, better<http://www.markramseymedia.com/2013/09/do-less-better/>"
>>>> I'm ok with this. Are the other teams?
>>>>
>>>>
>>>> Q: How do we determine how well this arrangement is working? or "What
>>>> does success look like?"
>>>>
>>>> A: At its simplest level, success is a happier design team, where
>>>> members feel like they can think further out in the future, and develop a
>>>> creative vision with me for the future of our projects, they don't feel
>>>> that now because much of our work is reactive to all the things that feel
>>>> like they need to be done right now.
>>>>
>>>> The other major factors for success to me are a backlog full of designs
>>>> that are interesting to foundation and community engineers. A clearer
>>>> vision of the design roadmap. Elevation of the WMF as a place where great
>>>> designer and designer flourish in an open (source) environment. A clear
>>>> direction for where we want to be with design for the projects in 6 mo, a
>>>> year, 3 years.
>>>>
>>>>
>>>> Q: What does failure look like?
>>>>
>>>> A: Designer feel like they have too much work and spend explore doing
>>>> assigned projects. Designers can't time-box themselves to focus on projects
>>>> with the right balance. A lot of time is spent on Explore designs and no
>>>> one in the community or foundation wants to build them. Explore projects
>>>> don't feel like they form a cohesive vision for the future of design at WMF.
>>>>
>>>>
>>>> Q: What is the role of Primary & Secondaries when interacting with the
>>>> community?
>>>>
>>>> A: Both roles will be responsible for getting designs on-wiki, and
>>>> responding to user and team comments on-wiki this is the current process
>>>> and I believe it works well.
>>>>
>>>> Both roles will be in contact with their PM & CL to have the CL to do
>>>> community research, and outreach. I don't see this part of the process
>>>> changing much, I'm not aware of any issues with the current state of things
>>>> in this regard, let me know if there are issues I'm unaware of.
>>>>
>>>>
>>>>
>>>> Any questions don't hesitate to contact me.
>>>>
>>>> *
>>>> *
>>>> *
>>>> *
>>>> *Jared Zimmerman * \\  Director of User Experience \\ Wikimedia
>>>> Foundation
>>>> M : +1 415 609 4043 |   :  @JaredZimmerman<https://twitter.com/JaredZimmerman>
>>>>
>>>>
>>>> _______________________________________________
>>>> Wmfall mailing list
>>>> Wmfall at lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>>>
>>>>
>>>
>>>
>>> --
>>> Steven Walling,
>>> Product Manager
>>> https://wikimediafoundation.org/
>>>
>>> _______________________________________________
>>> Wmfall mailing list
>>> Wmfall at lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>>
>>>
>>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20131008/5f2bfc87/attachment-0001.html>