I'm about to take over an IT team that lacks organisation between members.

The employees are as follows:

  • Part time lead software developer & team leader; Onsite; (Me)
  • Full time IT all rounder (Helpdesk, low level sysadmin, software development); Onsite
  • Contracted system administrator; Off site; Moderately expensive
  • Contracted database administrator; Off site; Expensive
  • Contracted system administrator; Off site; Expensive

I need to optimise my time managing this team since I'm doing majority of development for our systems and I'm part time (3-4 days a week). I therefore have a few questions:

  1. What overarching advice could you give managing a remote team?
  2. I use agile scrum (online board) in my own development, should I integrate this team into a my scrum board so we can track issues between ourselves in sprints?
  3. If so, should I use a single board for the whole team or split it up?
  • 1
    I assume, your mentioning the expense means those are not full time team members but get pulled in on demand?
    – CMW
    Commented Dec 17, 2013 at 22:49
  • Yeah, they are contractors pulled in when required, and their time is expensive. We prefer to avoid their services if possible
    – MrJD
    Commented Dec 17, 2013 at 23:47
  • Worth reading: pm.stackexchange.com/questions/9099/… and pm.stackexchange.com/questions/1326/…
    – Tiago Cardoso
    Commented Dec 18, 2013 at 0:36
  • 1
    So you, as a part time worker, are the team leader and the main developer? That's tough... What kind of projects do you work on? Who manages the requirements? What makes you the team leader (in terms of scrum, there's no such role)?
    – Sven Amann
    Commented Dec 18, 2013 at 9:14

3 Answers 3


The overarching advice is to do whatever works for you and the team.

The best scrum process with the best scrum team will be nothing but an impediment if priorities change several times a day, while even the worst specification nightmare carried out by the most incompatible team may still profit from a scrum that's done well.

Assuming the work your team does is mostly of the helpdesk/ticket kind, what's pressing can change rapidly. For this you should maybe look into Kanban boards instead of scrum. The difference is minute but can be critical in this case. Basically think of it as a scrum with sprints that last exactly one task. After that task is done, the team member goes back to the backlog and grabs the next task with the highest priority. Usually estimates are an unnecessary overhead, and there's no point in sprint plannings and sprint commitments.

This will give you greater flexibility as well as visibility for the whole team.

Both scrum and kanban are designed to have the team manage itself. They plan and assign their own work packages, tackle what ever fits best for that moment within the scope of their commitment and don't check back all the time to see whether there's anything that the manager would rather have them work on. This may not work for teams where contractors are involved on an hourly basis, only when they are needed and have work assigned to them. This is the wrong flavor of agile for these situation.

If there's only one set of responsibilities (either the rapidly changing scope of support work or the more structured backlog driven development cycle), having one board is fine. I would strongly advise against merging two sets that have very different constraints when it comes to planning.

  • 2
    You bring up a good point that I think about, the fact that helpdesk/ticket is different from projects. Perhaps I should have a separate board for that and keep project (long running) tasks in a scrum board?
    – MrJD
    Commented Dec 17, 2013 at 23:50
  • 1
    @MrJD: That's a very good idea, I think.
    – CMW
    Commented Dec 18, 2013 at 8:16

My background is mostly in Agile methods (XP and Scrum) and I do have experience with running remote teams. You're asking for advice which probably makes your question a bit too subjective. You've also posted three questions, which would be better split into separate ones.

In a way, I disagree with, "do whatever works for your team", because how do you actually know that it is really working for you? How do you know you're doing it right?

Start with something off the shelf. Only optimize for your team after you when are sure you (and your team) have enough expertise to know why you should make the change.

Don't make too many changes at once and measure the success of any change you make in terms of velocity. Avoid being a ScrumBut.

  • 1 Overarching advice:

I'd start off with a prescriptive method, one that can be easily and consistently applied. This way you can get all your team to work from a book or simple guide. The consultants I used really appreciated that I was using a standard Scrum process.

Help facilitate communication by ensuring that even when communication happens locally it is broadcast via email.

Use cloud/internet tools to run your processes. I've used, Rally for managing Scrum. Planningpoker for estimation, and corkboard.me for retrospectives. We used Google hangouts with a webcam for all group meetings, including the daily scrum.

  • 2 Should I use Scrum?

If you're experienced with Scrum then it is likely a good choice.

  • 3 Should I use a single board?

My default position is yes, but you haven't really given enough information as to why you're considering two.

  • Thanks Dave, some really valid points here. I'll try address a couple. As to why I would use multiple boards: I've never used scrum in a team (forever alone :P). I'm unsure whether to break boards up by project grouping or have the team together as one. It's also worth noting I've got a JIRA/Confluence instance setup where we can communicate, but I like the idea of G+Hangouts. To CMW's point, kanban would be best for the helpdesk/ticket style, so I'm thinking of using a separate board for that, and a scrum board for the projects.
    – MrJD
    Commented Dec 18, 2013 at 21:40

I'm currently working exactly how you describe and we have a few tricks to do it. I'm managing a team with people working remotely from many timezones... it is a mess :). But we follow SCRUM and a few custom rules and it works perfectly. In your case:

What overarching advice could you give managing a remote team?

I would say communication is the key. Have your team well communicated and everybody will help each other (they need some trust and they must know that they can count with each other for that).

I use agile scrum (online board) in my own development, should I integrate this team into a my scrum board so we can track issues between ourselves in sprints? 
If so, should I use a single board for the whole team or split it up?

We use Trello as our agile board. If your team members are in different projects, I wouldn't recommend that. But if they are working in the same project, that can be helpful so everybody know what tasks are pending, in progress, etc. Using internal messages (in Trello with @) also saves tons of time.

Try to have each card as atomic and smaller as possible, so they don't block each other. And finally, in order to have the motivation up, review what everybody is doing and so, I recommend you to use Dutyful. It generates everyday a report sent to everyone by email, so everybody knows what everybody did, their blockers, etc. Very useful for remote teams!

Hope it helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.