Today is my last day at Artsy, and I feel compelled to write about something that's important to me. I worked on several different teams while at Artsy, and I've had the opportunity to lead several teams, but none will be as special as Mobile Experience. The Mobile Experience team was the first team I started, where I got to help define the culture and our definitions of success, from day one.
The team started small, only myself and two other engineers, with part-time support from Design, Product, and Data. But we scaled to a full product team and accomplished some seriously awesome work.
Eventually, we wrote our own team working agreement, which is like a distillation of how the team works. It's meant to orient new team members as the join, or rotate through. The team working agreement was a product of the team, not just the lead, and I'm super-proud of it.
When I announced I was leaving, I wrote the following:
My biggest contribution at Artsy has been to install a culture where every person feels empowered, entitled, and encouraged to take ownership of that culture. To shape it, to grow it, to protect it.
The Mobile Experience team working agreement is a reflection of that culture. I'm proud to share this artefact of my time at Artsy with you below. It is a special document, to me. (Please note that the team working agreement contained many links that are internal to Artsy, which I have removed.)
Mobile Experience Team Working Agreement
Becoming a team involves a commitment to working together and supporting each other in our common goals. This commitment is supported by writing what all team members believe are important protocols for the team to comply with to maximize their capabilities to deliver faster and with higher quality.
How we Work
-
We make User Experience paramount
While tools are important, they are not as important as an excellent user experience. We aim for a best-in-class mobile app. Our product development process integrates user feedback, research, and metrics. We are guided by data but we aren't slowed by it.
-
We provide support to other product teams while also building our own features
Artsy is building more mobile software than any one team can accomplish. Other product teams look to us for help to build their own new features for the mobile app. This means that we pair with engineers, respond to questions from colleagues, and provide feedback on both code and design. We work with other teams to help them test and deploy their work.
-
We take ownership of Artsy's mobile infrastructure
Mobile Experience sets the vision for what mobile software at Artsy should look like, and sets standards for how that software gets built. We rely on tooling and process automation to the extent that it helps us do our jobs, never loosing sight of the fact that our team is made of human beings.
-
We solve problems by sharing knowledge
Mobile software at Artsy is complex, and none of us have built this exact product before. In order to build a great product, we focus on learning to build it rather than building it directly. This creates an environment where questions are welcomed, risks are celebrated, mistakes are learned from, and what we learn is as important as what we build. Knowledge sharing on our team encourages deep learning, to find out how something works rather than just verifying that it works.
-
We embrace a reciprocal relationship with open source
It is better to use a tool that someone else has built (and maybe improve upon it) rather than invent our own new tool. Similarly, we release our code to the open source community so that it might help others, and so that they might improve upon it in turn.
Our relationship with open source is mutually beneficial: we benefit from the work of others, and we help others by sharing what we have learned.
-
We empower every team member to make the team better
Sprint responsibilities (grooming, planning, retro, QA, release) are shared. No one individual is a bottleneck for the team to be productive. Feedback is solicited and treated as a gift.
-
We use process to help us, not slow us down
Product decisions are documented in Notion and Jira. We involve all team members early in the product development process so that everyone can contribute to the final product.
Sprint Routine
-
App release are done every two weeks
We integrate this two week cadence into how we plan our sprints:
- Presubmission: focus on user-facing improvements that will be submitted to App Store Review at the beginning of the second week.
- Postsubmission: use this time for longer-term improvements, projects that take longer than a week, etc.
-
Standup happens every day
It takes less than ten minutes. Someone starts and then nominates another person in turn, discussing:
- What have we done since the last standup?
- What do we plan to do before the next standup?
- Do we have any blockers?
Finally, we look at the board and review sprint goals as a team.
-
Sprint planning happens the Monday that sprints start
In sprint planning, we estimate groomed tickets and then discuss goals. Tickets are estimated based on their complexity (and not the time we think it will take to complete them). We use one of the following story point values:
- 1: Trivial tasks, where the approach is well-known.
- 2: More complicated tasks, but still without much uncertainty.
- 3: Complex tasks with lots of moving pieces, and there is some uncertainty.
We use a "planning poker" approach where we all estimate individually and share our estimates at the same time. When we disagree, we discuss as a way to learn more about the ticket.
-
Sprint grooming is every week
Two engineers look through the "To Groom" backlog and make sure every ticket has enough detail to be estimated and worked on. We might ask questions or break the ticket down into smaller pieces.
-
Knowledge Share meetings happen every Tuesday and Thursday
This is an open forum; it is a recurring, structured unstructured meeting. We discuss anything that has been learned recently, future plans, progress against quarterly goals, etc. Non-engineering topics are discussed at the beginning of the meeting. Ideas for future meetings are kept here.
-
Everyone gets an upkeep day per sprint
These upkeep days are to work on upkeep tasks. We get flexibility on what we work on, in exchange for making sure our tasks are in the backlog somewhere so everyone knows what we're working on. When individuals do their upkeep day is totally up to them!