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 &lt;jared.zimmerman(a)wikimedia.org <mailto:jared.zimmerman@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 &lt;jared.zimmerman(a)wikimedia.org <mailto:jared.zimmerman@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 <tel:%2B1%C2%A0415%20609%204043> | : @JaredZimmerman <https://twitter.com/JaredZimmerman> On Tue, Oct 8, 2013 at 3:30 PM, Steven Walling &lt;swalling(a)wikimedia.org <mailto:swalling@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 &lt;jared.zimmerman(a)wikimedia.org <mailto:jared.zimmerman@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 mustdraw 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 <tel:%2B1%C2%A0415%20609%204043> | : @JaredZimmerman <https://twitter.com/JaredZimmerman> _______________________________________________ Wmfall mailing list Wmfall(a)lists.wikimedia.org <mailto:Wmfall@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wmfall -- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Wmfall mailing list Wmfall(a)lists.wikimedia.org <mailto:Wmfall@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wmfall _______________________________________________ Wmfall mailing list Wmfall(a)lists.wikimedia.org <mailto:Wmfall@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wmfall _______________________________________________ teampractices mailing list teampractices(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices