Case study: Yunian Ma's story about working with two of his clients

Yunian joined Shinetech in 2007, having worked as a developer for an American software company. He has undergone regular training and participated in Scrum teams in which he continues to absorb knowledge from clients, colleagues, and books.

With regards to his professional development in Shinetech over the past few years, he acknowledges the importance of two main Shinetech clients: one involved his introduction to Scrum with which he worked for 1+ years, and the other, a client with which he grew to be a true Scrum Master. The following illustrates Yunian's Shinetech story:

Greg was one of us! (1+ years, 5 developers, Scrum)

A Swiss company that needed to develop a system to process large amounts of data for its clients had to date, cooperated with a Bulgarian supplier but was dissatisfied with the development costs and poor quality. The main contact on the client's side was Greg and he requested us to build a five man team (1 lead developer + 3 developers + 1 tester) to assist in architecture optimisation and BI system completion.

The whole Shinetech working process is managed smoothly in accordance with basic Scrum principles: Each of our developers is self-organized and accountable, through unit testing, for the efficiency and quality of his own work.. The tester is involved in requirements analysis, she manages the test strategy/ plan herself. The output from Greg is a continuously updating task list, according to which, we prioritise, and modify the sprint plan. Then for each sprint, we discuss the estimates, confirm the sprint backlog and deliver an incremental workable demo. Greg and his CEO are very happy with each demo delivered and believe “…we have a very great future in front of us…”

But that is not the all, the biggest accolade for the Shinetech team in my opinion is that we have learnt to think and act on behalf of the client: improving our problem solving capabilities and value add.

Try another way to select developers

Greg is a professional software development manager. He knows clearly what kind of developers are fit for his purposes and is very rigorous when recruiting new developers to his team. Most of the candidates we put forward, failed to answer his technology related questions --- team building was delayed. Technical ability is most definitely important but it is not everything a good developer requires. We proposed to trial each candidate with at least one iteration. Following this approach one of the developers that had been previously eliminated was hired for his ability to demonstrate Agile thinking whilst being trialled in the project team.

We allow for low efficiency

One of the team members was a new employee for Shinetech who consistently over estimated his development efficiency at 8 hours per day, when in fact it was only 4~5 hours --- he was always having difficulty in completing tasks on schedule. I discussed the developer's situation with Greg, and we agreed to conduct daily review meetings with the new team member so that everyone could advise and comment on his iteration progress. Very quickly our new team member learnt how to overcome his efficiency problems, and improved to 6~7 hours in the following days.

6 hours' efficiency could be improved!

After months of cooperation with our client, our average efficiency had stabilised at 6 hours per day, with which Greg was very satisfied. But through team discussion (Greg included), we learnt that our internal communications had become too frequent and some team members believed that interruptions were lowering development efficiency. So we agreed to implement a ‘silence time' of 2.5 hrs every afternoon during which all the email and instant messaging applications were exited, everyone was to concentrate on his work. Internal communications and that with Greg was allocated to an agreed morning slot. The result is a remarkable improvement in efficiency of 0.5 hour per developer.

Greg is one of us！

This is what we are most proud of! The whole team ‘Jelled' in the 1+ years' cooperation; all members (including Greg) enjoyed working with each other. With each new requirement discussion, experience sharing, problem solving and even dinner party, we further developed mutual trust and understanding.

The client ultimately concluded its development investment and the team was disbanded. but all of us (including Greg) expect to work together again some day to share the accomplishment of achieving the same levels of excellence.

With Mark, I have applied scrum practices flexibly (6 months to present, 3 developers)

Mark is a contact at an Australian client. He is a certified Scrum Master with rich experiences in offshore management. He was looking for eZPublish resources for one of its product developments under Scrum.

Since the hired developers are new employees for Shinetech who have no Scrum experience, I acted as a part time scrum master giving training to the whole team during the initial 2~3 months, coordinating the working process.

There are two roles on the client's side: a scrum master and a business analyst responsible for the design of user stories and the prioritizing of iterations for the Shintech team to estimate and implement one by one.

Free knowledge transfer period for inexperienced developers

Yes,we carried the cost for the inexperienced developers. Mark required three eZPublish developers as a start, but only one of our recommendations gets selected and hired on schedule since eZpublish is relatively new in China. We suggested trialling capable PHP developers with and agreed training schedule. Issues were soon raised as anticipated: developers learning was too slow, giving rise to poor quality & low efficiency. Again following discussion with Mark I introduced two new developers and offered free work until the new PHP team members learnt how to handle eZPublish efficiently.

Quality is guaranteed without Unit Testing

Unit testing is an efficient way to guarantee quality, but it is not the only way to guarantee quality, especially when developers do not understand how to execute it efficiently. Mark and I believed that our developers were good self-organizers; they could make quality deliveries by focusing on alternative methods, such as review meetings, good coding habits, adequate testing, and even delay of following stories. As a result and with due consideration of expected development efficiencies and schedule requirements, we decided to place the responsibility with each developer himself. This innovation has proven to be effective and Mark is satisfied with the quality of each subsequent iteration.

Chinese communication is allowed in standup meetings

The daily stand-up meeting with our clients is essential for effective internal and external team communications and problem resolution. I had noticed that spoken English communication was really a challenge for some of our developers, so the main method during the initial project days was to use Skype: a combination of typing and spoken English which required 1 hour meetings every day. This was a poor use of client's time so I proposed to Mark that we use Chinese communication for that part of the meeting covering internal team discussions. This idea alone has led to a 50% reduction in meeting times.

I really appreciate that Mark is very open to such ideas and it is through constant discussion and brainstorming with our clients that we at Shinetech can always find new and better ways to deliver our services.