Shinetech's insights on offshore softare development, company operation

You will learn our best practices of offshore collaboration, business value delivery and how our company works.

Shinetech Agile Delivery

By John Vanderpool on July 24th 2017

Do you know what is the number one thing that employees want most at work? It is that they matter. **Gallup polls (

Jerry had shared an article last week that reflected on a change that is happening in companies where traditional management methods (arising from the Industrial Era) are being changed to a more people-focused approach. Traditional management would create a whole bunch of rules for people to follow and drive people to deliver on what management wanted (or needed from a profit perspective). People were treated as machines and expected to have an output that would meet certain criteria. This type of management 'pushes' team members in a certain direction rather than allowing the team members to move in a natural direction of their choosing and unique talents. Traditional management does not allow for freedom of expression or work and really is a matter of control. As with most models, change is eventually necessary. As humans continue to learn and grow from past experiences, it becomes necessary to adjust towards a better and more suitable model that allows people the freedom and engagement that they desire so much.

As we shift towards a new model, it is the power within that we need to embrace and promote. We have entered what is known as the 'feedback economy'. Buyers are able to quickly provide feedback on products and services they have received as well as the ability to see and review feedback before they purchase. Buyers are able to engage directly and sellers can no longer hide the issues. This shift brings about a transparency and honesty that previous traditional models did not allow. Companies used to be able to hide their problems easily but the 'feedback economy' exposes these issues and helps the organizations to face their challenges head on. One of the key characteristics of agile delivery is the incorporation of feedback throughout the delivery process. The ability to incorporate feedback loops helps to embrace change so the outcome is useful and what the end user actually needs. At Shinetech, our model allows our team members the ability to interact directly with our clients and also provides a means of feedback for the client to openly share. Our team members are able to join in the planning of work, share opinions, promotion of ideas and freedom to explore options as well as directly see feedback for their accomplishments and work. This helps our team members to be engaged, provides a means for continuous improvement, and helps our team members to feel that THEY are in control of the outcome and not performing for some distant management model. Engaged team members are able to quickly see and know that their work matters...not only as a team member of Shinetech but as a human being.

Everyone wants to believe that their work matters. Humans want to feel needed and valuable and if we create that type of an environment, then our people will WANT to engage. If we have an environment where team members can openly share their opinions, work together to help each other solve challenges, have a sense of belonging and a part of something that they are actually helping to build (and get the reward for directly), then we are able to transform the traditional command and control management and outsourcing models to people driven success and freedom. This helps the environment to not only be engaging but helps 'work' to actually be enjoyable and fun. Can you imagine work to be 'fun' :-)?

I am very excited for the new direction of Shinetech and where this is headed. Our people are the catalyst for change and we have a very bright future!!

Something You Don't Know about ODC Service

By Deshui Wang on Mar 13th 2017

For our company, ODC accounts for a large proportion of our entire company's business, and most of the business that our branches perform is ODC as well. But do every one of us have a correct and proper understanding of ODC project? I do not think so, which is why I am writing this article and to share my understanding of ODC. In this article, our engineers can learn what ODC is; and on the other hand, our customers can also learn what the real ODC service is, its advantages and the potential consequences if not handled properly.

Some one-sided understanding of ODC

There are some explanations of ODC which can be heard inside the company, such as:

• ODC is Paid on a monthly basis

In my opinion, paid on a monthly basis is only a form of payment for ODC. It is not a service at all.

• ODC is Paid by time

This is also a one-sided understanding. One hour, one month or one year, they all are time. But if the service requires only a couple of days, could it be called ODC? I do not think so.

• ODC is Offshore Development Center

This explanation is too "shallow". Offshore development center, offshore research and development center, if we understand it this way, then ODC is merely an offshore office!

What is ODC really?

For our company, I think ODC is a form of cooperation. Its output is a kind of service, and the service could be the delivery of the following:

• Software - high quality software

• Consulting services - enterprise information (software project establishing, planning, vendor's evaluation etc.)

And the main factors to deliver a good ODC service should include:

• O (Open): both sides need to be open and transparent. This is the only way for trust building and better information sharing.

• D (Development): this is the implementation process of software development or of consulting services.

• C (Cooperation): cooperation. We all know customer cooperation is better than contract negotiation.

What are the advantages of ODC service?

I think ODC has some very important advantages:

• For software development, the requirements are often difficult to be fixed, especially in a time of rapid change. Once the requirements are fixed, the competitiveness will be lost. Take mobile phone development for example. If you define a mobile phone at the beginning, and develop it strictly in accordance with the plan, then when your mobile phone comes into the market one year later, you will find most of the mobile phones have the fingerprint feature, but yours don't. So your phone will lose all its competitiveness and all your hard work will be wasted.

• ODC contract is generally more suitable for long-term customers. It can make the team members more stable and serve the customers on a long time basis, consequently greatly reducing the risk of the software.

• The payment term of ODC is on a monthly basis, which can significantly reduce the risk of customers' costs and preserve cash flow.

• The delivery of ODC is mostly incremental. For instance, one iteration per 2 weeks allows the customers to detect problems and give feedback for improvements as soon as possible. In some cases, even to terminate the project at an earlier stage to reduce losses..

• For ODC service, both sides of customers and vendors need to see each other as their colleagues, open (O), cooperation (C), no information hidden; both sides share the same goal: to deliver a better software product.

• ODC is more likely to inspire the creativity of both sides, instead of focusing on the function defined at the beginning and KPI (Kill people idea), ODC can help you realize business value is a far more important thing.

• ODC provides more time for developers to continually enhance their understanding of the customers' business areas, so that to deliver better software products and services.

• ODC makes it easier for vendors to work out the plans, and let developers focus more on one client's project instead of working on a couple of projects at the same time as some other software vendors usually do.

• ODC projects are also easier for the company to plan the developers' personal development, so that to increase their recognition of the company. And a company that can retain talents is certainly able to provide better services.

We have used ODC to successfully deliver a large number of projects and the benefits of ODC are far more than the items mentioned above. But as one type of the cooperation model, what ODC can do is still relatively limited; it's not that easy to deliver a high quality service under ODC model.

What are the disadvantages of ODC service?

ODC model of course has many advantages, but at the same time, there are also many disadvantages. One of the biggest advantages of ODC is stable developers, you can keep developers, but at the same time this just happens to be the biggest problem:

• The project cycle is too long and the developers feel bored
Some projects have been developed for a long time, such as more than 5 years, which makes the technologies the developers have been using out of date. Although it's not a problem for the project the developer is working on, it emerges when the developer discusses the issues with other developers. They will realize their skillsets are getting old, which will easily cause them to be impetuous.

But in fact, there are several ways to solve this problem:

o Use new technologies in the existing projects.

o Use new technologies for some features or subsystems, such as using NoSQL, Elastic Search, Cloud and other new technologies. In addition to improving system performance and reducing maintenance tasks, the developers can also learn a lot of new things.

o Replace part of the team members: add some new members to the project, and send some old members to other projects.

However, all the above changes require strong support from the customers; it's very difficult for vendors to make changes unilaterally.

• The price of the quote is increasing too slow to meet the expectations of developers

This is also a common problem. The developers want a salary increase every year, but most developers' salary increase is based on the value/income that the developers bring to the company, that is the quote.

There are also three ways to solve this problem:

• Reduce profits

• Customers accept the corresponding quote increase

• Developers leave the project

If developers' productivity is not reduced (theoretically, it shall be improved every year, as developers are more familiar with the technologies and customers' business), I personally think the second method is the most cost effective choice for customers.

• Work efficiency is reduced as developers have been working on one project for a long time

When we are good at some skillsets, we can finish a piece of work which required 8 hours within 6 hours. Although at some level the output does not change, but for a long time, we'll become negative. And when we work in a negative mood, we cannot produce a good output even with a little bit of a new challenge.

The only solution for this problem, I think, is to replace THE developer!

• Too comfortable to learn new things

If a developer works on an ODC project for a long time, they will not feel much pressure, which will easily lead them into the comfort zone. And if they stay too long in the comfort zone, they might not be able to adapt to the new work pace, accept new knowledge or lose learning ability if they are transferred to a new project.

The solution for this problem is to constantly improve our quality and efficiency of ODC service by adopting the correct and appropriate development process.


Simply put, here are some last important factors:

• ODC is not selling Time, it's the Service

• ODC is only a type of cooperation model

• The output of ODC is Service (software or consulting service)

• The main purpose of ODC is to improve quality and efficiency, not to make more money, making more money is only an accessory of ODC

• ODC is the foundation for better employee development planning. Only when the employees are happy, they can deliver a good job and keep the customers happy

Discussion about Shinetech’s Value

By Jerry Zhang on Aug 28th 2016

Last month, we had some discussions with the Shinetech branch managers and they have put forward some questions on our mission and vision. It is good to talk about these topics, because it urges us to think more deeply about our mission and vision.

Here are the questions:

• If our mission is to promote the developers, and this could be a relatively clear direction for the company's management team, what should the developers do?

• If our company value puts the developers in first place, then what should the developers pay attention to?

First, I would like to talk about the concept of mission, vision and value, to make sure that we share a common understanding.

The mission of a company is the meaning of existence of the company. The question that a company's mission needs to answer is why do we build the company? Is all our hard work only for surviving?

Vision is the small goal set for achieving the mission; it's a periodic goal. If the mission requires decades of effort to realize, then the vision is the small goal which can be achieved within a few years.

Value is the concept or a number of code of conducts for realizing vision and mission; it can also be seen as the methods and means to achieve vision and mission.

The company without mission can easily turn into a profitable machine. I have a friend who is the owner of an enterprise, and he complained to me one day that he felt exhausted about having to explore new projects every day. Actually, I have ever had the same confusion. The original intention of building the company was to make more money, until I found the core driving force for sustainable development of the enterprise. This is namely that every developer should have space to develop and make money. We have tried many methods to help developers benefit from the company development at the same time they are making contribution to it, such as: significantly increased the developers' salaries, encouraged and developed branch offices, established overseas branch offices, encouraged developers to work abroad, tried different models (partners and delivery centers) etc. Shinetech's development process is parallel to the development process of our developers. We summarized all the methods as our mission, which is to enhance and reflect the value of developers.

In order to make our mission more concrete and effective, I have added one more sentence on the basis of the current mission: enhance and reflect the value of developers, and promote change in China's software industry. If we want to change the world, we have to change ourselves first. Only when the developers keep improving, change of the software industry can happen and therefore produce software that can create better value for users.

It's not only the technical capacity of the developers that we look to change while cultivating and improving them, more importantly, it is the awareness of software. These changes will eventually affect the entire software industry. And I hope this could be the direction that every Shinetech developer strives for.

As a small periodic goal, our vision is to build a company that is most suitable for developers to work in. This seems significantly different from the impression of a traditional outsourcing company. But if you must classify us as an outsourcing company, then we will have to subvert the impression of the outsourcing business in people's minds. But how?

Considering the development of developers as the cornerstone of the development of the enterprise, this can be seen as "developers first". Any enterprise's development strategy is ultimately an extension of its employees' development strategy. By training and providing opportunities, we can help our employees to upgrade and develop their abilities to their full potential. These abilities can only be accumulated and reflected in the process of creating value for customers, not by simple learning. People can only gain knowledge and skills by simple learning, and knowledge and skills are only the tools for problems solving and value creating. And it is only when you make good use of the tools to solve the problems you achieve value creation in the process.

In addition to "developers first", Agile Manifesto itself is a set of values, and is also an important part of the value of Shinetech. Agile Manifesto will not be explained in details here, but I hope the following four core values can be remembered:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The above four values can be applied at any time in our work, not only in software development, but also in company's daily management and operation. Agile is (i) an advanced concept which combines Western civilization and ancient oriental wisdom, (ii) a human-centered development concept and value, and (iii) in high coincidence with the values we want to express.

Software Development Project Management: The importance of the project leader

By Deshui Wang on Jan 5th 2016

It has been a long time since I have received this request to write an article about the importance of the project leader in software development project management. Before expounding on this subject, first, I would like to clarify the two words in the title. One is Management. It is often regarded as taking charge of the people: authority. The other is Leader. The leader in a software development team is always referred to as the project manager: the authorities. Those meanings are the things I always intend to mitigate when I act as a project manager. To my understanding, Management means managing the development team, and Leader means leading the developers, or setting an example for the developers.

Now, let's get back to the topic of the importance of the project leader. In my opinion, the project leader is likely to be the combination of Scrum Master and Agile coach. From the beginning I would say that everyone plays an important role in the software development project. This article focuses on how important the project leader is; likewise, we can write another article to discuss the importance of the developer. As Agile development is becoming popular these days, people get to know "self-organized development team" and the project leader is considered as unnecessary in an self-organized team. However, I don't agree. It is a misunderstanding of Agile, especially in the software development industry. In a profitable IT company, it is impossible to build a self-organized development team from the start. It takes a long time for the project leader to assist the team step by step: from team building, communicating and collaborating, to delivering the high-efficient work. There is a lot of work for the project leader before the team achieves high-efficiency, while the team is concentrating on two key points in software development management: Quality and High-efficiency.

Next, I want to talk about the responsibilities of the project leader from my own experience.

Firstly, building a team. As is known to all, a project leader is often the first member of a team, rather than adding a project leader to a team already consisting of several developers. The project leader also needs to know what technologies are used in the project and what developers are suitable for the project in the early phase of teambuilding.

Secondly, creating a good team culture. Whether actively cultivated or not, a team has its own culture. Therefore, as a project leader, you are required to build a good team culture. For example, team members should be honest and transparent. The project leader should be open to being challenged from other team members. The team members should learn and share with each other.

Thirdly, serving as the Agile coach.

a. Help the team to define an appropriate development process, for instance, starting from a basic procedure, and then making improvements gradually

b. Establish code standard and make team rules

c. Improve quality awareness of software delivery in the team, proposing TDD in the project (Test-Driven Development)

d. Lead the team members to be self-managed

e. Train the team members to become efficient, with the increased use of CI (continuous integration) and automated scripts

f. Co-ordinate project resources and shield the team from external disturbances

g. Make the team members think in the clients' business pespective and help the clients to solve the business problems

Fourthly, quick response to clients, and actively solve the problem.

Last but not least, there is much more to do before a team becomes self-organized. Just like how there are no two identical leaves in the world, different teams cannot not developed in the same way, and the importance of the project leader is to make adjustments according to various situations.

Confused "Agile"

By Jerry Zhang on Feb 26th 2015

Agile is not just a methodology, it’s a kind of attitude or philosophy for thinking and doing things.

The reason that our company no longer emphasizes agile is because we found most people view it as a process, and go into the wrong direction. What's agile? Simply put, agile means everyone in the team working independently and creatively.

Scrum causes more misunderstanding about agile. Scrum looks easier to understand, especially for people who are used to working with waterfall software development process. But as a matter of fact, agile is not the same kind of process as Scrum, and that is why Martin Fowler (CSO of ThoughtWorks) doesn't consider Scrum as agile.

Team members who are able to work independently and creatively could use Scrum as an incremental process, but that does not imply the whole team is agile. Agile is a way of placing emphasis on empowering teams to communicate, self-organise and collaborate in order to deliver the best possible solutions. If people do not really understand and accept the concept of agile, but merely use Scrum as process, it can cause many struggles and issues in the real world. Unfortunately, I have seen this happen again and again.

In these days, Shinetech doesn't speak about agile that much but does things in an agile way. Because we believe people could be influenced, and it is one of the best ways for them to understand and accept agile. We are trying to build an environment for agile to survive and grow. Forcing people to use a process may be a fast way, but will, in fact, make the situation worse.

As an organization, if we want to be "agile", we have to focus on the growth of our developers/employees, we can't just ask for the "results' or profits from the employees, this is the vision and value we acknowledge. If the result is bad, but it's good for our employees to grow or become more independent, we are happy to accept it. But instead, if a PM forces the team to work overtime for the so-called "good result", they will not get any support from the company. Because as I have mentioned before, we view our employees as the top priority, customers as the second and shareholders of the company the last.

If our management can help our employees to be more independent and creative, then it is a good agile management. But if we manage people like a production line in a factory, then we will lose all of our advantages and cannot compete with any of the larger outsourcing companies in India or China.