In a large organization, every morning a manager from the HQ office has a meeting with the dev team(s) based offshore (India) and checks the work they've done. He's very tech savvy, and says that he can tell whether they're taking the piss or are honest with him always. He's able to dig in the problems and resolve them, and also provide solutions. Some might say that he's doing a great job in scrutinizing their work, especially given that these teams are responsible for millions of revenue to the company.

This organization wants to move towards more agile ways of working. Is the above suitable to keep or should it be phased out, therefore moving the responsibility closer to the dev team? Is this an issue of trust? What questions would you ask to start changing this approach?

  • 1
    Can you narrow the scope by describing how the current process is negatively impacting things, or causing some sort of actual problem? Opinion polls are off-topic, and changing a process just to change it doesn't allow for meaningful measurement of the change. Without editing, this question is likely to be closed. – Todd A. Jacobs Mar 19 '19 at 15:53

Agile is very much built around trust and empowerment. Micromanaging and trying to 'catch out' teams is incompatible with this.

Some of the effects of the current approach include:

  • By providing top-down technical solutions you take away ownership from the team doing the work. If things go badly, they may just think 'well it wasn't our idea in the first place'.
  • The constant checking-up may result in the team being risk averse. Why take on things that may fail if you will just get hauled over the coals for it?
  • The team may even start to hide problems if they feel that the manager does not have the full context and so may misinterpret them.

The best thing to do is to leverage agile principles.

For example, if the team releases frequently (say every 2 weeks) then true progress is clearly visible. If it is not possible to do this production, at least do it to a beta release environment that is viewed by stakeholders.

Also, look to use continuous integration and automation to better integrate the offshore team with the in-house one. For example, you could pull the code from the offshore team in to in-house servers every night or when a check-in occurs. Doing this will start to break down the barriers between the two teams.

Look for ways to build trust. Can the offshore team visit the in-house team, or perhaps some in-house team members can visit the offshore office? Create a safe to fail environment, where the offshore team knows that they will not be punished for making mistakes and so are willing to be open and look for solutions. Have the offshore team ask for help, rather than pushing technical solutions to them. For example, you could have a chat application running that allows the offshore team to bounce questions/ideas off of the in-house team.

Finally, show that you respect the offshore team and that you want to make their work a success. Encourage them, congratulate them on successes and help them to feel that they are wanted and appreciated. This will foster a culture of transparency and collaboration.

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