Allan Kelly from Allan Kelly Associates
2) Offshoring – When Project meets #NoProject
In our department, we maintain products, … we deliver small features. In parallel, we have some offshore teams working in traditional project mode
The hard part comes when we need to integrate/merge our code. We have different cycles, schedules and objectives. How do we manage code handover code from offshore? – we feel we are inheriting a pack of legacy and tech debt that is added to our own stack.
No matter the handover contract agreement we set, … they don’t make the right choices for a long term maintenance vision.
They deliver the requested features, it works from a business point of view, but they deliver it in a way that can be difficult to maintain in production.
Of course, they do not maintain it, so they don’t have the experience of it.
This is the second question carried over from the #NoEstimates/#NoProjects workshop in Zurich last month.
While the question is phrased as “working with offshoring†I don’t see this as an offshore specific question. I think the question is about working with a second team, a team which does not hold maintenance responsibility and a team which perhaps doesn’t have the same quality standards as the primary team. I am sure that offshoring – and probably outsourcing – complicate matters because issues need to navigate additional boundaries.
One question in my mind is: if the second team impose such additional costs on the primary team are they actually making more work than they are doing? That is, every hour the primary team spending dealing with the liabilities of handover is an hour not delivering their own work. I’d want to look at that but lets assume the second team are worth it.
Something which worries me here: “No matter the handover contract agreement we setâ€. Are the second team listening? Are they making an effort to work with the primary team? Or are they ignoring the primary team?
If that is the case then it is a big problem because there is little the primary team can do to fix how the second team work. So a question comes into my mind: are those responsible for having the second team aware of the issues? Would they like to improve things?
If not then, as the second team and those employing them are not concerned, the problem may be unsolvable. The only solution the primary team have is to insulate themselves from the problems of the second team. In the short run that removes the pain for individuals but in the long run it will make things worse.
To my mind it does fall on the primary team to make a case to both groups that they would like to make things better and to work with the second team and management to make things better.
So how do we make things better?
The good news is there is lots that can be done here, there are people changes, process change and technical solutions. The bad news is, there is no silver bullet.
People changes: team members should visit each other.
I know travel budgets get cut but there is a clear case here that if team members could visit each other, understand each other, known each other then they will both work together better and be in a better position to improve things.
Process changes: ask the second team to do smaller pieces of work and deliver more often.
I don’t know the mechanism by which work reaches the second team but someone somewhere is asking them to do things. That person needs to change their requests. Of course, this means moving the second team away from the Project Model and towards a Continuous model.
Technical changes: there are a lot of options here but each of these options is gong to work best if people have visited one another and the process has been changed to lots of little.
So:
- Have both teams practice continuous integration (if they are not already).
- Reduce the number of branches, move towards trunk based development.
- Have both teams practice automated unit testing (preferably TDD) and automated acceptance testing (ATDD).
- Add static analysis tools to the build.
- Do manual live code reviews, i.e. developers at one location talk to one at the other location while they do the code review.
None of these changes are unique to the scenario described in the question. They are common quality improvement practices. The only addition I’m making is on the code review, I want the second team to review the primary team’s code, not just the primary reviewing the second. I want this because I want teams to learn from each other.
Hopefully you can spot two themes to my suggestions.
Firstly, I’m treating both teams as equal. That is only fair but it makes sense too. If the onshore team makes the offshore team feel as if they are treated as second class then they will act as if they are second class.
Second, most of my suggestions are straight from the Continuous Delivery playbook: have both teams do lots of small high quality pieces of work and integrate them without delay.
Underlying here is a problem: the second team don’t do maintenance. They have little incentive to do better work and maybe unaware of the problems their style of working is causing.
Now having said all this I might be accused of ignoring the question. The question stated: the offshore team work in project mode. And I’ve just given suggestions which could be considered not project mode. Put it this way, I think changes need to happen one way or another. If the second team want to cling to projects then so be it, but they can still improve their quality as they do so.
If you have any questions about Continuous Digital, Project Myopia and #NoProjects please mail them over and I’ll do my best to answer them in this blog.
Receive these posts by e-mail?
Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Developmentâ€
The post How do we organise with with a parallel team? appeared first on Allan Kelly Associates.
