I am very interested in what were the problems encountered in the previous organization and how the adjustment have been conducted (one go or iteratively? Top down, or with self organized? etc).

onboarding process for volunteers, not sure what that means, but it is a good teaser and definitely gets me interested in this session.

In T234652#5552320, @hashar wrote:

onboarding process for volunteers, not sure what that means, but it is a good teaser and definitely gets me interested in this session.

It indeeds sounds like a good ad teaser. The person who suggested this part of the topic meant looking into whether/how the WMDE onboarding process for new developers could possibly be applied/extended/etc for volunteer developers. To be clear: WMDE has not done this and we have no onboarding process for volunteer devs.

@WMDE-leszek - Thanks for the feedback. I've updated the session description accordingly.

@RazShuty - Would you be interested in leading this session?

@WMDE-leszek or @Bmueller - Haven't heard from @RazShuty. Do you know if anyone else at WMDE might be interested in presenting on this topic?

added @Franziska_Heine as a lead, per discussion off-phabricator

(Programming note)

This session was accepted and will be scheduled.

Notes to the session leader

• Please continue to scope this session and post the session's goals and main questions into the task description.
  • If your topic is too big for one session, work with your Program Committee contact to break it down even further.
  • Session descriptions need to be completely finalized by November 1, 2019.
• Please build your session collaboratively!
  • You should consider breakout groups with report-backs, using posters / post-its to visualize thoughts and themes, or any other collaborative meeting method you like.
  • If you need to have any large group discussions they must be planned out, specific, and focused.
  • A brief summary of your session format will need to go in the associated Phabricator task.
  • Some ideas from the old WMF Team Practices Group.
• If you have any pre-session suggested reading or any specific ideas that you would like your attendees to think about in advance of your session, please state that explicitly in your session’s task.
  • Please put this at the top of your Phabricator task under the label “Pre-reading for all Participants.”

Notes to those interested in attending this session

(or those wanting to engage before the event because they are not attending)

• If the session leader is asking for feedback, please engage!
• Please do any pre-session reading that the leader would like you to do.

I could use some more information in order to decide whether to attend this session. Such as what were the issues and motivation for change? Which things improved? Which things maybe regressed? Is it about technical issues (code quality, productivity) (as I would assume in techconf) or something else?

Please, find the slides on Wikimedia Commons under the Category "Wikimedia Technical Conference 2019, day 2" here

@debt notes are done =)

In T234652#5662068, @darthmon_wmde wrote:

@debt notes are done =)

sweet! :)

Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019

Session Name / Topic
Learning how WMDE improved their organizational structure
Session Leader: Franziska; Facilitator: Brooke; Scribe: Will, Chris
https://phabricator.wikimedia.org/T234652

Session Attendees
Timo, Will, Rachel, Antoine, TPT, Cormac, Erika, Grant, Franziska, Mónica, Tobi

Notes:

• Introduction
• Franziska: Hello, folks from WMDE will be talking about their experiences in how improving their organizational structure improved their productivity. It's not so much about producing more - code, features, etc - but providing more value to the users. Giving folks what they are asking for and building something they will use.
• Mónica - Engineering manager of the Wikidata engineering team.
• Let's travel two years back in time, to discover why the journey model came to be and what role the product discovery approach has to do with it
• Franziska: Go back to September 2017 - I joined WMDE - Community communications team (Birgit) and the only engineering manager we had, Tobi
• We had 17 other people besides those team leads reporting to me. Variety - engineers, product people, designers, etc. I'm a product person, not an engineer. The people were not really happy with the current situation. It was clear we needed to change something.
• 3 projects in 2017:
  • Wikidata
  • Technical wishes
  • Fundraising
• We had different processes - Kanban (FUN/QWERTY) and not really defined process (Wikidata). They just stopped using a process.
• Productivity was so low
  • Q: how can you measure if no process?
    • A: They were working on stuff, but nothing reached the end user. A prototype was made, but not delivered. Weighed on people.
• No process in place to monitor quality
• People working on Wikidata were specifically unhappy
  • no manager
  • no working process
  • unclear why features were prioritized and others not
  • many knowledge silos
  • We had people who were not able to work with each other
• How could we get to a happier place?
  • Started slow and carefully
    • added manager to the FUN team, added a level of team domain leads that could talk about issues on their teams that could cross teams that were not individual.
    • daily estimation meetings, etc, led to the journey model
• Today - Six team leads
  • More manageable team sizes
  • we started shipping again for Wikidata
  • people started seeing actual results
  • better support for employees like regular 1:1 and team meetings
  • regular feedback cycles
  • we hired in a way that allowed us to expand the team with people that brought in outside expertise
    • we had good WM knowledge, but not people who came from other areas and other perspectives to bring them into the department. It was not always easy and not a given it would turn out smoothly, but added invaluable insights and people.
• Mónica: The Journey Model
  • Problems to solve
    • complicated structure to our roadmap: sometimes 3 different projects, sometimes 1
    • no room for sharing knowledge
    • no time to modernize and to try new things
    • no time to concentrate on infrastructure or technical issues and technical improvements
  • Goals
    • remain flexible: we need to be able to allocate the right amount of people to every project, knowing that project sizes differ from each other and number of projects to take on is always different.
    • make room for technical issues/improvements
    • gain focus and minimize context switching
      • focus on features or issues from beginning to end in order to get stuff done
    • enable knowledge sharing
  • Our Solution
    • Journey model - hiking and camping metaphor
      • Agile - Scrum + Kanban
      • Hikes
        • features will come from product. Go on a scrum basis with two week sprints, dailies, retros, etc.
      • Trailblazers
        • to tackle issues, improvements, technical debt, refactoring. Didn't have room for this in the previous lack of processes.
      • Campsite
        • Maintenance, bug fixing
      • Whole team rotates [diagram explaining how]
        • When product has a feature to be done, there is a presentation happening, where the team is formed. They figuratively leave campsite, focus on feature, come back to campsite. The same process happens for trailblazers: when there is capacity and a pressing issue to tackle, it is presented to the team and the team is formed. They figuratively leave the campsite to focus on that issue and then come back.
  • What it solves
    • more dynamic and flexible
    • Fits our roadmap and technical needs
      • projects done, technical issues get the attention needed, maintenance work never stops
    • Knowledge sharing - regular presentations from hikes/trailblazers to the rest of the dev team
      • discuss challenges encountered
      • investigations made
      • design and architectural decision made
      • existing and/or recurrent issues
    • Navigators summit
      • reps from hikes and trailblazers meet once a week to share and discuss technical and software design decisions
      • 20% of hikers to be spend in campsite (maintenance) only reviewing
        • to prevent folks on hikes to lose track on what is happening in the maintenance team they review what happens
    • after hikes, at least one member goes to campsite in case bugs appear
      • that person can let others know - non participants of the hike/trailblazer - deal with them and assist
  • Results
    • Wikidata tem has shipped:
      • Termbox
      • Senses
      • Shape Expressions
      • Wb-terms
      • Improvement in RL Module use
  • Challenges - that we still have
    • Team forming takes time, slow start in projects
    • Hikes that start without clear goals, paths will be doomed to fail
    • Lots of pressure on the product work, since the team is focusing on several projects at a time (on several hikes), and they need product manager to deliver what they need
    • The more hikes/trailblazers we have the more complicated it gets to EM [Engineering Managers] to track what's going on
  • Q: are teams fixed?
    • A: no. Folks get pulled from campsite and they go back to campsite after hikes or trailblazers finish.
  • Q: How do you know it works? If you're changing teams all the time...
    • A: The teams are not that large - in total 14 engineers now. You can sometimes choose who you work with. You know most people. They all belong to the same team and end up working with each other in one or other hike or trailblazer.
  • Q: I really like this picture and hiking. How do you transform this to the actual work of a developer? What does it mean to be on a hike or be a trailblazer?
    • A: A hike is a feature that comes from PM. They want to build a feature. They come to us and present. The hike is building this feature. It's a product.
  • Q: When a team gets lost (to continue the metaphor) how do you think about where teams get off track or behind schedule?
    • A: That is an issue the EM - as the Scrum Manager - and PM must catch up on. Why is it happening? Tech difficulties? New coding to learn? Conflicts in the team?
    • A: What they do when they start a hike/trailblaze - they have a start and end date. Not set in stone. Depending on how well something has been prepared, it's hard to judge how much time you are going to take on the hike. That's the flexibility build in - not everyone is working, just a few people. You can grow the size if needed or be fine with it taking more time.
  • Q: how do the EM break up the campsite?
    • A: just one campsite, multiple journeys
  • Q: How do you handle a big feature?
    • A: We try to split features to be implemental in an incremental way. We have a maximum time limit: a quarter. We don't want to have a feature team for over a quarter. If, for whatever reason a feature is taking longer than that, we can dissolve the team and take on a new team. We can also, if the capacity of the team allows it, add more engineers to the feature team.
  • Q: can you conceptualize the campsite as where a team is at by default?
    • A: Yes.
  • Q: when you start a hike you say there are people that move from the campsite to the hike. Are they moving physically as well in the office? To go work with the PM in a different space?
    • A: They are not all in the office space. There are two rooms. It does happen when needed or when engineers ask for it.
    • Followup: Valve (video game company in Seattle) follow something similar by physically moving to where they will be working with the PM.
  • Q: What is the role of the EM in that?
    • A: We manage personal and professional growth and interests. on top of that we operate as scrum masters of the hikes and trailblazers - duties are split between teams.
  • Q: are you all in the same timezone?
    • A: yes and all in the same office! A few remote, but only a timezone away
  • Q: how do you balance between remote folks and folks in the office?
    • A: pretty easy. Not much timezone switching, freedom to work from where ever. That depends on the people. Some folks like it, but some want to be in the office.
    • Followup: Your remote people are integrated socially
    • A: yes, most of them are. they participate in all the regular meetings (daily, retros, bonfire,...). We make sure that they come to the office at least once a quarter. Also: we are pretty lucky with our remote people they are awesome and make it work like a charm.
    • A: We have some working students that are remote and it is a bit more difficult with them since they spend less time with us and being remote makes that harder to manage.
  • [showing spreadsheet of campsite and journey model data]
    • Current situation in camp - availability in camp
    • current running journeys
      • each journey has a tab (in the spreadsheet that was referenced earlier (on screen))
        • helps with sprint planning
  • Q: do you ever have problems with rotations? Do people ever get stuck in the campsite due to prolonged end dates?
    • A: No, we try not to. If that does happen we'll dissolve the team and get a new team. Maximum length of a hike is a quarter (3 months). Trailblazers are for a month and a half or two months. If the issue needs more time we make it into smaller packages to be taken care of separately.
  • Q: Do you handle your technical spikes in this system? How would you handle really big unknown project?
    • A: What do you mean by a big unknown project?
      • Clarify: a new feature in a code base you're not familiar with.
        • A: we spent one or two sprints - when needed - as a technical discovery sprint - engineers research to understand the issue and the technical difficulties and to gain some knowledge about it, together with the product manager, so they get aligned on what they are talking about from both the product and technical perspective.
  • Q: How do you do QA?
    • A: We don't have QA dept. We try to do TDD (Test Driven Development), Unit tests with a high coverage, all is estimated within the same project
• Product Discovery
  • All the features we have released are big. Some have taken more time because of new territory. And still we managed to release them in the end.
  • This journey model puts a lot of pressure on product, multiple teams, one product person can not manage. No matter how great discovery we need more product people.
  • It's great to build and ship a lot, but if it's not the right stuff you're not really successful
  • Product discovery
    • before we get to product development, we know enough about a problem, develop a solution, and generate development as successfully as possible.
  • Who does what during Discovery?
    • PM fills out template where possible
    • Review results and decide on direction with discovery team
    • participate in research activities to understand user needs
    • UX Designer
      • propose research methods and drive user reports
    • developers
      • A lot of devs come from community and they can facilitate conversations (both to and from community)
  • One important thing at the end is a celebration.
    • We (previously) did things silently, without acknowledgement of our accomplishments.
    • We talk about what we released
    • did we have feedback from community
    • did it make them happy
    • how many bug fixes
    • how many story points
    • have some closure on the thing (with our party hats on)
• Q&A:
  • Q: When you are onboarding new folks, how intuitive is this?
    • A: It sounds more complicated than it is. Checking the documentation, having a couple of talks about it and checking how it works in real life and hoy the dynamics are - this is obviously easy, since we all work in the same office - will do.
  • Q: The number of releases were raised from 0 to 6. How much did other metrics improve to have a good feeling of the team?
    • A: How do you measure happiness? :) This took us two years. They were tough years. During the process change the teams were not happy. If you talk to them today the likelihood of most of them being happy is high.
  • Q: These are for bigger things (campsite and hikes). How do you then approach technical debt? Do you take a quarter to do something like this or along the way?
    • A: tech debt is often handled as trailblazing. There is for now three engineers that do a trailblazer exploration. All the tasks that are suspicious to have an underlying technical issue land on their board. They investigate and sync with them every couple of week with EM. This looks like a bug - goes to campsite. This is big but not in our hands or impact low - leave for later. Do in an incremental way so the impact is large - performance, need, developer productivity etc. this on we'll tackle and turn into a trailblazer.
  • Q: You're now the CTO of the WMF. What do you think here scales and what doesn't?
    • A: You already have a structure. You can use that. Start small. Take the blocks you have and see what make sense. It might not be the solution to all productivity challenges. You might not need the whole structure but only chunks of it.
    • A: this makes not much sense for really small teams.
  • Q: Is there space for people outside the WMDE to observe the process? Can this work for remote folks?
    • A: Let's talk about this offline [out of time]
  • Q: Does this solve your interpersonal problems?
    • A: since the feature team is a smaller portion it's easer to get someone out of the hike and de-escalate.

https://somehowimanage.blog/2018/06/26/the-journey-model/

Thank you for the session!

The terms used for the journey model were a bit confusing to me at first, but after acquiring some vocabulary related to hiking, it all made sense.

The most important thing I have learned is that Wikidata-Campsite is not a parking lot / endless backlog but meas a task is under the responsibility of a maintenance team :-]