Recall that in my last post I covered some common pitfalls that we see when companies start doing some software development offshore. Now, let’s discuss some best-practices for Agile offshore development, which will (hopefully) allow us to avoid those pitfalls.
In brief, and as I’ve discussed in my prior posts, we’re going to use dedicated offshore development teams that work hand-in-hand with onshore staff. And we’re going to use an Agile process, since it emphasizes teamwork, bit-sized requirements, streamlined decision-making in order to resolve issues on a timely basis, and a lot of small victories. This approach helps you bridge the communication and culture gap that can arise when developing software with a mix of offshore and onshore resources. This mix is the “new normal”, due to the shortage of skilled resources in the US, and the need for a cost-effective mix of resources.
Here are my best practices:
1) Team Roles – I’m not going to define these roles. I assume you can read the definitions elsewhere if you need to. Instead, let’s focus on where our team members are going to be located-onshore or offshore.
- Product Owner – Product Owner is normally located onshore. Typically this person might be a product manager, who understands both the business and the product functionality very well. So normally this person is going to be onshore, although some companies are also putting a product manager on the offshore side too, and the onshore and offshore PMs work together. It’s that’s a nice intention, and I think it can work if you have a very special offshore PM, but I’m not completely convinced about this joint approach.
- Architect – I used to think your Architect should be onshore, but I’m not so sure anymore. If most of the developers end up being offshore, then placing your Architect onshore puts you at risk of having the Architect produce beautiful documents that nobody reads. Sad to say, but this not uncommon. The Architect needs to have the respect of the developers, or else they will have little influence, and the developers will make all the Architecture decisions on their own. Ideally the Architect should be able to watch the developers out of the corner of his eye to ensure they aren’t reinventing the wheel. So you might want to consider placing the Architect offshore in some cases.
- Engineering Manager/Team Leads – Should ideally be located wherever their developers are located. Normally you’d expect you offshore service provider to supply Engineering Team Leads for you.
- IT Operations/Production Support – Normally the leadership here would be onshore, but more and more you can do this offshore. E.g., if you are using Amazon Web Services, then the days of your IT Ops team driving down to the data center to do a memory upgrade are over. So you can manage this stuff offshore more and more. So you’ll most likely end up with a mixed onshore/offshore team.
- QA – I’ll cover this in a bit more detail in point 5, below.
2) Team meetings – The key Agile team meeting is the Scrum, where the team holds a brief meeting, at the same time each day, to discuss the project status, with each key team member saying what they did over the past day, what they are committing to do by tomorrow, and if they have any showstopper issues. This works well in the offshore environment since it forces communication between the onshore and offshore team on a daily basis. I’ve heard people say you can’t do Scrums with offshore developers, since you need to do your Scrum meetings in-person. Come on-get real. Sure, meetings are better when everyone is in the same spot, but we’ve got to live in the real world and unless you are a very early stage company, with a very compact team, in my experience it’s very rare to have all of your resources in one place. Your company just needs to do one acquisition and suddenly, like it or not, you’re a distributed team and you’ve got to deal with that. Skype and similar tools can work quite well if the parties (both onshore and offshore) have met each other in person in the past and have a good team dynamic (see point 6, below).
3) Charts and Project Communication Tools: You can review some of the charts and “tools” that Agile fans recommend (the Agile Academy has some very nice and easy to understand videos you can watch: http://www.agileacademy.com.au/agile/knowledgehub/agile-practice ) and use the ones that make sense to you. I particularly like burn-down charts to get a feel for where you really stand on delivering a release. I’ve seen people use “yellow stickies” quite effectively, in order to show which requirements are in some kind of trouble (e.g., the team doesn’t understand a requirement sufficiently to develop it, etc.). You can get tools that will help you generate charts, and share these onshore and offshore. But yellow stickies aren’t easily shared across borders. So you might be better off with really solid requirements management tool(s) that all team members can access. I’ve seen Jira used nicely-I like the ability to discuss issues related to a requirement in Jira, rather than having a string of emails with reply-all, which can be annoying as hell, in addition to making it nearly impossible to retrace why the team made some particular decision at some point in the project. You can also use Bugzilla or more expensive tools such as IBM Rational or HP Quality Center to track requirements (in addition to bugs). I think the open source tools are pretty good these days, and some of the budget-oriented commercial tools such as Jira come at a very reasonable price.
4) Requirements Management and Sprint/Release Management: Speaking of requirements management tools, these are critical for storing your “backlog” of requirements. This includes new features and bug fixes. So all new requirements and bugs get entered into the tool and this forms your backlog. At the start of each sprint you need to mark (in the requirements management tool) which requirements are being targeted for the upcoming sprint. If you have a big new project then you should break this down into a set of digestible requirements which can then be dropped into upcoming sprints, allowing you to deliver the project in a few iterations, rather than in one big lump. In the context of offshore development, it’s important that requirements be bite-sized and digestible, especially when you are just ramping up the offshore team. We want the offshore team to be able to contribute very quickly, and working on bite-sized requirements is a great way to do that.
5) QA – The ability to compress the sprint cycles down to a very short duration means you need to be able to regression test the product very quickly. Once your product is above a certain complexity, the only way to do that (short of throwing an army of manual testers on the team), is to automate your testing using test automation tools. I’ve found that you can do most of your testing offshore, possibly with a team lead located onshore, and everyone else offshore. You can actually hire very good test automation people in some offshore locations-possibly better than you’d find onshore. For example, in Ukraine I’ve found a real professionalism in QA and test automation that’s difficult to find in the US, where everyone wants to be a developer, not a tester.
6) Travel – Plan on having a big travel budget. In the grand scheme of things, it’s not worth being cheap about this, especially when you are starting up an offshore site and getting your onshore/offshore development process going. You can’t just hope that you’re going to get the onshore people working well with the offshore people (and vice versa) through teleconferences. You need to bring over at least a couple of key offshore people to your home office for training, and to meet the onshore team. Over time all of your key offshore people should visit your home office. And you need your key onshore team members to travel to your offshore office. I’d say plan on having a trip where at least some key team members are visiting once per quarter. Once the key people have met each other, shared meals together and had a few drinks together, you might still have some rivalries, and technical disagreements. Look, that’s business, like it or not. But hopefully you’ll begin to see some shared ownership and mutual respect beginning to take shape.
7) Training – If the people on the team are new to Agile then it might be worth spending a little money on some Agile training. Sure, most of them will probably have some familiarity with the concepts, and you could hand them all a book and tell them to read it, but we’re trying to achieve a bit of a culture shift here. So working through some training exercises together might be worth the relatively small investment.
If you have some additional tips I’d be interested to hear them.
CEO at Cayuga Soft