Doing Offshore Development: My Key Success Factors

A little over two years ago, I took on the endeavor of offshoring development of my software project.  This was something new to me, from an execution point of view.  As I embarked on the process of engaging an offshore team, I got a lot of advice from colleagues.  Some of it was even solicited by me (rim shot).  To be sure, much has been written and said about this topic, but here are my key learnings that hopefully will help you as you start down the offshore path to software development.

Cost Savings Should Not Be Expected Early

Many firms go into this with an expectation that development costs will go down between 50 and 65% right away after deciding to do offshore.  This is an unrealistic expectation that needs to be managed.  My research revealed that it takes 1-2 years to fully integrate and optimize an offshore team into the local team.  In the interim, there are many hurdles to overcome such as language, cultural differences, understanding individual contributor technical expertise, shared understanding of the software process used and the like.  Overall, expect productivity to go down and costs to actually rise in the first 6-9 months (I think team size is the big variable here – Mythical Man Month rules apply) while the team figures out how to work together effectively.

Recognize That Optimizing Offshore Development Is a Journey

In my experience, integrating offshore is an exercise in maturing overall team performance.  It’s really no different than working with a team that sits in your midst.  Mistakes will be made, miscommunications happen and you get some downright bad results early on.  It may seem like nothing is happening because you can’t see people working on your software project.  In my experience, I had to manage the local offshore team’s expectations more than anything.  They had to adjust to working with colleagues who they perceived were not as strong technically.  My team early on overcompensated for what they saw to be as poor results.  This type of behavior actually proved to be counter-productive to the development of an overall working relationship and software engineering process.

My recommendation:  keep the process as simple and clear as possible and build upon successes.  At some point, you as the leader will need to inspire another evolution of process as the team matures.  There will always be room for improvement.  Don’t try to do it all at once.  We try to infuse internal process improvements into each development iteration to drive the most urgent improvement opportunities.

Agile Process Is The Way

In an offshore development model, I have come to embrace Agile as the only way to develop quality software.  We use the Scrum brand of Agile and I found that with two-week sprints I was able to frequently provide feedback and check in on progress.  I observed how the team interacted with each other, which people seemed to consistently step forward in sprint reviews and planning sessions as well as probing deeper on process improvements.  When there are gaps, I could provide advice and direction on what needed to change.  I also used these as opportunities to form opinions on which team members were top contributors and which were at the bottom.  In partnership with my offshore partner, we were able to replace the lower performers quickly and increase team effectiveness. 

HD Video Teleconferencing Equipment

The best technology investment I made was to outfit our team scrum room with high-definition video teleconferencing capabilities.  I vividly recall the day we enabled the system — it was so cool to see the people we are working with live and in person.  It didn’t take more than a few days for the programmers on both ends to get used to using the equipment — the daily scrums were much more compelling in HD video!  It seemed like the table became one, longer table that everyone sat around.  The names became people that we could talk to and laugh with even though we are a world apart geographically.  Picking up on non-verbal cues really helped.

Let’s face it, building software with a geographically dispursed team is really hard.  I don’t think you can get around it.  But, I hope these few ideas I have based on my lessons learned can help you create conditions on which to build successful software projects.  It is a journey indeed.


Big Plays Post On Marcato Partners Site

Visit the Marcato Partners site to see the Sprint Contract Part I post at  This company is on the forefront of Agile consulting and have a comprehensive set of service offerings to help customers develop their software applications.  Highly recommend them for your software development projects.

Leadership Lesson – Getting To The End

In the experience of starting the brand new Lego League program at my kids’ school, I learned an important lesson about leadership when starting something brand new.  This lesson I call “Getting to the End.” 

When you are starting something new, it’s not a big shock that there are more questions than answers, colleagues that will create roadblocks to success (either subtlety or not so much), challenges that emerge that were not planned or self-doubt about your ability to lead the team through the process.  As a leader, it’s important to the team following you that you do not allow these obstacles to become a distraction to the larger goal.  In my case, the goal was to complete the first season of Lego League and to have a showcase event to wrap up the season. 

I noticed a few key elements about what happened to me as a leader through the process.  The first was passion around the objective.  I had a pretty clear picture that I had of the end state, and I was determined to see it through.  I repeated this vision often to my team of volunteers.  The vision became contagious, and the team definitely pulled together to deliver a great event!

The second was effectively delegating responsibility and trusting those delegates to deliver.  As a control freak, this was hard for me.  With this size of an effort, I found out that delegation was an absolute necessity.  Plus, people are more than willing to help if they know what you want done.  Once you do that delegation, you have to let go and let them be accountable for the result.  In my case, I had a great group of volunteers and they convinced me early on to back off and let them handle the small details.  The net result was a fantastic  event and a group of volunteers who felt really good about the outcome.  I remember how great I felt after it was all over.

So, getting to the end is probably the most important thing when starting a new venture.  The learnings and insights gained during the journey will make the second iteration go so much better if you can avoid the distractions and keeping the eye on the prize.

Book Review: Pursuit of Honor by Vince Flynn

I just finished getting my annual Vince Flynn fix.  In years past, I tended to read the book so fast that I barely got the chance to enjoy it.  I would then have to wait about another 360 days to get my hands on the next book.

Vince Flynn
Pursuit of Honor by Vince Flynn

  When I received my copy of Pursuit of Honor, I promised myself that I would take the time to savor it and I was so glad that I did.

This book picks up the storyline at the end of the previous book where Mitch Rapp and his clandestine colleagues deal with the fallout of the terrorist attack in Washington, DC.

The action moves quickly, as always, and the combination of the subplots reflect the political complexities that those who are working secretly to protect us must navigate.  It points out the conundrum we as a nation face when we think about conducting the war on terrorism.  I am thankful there are people who so willingly serve our country in the shadows and tenaciously pursue those who seek to harm us.

Without spoiling any of the plot, I’d definitely say that Vince Flynn delivers yet another winner.  The ending left me wanting to start the next book now!  At least this time I only have to wait about 300 days until his next book.  Get It Here at Amazon.

The Sprint Contract – Part II: Producing the Document

As a product owner, I need the commitment between the product owner and the release manager to be documented prior to the sprint beginning.  

In my previous post I described the genesis of the sprint contract idea based on a blog post I read. I also described why there was a need for such a document. This post will go over some of the mechanics of how my release manager would create such a document.

In order for this exercise to be useful, there are a few key parameters that must be considered.

In order for the contract to have any real impact on the outcome of the sprint it must be produced in advance of the sprint planning meeting. It will go through a couple of revision cycles as I negotiate priority user stories with the release manager.

The release manager spends a lot of time in our backlog of user stories, so the idea of creating a separate document at first seemed like an extra step. As the product owner, I felt that producing this artifact outside of the system used to manage the backlog provided some advantages to me.  Probably the most important advantage was that I did not need to sift through the details myself, which allowed me to easily focus on the stories at hand and quickly give feedback to drive priorities. From the release manager’s point of view, if the stories are written well in the backlog system, it should be a matter of cut and paste to create the document, followed by some minor edits.

Single Page
A key tenant of Agile is to produce just the right amount of documentation to support the software development process. An important part of the sprint contract is keeping it to one page in length. One page helps keep the content at the right level of detail, plus it makes for an easy-to-use scorecard I like to use at the sprint review to evaluate whether or not each of the commitments were met.

Stretch the Team
At the beginning of implementing this process, I was most concerned that the document would either have a far too aggressive scope. If they were unable to complete every commitment on the document, they would feel as though they had failed. As the product owner, the challenge during the editing process would be to get as much as possible in the scope of the sprint. I found the key was to go for a stretch of the scope to maybe a story or two beyond what I thought could be accomplished. In future posts, I will present some data to give an idea of how much to expand the scope. My goal was to never achieve 100% as then I knew that more could likely have been finished in the sprint.

Working Software Is The Priority
The stories in the sprint contract must represent working software to be demonstrated in the sprint review. Any stories that don’t should not be on the sprint contract document. Again, this document sets the stage for the sprint review, so other user stories (for example, we like to have process improvement stories) are not necessarily interesting for the attendees of the sprint review to discuss.

I like to use this document as a scorecard, so the items listed on the document should be written in a way that makes it easy to assess success for each item on the document. This is important to the team so they know what the definition of success will be as the product owner follows the events of the sprint review.

In the next post, I will talk about the impact the Sprint Contract has made with my team, including the data. Hope this is useful, as it has really helped.

The Sprint Contract, Part I

As a Product Owner, I need the development team to deliver the functionality agreed upon during sprint planning.

My scrum team had developed the tendency to quickly defer user stories they did not complete into the next sprint.  The tool allowed them to game the burndown so that it always looked like performed well, but I was not satisfied with the amount of software presented at each sprint review.  It just didn’t add up.

I tried asking nicely, being impatient and demanding, begging and pleading among other motivational techniques from my project management past.  Still, no real change in results.  Then, I tried my good friend Google, and I ended up at this blog post from an Agile coach named Peter Stevens:  At last!   The sprint contract concept.  It’s all about setting expectations up front in planning by focusing on what will be presented at the sprint review.  In my environment, sprint reviews include stakeholders from all over the world that are using our software, so it’s critical the “show” is a good one. 

In future posts I’ll review how I adapted Mr. Stevens’ approach and what results I saw and why I think I saw what I saw.

So I wanted to start this blog…

So I got this bright idea to start a blog.  I can feel the eyes rolling as I write this.

Here’s the back story:

My job requires me to be up on the latest trends in or near the software technology space.  Lately the social media space has gotten my attention with sites such as Twitter and Facebook.  Now that I am actively using these sites it occurs to me that I do have some unique ideas and perspectives that I should be writing down.  My biggest hurdle so far is figuring out what to say and why I would share.  Isn’t it better to keep my mouth shut?  Maybe, but I think the journey will be worth it and I hope it is useful.

I found an interesting page for beginners that will help guide me.  I will do my best to follow the author’s advice, as I think it is good.