In years of researching and practicing in cooperation with our clients, we found in 2006 that Agile development is conducive to successful offshore collaboration.
Agile is not a development methodology. It's the spirit and consciousness of collaboration. It aims to eliminate the influence brought in by culture difference. Only with such spirit and consciousness can developers serve clients in a satisfying way.
Shinetech provides veteran Agile developers that are honest, transparent and quickly responsive. We learn about Agile development, appreciate it and share our appreciation with each other; Agile is used in projects, interviews and even daily life at Shinetech.
The following are what we value when applying Agile practices in projects:
Work like we're in the same room as clients
At Shinetech, the development team and the clients may be separated by the ocean, but we implement practices that make it seem like we're in the same room.
Daily instant communication
- Voice or video call for daily SCRUM meeting usually lasts 20 minutes.
- GoToMeeting, TeamViewer, and remote computer control are commonly used to make demos.
- We work on the client side for one month or more to start the collaboration more efficiently.
Continuous integration and continuous delivery
Most of our teams have built a server for continuous integration, through which the client can easily get a daily version of development update by themselves. Some teams also run continuous delivery, for which the system is designed with plug-in. The team finishes subsystems as plug-in units and integrates them into the working system in sprints.
Team rules contribute to build a self-organizing team
Many clients complain when they find problems in deliveries and cannot solve them immediately because their offshore developers have been off work. At Shinetech, we set a rule in some projects under which developers work for seven hours during the daytime and separate 0.5 hour at early morning and night to communicate and solve clients' problems.
- The team member must reestimate a story before the middle of the sprint.
With this rule, the Scrum team perceives and resolves issues in advance. The high-priority stories/coarse story are better-understood and estimated and finished successfully within sprints.
- Unused code or commented code should be deleted before committed to SVN.
One of our teams made it a rule for that unused or commented code was not convenient for them to understand each other. They worked overtime one day and deleted all old commented code.
- No task takes more than six hours.
The rule is created by a team consisting of two developers. Under the rule, their work has been easily verified and estimated and is more transparent
We don't follow an unchanged process but rather define some rules in projects as they're needed. The rules are followed by the whole team to make continuous improvement. The following are some rules we have made in some projects:
Good coding style and teamwork
In Shinetech, our engineers are all good at design pattern and have perfect coding style. The system architecture is not built by an individual person but rather the effort of the whole team, which benefits us a lot.
We ever have an SA who used Smart Client Software Factory for MDI System, but after two months, his team found some problems between SCSF and WPF modules. He and the team then decided to change SCSF to MEF. Thanks to our working method, the system has been running very well to date.