Shift-left benefits for mobile app development is not just a tool problem

Although Waldo is a pretty new company, we’ve consistently shipped product updates every week while maintaining a reasonable workload and respectable hours. We credit much – if not all – of this to our product process.
Like any process, it took a small investment of time to sit down and write out, but the ROI (time saved and clear expectations established) has been incredible. Fortunately, we were able to draw from the experience our team has working with fast-moving tech startups and adapt those experiences to fit Waldo.
The result was a wiki page outlining our product and launch process that lives in Github, which we’ve pretty much copy and pasted below with some context. We’ve covered in past articles how we live and die by Github. If it’s not on Github, it doesn’t exist, as you’ll find below.
Keep in mind, this is the product process that works for us. Yours will likely look a bit different, as no two products and no two teams are exactly alike. That said, we hope ours can provide you with inspiration or at least a starting point if you’re feeling stuck in developing or streamlining a process that keeps your team focused and your product pipeline on schedule.
Before we dive into what our process is, it’s important to share why we have one. Our goal is to involve the entire team in the shipping process, ensuring everyone has ownership and agrees with the company strategy. Everyone on the team should know what they need to do and what the rest of the team is working on. This creates transparency and helps us develop realistic timelines for each project.
There can never be too many Github issues or too many questions. We value open communication, as you’ll find throughout the rest of this article. Now onward to our actual process.
Every quarter, the product team plans the new roadmap together. Then they open it up for discussion with the rest of the team so everyone feels good and confident about what’s to come.
Every week, the team reviews what’s been achieved and decides whether and how we stick to the original plan or if the roadmap needs to be changed.
The roadmap is also shared with our investors because again, transparency is crucial for healthy work relationships.
“Done is something that happened.”
Ryan Singer, Head of Strategy at Basecamp
For planning’s sake, we start our week on Wednesday and end on Tuesday. Here’s our logic:
Here’s what our weekly flow generally looks like:
Tuesday: Each member of the team presents what has been done in the past week and what will be done during the coming sprint in our Daily Sync calls.
Wednesday:
Thursday: Thursdays are meetings free day. We want every member of the team to focus on their tasks and nothing else.
Friday: Friday at 10:30 am is the “Lock Plan meeting” detailed below.
Monday: Resume whatever tasks you were working on last week for Tuesday’s release.
Every Friday, we go over our backlog and prioritize the entire team’s task list (which live as issues in Github) together. We start this meeting by looking at our roadmap objectives, then zoom in from the bigger picture.
This helps us remember why tasks need to be done and how they impact our overall progress. It’s during our 1:1 meetings that each team member decides exactly what they’re working on that work, what the roadblocks are – if any – and what support is needed.
Above is an example of what our general sprint board looks like in Zenhub. We go over the issues, close the ones that became irrelevant, review the ones that should be done next, make sure they’re properly specced out, establish the link of dependency between different issues, and assign to one (and only one) person.
Everything we do is trackable with issues on Github, accessible via Zenhub. An issue is done once there’s no more work to do on them. Here’s what done looks like:
These are defined in our product process wiki page.
A Github issue should always have one and only one assignee. We have default assignees for each area: tech, product, and content. Each of these assignees is responsible to triage and assign issues to other people. They’re the overseers of these areas of the product process.
The same issue should not be used for the design and the implementation phase of a sprint. This is probably what causes the most confusion.
Let’s consider an issue about a new feature, i.e. a GithHub integration for Waldo.
The result is a parent (Epic) issue for “Github integration” with two sub-issues(specs) to support it.
A feature implementation issue cannot be added in This Week until the corresponding Product Spec issue is marked as done. The Epic is only closed once all the issues inside are done.
The only interruptions we can add to the section of our sprint board labeled “This Week” are for bugs or customer support issues.
There should be three kinds of priorities for such:
This means nothing else should ever modify the list of what’s in This Week or Week + 1.
At Waldo, it’s important that each team member truly owns their area of work. Of course, we collaborate and help each other, but we believe there should be one driver for each scope of work.
That’s why we each manage our own weekly changelog in Github, then share it with the rest of the team. That way, everyone has a clear picture of what we’ve accomplished and what we’re working on.
Have questions about why we do things this way? Leave a comment below and I’d be happy to elaborate!