First, let me be up front: Uclusion solves the problems presented here. However before we go there I will explain in detail my experience trying to use other software to lead remote developers.
Wiki + Email + Jira + Stand-ups
Before starting Uclusion, I was running a team of local and in Ukraine developers using this combination of tools. The general breakdown was like this:
Bugs in Jira
Design specifications in Wiki
Questions about implementations or requirements in email
Status tracking in stand-ups
… And that was just our group communication tools.
It deserves mentioning that almost any Wiki has a full commenting system and you would think the discussion could just live there and avoid email. Unfortunately a full specification is not a great place to hold a decision about a particular aspect of the project.
As might be expected, with so many different tools being coordinated the stand-ups got longer and longer and I either had to get up earlier and earlier or force a whole remote team to stay later and later after work. And I had to follow up the remote teams emails to my local peers with local meetings because what they wrote in their emails might not be correct anymore after the stand-up.
Slack + GitHub boards + Google Docs
This time I was working with developers in California and China. The flow went like this:
Bugs and stories in GitHub boards
Designs in Google Docs
Stand-up like discussions in Slack
The first problem was that the Kanban boards quickly became overloaded storing a massive backlog. With a Wiki we might have had a list of potential stories and requirements, but now everything had to have its own individual card. Where Wiki had tracked changes now one had to stay on top of finding and grooming hundreds of cards.
Ignoring the backlog problem using Google Docs over Wiki was a small improvement because Docs supported opening and resolving comments directly in the document. Stand-up like discussions in Slack was a complete fail though. Important information would scroll up the screen never to be seen again.
Uclusion + GitHub boards
This is how I currently work:
Bugs in GitHub boards
Everything else in Uclusion
I’m still doing direct messages and voice calls with my co-founder but the rest of our team interfaces with us exclusively in Uclusion. They don’t even see our bug board because we roll up bugs for them to work on into stories.
We don’t need status meetings because we can see the progress of everyone’s stories at a glance. We don’t need email discussions because we can open Uclusion Dialogs and vote on options. We avoid a giant backlog because a Uclusion workspace has a Wiki like, diff backed, context section to hold and discuss requirements or potential stories.
In short currently I just use tools to do what they were designed to do. Kanban boards are excellent for bugs because you get a categorized view of lists of simple items. We don’t use Kanban boards for stories because a story is a whole world of its own (including progress reports — the story in the picture above is yellow because its missing one) and doesn’t fit well into a card based on a sticky note. We use Uclusion for all the rest of our asynchronous communication because that’s what it was built to do.
Top comments (0)