This is Part #3 of the series of posts devoted to combining agile methodologies with software development outsourcing. You can find Parts #1 and #2 here and here.
One of the main challenges in agile outsourcing is organizing the agile process (e.g., Scrum) in a distributed team. Typically, the Product Owner is on the client side, while the development team is on the provider side, often several time zones away from the client. The Scrum Master is normally residing with the development team, though some clients insist on using their Scrum Master. But let’s leave the remote Scrum Master situation for somebody else to dissect and concentrate on the ever-present issue: the remote Product Owner (PO).
If the PO is remote, the life of the team goes on as usual—with daily scrums, addressing discovered issues and obstacles, etc.—except when the team needs to communicate with the PO. Reporting the intermediate status to the client is usually a non-issue in the modern IT world. The team can update the status in some tasks/requirements tracking systems on an almost real-time (or, at least, daily) basis. Besides, verifying that the status is indeed as reported also happens often enough—at demonstration sessions at the end of every sprint.
The problems start when a team member needs to clarify some requirement with the PO. First, it may be midnight in the PO’s time zone, and waiting until the next day is not the best option. Second, software engineers are far from the best communicators, so it’s much easier for them to ask a question and get an answer during a face-to-face meeting, with a whiteboard and everything. And third, don’t forget that in offshore outsourcing, a client typically deals with engineers from countries that speak other languages. And though many engineers know enough English (let’s assume the client is English speaking) for e-mails and occasional verbal communications, it still adds to the list of issues to overcome in case of a complex question to the PO.
The approach we usually take here is to designate the leader of the development team and make that person a “deputy product owner” (DPO). At scrum meetings and during daily communications, the DPO plays the role of PO for the team—answers the questions and makes assumptions about the actual meaning behind the requirements to the best of his/her knowledge. And if the DPO suspects that (s)he is misinterpreting or misunderstanding something, (s)he asks that question to the actual PO. In practice, the DPO is much more often right than wrong. Still, the DPO and the PO talk one-on-one every day (or as often as actually needed) during the overlapping work hours. They use all the modern IT tools—like virtual collaboration suites and whiteboards—to better understand each other. And, yes, the DPO should be a good communicator and fluent English speaker (again, assuming that the client speaks English). Plus, the DPO needs to be technically experienced and needs to quickly grasp new knowledge to be able to make viable assumptions when playing the PO role for the team.
That’s not the easiest set of skills to find, and those skills don’t come cheap in terms of the required compensation package for the DPO. But, at least, that’s a single person on the team. For other engineers, we can reduce the requirements in terms of communications and foreign-language skills. Don’t get me wrong: You should not eliminate those requirements, just reduce them, but that already allows you to build healthy, balanced teams (and seniority balance is important—read another recent post on this topic. The DPO doesn’t completely usurp the communication line between the client and the team. There’s still plenty of direct communication for other team members during the planning, demonstration, and retrospection sessions. But the presence of the DPO simplifies the day-to-day life of the team and makes the daily stand-up meetings more about the actual exchange between the team members than practicing a foreign language.
That—introducing a DPO role—I believe, is the main alteration you need to make to your orthodox agile process to work with a remote team. There are other challenges, but they are typically not agile specific. For example, if you are doing embedded software development rather than web development, you need to think of a good test infrastructure. That test infrastructure should allow engineers from any location to run the entire product test suite, and ideally without the need to ship equipment back and forth (those shipments lead to new problems—like delays with availability for new hardware, design re-spins, customs, repair/calibration, etc.). That need can be addressed by implementing a virtual lab framework—an important concept that deserves a separate post. Still, as I said, it’s not agile specific. Though agile methodologies put special emphasis on testing, it’s equally important for waterfall projects (if anybody still does pure waterfall) and other traditional models.
Thus, for your distributed agile team, start by defining the DPO role and finding a good candidate to fill that role. That should address the key issues with the distributed agile approach. And then you can do other tweaks relevant to your situation and project.
