What project do you work on?
I work on the mobile app portion of an online radio network and its sister-networks. Networks here just meaning a different brand with a different content offering, but the same underlying system.
It's probably worth pointing out early in that we're a fully remote team, spread around the globe. I'm in the UK, several of us are in Ukraine, some in Israel, Poland, Canada, Japan, and more.
What is your role?
My job title is "Senior Mobile developer"; my focus is working on the Android applications, but I touch the iOS portion which some regularity too.
How big is the product team; What's the makeup of your team?
Some 17 strong:
1 Chief product officer, 1 director of engineering, 3 back-end devs (hiring for 1 more), 2 front-end devs (websites), 5 mobile devs (2 iOS, 2 Android, 1 team lead who does both), 2.5 quality assurance engineers (1 of them also has responsibilities in advertising operations) + hiring for a new QA team lead, 1 UI/UX Architect, 1 UX/UI Designer
What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?
For bugs coming in, usually they are reported from the customer support team. Customer support brings it up to the QA team through Slack; QA team creates a Trello card and attempts to reproduce the issue. If they can't reproduce it, generally the customer is asked for more details, given instructions to capture logs where applicable. New incoming issues are brought up during a daily meeting, and if necessary, a developer will subsequently take a look at it - not to start fixing it yet, but to help investigate. After QA determines severity of the bug (which determines fix priority), the Trello card is fleshed out further and queued up for development. If it's very urgent, a developer will drop what they're working on and fix it, otherwise it'll be queued for after higher priority work.
For minor other improvements, like something someone in management, or a member of the product team would bring up, it is pointed out in an appropriate slack channel, and stakeholders will give their input. If it's decided to make the change, either the person who initially brought it up, or the relevant dev team lead will put together a trello card and show it to the stakeholder for their thumbs-up. Then it enters the development process depending on priority. If it's some refinement that goes well with on-going work, it's likely to be slipped in with it.
At this point, the process becomes mostly the same: A developer picks up the task, writes the code and tests locally. Once they're satisfied, they open a new pull request against the main branch (using git/github), and notify relevant other devs on the trello card (and recently, using "request review" on github) that it's ready for code review. Other dev reviews the code, makes any suggestions / change requests. Implementing dev revises changeset / discusses with reviewer until they're both happy. Around this time, a testing checklist is also made up by the implementing developer, which can include any specific cases that aren't immediately obvious by the description; particularly things the developer knows where touched by the code changes.
Then, as the task is declared ready for testing, a QA engineer picks it up, and installs the build linked on the card (or uses a specific staging environment that's been set up for the changeset, if for web). They verify everything works as expected, and try to break it. ;) If issues are found, they are documented, logs/screenshots provided, and the card gets put into a "needs changes" state, where the developer can pick it back up to address things. If no issues are found, it is marked "good to go", and the developer is free to merge to git branch to the main branch, at which point the Trello card is added to a "pending release" list, where we regularly push out new releases to production.
How much (if any) paperwork/bureaucracy is there involved with releasing a new feature/bug?
I like to think, not much. Generally it's just Slack conversations that turn into Trello cards if it's a small thing. For larger features, the product manager, designers and team leads work together to document and specify all the requirements for the feature, using Confluence. On here, other members of the team also have opportunity early in to make suggestions and ask questions about specifics. Once this document is stabilised, Trello cards are derived from it and queued up, and the usual process kicks off. For larger features, individual parts may be completed and merged to a main feature branch, before making it to release.
Tell me about your process for planning work in, do you use sprints? Does it work well for your team?
We've somewhat recently started using 2-week sprints, and it works better for some part of the team than others at the moment. We've always had a kanban-ish style approach though. We currently have long-ongoing feature project, for which the 2-week sprints don't really work well, in my opinion. There's too much still going on to box parts of it into 2-week sections. I do think after it is out of the way it will start working better.
Do you plan testing upfront or chat to testers about it once the dev work is done? And do you take the testing work into consideration when planning what to bring in?
As mentioned a bit earlier, often our testing checklists are initially writing by the implementing developer. During QA there regularly is conversation between the tester and the developer, to clarify. The QA engineers have some regular things they also add to the testing, particularly the "unhappy" paths. For "Release candidate" builds they've got a well-documented series of tests that are performed to ensure all the critical parts of the application work as expected.
Amount of testing work isn't usually taken into account when planning what to bring in, except if it's a very minor looking thing that would have a disproportionate risk of new bugs attached to it.
What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?
We've built some infrastructure into the app for serving adverts. Working out the exact business logic for the conditions under which they should be served, rate limiting etc was a huge hassle. Complicated flow charts were drawn up, adjusted until stakeholder approval, and eventually implemented, with unit tests to verify everything. Later, already in production, it was revealed that still some assumptions were made; needless to say, they were wrong assumptions, and more adjustments had to be made.
Another thing is that we've had some developer unhappiness about parts of the stack we're using it. Budget restrictions meant that there are only limited options available for a process to swap that part of the stack out - we have no resources available to drop product development and do a rewrite, so some less than ideal middle group solution is being worked on.
Which (if any) tools do you help to keep track of work?
Our main work tool is Trello, where all the work is organised into cards, across several boards. These are mainly "development" (for back-end, web, and mobile teams) boards, defect triage boards, and planning boards.
Other than that, Slack, Github, Confluence, Circle CI and TeamCity for continuous integration.
You mentioned that you have cards across several boards on Trello, how do you manage this? Does it become an issue to find a card or does it work well for you?
It can be a bit tricky to find cards sometimes, particularly in cases of "I wonder if there already is a card for this issue" cases. However, for related cards around boards, we often add a "Related cards" checklist where we link to them. Manual, but it does the trick to keep things connected where relevant.