The Scroll Engineering team is small. We fit in a small three room row house and mostly run on a startup-ish culture. By this I mean that while we enjoy our own flexible work timings, we do prefer seeing each other other in person, having face to face meetings, playing a match or two of table tennis, celebrating birthdays and so on. This is how it's been for over five years until The Pandemic (Yes, I'm referring to none other than the COVID-19 pandemic) brought about some unprecedented challenges for us.
We never really needed many tools to organise Engineering project work. We use Slack, Trello, Quire etc. with mostly a simple setup.

But this all changed with the Janata curfew being imposed followed by lockdown orders starting late March this year. The need to maintain channels of communication and better organisation practices just exploded.

So here is a quick peek of what we use to manage our projects and communication.

Quire

Quire is our main tasks and bug tracking tool. In past we used Trello with a reasonable rate of success. Over time, we realised that the structure was more suitable for tracking project iterations rather than task management and bug resolution. This is what the Trello board structure looked like:

What worked for us:
- It was easy to measure how much was achieved in an iteration.
- Anyone could look at the Trello board and understand what the team was working on and what had been achieved over a certain period.

It has certain drawbacks though:
- A good amount of time was spent on planning on the first day of every new iteration. I was usually tasked with this activity. :(
- New new sprints would often copy the last sprint's leftovers.
- Task hierarchy was difficult to achieve unless you had nested cards, but this was not very intuitive.
So we moved to Quire. I am a big fan of outliners. <3 . The simplicity and ease to organise complex projects made it very appealing.

Here is what our task board looks like now:

What's left to do: Non-tech folks in the company always wonder why things don't seem to be moving when their tech requirements were discussed centuries ago. We're still figuring out how to fine tune our Quire task board for iterations, but that's a post 1.0 challenge.

Slack

We started off by using gitter.im and loved it. But with cross functional teams in the organisation we found Slack to be more suitable for communication. Since most of the team works remotely, members are encouraged to be online during working hours and respond to communication in a reasonable timeframe.

We also need to keep in mind that messages are lost after some point on the free plan that we use. This prompts us to keep our communication relevant and succinct.

Channels we use:
#tech-whatamiworkingon: As it might be evident from the name, we use this channel to inform team members what each person is currently working on. This helps get an idea of what tasks are being handled.
#tech-dev: We use this channel mostly for technical discussions. We use threads a lot to keep noise levels low.
#tech: This channel is used by non-Tech team members to contact us on slack.
#tech-stack-quality: A relatively new channel, we use this one to discuss Build quality.
#tech-notifications: This channel houses all PRs and notifications from other services.

Dropbox Paper

For knowledge management, we had started with a git repository "knowledge" on bitbucket. We used the wiki which was powered by RestructuredText. It worked well for us for a long time, but it was difficult for cross functional teams to contribute. A team member suggested Dropbox paper as an alternative and we've been using it ever since. It's easy to use thanks to markdown style binding.

Aside usual documentation, we use Dropbox paper quite a lot for long checklist oriented plans and template building.

Templates are really helpful when we need to run repetitive tests on a new build and log quality test results. For example, prior to every new build we release, beta test results are recorded to a document based on a template we created. These templates are modifiable as required to accommodate for new tests as the product grows.

I have covered quite a bit. Will offer more insights soon...
Till then 🤗
- Shekhar