Agile Offshoring : It’s hard work but it works!

Posted on Wednesday, July 18, 2007

1


This article is based on my personal experience that I went through when we started adopting the Toyota way of working. It has since been published on TSS (The Server Side) and can be accessed here.

Software Off-shoring is a reality of the day however there are many projects which fail due to incorrect off-shoring. Apart from tremendous advantages, off-shoring brings additional complexity, risk and avenues for wastage. This experience report will discuss how we turned off-shoring into a successful model based on Toyota manufacturing Process. We call this methodology ‘Lean Agile Off-
shoring.’

Our goal to go offshore was to deliver software faster by leveraging a vast talent pool at offshore location with higher efficiency. We chose Scrum and the Toyota way of working because of its strong foundation in successful new product development. The Toyota principles can be very well applied to any software development project. The underlying points discuss the Toyota way of working and how they were mapped to make our off-shoring process lean.

The overall methodology remained Scrum and Toyota way of working helped us to look at improving on a daily basis.

The project on which we applied this methodology is a batch processing system for a central social security organization. Our system processes relevant incoming data employer and employee data from the Income Tax department, validates this data and creates income declarations for a person for a period. The system handles 16 million records per month with the throughput of 50 records per second.

Principle 1: Define a long term philosophy and stick to it

We started out with the project off-shoring with one thought in mind that we are going to work on this not like a one project task but we are going to base all our actions on a long term vision to be the best agile company with a stable and repeatable off-shoring model. It should be a model from which the software community can benefit as a whole. We would not take any shortcuts that defy or compromise quality for the project.

We would actively invent and refine the way to work so as to improve the success rate of the way agile projects are off-shored across the industry.

Principle 2: Create connected, continuous process flow to bring problems to the surface

We decided to be agile in all our actions and follow no plan driven methodologies. However it is easy to lose way without a plan, this is where continuous communication and integration play a vital role.

We followed a model of regular sending of ambassadors from one site to the other, making the business context travel across geographies, building trust, gelling across the wire and mentoring.

Communication was also facilitated by having ‘always on’ communication machines across geographies. Talking to the team across the geography was a matter of picking up the mike and talking.

For project work we had single code base for multi site development with continuous integration so that problems would surface out quickly and would be taken care of immediately.

Principle 3: Using pull systems to avoid overproduction

Taking hint from the above principle we decided not to produce everything based on push but on the basis of stakeholders pull. After all we are not writing lines of code to increase our code base but the whole intent is to add business value with every line that we write. We reduced the size of the iteration if the pull was not strong enough or else used time to refactor, improve the quality of process and deliverables thus achieving success in making sure that we produced what the customers want, when they want it, with the best quality.

Principle 4: Leveling burden (heijunka)

Toyota talks about reducing muda (waste), muri (overburdening people) and mura (unevenness).

Keeping in mind the above 3 the biggest wastages in an off-shored project are in terms of extra features, more detailed than required requirements, extra layers of abstraction between the team and the customer, finding relevant information, defects not caught by tests, inefficient hand-off to the customer.

We took care of eliminating waste by developing only for todays stories, using story cards which were detailed only for the current iteration and had just enough information, coded directly from the stories and for clarification even the offshore team could always be in touch with the customer, test first both developer and customer tests. For leveling of work we always worked according to the team velocity and made sure that there were no uneven trends in the amount of user stories completed. There is nothing more harmful in a software project than burnt out team members. Teams velocity plays a very important role in deciding who does what and how much we do as a team.

Principle 5: Build a culture that stops to fix problems (jidoka)

We promoted a culture to stop work if there is a problem that can affect the quality of the deliverable.

If the offshore-onsite team felt that they could not communicate effectively we installed an ‘always on’ communications machine with always-on skype voice and video channel.

Once the team felt that our sprint evaluation was not being effective and we were not getting what we desired, we called off the evaluation, brainstormed on how we can do it better, had an improved kickoff in which we reduced the time spent on the reviews and followed an agenda to guide us through.

If there was an issue with our continuous integration or performance testing environment then we fixed that first before going further with developing stories.

If we developed enough stories but the functionality testers did not have time to test them then we stopped developing more stories till the testing team was comfortable with what we had done so far.
All this not only helped us by using counter measures but we were also able to error proof future situations.

Principle 6: standardized processes and procedures

Standardization is the basis for continuous improvement, empowered employees, rules and procedures as enabling tools, and a hierarchy that supports organizational learning.

We created standardized processes for the way to do development using TDD, issue tracking and resolution process, build generation and testing process. This is not to say that these processes were frozen in time, they were as alive and agile as our project but having some standards ensured that we started on a stable platform which can be improved further by the team.

Principle 7: Use visual control so that none of the problems are hidden

Our motto, everything should be visible to everyone on the team and yes this includes the client.

We created a common product backlog for onsite and offshore team in Jira, created a common burn down chart and issue log which was available for the client to report production issues and even look into our daily status. Cruise control would visually report the status of a build with every check-in and a build bunny would announce the success or failure of a build.

The physical and virtual walls and white boards had enough visual information for any stakeholder to walk to the wall and white board and get the information about the project in a matter of 10 minutes.

We decided to keep all visual information on our virtual team boards which were created on a wiki and then print out the relevant ones to paste on team walls.

Principle 8: tailor technology to fit people and processes

The truly lean project has two key features.

It transfers the maximum number of tasks and responsibilities to developers actually adding value to the product, and has a process for tracing defects and working on them as soon as they occur.

People is the greatest asset of an agile team, we want the team to change and tailor technology to suit their needs best rather than technology dictating how things should be done. In one example we moved our entire presentation logic from Struts to Spring MVC because it made more sense in the present context and the team as a whole took a decision to make the change. The best decisions and commitments came from a team when they took the decision on their own. The self organizing team knew best how to tailor technology and processes to work in the best interest of everyone.

Principle 9: Develop leaders from within the team

It is a well-known concept machinery depreciates and people appreciate.

We were committed to develop leaders in our offshore project from within the team. Instead of bringing scrum masters from elsewhere we sent some people from onsite and offshore teams for scrum master training and needless to say that these are the people who know the teams best.

Principle 10: Develop exceptional team associates

Unhindered communication, effective teamwork, form vs function of teams, good pay, the best facilities, a safe working environment, a work balanced life, continuous improvement, job rotation.

All these when followed in the right spirit can create star teams.

Healthy communication within different geographies is a core for efficient teams. For this we had a lot of seeding visits early the in the project intended to create the relationships, and regular visits to maintain the relationships. Of course the idea of these visits was not to get work done but to get healthy relationships going between geographies.

People are often discouraged from asking questions, talking about problems, warning about unfeasible deadlines, or proposing alternatives to perceived instructions from superiors. Though getting teams to be more pro-active is an uphill battle, and one that inevitably takes a lot of time.

However we actively promoted a culture of asking a lot of questions and highlighting issues. Once people realize they have the freedom, and the responsibility, of making decisions – they further contribute to becoming an exceptional associate.

Principle 11: Develop partners and suppliers as extension of the enterprise

Fair and honorable business relations is the key to have long term working relationships with the partners and suppliers.

We tried to follow this in spirit by exposing the wiki and Jira to customer and other software vendors who were working on different modules of the same project. This have full visibility into who is doing what, we could set clear expectations with all the stakeholders and vendors. The advantage, we built a huge wealth of trust and transparency, we had nothing to hide.

This not only gave a lot of credibility to our offshore process as a whole but actively helped in our long term mission to take the best practices to the software community by involving a bigger group of partners. Our partners learned from our burn down charts and Sprint signatures and we learned from theirs.

Principle 12: Go and see for yourself

There is nothing like being in the trenches to get the real feel of the situation, hence we had no lip service designers and architects on the team, everyone had to code and code well apart from any other role that they were playing. Period.

This helped us bringing about the attributes of clearly assign tasks to yourself and other people, speak on basis of well verified data, consult experts, analyze and understand situations and their solutions.

Principle 13: Evaluate alternatives while looking for consensus and implement them fast

We actively followed a policy of not picking a single direction and going down that one path until we had thoroughly considered alternatives. Once we picked the right path, we moved quickly and continuously down the path.

At several instances we tried to find alternatives to various issues like how to get Dutch documents across to the offshore team – should we manually translate them? Should we use a tool, since a tool would get us 60% there? Finally we decided that the Dutch team would make Jira issues out of relevant documents and then the offshore team would study the issues and ask questions on that. This approach went well and quickly with the team.

Principle 14: Become a learning organization through relentless reflection ( Hansei ) and continuous improvement (kaizen)

This is the most important principle which has helped us reach where we are today, we do rigorous iteration evaluations for reflections of good things to preserve and areas of improvement to help us improve iteration on iteration.

We solicit constant and immediate client and team feedback so that the ultimate aim of the software is realized in an effective and efficient way.

Apart from this we made it a point to get to the root cause of any problem that we came across by asking “why” 5 times.

Conclusion

To conclude I would say that we are still learning. The lean production metaphor has been successfully applied to software offshoring but it can be improved. The Toyota principles when applied to software offshoring can make remarkable differences to the way software is being developed and offshored. We are trying to continuously improve and reach our goal of ‘Whitebox Lean Agile Offshoring’ in which transparency and quality are taken to the extreme.

As an advice for the offshoring industry, follow Scrum with the Toyota principles in spirit without diluting their essence. Apply them to your way of working and see the magic unfold.

vikas_grayemboss.jpg

About these ads
Posted in: Agile, Scrum