11
No guarantees on this one, but here is what I would try:
Either they are not understanding your documents or they are not doing the work and using the documents as a scapegoat. It is a little extreme but ask for a restatement of your documents along with their anticipated approach. Get this by the next day as a precursor to them commencing work on the ...
10
I totally agree with Michael and Mark. Both nailed the problem with the ask for a restatement of your documents along with their anticipated approach. They're clearly not understanding the requirements. The problem is... are they trying to understand beforehand? If they're not analysing the requirements and jumping straight to the dev, they'll have a hard ...
9
There are two major impacts of a remote Scrum Master in my experience.
The first is that meetings like the retrospective and sprint planning are a real challenge. The biggest problems are usually with audio quality, particularly if using phone lines or teleconference hardware that mutes the end of the call that isn't talking. If you can get a top quality ...
8
It isn't clear from your post if your team is practicing Scrum, so I'll start with general information before going to Scrum.
There is no single right way to run a stand-up meeting. You can call it whatever you like (just consider that the term Daily Scrum suggests a specific practice). Usually, the value of the standup to share important information that ...
8
Managing remote developers: There is sound advice here already, with respect to JIRA and frequent calls to stay in touch. Having managed distant development for the last two years here are a few extra suggestions on top of JIRA and Skype phonecalls:
Be ready for remote development to take longer. Establish good communication lines, encourage the developer ...
7
You can measure results. You can't measure hours in front of screen (and probably shouldn't).
You need to agree on a goal and a deadline.
Given step 2., you need to talk each time the current goal is accomplished, so you can evaluate it, and agree on a new goal and a new deadline.
You need a way (e.g. email) for the remote worker to let you know if the ...
7
You certainly have a problem. Ultimately the problem is yours, even if the team is composed of total slackers. You're accountable for delivering on time; the team is accountable only to you. I'm not sure that offshore/onshore is relevant; I'm not sure that many of the details above are relevant (except that we would have asked if you hadn't supplied them.)...
6
Start with the "why". What information exactly is it that Senior Management is looking for. What are they using that information for?
It could be as simple as wanting to see progress, or open to closed incidents. Until you know exactly what the information is for, you'll be doing a lot of wheel spinning. For example, I started at one company and they had a ...
4
Before I start I should mention that I have managed India teams as large as 180 on over 100 projects over the last 10 years and have gone through the same exact issues. It is critical in any project to match the right skillset to the project at hand, but 10x more critical in India due to culture, communication, time differences, etc.
Other posters have ...
4
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 ...
4
Have you tried using Trello for this? Although we don't have any "permanent" remote workers, we do have several members of the team who work away from the office for months at a time. We have the "Product Backlog" for each product, which the PO maintains and we (as a team) go through this during our sprint planning and pull stories into the "Sprint backlog" ...
4
I had a similar situation to this, with a distributed team that was getting quite large, and there was a lot of "wasted" time in side conversations, silences, or people needing to be pulled out of work they were doing on the side to chime in.
The way we addressed this was twofold:
we used an online note board for the sprint retrospective, which was shared ...
4
In my experience periods of silence in a retrospective are caused by the following:
The team sees no value in the retrospective
The team is too large and people are uncomfortable talking
The team has a lot of introverts that feel uncomfortable talking in meetings
It is quite possible that you have a combination of all three problems. Throw in the fact it ...
4
Well, one by-the-book answer is: don't.
The Daily Scrum is a 15-minute time-boxed event for the Development Team.
Your attendance is not required. And as long as you do your job in
Ensuring the Development Team understands items in the Product Backlog to the level needed.
There should be no problem.
Now the real world answer is probably more ...
4
All the team members can agree on some set of guidelines to help.
We are following these fun guidelines that are working very well for us:
No person can talk for more than 1 minute at a time.
Every person in the team must talk.
Every person must nominate the name of another person in the team, at the end of his/her turn. The nominated person will then talk ...
3
Don't.
You're asking a subjective question - we don't have nearly enough information to provide an answer, but the inference I would draw is that the individual is reluctant to ask for help. You don't describe the efforts you've made to communicate that help is a desired & expected transaction, but I'm going to assume that you've done everything in ...
3
I'd expand on Joel BC answer - 'why' is the key, and being from a very similar environment (multi location / cultural place with hundreds of people reporting to a single head) I believe that understanding why such report is required is the key to define whether the proposed approaches will succeed or fail.
I believe that understanding the target audience, ...
3
From the university courses and companies I was at remotely / with some distance, it was common to use a Facebook Group from where we all would connect and discuss relevant content (updates from the university/company, auctions, contests (chess, cooking, ....), discussions about the general approach to solving problems, etc.). The pattern I could see is that ...
answered Nov 28 '18 at 12:59
Tiago Martins Peres 李大仁
1,8782 gold badges7 silver badges30 bronze badges
3
We recently had two retrospectives where parties joined from two continents. It wasn't that different than having the whole team in one room.
The key is where you store the information. It is common that teams write a shared documentation during the retrospective and that kills the dynamics of the event. Select one site and do the writing and drawing part ...
3
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 ...
3
I'm a fan of using a web conference with video to highlight the team member's individual work environments. Kind of like an MTV Cribs-type virtual tour get together that allows each team member to showcase where they work and to interact with their teammates through stories and questions about their work environment. We do this every so often (really ...
3
The first item in the Agile Manifesto is:
Individuals and interactions over processes and tools
Your question lists a bunch of tools and asks about more tools, some that are more flexible to use given your new situation with people working remotely.
How about turning the problem on its head and think about improving the interactions between people? At ...
3
A few additional suggestions that we've tried with some success:
To specify seating order, you can do things like:
have everyone roll dice (slack has a D&D dice roller app, use /roll d100 to get a good dynamic range)
have everyone say their favorite color then go in spectral order
choose the first person by something lighthearted like oldest car, or ...
2
Managing remote/near-shore/off-shore development teams can certainly be a daunting prospect, especially if you haven't worked with them before and have yet to build up any trust/rapport.
How can you be sure they are working the hours they say?
This all boils to down to the agreement you have with your development team. Are you paying them on a hourly ...
2
Has anyone done this before? How effective it is compared to using a laptop
Of course this has been tried before. And obviously a system with better microphones and speakers will be better than one without them.
Of more interesting to note here though is that you seem to be hosting some kind of "Scrum" meeting with multiple Scrum teams. Is that really ...
2
One of the keys to a successful meeting is having the right people in the room. That seems obvious but it's amazing how often it doesn't happen and you find yourself saying 'that's a question for Jane from the dev team' etc.
Before the client meetings take place determine an agenda that covers everything that both parties are likely to need to discuss - a ...
2
Transparency is key.
I've been working with remote teams for the last few years, and I have had the most success when you have an easily visible measure of progress.
It's essential to have small pieces of work that are clearly done / not done. We use scrum and Jira, but the process and tools are less important that what they display.
By breaking things ...
2
It looks like you're doing the right thing by moving to an automated system of sorts.
The thing that will be most up to date will be the code and the Pull Requests or the patches that are proposed. The issues, tasks and time tracking linked to that won't always be the most up to date so if it's important, you're going to have to sit down and ping each ...
2
First of all, what's the difference between 'remote' and 'local' PM? Where these two roles differ? As the question stands, it looks like just you have a redundant position on the main office while the offshore team does the job. If that's the case, then I'd say the problem is likely to be at company level... after all, what's the reason on having two ...
2
Well.. Your question caption states that you're wondering if you should use daily reports in your team, however as it turns out to be, you cannot decline using such the reports and the issue is actually in the reporting format. Either this would be a simple mail or a work log in Zoho.
I believe that the last one would be the best way since:
Your team ...
Only top voted, non community-wiki answers of a minimum length are eligible
