Agile Management: How Siemens Manages Offshore Development with Scrum
April 7, 2009 The Chicago Quality Assurance Association had an interesting lecture at the Willis Sears Tower on March 24th titled "Building and Managing Successful Offshore Teams Using Scrum" There is a big difference between offshoring internal IT projects versus offshoring commercial product development, but some of the same lessons still apply. In the case of commercial work, there needs to be a vested interest on both sides to adhere to the constant communication... doing this offshore is tricky. The main problem with traditional waterfall development (especially when working with offshore resources) is that problems are hidden and they only appear at the tail end of the project. It's no wonder that almost 65% of software projects fail! How many horror stories have you heard about offshore IT projects over budget, out of scope, or over due because no one knew what the offshore team was really doing?
Benefits of Distributed Agile Development
1). Lots visibility and transparency
2). Were able to deliver work fast enough with acceptable quality
3). Offshore team enjoyed agile/scrum, especially the intense collaboration with each other
4). Not one "onshore" resource lost their job
How To Do Distributed Scrum
1). The most important thing is that they took the attitude that outsourcing would succeed; no matter what
2). They did a lot of risk analysis and thought of everything that could go wrong: communication, source code violations, connectivity, etc.
3). Asked their friends and they said "don't do it"
4). Lots of cultural awareness training... learned about the Indian head bob
5). Refined the product backlog: for the first sprint they had 2 guys at a time in the US. Hires were all fresh off the street, not much experience
6). Created a sprint planning calendar
7). Trained Indian team in scrum
8). Lots of product training in the design, architecture, etc.
9). Held both teams to the same standard
10). Created team bios on MS Sharepoint
11). VSS was a problem so they had to merge code every month, it was a huge pain
12). Made sure user stories are well defined; good user story should be well developed
Challenges with Distributed Agile Development
1). Had to have a few conversations about underpromising and overdelivering with their offshore team because they took too many user stories and then ended up failing at the end of the sprint. this is a common issue with Indian developers. The desire to please is common in Indian culture, so it has to be tempered with a sense of creating realistic expectations.
2). Because of the problems with Visual Source Safe, they didn't see offshore code till after the monthly merge... code review revealed problems which they had to fix
For more on agile offshore software development listen to Andy Singleton's podcast on managing distributed agile software developmentand read Martin Fowler's article about offshore agile software development
Also check out Tackling Offshore Agile Development and Making Offshore Agile Work
Reader Comments (6)
Recent trends towards cost effective alternatives for IT in today's stagnant global market have boosted demand for open source solutions, allowing Liferay to further invest in ongoing product development.
Marc Jansen
Philippines Data Entry
"1). The most important thing is that they took the attitude that outsourcing would succeed; no matter what". Right on, it is not only aptitude but also attitude that determines altitude in success.
Though there is a slight difference between off shoring internal IT projects versus off shoring commercial product development but in my opinion it all revolves around the offshore outsourcing. In this off shore business transparency is one of the most critical factors to be considered.
http://www.offshoreadvisor.com/
Thanks for sharing your information.
I also know about a similar company which provides offshore software development, web development, web design services to their clients globally. Kindly visit www.ardentisys.com to outsource business with them.
Well done got some nice information, keep going...
Webplore
My experience within the Siemens software shop was seeing SCRUM misused when SCRUM was forced on their North American / Canadian developers over their collective and voiced dismay and reluctance. In my experience with Siemens, there were no caves - ONLY commons and that was not an oversight as it was clearly and repeatedly brought to their attention during implementation and post implementation. When attrition skyrocketed, the company was indifferent to the point of seemingly desirous of its use to reduce headcount.
As Tom DeMarco warns "caves and commons" can be used to exploit workers and make software sweatshops, I have seen it in action.
It's too bad, there was definite potential there since there ARE benefits with SCRUM and Agile. It sounds like this branch of Siemens may have done it right.