Remote team - mobile tools

When working remotely and/or asynchronously you may be often in situations where a mobile access to the team/project data is very useful. See my previous blog post on desktop tools for remote teams.

Here is a list of tools I often use in the context of the Arkency team. I use all of them from my iPhone 5s. I think most of them have their Android versions.

• Team/project
• Slack
• our IM tool of choice, good UX, easy to use, even with a 20+ team
• the nice thing is that it caches all the history of our channels, so I can sync with them whenever I want
• Hackpad
• accessing offline and creating hackpads offline is the killer feature
• Trello
• iOctocat
• This app pushes me a notification whenever any new commit appears in any of my github repos. I can easily review the diff, comment on the changes or just browse through the code - highly recommended!
• basic version is free. it's worth upgrading to receive notifications ($12.99)
• Mumble
• the voice communication tool of our choice, push to talk, multiple rooms
• Social
• Twitter
• Facebook
• AlienBlue
• a Reddit client - useful if you often post your blog posts to Reddits
• free, but worth upgrading for $1.99
• Getting Things Done
• MindNode
• $9.99
• it's the mind mapping tool, that I was looking for a long time
• it has a Mac version (paid separately) and integrates/syncs via iCloud
• Evernote
• Quick to find important information, even from a mobile.
• Geo
• Foursquare
• Even though, we are a remote team, many of us live in the Wroclaw area. When people are in the habit of checking in, you can easily see if anyone is close to you right now. I'm a strong believer of async/remote work but when there's a chance to meet face to face, that's always a good idea!

This blogpost is a work-in-progress chapter from the "Developer Oriented Project Management" book. The book is just weeks before the final release. Grab it now, before the price goes up!

Async standups

When you work remotely, you want to have some kind of a standup meeting regularly. In our team, after experimenting with many different approaches, we settled with text-based, asynchronous standups every day. Additionally, every project has a weekly 'sync' meeting.

Whatever tool we currently use for remote communication (irc in the past, now Slack), we create a channel that is dedicated to #standup. We don't have a specific time to post there, usually we do it, when we begin our work session - so, in the spirit of async - different people at different times.

I consider #standup to be a very good opportunity to communicate cross-project, to educate, to learn, to help. Short standup messages are not bad, but they miss this opportunity.

When writing the standup message, think more about the others, than about yourself - what can they get from it by reading your status?

Example 

Yesterday I finished the "fix the price calculator" feature, which was mostly about removing the Coffee code and rely on the value retrieved from the backend, via ajax. The nice thing was that the backend code was already covered with tests, while the Coffee one wasn't. After that I helped Jack with the "allow logging in with email" feature (we need it now because we have a batch import of users from system X soon). After that I did a small ticket, where I block buying licences for special periods of time. This was nicely TDD'ed, thanks to the concept of aggregate, introduced by Robert recently - all the tests pass < 1s. Here is a commit worth looking at: .
Today I'm going to start with foreman'ing the recent commits and after that I want to work the XYZ system to allow a better editing of entries. I'm not sure how to start it, so all help is welcome.

What's good?

• many details, 
• letting other people jump in and help me,
• some opinions about the code that I saw, 
• some details about practices I applied (TDD, foreman'ing) 
• reminds about some business information - import of users from the X system, happening soon 
• links to the commit (potential education) 

Format 

1. yesterday
2. today
3. good thing
4. bad things
5. challenges
6. call for help
7. reminder about good practices (tdd, foreman, help colleagues) 
8. code examples (link)
9. business-related info


(this blog post is a work-in-progress chapter in the Developer-oriented Project Management book.)