I'm a product person. keep that in mind.
In tech you hear this repeated frequently, mostly because of the difficulty we all have in balancing people and their needs, creativity, and stress levels with an organizaitonal process and its timelines, requirements, and information flows.
My own teams at DramaFever suffer occasional malaise due to the processes we employ, which are themselves in place to compensate for us having two very culturally different offices. It's a constant struggle to bring people together without making anyone feel like a cog in a machine rather than a fully functional adult developer.
So, I spend a lot of time finding ways to ameliorate the situation. We use Google Hangouts to video chat. We aren't an Agile shop but I try to check in daily with everyone, even if just to say hello. I organize my features first by writing business requirements, then by asking developers and designers for their own requirements, then writing loose functional specs to collect final, pre-development buy-in.
But things could always be better. And, having hired some new mobile devs recently, I saw an opportunity to improve things further by clarifying why we care about our teams. Here's what I came up with to be used as part of our onboarding docs for these new mobile devs:
When we decide what's happening in the next few versions of the app, everyone who will touch the project is in the meeting. Product will come ready with requirements and a Project Manager will facilitate the meeting, but everyone is heard and everyone should strive to achieve buy-in from the other team members when suggesting a change. We do this to get on the same page up front and to avoid having more meetings during active development.
Milestones are flexible
We use Github milestones to organize features and issues. Milestones collect issues and have a date of potential release attached to them. This release date is flexible and a suggestion based on the amount of work contained within that milestone. Work doesn't get rushed to meet a milestone. Milestones flex in date or issue count to accommodate the pace of development.
We anchor milestones with large features
Whether it's new stuff or bug fix releases, milestones should encompass one big idea. This big idea gets split into many tickets, and sometimes has unrelated tasks thrown in by necessity. A milestone should not be a bucket for product backlog features.
Milestones can become releases
A milestone should have enough code change to warrant a release. However, a milestone does not have to become a release. It should be modular enough to allow us to add to a bigger release or even to push it off for later should we need to.
Release Candidates have change logs
When we're ready to test a new build, whether it's intermediate or a true RC, a change log is needed to keep everyone sane. Generally that just means marking tasks as "retest", but all parties should know exactly what and how to test the new features or fixes going into a build.
Acceptance testing, that is. If you have a feature going in, make sure you're part of the testing effort. We want our app to work. We also want it to work the way you intended it to work. Consider this pre-release dogfooding.
Everyone gives feedback
At any point in the release cycle you should feel free to give me (Product), Design, Development, or anyone in between whatever feedback you feel is necessary. Don't wait. Because we should all have buy-in at this point, we all expect things to work and function as discussed. If you expect things to work differently, speak up. We don't bite.
Everyone gets credit
We're a team. We do a lot of awesome work. We all deserve recognition when things go well. And, when things don't go well, we learn from our mistakes. When a project reaches public release, everyone gets mentioned. If issues arise, we tackle them as a team. If your view performs well, all your teammates get the credit with you, and if your view has some mistakes in it, we all scramble to fix it with you.